From owner-ipng Wed Feb 1 01:39:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19580; Wed, 1 Feb 95 01:39:25 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19574; Wed, 1 Feb 95 01:39:13 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id BAA18808; Wed, 1 Feb 1995 01:32:42 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA10163; Wed, 1 Feb 95 01:32:33 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) ICMP security issues To: ipng@sunroof.Eng.Sun.COM Date: Wed, 1 Feb 1995 09:32:59 +0000 (GMT) In-Reply-To: <199501312153.NAA05341@elrond.ss-eng.eng.sun.com> from "Dan Nessett" at Jan 31, 95 01:53:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The most fundamental issue is whether ICMP messages need to be authenticated or > not. I think most would agree that at least some types should be authenticated. > Whether or not there are situations in which some may also need to be > confidentiality protected (i.e., by placing them in an ESP protected message) > has not been discussed. I have no doubt that they must. I've run an Efnet irc server for a while and every so often someone thinks "port unreachable" spoofs are funny. > However, the amount of data necessary for these attacks is usually very > large and so it would be fairly impractical to use echo in this way. If an ICMP reply is only authenticated/encrypted when the request is you can't do it at all. > o Finally, in a global internet we must engineer the ICMP protocols so that > vendors can economically supply implementations that meet various export > control restrictions as well as use restrictions on cryptographic > technology within certain countries. At a minimum the standard should > not require a conforming implementation to provide encryption of ICMP > data, if that is ever considered useful. Very very important indeed. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 1 08:59:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19841; Wed, 1 Feb 95 08:59:12 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19835; Wed, 1 Feb 95 08:59:05 PST Received: from elrond.ss-eng.eng.sun.com by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA29039; Wed, 1 Feb 1995 08:52:32 -0800 Received: by elrond.ss-eng.eng.sun.com (SMI-8.6.9/SMI-SVR4) id IAA05801; Wed, 1 Feb 1995 08:52:29 -0800 Date: Wed, 1 Feb 1995 08:52:29 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199502011652.IAA05801@elrond.ss-eng.eng.sun.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP security issues X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From iialan@iiit.swan.ac.uk Wed Feb 1 01:33:57 1995 > Subject: Re: (IPng) ICMP security issues > To: ipng@sunroof.Eng.Sun.COM > [text deleted] > > > However, the amount of data necessary for these attacks is usually very > > large and so it would be fairly impractical to use echo in this way. > > If an ICMP reply is only authenticated/encrypted when the request is you > can't do it at all. True. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 1 12:00:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19950; Wed, 1 Feb 95 12:00:31 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19944; Wed, 1 Feb 95 12:00:24 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA18247; Wed, 1 Feb 1995 11:53:50 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA25974; Wed, 1 Feb 95 11:53:46 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14526(6)>; Wed, 1 Feb 1995 11:53:29 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Wed, 1 Feb 1995 11:53:21 -0800 To: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com Subject: Re: (IPng) Re: interim IPng WG meeting -- attendees In-Reply-To: deering's message of Thu, 26 Jan 95 14:24:12 -0800. <95Jan26.142419pst.12174@skylark.parc.xerox.com> Date: Wed, 1 Feb 1995 11:53:14 PST From: Steve Deering Message-Id: <95Feb1.115321pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Here's the current list of attendees for the IPng + addrconf + ngtrans meeting on Feb 9 & 10 at PARC, updated according to messages I've received since my last posting. Please send me any additional corrections. Jim Bound Scott Bradner Ross Callon Graham Campbell Ping Chen Alex Conta Mike Davis Steve Deering Phil DeMar Barbara Denny Ralph Droms Bob Fink Rich Fox Bob Gilligan Heather Gray Tony Hain Tim Hartrick Dimitry Haskins Wayne Hathaway Marc Hasson Bob Hinden Wan-yen Hsu Allison Mankin Joachim Martillo Greg Minshall Dan Nessett Erik Nordmark Bill Nowicki Michael Reilly Steve Russell Bill Simpson Frank Solensky Rob Stevens Sue Thomson John Veizades Justin Walker Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 04:15:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20543; Thu, 2 Feb 95 04:15:24 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20528; Thu, 2 Feb 95 04:15:01 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA29092; Thu, 2 Feb 1995 04:08:27 -0800 From: Telford001@aol.com Received: from mail04.mail.aol.com by Sun.COM (sun-barr.Sun.COM) id AA19629; Thu, 2 Feb 95 04:08:27 PST Received: by mail04.mail.aol.com (1.37.109.11/16.2) id AA057306621; Thu, 2 Feb 1995 07:03:41 -0500 Date: Thu, 2 Feb 1995 07:03:41 -0500 Message-Id: <950202070339_10812899@aol.com> To: snmpv2@tis.com, snmp@psi.com, egypt-net@cs.sunysb.edu, iab@isi.edu, ietf@cnri.reston.va.us, anf-announce@netcom.com, anf-disc@netcom.com, ipng@sunroof.Eng.Sun.COM, rolc@maelstrom.acton.timeplex.com, cisco@spot.colorado.edu, jcurran@nic.near.net, nomcom@nic.near.net Cc: Telford001@aol.com, Joseph_S._Ayoub@gmlaw.com Subject: (IPng) Announcement Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As of January 26, 1995, Joachim Martillo (Joachim Carlo Santos Martillo Ajami) formerly Manager of Internetworking Research at Penril Datability Networks 190 North Main Street Natick, MA 01760 Corporate Headquarters 1300 Quince Orchard Boulevard Gaithersburg, Maryland 20878-4106 no longer works for Penril Datability Networks. Joachim Martillo may be reached as follows: Voice: 617-298-4107 E-MAIL: martillo@delphi.com US-MAIL: 15 Pleasant Hill Ave Dorchester, MA 02126-2813 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 04:15:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20542; Thu, 2 Feb 95 04:15:23 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20526; Thu, 2 Feb 95 04:14:59 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA29089; Thu, 2 Feb 1995 04:08:26 -0800 From: Telford001@aol.com Received: from mail02.mail.aol.com by Sun.COM (sun-barr.Sun.COM) id AA19625; Thu, 2 Feb 95 04:08:26 PST Received: by mail02.mail.aol.com (1.38.193.5/16.2) id AA01085; Thu, 2 Feb 1995 07:08:42 -0500 Date: Thu, 2 Feb 1995 07:08:42 -0500 Message-Id: <950202070838_10813016@aol.com> To: snmpv2@tis.com, snmp@psi.com, egypt-net@cs.sunysb.edu, iab@isi.edu, ietf@cnri.reston.va.us, anf-announce@netcom.com, anf-disc@netcom.com, ipng@sunroof.Eng.Sun.COM, rolc@maelstrom.acton.timeplex.com, cisco@spot.colorado.edu Cc: Telford001@aol.com, Joseph_S._Ayoub@gmlaw.com Subject: (IPng) Severance of Relationships Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As of January 26, 1995, Telford Tools, Inc., formerly known as Tudor Technology, Inc. a Massachusetts corporation in good standing, which was founded in 1993 by Joachim Martillo and which sells services related to software development and network debugging as well as communications equipment has severed all relationships with Penril Datability Networks, Penril Datacomm Networks, Inc and Penril Datacomm, Inc. All inquiries should be directed to: E-Mail: Telford001@aol.com Voice: 617-298-1617 FAX: 617-298-1745 US-MAIL: 17 Pleasant Hill Avenue Dorchester, MA 02126-2813 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 04:29:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20560; Thu, 2 Feb 95 04:29:53 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20554; Thu, 2 Feb 95 04:29:46 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA29365; Thu, 2 Feb 1995 04:23:13 -0800 Received: from cps203.cps.cmich.edu by Sun.COM (sun-barr.Sun.COM) id AA21191; Thu, 2 Feb 95 04:23:11 PST Received: (from wilson@localhost) by cps203.cps.cmich.edu (8.6.9/8.6.9) id HAA09929 for ipng@sunroof.Eng.Sun.COM; Thu, 2 Feb 1995 07:23:09 -0500 From: Brad Wilson Message-Id: <199502021223.HAA09929@cps203.cps.cmich.edu> Subject: Re: (IPng) Severance of Relationships To: ipng@sunroof.Eng.Sun.COM Date: Thu, 2 Feb 1995 07:23:09 -0500 (EST) In-Reply-To: <950202070838_10813016@aol.com> from "Telford001@aol.com" at Feb 2, 95 07:08:42 am X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joachim: Come on ... what it REALLY necessary to make some people who PAY for email to read that you had quit? Twice? -- Brad Wilson Crucial Software Share and Enjoy! msg++; smiley++; Internet: wilson@cps201.cps.cmich.edu Speaking for myself and myself alone ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 04:53:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20575; Thu, 2 Feb 95 04:53:42 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20569; Thu, 2 Feb 95 04:53:34 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA29885; Thu, 2 Feb 1995 04:47:01 -0800 Received: from cps203.cps.cmich.edu by Sun.COM (sun-barr.Sun.COM) id AA23938; Thu, 2 Feb 95 04:47:00 PST Received: (from wilson@localhost) by cps203.cps.cmich.edu (8.6.9/8.6.9) id HAA09967 for ipng@sunroof.eng.sun.com; Thu, 2 Feb 1995 07:46:58 -0500 From: Brad Wilson Message-Id: <199502021246.HAA09967@cps203.cps.cmich.edu> Subject: (IPng) Apologies for not checking header... To: ipng@sunroof.Eng.Sun.COM Date: Thu, 2 Feb 1995 07:46:57 -0500 (EST) X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ARGH! Gotta check my header better... guilty. ;-( Sorry, that last message was meant to be sent privately. Sorry... Brad ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 06:48:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20609; Thu, 2 Feb 95 06:48:46 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20603; Thu, 2 Feb 95 06:48:39 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA03042; Thu, 2 Feb 1995 06:42:05 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA08406; Thu, 2 Feb 95 06:42:04 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA29176; Thu, 2 Feb 95 08:57:52 CST Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA08349; Thu, 2 Feb 95 08:41:37 CST Date: Thu, 2 Feb 95 08:41:37 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9502021441.AA08349@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Severance of Relationships Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Like, why do I care, you worthless little vandal? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 07:40:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20664; Thu, 2 Feb 95 07:40:10 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20658; Thu, 2 Feb 95 07:40:03 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA05069; Thu, 2 Feb 1995 07:33:29 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA17412; Thu, 2 Feb 95 07:33:28 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA29996; Thu, 2 Feb 95 09:49:08 CST Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA09685; Thu, 2 Feb 95 09:32:53 CST Date: Thu, 2 Feb 95 09:32:53 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9502021532.AA09685@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) apologies from me too - Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Much as I hate to add spam to the list, I need to point out for the record that my previous note was intended as private email, and in NO WAY reflects the opinions of network systems corp. It was mere unprofessional, personal, private, irritation on my part. Andrew Molitor ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 08:30:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20688; Thu, 2 Feb 95 08:30:36 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20682; Thu, 2 Feb 95 08:30:29 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA07436; Thu, 2 Feb 1995 08:23:54 -0800 Received: from ecbull.frec.bull.fr by Sun.COM (sun-barr.Sun.COM) id AA27338; Thu, 2 Feb 95 08:23:50 PST Received: from scxel3.frec.bull.fr by ecbull.frec.bull.fr; Thu, 2 Feb 1995 17:21:31 +0100 (MET) Received: by scxel3.frec.bull.fr; Thu, 2 Feb 95 16:25:05 GMT (MET) From: domine@scxel3.frec.bull.fr (Anne Domine) Message-Id: <9502021625.AA11478@scxel3.frec.bull.fr> Subject: (IPng) Cluster Adress To: ipng@sunroof.Eng.Sun.COM Date: Thu, 2 Feb 1995 17:25:03 +0100 (MET) X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hello, Could someone explain me what are exactly cluster adresses and how they will be assigned ? Thanks. -------------------------------------------------------------------------- Anne Domine ENSIMAG Student (Informatics & Applicated Mathematics) , Grenoble (France) Email : Anne.Domine@ensimag.imag.fr domine@scxel3.frec.bull.fr -------------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 08:59:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20737; Thu, 2 Feb 95 08:59:02 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20731; Thu, 2 Feb 95 08:58:54 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA09107; Thu, 2 Feb 1995 08:52:19 -0800 Received: from ecbull.frec.bull.fr by Sun.COM (sun-barr.Sun.COM) id AA02518; Thu, 2 Feb 95 08:47:02 PST Received: from eliane.frec.bull.fr by ecbull.frec.bull.fr; Thu, 2 Feb 1995 17:42:37 +0100 (MET) Received: by eliane.frec.bull.fr; Thu, 2 Feb 95 16:41:07 GMT (EET) From: M.Habert@frec.bull.fr (Michel Habert) Message-Id: <9502021641.AA22936@eliane.frec.bull.fr> Subject: Re: (IPng) Cluster Adress To: ipng@sunroof.Eng.Sun.COM Date: Thu, 2 Feb 1995 17:41:04 +0100 (MET) In-Reply-To: <9502021625.AA11478@scxel3.frec.bull.fr> from "Anne Domine" at Feb 2, 95 05:25:03 pm X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From owner-ipng@sunroof2.Eng.Sun.COM Fri Oct 21 11:26 GMT 1994 Received: from Sun.COM by ecbull.frec.bull.fr; Fri, 21 Oct 1994 12:25:10 +0100 (MET) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA10315; Fri, 21 Oct 94 04:27:01 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA27660; Fri, 21 Oct 94 04:26:06 PDT Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16631; Fri, 21 Oct 94 04:27:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16625; Fri, 21 Oct 94 04:27:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29784; Fri, 21 Oct 94 04:23:36 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA09973; Fri, 21 Oct 94 04:23:35 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA00981; Fri, 21 Oct 1994 12:26:11 +0100 Message-Id: <199410211126.AA00981@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Terminology - Cluster Address In-Reply-To: Your message of "Thu, 20 Oct 1994 14:20:18 +0100." <19063.9410201320@raft.spider.co.uk> Date: Fri, 21 Oct 1994 12:26:10 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Status: RO Andy, The "semi-random routing" which has you baffled is the very definition of today's IP service. When you send a packet through the Internet today, you generally do not know where it will go through. Routing tables may change, so that the next packet does not quite follow the same route as the preceeding one. Even if routing tables are stable, routers may do "load splitting" between "equal length routes" - both IGRP and OSPF have provision for that, one could in fact even do it with RIP. There are cases when the user wants to specify the routing. Today, this can be done via source routing mechanism, e.g "go from A to B through C". The problem is that, in many case, source routing through a host may be an overspecification: you want for example to say "use provider X", not "use router Y of provider X". SDRP includes a "routing through an AS" feature that is an example of a response to this problem. Cluster addresses are generalizations of this principle. They are primarily to be used as elements of source routes, to assert that you want to "route through cloud X". The source route will be "progressed" by the first router within cloud X that the packet reaches, effectively a "border of cloud X" since the previous router, by definition, was not a member of that cloud. Usage of cluster addresses within source routes, and the relation with "probe" and 'set up" procedures, should be discussed as part of "SDRP for IPv6". Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com >From owner-ipng@sunroof2.Eng.Sun.COM Wed Oct 19 06:32 GMT 1994 Received: from Sun.COM by ecbull.frec.bull.fr; Wed, 19 Oct 1994 07:32:01 +0100 (MET) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA07454; Tue, 18 Oct 94 23:27:30 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA09563; Tue, 18 Oct 94 23:25:27 PDT Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10188; Tue, 18 Oct 94 23:28:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10182; Tue, 18 Oct 94 23:28:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09160; Tue, 18 Oct 94 23:24:11 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA07143; Tue, 18 Oct 94 23:24:11 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA15673; Tue, 18 Oct 1994 23:24:10 -0700 Date: Tue, 18 Oct 1994 23:24:10 -0700 From: Tony Li Message-Id: <199410190624.XAA15673@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Andy Davis's message of Tue, 18 Oct 94 14:36:26 +0100 <25030.9410181336@raft.spider.co.uk> Subject: (IPng) IPv6 Terminology - Cluster Address Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Status: RO The concept of a Cluster Address is certainly one which has me baffled, because it is an artefact for which I cannot imagine a use. The name is misleading, because I might expect a packet sent to the cluster address to be delivered to ALL the nodes in that cluster - the suggestion of "boundary address" might be an improvement; deliver the packet to the "boundary"? But why? Please can someone enlighten me? We're about to have this discussion over on the SDRP mailing list... One of the possible applications is that a cluster is one hop along a source route. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com >From owner-ipng@sunroof2.Eng.Sun.COM Thu Oct 20 21:41 GMT 1994 Received: from Sun.COM by ecbull.frec.bull.fr; Thu, 20 Oct 1994 22:40:43 +0100 (MET) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AB23425; Thu, 20 Oct 94 14:42:12 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA11257; Thu, 20 Oct 94 14:13:17 PDT Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15933; Thu, 20 Oct 94 14:13:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15927; Thu, 20 Oct 94 14:13:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15845; Thu, 20 Oct 94 14:09:29 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA12867; Thu, 20 Oct 94 14:03:24 PDT Received: by rodan.UU.NET id QQxmmb29587; Thu, 20 Oct 1994 16:23:58 -0400 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: Re: (IPng) IPv6 Terminology - Cluster Address To: ipng@sunroof.Eng.Sun.COM Date: Thu, 20 Oct 1994 16:23:57 -0400 (EDT) In-Reply-To: <19063.9410201320@raft.spider.co.uk> from "Andy Davis" at Oct 20, 94 02:20:18 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1463 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Status: RO [...] >But the problem with this is that, as I understand the semantics of a >cluster address, it does NOT identify a boundary router - so calling >it a "boundary router identifier" is bogus. My understanding is that >a packet addressed to the cluster address (or indirectly addressing >the cluster address, eg in a source route) will "match" whichever >boundary router it happens to hit first. Wouldn't it also match "any host" if it was sent from within the cluster it addresses? > If there are multiple paths >in the network, then a subsequent packet addressed the same way might >well be delivered to a DIFFERENT boundary router. Which behaviour >incidently is what makes me doubt the value of the mechanism in a >practical network - what protocol can use a semi-random destination >address mechanism? In any case, it doesn't address or identify a >particular router... When you don't care _where_ inside a routing domain you get, but just that you get there. The uses I have thought (or seen) for them: * Put them in source routes for mobile hosts * Manually route around network problems (one would hope this use would be rare, but I susspect not all failure modes will be automaticly routed around) * Network debugging (routing around parts of a net to see how that effects some failure mode) All three of these could be done with a "normal" address, but cluster addresses might be cleaner. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com >From owner-ipng@sunroof2.Eng.Sun.COM Mon Aug 29 13:53 GMT 1994 Received: from Sun.COM ([192.9.9.1]) by ecbull.frec.bull.fr; Mon, 29 Aug 1994 15:54:45 +0200 (MET) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25649; Mon, 29 Aug 94 06:55:13 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA03114; Mon, 29 Aug 94 06:57:17 PDT Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26116; Mon, 29 Aug 94 06:57:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26110; Mon, 29 Aug 94 06:57:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08723; Mon, 29 Aug 94 06:54:17 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA25504; Mon, 29 Aug 94 06:54:00 PDT Message-Id: <9408291354.AA25504@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9461; Mon, 29 Aug 94 09:53:54 EDT Date: Mon, 29 Aug 94 09:52:12 EDT From: yakov@watson.ibm.com To: tli@cisco.com Cc: mo@uunet.uu.net, ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng) cluster addresses and routing and such.... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Status: O Ref: Your note of Sat, 27 Aug 1994 00:27:22 -0700 Tony, >>The cluster *are the prefixes ! > >I'd like to point out a serious problem with this approach. I think >the simplest way of doing this is to use IPv4 addresses and notation >for a moment, if you'll indulge me... The following illustrate your point in the context of IPv6: Assume that we have two clusters, A and B, with addresses | 2 | m bits | 128-m bits | +----+--------------+---------------------------------------------+ | 01 | provider = D |000000000000000000000000000000000000000000000| +----+--------------+---------------------------------------------+ and | 2 | m bits | n bits | 128-m-n bits | +----+--------------+----------------+----------------------------+ | 01 | provider = D | subscriber = S |0000000000000000000000000000| +----+--------------+----------------+----------------------------+ Further assume that n = 4, and we allocate value S=0001 for subscriber S1, S=0010 for subscriber S2, S=0011 for subscriber S3, and S=0100 for subscriber S4. Two (related) questions: 1. Is it possible to form a new cluster X that includes only S1, S2, and S3 ? 2. If yes, then what is the cluster address of this cluster ? Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com >From owner-ipng@sunroof2.Eng.Sun.COM Sat Sep 3 19:10 GMT 1994 Received: from Sun.COM by ecbull.frec.bull.fr; Sat, 3 Sep 1994 21:12:02 +0200 (MET) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA27446; Sat, 3 Sep 94 12:01:10 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA18529; Sat, 3 Sep 94 12:03:20 PDT Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08185; Sat, 3 Sep 94 12:01:05 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08178; Sat, 3 Sep 94 12:00:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18421; Sat, 3 Sep 94 11:59:56 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA27165; Sat, 3 Sep 94 11:57:41 PDT Received: from via.rmm3.merit.edu ([35.196.49.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA26101 for ; Sat, 3 Sep 1994 14:57:39 -0400 Date: Sat, 3 Sep 94 18:30:48 GMT From: "William Allen Simpson" Message-Id: <3126.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) cluster addresses and routing and such.... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Status: O > From: yakov@watson.ibm.com > >>The cluster *are the prefixes ! > > > Further assume that n = 4, and we allocate value S=0001 for subscriber > S1, S=0010 for subscriber S2, S=0011 for subscriber S3, and S=0100 > for subscriber S4. > > 1. Is it possible to form a new cluster X that includes only S1, S2, and S3 ? > This is another "have you stopped beating your wife" question. Since, by definition, the cluster address RESERVES prefix zero, the obvious answer to your question is "S4 violates the reserved cluster", not "yes" or "no". To create a new cluster of (S1 to S3) which excludes (S4) would require either (S1 to S3) or (S4) to renumber. Since auto-renumbering is a part of IPv6, this will be easy to do. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com -- Michel Habert BULL SA B1-219 BP 208, 38432 Echirolles CEDEX Email : M.Habert@frec.bull.fr Phone: +33 76397611 Fax : +33 76397891 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 08:59:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20749; Thu, 2 Feb 95 08:59:22 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20738; Thu, 2 Feb 95 08:59:06 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA09119; Thu, 2 Feb 1995 08:52:31 -0800 Received: from ecbull.frec.bull.fr by Sun.COM (sun-barr.Sun.COM) id AA04139; Thu, 2 Feb 95 08:52:12 PST Received: from eliane.frec.bull.fr by ecbull.frec.bull.fr; Thu, 2 Feb 1995 17:42:37 +0100 (MET) Received: by eliane.frec.bull.fr; Thu, 2 Feb 95 16:41:07 GMT (EET) From: M.Habert@frec.bull.fr (Michel Habert) Message-Id: <9502021641.AA22936@eliane.frec.bull.fr> Subject: Re: (IPng) Cluster Adress To: ipng@sunroof.Eng.Sun.COM Date: Thu, 2 Feb 1995 17:41:04 +0100 (MET) In-Reply-To: <9502021625.AA11478@scxel3.frec.bull.fr> from "Anne Domine" at Feb 2, 95 05:25:03 pm X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From owner-ipng@sunroof2.Eng.Sun.COM Fri Oct 21 11:26 GMT 1994 Received: from Sun.COM by ecbull.frec.bull.fr; Fri, 21 Oct 1994 12:25:10 +0100 (MET) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA10315; Fri, 21 Oct 94 04:27:01 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA27660; Fri, 21 Oct 94 04:26:06 PDT Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16631; Fri, 21 Oct 94 04:27:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16625; Fri, 21 Oct 94 04:27:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29784; Fri, 21 Oct 94 04:23:36 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA09973; Fri, 21 Oct 94 04:23:35 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA00981; Fri, 21 Oct 1994 12:26:11 +0100 Message-Id: <199410211126.AA00981@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Terminology - Cluster Address In-Reply-To: Your message of "Thu, 20 Oct 1994 14:20:18 +0100." <19063.9410201320@raft.spider.co.uk> Date: Fri, 21 Oct 1994 12:26:10 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Status: RO Andy, The "semi-random routing" which has you baffled is the very definition of today's IP service. When you send a packet through the Internet today, you generally do not know where it will go through. Routing tables may change, so that the next packet does not quite follow the same route as the preceeding one. Even if routing tables are stable, routers may do "load splitting" between "equal length routes" - both IGRP and OSPF have provision for that, one could in fact even do it with RIP. There are cases when the user wants to specify the routing. Today, this can be done via source routing mechanism, e.g "go from A to B through C". The problem is that, in many case, source routing through a host may be an overspecification: you want for example to say "use provider X", not "use router Y of provider X". SDRP includes a "routing through an AS" feature that is an example of a response to this problem. Cluster addresses are generalizations of this principle. They are primarily to be used as elements of source routes, to assert that you want to "route through cloud X". The source route will be "progressed" by the first router within cloud X that the packet reaches, effectively a "border of cloud X" since the previous router, by definition, was not a member of that cloud. Usage of cluster addresses within source routes, and the relation with "probe" and 'set up" procedures, should be discussed as part of "SDRP for IPv6". Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com >From owner-ipng@sunroof2.Eng.Sun.COM Wed Oct 19 06:32 GMT 1994 Received: from Sun.COM by ecbull.frec.bull.fr; Wed, 19 Oct 1994 07:32:01 +0100 (MET) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA07454; Tue, 18 Oct 94 23:27:30 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA09563; Tue, 18 Oct 94 23:25:27 PDT Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10188; Tue, 18 Oct 94 23:28:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10182; Tue, 18 Oct 94 23:28:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09160; Tue, 18 Oct 94 23:24:11 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA07143; Tue, 18 Oct 94 23:24:11 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA15673; Tue, 18 Oct 1994 23:24:10 -0700 Date: Tue, 18 Oct 1994 23:24:10 -0700 From: Tony Li Message-Id: <199410190624.XAA15673@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Andy Davis's message of Tue, 18 Oct 94 14:36:26 +0100 <25030.9410181336@raft.spider.co.uk> Subject: (IPng) IPv6 Terminology - Cluster Address Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Status: RO The concept of a Cluster Address is certainly one which has me baffled, because it is an artefact for which I cannot imagine a use. The name is misleading, because I might expect a packet sent to the cluster address to be delivered to ALL the nodes in that cluster - the suggestion of "boundary address" might be an improvement; deliver the packet to the "boundary"? But why? Please can someone enlighten me? We're about to have this discussion over on the SDRP mailing list... One of the possible applications is that a cluster is one hop along a source route. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com >From owner-ipng@sunroof2.Eng.Sun.COM Thu Oct 20 21:41 GMT 1994 Received: from Sun.COM by ecbull.frec.bull.fr; Thu, 20 Oct 1994 22:40:43 +0100 (MET) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AB23425; Thu, 20 Oct 94 14:42:12 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA11257; Thu, 20 Oct 94 14:13:17 PDT Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15933; Thu, 20 Oct 94 14:13:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15927; Thu, 20 Oct 94 14:13:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15845; Thu, 20 Oct 94 14:09:29 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA12867; Thu, 20 Oct 94 14:03:24 PDT Received: by rodan.UU.NET id QQxmmb29587; Thu, 20 Oct 1994 16:23:58 -0400 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: Re: (IPng) IPv6 Terminology - Cluster Address To: ipng@sunroof.Eng.Sun.COM Date: Thu, 20 Oct 1994 16:23:57 -0400 (EDT) In-Reply-To: <19063.9410201320@raft.spider.co.uk> from "Andy Davis" at Oct 20, 94 02:20:18 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1463 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Status: RO [...] >But the problem with this is that, as I understand the semantics of a >cluster address, it does NOT identify a boundary router - so calling >it a "boundary router identifier" is bogus. My understanding is that >a packet addressed to the cluster address (or indirectly addressing >the cluster address, eg in a source route) will "match" whichever >boundary router it happens to hit first. Wouldn't it also match "any host" if it was sent from within the cluster it addresses? > If there are multiple paths >in the network, then a subsequent packet addressed the same way might >well be delivered to a DIFFERENT boundary router. Which behaviour >incidently is what makes me doubt the value of the mechanism in a >practical network - what protocol can use a semi-random destination >address mechanism? In any case, it doesn't address or identify a >particular router... When you don't care _where_ inside a routing domain you get, but just that you get there. The uses I have thought (or seen) for them: * Put them in source routes for mobile hosts * Manually route around network problems (one would hope this use would be rare, but I susspect not all failure modes will be automaticly routed around) * Network debugging (routing around parts of a net to see how that effects some failure mode) All three of these could be done with a "normal" address, but cluster addresses might be cleaner. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com >From owner-ipng@sunroof2.Eng.Sun.COM Mon Aug 29 13:53 GMT 1994 Received: from Sun.COM ([192.9.9.1]) by ecbull.frec.bull.fr; Mon, 29 Aug 1994 15:54:45 +0200 (MET) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25649; Mon, 29 Aug 94 06:55:13 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA03114; Mon, 29 Aug 94 06:57:17 PDT Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26116; Mon, 29 Aug 94 06:57:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26110; Mon, 29 Aug 94 06:57:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08723; Mon, 29 Aug 94 06:54:17 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA25504; Mon, 29 Aug 94 06:54:00 PDT Message-Id: <9408291354.AA25504@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9461; Mon, 29 Aug 94 09:53:54 EDT Date: Mon, 29 Aug 94 09:52:12 EDT From: yakov@watson.ibm.com To: tli@cisco.com Cc: mo@uunet.uu.net, ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng) cluster addresses and routing and such.... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Status: O Ref: Your note of Sat, 27 Aug 1994 00:27:22 -0700 Tony, >>The cluster *are the prefixes ! > >I'd like to point out a serious problem with this approach. I think >the simplest way of doing this is to use IPv4 addresses and notation >for a moment, if you'll indulge me... The following illustrate your point in the context of IPv6: Assume that we have two clusters, A and B, with addresses | 2 | m bits | 128-m bits | +----+--------------+---------------------------------------------+ | 01 | provider = D |000000000000000000000000000000000000000000000| +----+--------------+---------------------------------------------+ and | 2 | m bits | n bits | 128-m-n bits | +----+--------------+----------------+----------------------------+ | 01 | provider = D | subscriber = S |0000000000000000000000000000| +----+--------------+----------------+----------------------------+ Further assume that n = 4, and we allocate value S=0001 for subscriber S1, S=0010 for subscriber S2, S=0011 for subscriber S3, and S=0100 for subscriber S4. Two (related) questions: 1. Is it possible to form a new cluster X that includes only S1, S2, and S3 ? 2. If yes, then what is the cluster address of this cluster ? Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com >From owner-ipng@sunroof2.Eng.Sun.COM Sat Sep 3 19:10 GMT 1994 Received: from Sun.COM by ecbull.frec.bull.fr; Sat, 3 Sep 1994 21:12:02 +0200 (MET) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA27446; Sat, 3 Sep 94 12:01:10 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA18529; Sat, 3 Sep 94 12:03:20 PDT Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08185; Sat, 3 Sep 94 12:01:05 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08178; Sat, 3 Sep 94 12:00:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18421; Sat, 3 Sep 94 11:59:56 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA27165; Sat, 3 Sep 94 11:57:41 PDT Received: from via.rmm3.merit.edu ([35.196.49.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA26101 for ; Sat, 3 Sep 1994 14:57:39 -0400 Date: Sat, 3 Sep 94 18:30:48 GMT From: "William Allen Simpson" Message-Id: <3126.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) cluster addresses and routing and such.... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Status: O > From: yakov@watson.ibm.com > >>The cluster *are the prefixes ! > > > Further assume that n = 4, and we allocate value S=0001 for subscriber > S1, S=0010 for subscriber S2, S=0011 for subscriber S3, and S=0100 > for subscriber S4. > > 1. Is it possible to form a new cluster X that includes only S1, S2, and S3 ? > This is another "have you stopped beating your wife" question. Since, by definition, the cluster address RESERVES prefix zero, the obvious answer to your question is "S4 violates the reserved cluster", not "yes" or "no". To create a new cluster of (S1 to S3) which excludes (S4) would require either (S1 to S3) or (S4) to renumber. Since auto-renumbering is a part of IPv6, this will be easy to do. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com -- Michel Habert BULL SA B1-219 BP 208, 38432 Echirolles CEDEX Email : M.Habert@frec.bull.fr Phone: +33 76397611 Fax : +33 76397891 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 13:37:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21152; Thu, 2 Feb 95 13:37:59 PST Received: from Eng.Sun.COM (tuna) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21146; Thu, 2 Feb 95 13:37:47 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06175; Thu, 2 Feb 1995 13:31:11 -0800 Received: from scratchy (scratchy.inner.net) by Sun.COM (sun-barr.Sun.COM) id AA02599; Thu, 2 Feb 95 13:31:04 PST Received: from itchy by scratchy with smtp (Smail3.1.29.0 #4) id m0R5nKr-000042C; Wed, 8 Sep 82 10:12 EDT Received: from itchy.inner.net by itchy with smtp (Smail3.1.29.0 #4) id m0rZRIt-000DJEC; Tue, 31 Jan 95 17:44 EST Message-Id: X-Mailer: exmh version 1.5.2 12/21/94 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Announcement In-Reply-To: Your message of "Thu, 02 Feb 1995 07:03:41 EST." <950202070339_10812899@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Jan 1995 17:44:06 -0500 From: Craig Metz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message <950202070339_10812899@aol.com>, you write: > As of January 26, 1995, > Joachim Martillo > (Joachim Carlo Santos Martillo Ajami) > formerly > Manager of Internetworking Research > > at > Penril Datability Networks > 190 North Main Street > Natick, MA 01760 > Corporate Headquarters > 1300 Quince Orchard Boulevard > Gaithersburg, Maryland 20878-4106 > > no longer works for > > Penril Datability Networks. > > Joachim Martillo may be reached as follows: > Voice: 617-298-4107 > E-MAIL: martillo@delphi.com > US-MAIL: 15 Pleasant Hill Ave > Dorchester, MA 02126-2813 > > >------------------------------------------------------------------------------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >Unsubscribe: unsubscribe ipng (as message body, not subject) >Direct all administrative requests to majordomo@sunroof.eng.sun.com And I care because? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 13:38:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21159; Thu, 2 Feb 95 13:38:18 PST Received: from Eng.Sun.COM (tuna) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21153; Thu, 2 Feb 95 13:38:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06185; Thu, 2 Feb 1995 13:31:27 -0800 Received: from scratchy (scratchy.inner.net) by Sun.COM (sun-barr.Sun.COM) id AA02672; Thu, 2 Feb 95 13:31:22 PST Received: from itchy by scratchy with smtp (Smail3.1.29.0 #4) id m0R5nLE-000042C; Wed, 8 Sep 82 10:13 EDT Received: from itchy.inner.net by itchy with smtp (Smail3.1.29.0 #4) id m0rZRJH-000DJEC; Tue, 31 Jan 95 17:44 EST Message-Id: X-Mailer: exmh version 1.5.2 12/21/94 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Severance of Relationships In-Reply-To: Your message of "Thu, 02 Feb 1995 07:08:42 EST." <950202070838_10813016@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Jan 1995 17:44:31 -0500 From: Craig Metz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message <950202070838_10813016@aol.com>, you write: > As of January 26, 1995, > Telford Tools, Inc., > formerly known as > Tudor Technology, Inc. > a Massachusetts corporation in good standing, > which was founded in 1993 > by > Joachim Martillo > and > which sells > services related to software development and network debugging > as well as > communications equipment > > has severed all relationships with > > Penril Datability Networks, > Penril Datacomm Networks, Inc > and > Penril Datacomm, Inc. > >All inquiries should be directed to: > >E-Mail: Telford001@aol.com >Voice: 617-298-1617 >FAX: 617-298-1745 >US-MAIL: 17 Pleasant Hill Avenue > Dorchester, MA 02126-2813 > >------------------------------------------------------------------------------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >Unsubscribe: unsubscribe ipng (as message body, not subject) >Direct all administrative requests to majordomo@sunroof.eng.sun.com And I care because? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 13:51:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21224; Thu, 2 Feb 95 13:51:00 PST Received: from Eng.Sun.COM (tuna) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21218; Thu, 2 Feb 95 13:50:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07463; Thu, 2 Feb 1995 13:44:17 -0800 Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA05682; Thu, 2 Feb 95 13:43:56 PST Message-Id: <9502022143.AA05682@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1487; Thu, 02 Feb 95 16:43:50 EST Date: Thu, 2 Feb 95 16:43:50 EST From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 address format I-D. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, The revised version of the IPv6 Address Format I-D is available. (draft-rekhter-IPv6-address-format-01.txt). It includes the comments we got at the last IETF. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 13:59:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21237; Thu, 2 Feb 95 13:59:44 PST Received: from Eng.Sun.COM (tuna) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21231; Thu, 2 Feb 95 13:59:32 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08278; Thu, 2 Feb 1995 13:52:56 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA07536; Thu, 2 Feb 95 13:52:45 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm012-20.dialip.mich.net [141.211.7.188]) by merit.edu (8.6.9/merit-2.0) with SMTP id QAA24817 for ; Thu, 2 Feb 1995 16:52:40 -0500 Date: Thu, 2 Feb 95 21:11:21 GMT From: "William Allen Simpson" Message-Id: <3860.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Severance of Relationships Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From POP3@popmail.morningstar.com. Thu Feb 02 20:48:37 1995 > Received: from koriel.Sun.COM by volitans.MorningStar.Com (5.65a/94040804) > id AA11757; Thu, 2 Feb 95 09:57:03 -0500 > Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) > id AA06018; Thu, 2 Feb 95 06:43:01 PST > Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3) > id AA03644; Thu, 2 Feb 1995 06:42:55 -0800 > Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) > id AA20609; Thu, 2 Feb 95 06:48:46 PST > Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) > id AA20603; Thu, 2 Feb 95 06:48:39 PST > Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) > id GAA03042; Thu, 2 Feb 1995 06:42:05 -0800 > Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) > id AA08406; Thu, 2 Feb 95 06:42:04 PST > Received: from anubis.network.com by nsco.network.com (4.1/1.34) > id AA29176; Thu, 2 Feb 95 08:57:52 CST > Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) > id AA08349; Thu, 2 Feb 95 08:41:37 CST > Date: Thu, 2 Feb 95 08:41:37 CST > From: amolitor@anubis.network.com (Andrew Molitor) > Message-Id: <9502021441.AA08349@anubis.network.com> > To: ipng@sunroof.eng.sun.com > Subject: Re: (IPng) Severance of Relationships > Sender: owner-ipng@sunroof.eng.sun.com > Precedence: bulk > Reply-To: ipng@sunroof.eng.sun.com > > Like, why do I care, you worthless little vandal? > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 14:00:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21249; Thu, 2 Feb 95 14:00:18 PST Received: from Eng.Sun.COM (tuna) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21243; Thu, 2 Feb 95 14:00:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08321; Thu, 2 Feb 1995 13:53:30 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA07633; Thu, 2 Feb 95 13:53:19 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm012-20.dialip.mich.net [141.211.7.188]) by merit.edu (8.6.9/merit-2.0) with SMTP id QAA24814; Thu, 2 Feb 1995 16:52:37 -0500 Date: Thu, 2 Feb 95 21:05:06 GMT From: "William Allen Simpson" Message-Id: <3859.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Cc: ietf@cnri.reston.va.us Subject: (IPng) Re: Severance of Relationships Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Brad Wilson > Come on ... what it REALLY necessary to make some people who PAY for email > to read that you had quit? Twice? > 8 times here! Now we know which mailing lists haven't thrown him off, yet. > From: another user who apologized for accidentally sending it to the list > Like, why do I care, you worthless little vandal? My feelings, exactly. Seems more like a commercial advertisement. Against our Acceptable Use Policy. Let's all ask for his Delphi account to be closed. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 14:26:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21340; Thu, 2 Feb 95 14:26:56 PST Received: from Eng.Sun.COM (tuna) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21331; Thu, 2 Feb 95 14:26:44 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10981; Thu, 2 Feb 1995 14:20:08 -0800 Received: from scratchy (scratchy.inner.net) by Sun.COM (sun-barr.Sun.COM) id AA12981; Thu, 2 Feb 95 14:20:06 PST Received: from itchy by scratchy with smtp (Smail3.1.29.0 #4) id m0R5o6N-000042C; Wed, 8 Sep 82 11:01 EDT Received: from itchy.inner.net by itchy with smtp (Smail3.1.29.0 #4) id m0rZS4R-000DJEC; Tue, 31 Jan 95 18:33 EST Message-Id: X-Mailer: exmh version 1.5.2 12/21/94 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Severance of Relationships In-Reply-To: Your message of "Tue, 31 Jan 1995 17:44:31 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 31 Jan 1995 18:33:14 -0500 From: Craig Metz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message , I wrote: > And I care because? Egg on face time. My apologies for not checking more carefully where my spam was going. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 2 20:59:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21548; Thu, 2 Feb 95 20:59:43 PST Received: from Eng.Sun.COM (tuna) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21542; Thu, 2 Feb 95 20:59:36 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08510; Thu, 2 Feb 1995 20:51:30 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA21145; Thu, 2 Feb 95 20:51:25 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA26122; Thu, 2 Feb 95 20:45:10 -0800 Received: by xirtlu.zk3.dec.com; id AA20408; Thu, 2 Feb 1995 23:44:58 -0500 Message-Id: <9502030444.AA20408@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Severance of Relationships In-Reply-To: Your message of "Tue, 31 Jan 95 17:44:31 EST." Date: Thu, 02 Feb 95 23:44:52 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Give me a freakin break everybody. Joachim's mail that he left his company is one of several I have seen this past six months of people changing locations or whatever. I did not see this kind of hate mail and I don't care for it. Joachim has made good technical contributions for the past six months on the work in IPng and I do want to know where he went. Just cause of its style and 1.5 screen length was long should not cause hate mail. And the more nasty ones I have seen. Just hit the 'd' key. Also I believe most of these kind of responses would never be done face to face because you would be in the persons face in person and that takes more fortitude than being a wimp behind an electronic mail message. Do it in person or be quiet. Also take a social course in valuing differences. Also I will be at a couple of different favorite SanFranciso taverns next week at the meeting if you would like to come by and talk to me about this in person if you don't like my mail. There is enough nasty stuff on the news I don't need to see that tone in the IETF. Be glad to discuss tone outside of an IETF environment though anytime. But give the guy a break. Good luck Joachim. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 3 14:00:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22010; Fri, 3 Feb 95 14:00:13 PST Received: from Eng.Sun.COM (tuna) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21859; Fri, 3 Feb 95 09:29:54 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05641; Fri, 3 Feb 1995 09:23:16 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA25941; Fri, 3 Feb 95 09:23:18 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.8/BARRNET-RELAY.1) id JAA05771; Fri, 3 Feb 1995 09:19:07 -0800 Received: from [192.216.126.207] (acacia) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA19866; Fri, 3 Feb 95 09:17:22 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Feb 1995 09:19:04 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: Re: (IPng) Severance of Relationships Cc: bound@zk3.dec.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 8:44 PM 2/2/95, bound@zk3.dec.com wrote: >Give me a freakin break everybody. Joachim's mail that he left his >company is one of several I have seen this past six months of people >changing locations or whatever. I did not see this kind of hate mail >and I don't care for it. I agree with Jim. This stuff is out of line. I recently changed jobs and sent a short message to this list. I don't think this kind of email is inappropriate for this list. I too have also had my "discussions" with Joachim, but I don't think is warrants this kind of email. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 3 14:55:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22051; Fri, 3 Feb 95 14:55:02 PST Received: from Eng.Sun.COM (tuna) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22045; Fri, 3 Feb 95 14:54:55 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04356; Fri, 3 Feb 1995 14:48:16 -0800 Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA29642; Fri, 3 Feb 95 14:48:03 PST Received: from [198.120.32.24] (arc-tac1-slip6.nsi.nasa.gov [198.120.32.26]) by Mordor.Stanford.EDU (8.6.9/8.6.6) with SMTP id OAA12980; Fri, 3 Feb 1995 14:47:59 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Feb 1995 14:48:03 -0800 To: ipng@sunroof.Eng.Sun.COM From: Dave Crocker Subject: Re: (IPng) Severance of Relationships Cc: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 9:19 AM 2/3/95, Bob Hinden wrote: >I agree with Jim. This stuff is out of line. I recently changed jobs and >sent a short message to this list. I don't think this kind of email is >inappropriate I agree in principle, but disagree in this particular case. There is a simple and direct style in which these announcements usually are done. The style of the one in question is much more in line with advertising than announcing, even though it makes a feable attempt to emulate the style of professional announcements that are sometimes done by folks like lawyers. The format, as well as the content describing services offered, were inappropriate. IMO, of course. d/ -------------------- Dave Crocker Brandenburg Consulting +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 6 06:42:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22724; Mon, 6 Feb 95 06:42:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22718; Mon, 6 Feb 95 06:41:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05866; Mon, 6 Feb 1995 06:35:17 -0800 Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA02657; Mon, 6 Feb 95 06:35:18 PST Message-Id: <9502061435.AA02657@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4899; Mon, 06 Feb 95 09:35:16 EST Date: Mon, 6 Feb 95 09:35:15 EST From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) minor correction to I-D Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, It was pointed to me that draft-rekhter-IPv6-address-format-02.txt has incorrect date -- January 1994. I'd like to apologize for the error. Yakov ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 6 07:49:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22810; Mon, 6 Feb 95 07:49:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22804; Mon, 6 Feb 95 07:49:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09431; Mon, 6 Feb 1995 07:42:58 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA14509; Mon, 6 Feb 95 07:42:36 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14454(6)>; Mon, 6 Feb 1995 07:42:16 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Mon, 6 Feb 1995 07:42:05 -0800 To: rem-conf@es.net, ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com Cc: deering@parc.xerox.com Subject: (IPng) multicast of IPng area WG meetings, Feb 9 and 10 Date: Mon, 6 Feb 1995 07:41:49 PST From: Steve Deering Message-Id: <95Feb6.074205pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The interim meeting of the IPng, ngtrans, and addrconf working groups at Xerox PARC will be multicast on the MBone on Thursday and Friday, Feb 9 and 10, from 9 am to 6 pm PST (1700-0200 GMT), using the same TTL scope as regular IETF meetings ("IETF channel 1"). We *may* be able to do a tape-delayed replay for the time-zone-challenged, but no promises. Please let me know of any overlap with other MBone events. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 6 14:26:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23131; Mon, 6 Feb 95 14:26:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23125; Mon, 6 Feb 95 14:26:45 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22667; Mon, 6 Feb 1995 14:20:04 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA03719; Mon, 6 Feb 95 14:19:49 PST Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA20194; Mon, 6 Feb 1995 17:19:26 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA02117; Mon, 6 Feb 1995 17:19:22 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA25904; Mon, 6 Feb 1995 16:55:20 -0500 Message-Id: <9502062155.AA25904@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) Severance of Relationships In-Reply-To: Your message of "Thu, 02 Feb 95 23:44:52 EST." <9502030444.AA20408@xirtlu.zk3.dec.com> Date: Mon, 06 Feb 95 16:55:20 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: bound@zk3.dec.com Subject: Re: (IPng) Severance of Relationships ...... Joachim's mail that he left his company is one of several I have seen this past six months of people changing locations or whatever.... I do agree with Jim, and others, that a change of address is a reasonable thing to announce, for one that was or is active on the list. If Joachim had done it earlier, it would have saved my time of guessing whether the last several messages he has sent, are coming from the same Joachim that was sending messages from a different company address before. And yes, good luck... Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 6 19:05:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23371; Mon, 6 Feb 95 19:05:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23365; Mon, 6 Feb 95 19:05:37 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27282; Mon, 6 Feb 1995 18:58:54 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA21179; Mon, 6 Feb 95 18:58:55 PST Received: by rodan.UU.NET id QQybzn27858; Mon, 6 Feb 1995 21:58:49 -0500 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) minor correction to I-D In-Reply-To: Your message of "Mon, 06 Feb 1995 09:35:15 EST." <9502061435.AA02657@Sun.COM> Date: Mon, 06 Feb 1995 21:58:49 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Oh Yakov, we know you've had it done for a year and were just holding it close to the chest until you could spring it on us at the right moment! cheers, -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 7 02:32:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23514; Tue, 7 Feb 95 02:32:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23508; Tue, 7 Feb 95 02:32:16 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14957; Tue, 7 Feb 1995 02:25:35 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA12240; Tue, 7 Feb 95 02:25:33 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 7 Feb 95 19:24:20 +0900 From: Masataka Ohta Message-Id: <9502071024.AA20012@necom830.cc.titech.ac.jp> Subject: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Tue, 7 Feb 95 19:24:18 JST In-Reply-To: <199501152218.OAA05758@gauss.asd.sgi.com>; from "Casey Leedom" at Jan 15, 95 2:18 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As for provider independence and multihoming, it seems to me that does not address the issue properly. And, the only workable solution is, it seems to me, UID based ones. The difficulty, perhaps, is that usual "working code" approach is not applicable to evaluate multihoming scheme, because what we need is "working providers". > 5.4 Multi-homed Routing Domains IMHO, there seems to be no solutions presented. > 5.4.1 Solution 1 > > > One possible solution is for each multi-homed organization to obtain > its IPv6 address space independently of the providers to which it is > attached. This does not scale. > 5.4.2 Solution 2 > > > A second possible approach would be for multi-homed organizations to > be assigned a separate IPv6 address space for each connection to a > TRD, and to assign a single prefix to some subset of its domain(s) > based on the closest interconnection point. For example, if MBII had > connections to two providers in the U.S. (one east coast, and one > west coast), as well as three connections to national backbones in > Europe, and one in the far east, then MBII may make use of six > different address prefixes. Each part of MBII would be assigned a > single address prefix based on the nearest connection. This is NOT multihoming at all. Just a collection of singlly homed subsets. > 5.4.3 Solution 3 > > > There are other possible solutions as well. A third approach is to > assign each multi-homed organization a single address prefix, based > on one of its connections to a TRD. Other TRDs to which the multi- > homed organization are attached maintain a routing table entry for > the organization, but are extremely selective in terms of which other > TRDs are told of this route. This approach will produce a single > `default' routing entry which all TRDs will know how to reach (since > presumably all TRDs will maintain routes to each other), while > providing more direct routing in some cases. This approach does not scale, if flexible multihoming is desired and is no good. > 5.4.4 Solution 4 > > > A fourth solution involves assignment of a particular address prefix > for routing domains which are attached to precisely two (or more) > specific routing domains. This approach does not scale well with tri- or quad- homing. Moreover, it is completely unreasonable to expect providers offer this type of multihoming. They prefer monopoly and can do so by simply not offering additional particular address prefix. In addition, there is a severe technical fault. If an organization is connected to provider A and B with a shared prefix of C: ----------------------------------- | | | | | Global Internet | | | | | |route to A route to B & C| |-------| ----------------------------------- |O | | | |t D | | -----------------+--------------------|h u O | | / | |e a r w| ---------------- / ---------------- |r l g i| | |/ | |----------| | a t| | | | | | h n h| | provider A | | provider B | | o i | | | | | | m z p| | | | | | e a r| ---------------- ---------------- | d t e| | | | i f| | | | o i| | | | n x| | | | | ----------------------------------- | C| | | |-------| | dual-homed organization | | with dual-homed prefix of C | ----------------------------------- and provider B is partitioned or, link from the dual homed organization is cut, ----------------------------------- | | | | | Global Internet | | | | | |route to A route to B & C| |-------| ----------------------------------- |O | | | |t D | | -----------------+--------------------|h u O | | / | |e a r w| ---------------- / ---------------- |r l g i| | |/ | |----------| | a t| | | | | | h n h| | provider A | | provider B | | o i | | | | | m z p| | | | e a r| ---------------- | d t e| | | i f| | | o i| | | n x| | | | ----------------------------------- | C| | | |-------| | dual-homed organization | | with dual-homed prefix of C | ----------------------------------- the organization becomes unreachable from the global internet. Without provider fault tolerance, which is, of course, a primay benefit of multihoming, this approach is unacceptable. > 5.4.5 Summary > > > There are therefore a number of possible solutions to the problem of > assigning IPv6 addresses to multi-homed routing domains. Thus, in the draft, there are NO solutions presented for multihoming. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 7 09:06:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23648; Tue, 7 Feb 95 09:06:02 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23642; Tue, 7 Feb 95 09:05:55 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA14795; Tue, 7 Feb 1995 08:59:08 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA17634; Tue, 7 Feb 1995 08:59:03 -0800 Date: Tue, 7 Feb 1995 08:59:03 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199502071659.IAA17634@elrond.Eng.Sun.COM> To: danmcd@itd.nrl.navy.mil Subject: (IPng) Comments on your proposed IPv6 security API Cc: ipng@sunroof X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, Here are some comments on your socket API for IPv6 security. I am working from the draft you sent out by email, rather than the I-D you just posted, but I believe the comments are applicable to both. o On page two you write : Especially in cases of manual key management, two separate user-level sockets may have their data encrypted with the same key, algorithm, and therefore, the same SAID. If more than one user's data is encrypted with the same key, then user-level security is not provided, but system level security is. Encrypting more than one user's data with the same key is complicated for other reasons. If replay detection is an issue, then you have to ensure that the replay detection state (e.g., timestamps or sequence numbers) is also common, or at least managed so that duplicate replay information isn't used. Otherwise, replay becomes a hazard. I think manual key distribution will only be practical for testing purposes and not for very many real life applications. o You call the parameters associated with a given SAID a "security level." I would recomend using another term. The term "security level" already is in widespread use, meaning the level of classification, e.g., SECRET, CONFIDENTIAL, PROPRIETARY. How about security parameters (SECPARMS) or some other term? o You suggest 3 types of authentication, the second of which is authentication of security-critical packets. There is a potential problem here with a change of what is considered a security critical packet, which could lead to interoperability problems. Furthermore, and perhaps more importantly, if all packets are not authenticated, what will bind the non-authenticated packets to the authenticated ones? I'm not sure how useful this authentication service would be. o On page 4 you write : Per Socket Security Level At each socket, the user should have the ability to set his or her security level beyond what the system mandates, provided there are the appropriate security associations. Do you mean "beyond" or different from? The term "beyond" suggests that the system default is a minimum (or would the mandated "level" be yet another system parameter?). o In the next paragraph you write : No security errors are reported to security unaware applications. I think there would be some errors that you should map into existing socket errors. For example, if no SAID is available, the socket will be unuseable, for at least a while and perhaps permanently. This error should be mapped into something like "host unreachable." Other security errors might have mappings as well. o Further down on page 5 you write : The systemwide security level, if more secure, supersedes whatever the user-level socket requests. This again suggests that the system default is a minimum. I think these concepts should be separated or you should change the term "default" to "minimum." o In the same paragraph you write : If an application requests authentication to a destination that has security associations for both authentication and encryption, then the application's packets will be both authenticated and encrypted. I don't think you want to force encryption when only authentication is requested. You are imposing a performance hit on the application which it may not be able to tolerate (e.g., for a real-time application that needs only authentication not encryption). o On page 6 you write : IP_SECLEVEL sets or obtains the security level for a socket. The integer argument is a bitmask of possible values. The low two bits of the integer are for authentication levels. The two bits above the authentication bits indicate what parts of datagrams should be encapsulated in an ESP. Packing the bits this densely doesn't allow for the graceful addition of new values. I would give both authetication and encryption their own byte in a 16 or 32 bit word. How these comments help. Regards, Dan Nessett ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 7 11:33:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23863; Tue, 7 Feb 95 11:33:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23857; Tue, 7 Feb 95 11:33:36 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24526; Tue, 7 Feb 1995 11:26:52 -0800 Received: from sgigate.sgi.com ([192.82.208.1]) by Sun.COM (sun-barr.Sun.COM) id AA09476; Tue, 7 Feb 95 11:24:56 PST Received: from sgihub.corp.sgi.com (sgihub.corp.sgi.com [192.26.51.188]) by sgigate.sgi.com (940519.SGI.8.6.9/8.6.4) with ESMTP id LAA07446; Tue, 7 Feb 1995 11:05:29 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for <@sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com> id LAA25268; Tue, 7 Feb 1995 11:05:28 -0800 Received: from gauss.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com id AA27664; Tue, 7 Feb 95 11:05:25 -0800 Received: from localhost by gauss.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id LAA05321; Tue, 7 Feb 1995 11:05:21 -0800 Message-Id: <199502071905.LAA05321@gauss.asd.sgi.com> From: leedom@gauss.asd.sgi.com (Casey Leedom) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) A thought on addressing Date: Tue, 07 Feb 1995 11:05:17 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM | Date: Tue, 7 Feb 95 19:24:18 JST | From: Masataka Ohta | | And, the only workable solution is, it seems to me, UID based ones. Could you briefly explain what you mean here? Sorry if this is already a well known concept. | > 5.4.1 Solution 1 | > | > One possible solution is for each multi-homed organization to obtain | > its IPv6 address space independently of the providers to which it is | > attached. | | This does not scale. Why doesn't this scale? (I'm honestly curious; not offering criticism.) It may be that I don't understand what this scheme is specifically proposing. Casey ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 7 13:29:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23914; Tue, 7 Feb 95 13:29:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23908; Tue, 7 Feb 95 13:29:20 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07376; Tue, 7 Feb 1995 13:22:37 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA02115; Tue, 7 Feb 95 13:22:36 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07200; 7 Feb 95 15:12 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-simpson-ipv6-discov-process-02.txt Date: Tue, 07 Feb 95 15:12:54 -0500 Message-Id: <9502071512.aa07200@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Neighbor Discovery -- Processing Author(s) : W. Simpson Filename : draft-simpson-ipv6-discov-process-02.txt Pages : 47 Date : 02/06/1995 This document discusses the implementation techniques for identification of and forwarding to adjacent IPv6 nodes, including Next Hop Determination and Router Discovery. 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-simpson-ipv6-discov-process-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-ipv6-discov-process-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-simpson-ipv6-discov-process-02.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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19950206164633.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-ipv6-discov-process-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-ipv6-discov-process-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950206164633.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 7 18:31:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24086; Tue, 7 Feb 95 18:31:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24080; Tue, 7 Feb 95 18:31:35 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09634; Tue, 7 Feb 1995 18:24:52 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA11428; Tue, 7 Feb 95 18:24:50 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 8 Feb 95 11:23:32 +0900 From: Masataka Ohta Message-Id: <9502080223.AA23569@necom830.cc.titech.ac.jp> Subject: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Wed, 8 Feb 95 11:23:30 JST In-Reply-To: <199502071905.LAA05321@gauss.asd.sgi.com>; from "Casey Leedom" at Feb 7, 95 11:05 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > | Date: Tue, 7 Feb 95 19:24:18 JST > | From: Masataka Ohta > | > | And, the only workable solution is, it seems to me, UID based ones. > > Could you briefly explain what you mean here? To make IP address consist of a globally unique, but unroutable, ID and a hierarchically routable parts. Both can be 8 byte long. See the Dave Clark's original post with this subject. For more detailed proposal, see: From: Masataka Ohta Message-Id: <9408241540.AA15492@necom830.cc.titech.ac.jp> Subject: (IPng) Multi-homed organizations, geographical constraint, security and more Date: Thu, 25 Aug 94 0:39:58 JST in IPng archive. > Sorry if this is already a well known concept. It is too much :-) well known in bigI ML causing a lot of confused debate. > | > 5.4.1 Solution 1 > | > > | > One possible solution is for each multi-homed organization to obtain > | > its IPv6 address space independently of the providers to which it is > | > attached. > | > | This does not scale. > > Why doesn't this scale? (I'm honestly curious; not offering > criticism.) That is already documented in the latter paragraphs of the same section: : providers. Other providers (potentially worldwide) will need to : maintain an explicit entry for that organization in their routing : tables. : (including backbones to which MBII is not attached). Clearly this may : be acceptable if there are a small number of such multi-homed routing : domains, but would place an unacceptable load on routers within : backbones if all organizations were to choose such address : assignments. This solution may not scale to internets where there : are many hundreds of thousands of multi-homed organizations. > It may be that I don't understand what this scheme is > specifically proposing. Well, the draft, which lists up a lot of known-to-be-not-to-work schemes and call them "solutions" is written rather dishonestly and should partially be responsible for you not reading the draft and blindly believe there are some solutions. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 9 18:03:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25199; Thu, 9 Feb 95 18:03:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25193; Thu, 9 Feb 95 18:03:30 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16769; Thu, 9 Feb 1995 17:56:43 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA25382; Thu, 9 Feb 95 17:56:40 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA19300; Fri, 10 Feb 1995 12:56:34 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA09861; Fri, 10 Feb 95 11:51:48 +1000 Received: by dcthq2.datacraft.com.au; Fri, 10 Feb 95 12:59:41 +1100 Date: Fri, 10 Feb 95 12:10:51 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) comments on draft IPv6 Global Unicast Address Form at X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Comments on draft-rekhter-ipv6-address-format-01.txt Yakov, just a few comments. The regional registries and their IDs. I still would prefer these to be identified as left justified Hex not right justified. Or is this usual practice in the US? eg 0xf8 should be 0x1f as it represents the lower 5 bits of the prefix byte. the top 3 bits set to unicast The other comment is the national registry text. what are the viwes on providing a registry ID for "National Bodies" eg a FP of of 0xD8 (or 0x1b) then the ISO body such as ANSI or BSI or Standards Australia can use as the next two bytes the DCC and then sub reg authority identifiers can follow. At least that will give some degree of consistency to national addressing and permit cleaner routing between neighbouring countries that straddle the regional routing levels. It is additive to what is already proposed and therefore does not prohibit regionally assigned "nationally based" sub authorities. Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 11 18:12:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26023; Sat, 11 Feb 95 18:12:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26017; Sat, 11 Feb 95 18:12:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28580; Sat, 11 Feb 1995 18:05:49 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA29942; Sat, 11 Feb 95 18:05:51 PST Received: from LapTop.Simpson.DialUp.Mich.Net (pm002-06.dialip.mich.net [141.211.7.142]) by merit.edu (8.6.9/merit-2.0) with SMTP id VAA20462 for ; Sat, 11 Feb 1995 21:05:47 -0500 Date: Sat, 11 Feb 95 16:56:24 GMT From: "William Allen Simpson" Message-Id: <1257.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Mediocrity Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Last year saw the formation of the IPv6 WG from the forced destruction of SIPP -- which won the design competition technically, but lost the final event politically. Since, we have seen the repeated ravages of "design by committee". No opinion too trivial, no thought required, no vision, no common sense. Fields ever bigger, processing times ever slower. The Neighbor Discovery design vision was developed among a small number of architects, which looked at the current environment, and asked for a reduction in latency, self-configuration of both name and address, mobility support, rapid black-hole detection, and a common solution over multiple media. Over the months, the IPv6 committee has eviscerated Neighbor Discovery. ARP latency was restored. Mobility support was removed. Black-hole detection is optional. Support for other media than ethernet is removed. All that is left is a simple ARP replacement, without innovation, coupled to Router Discovery, which although rarely implemented has the benefit of being old. One pedant summarized the position -- "ARP has always been good enough". As to self-configuration, the committee expanded the methods to three, instead of consolidating -- passive stateless, active stateless, and stateful (DHCPv6). Despite the agreement within the DNSIND WG on Wednesday, auto-registration with DNS is "too new" to be acceptable by the conservative IPv6 members, which apparently prefer good old hand configuration of host files, thank you very much. The most positive advance was a general agreement to eliminate the inverse DNS mapping in favor of querying nodes directly. Objections were raised, of course, because each node would have to know its name, which is no longer a requirement of Neighbor Discovery. I am so depressed as to be physically ill.... Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 12 10:53:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26107; Sun, 12 Feb 95 10:53:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26101; Sun, 12 Feb 95 10:53:31 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22513; Sun, 12 Feb 1995 10:46:40 -0800 Received: from mail04.mail.aol.com by Sun.COM (sun-barr.Sun.COM) id AA06704; Sun, 12 Feb 95 10:46:42 PST Received: by mail04.mail.aol.com (1.37.109.11/16.2) id AA278524600; Sun, 12 Feb 1995 13:43:20 -0500 Date: Sun, 12 Feb 1995 13:43:20 -0500 From: Telford001@aol.com Message-Id: <950212134241_19831226@aol.com> To: ipng@sunroof.Eng.Sun.COM Cc: 0007387601@mcimail.com, Telford001@aol.com Subject: Re: (IPng) Mediocrity Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM X-From: bill.simpson@um.cc.umich.edu (William Allen Simpson) Sender: owner-ipng@sunroof.Eng.Sun.COM Reply-to: ipng@sunroof.Eng.Sun.COM To: ipng@sunroof.Eng.Sun.COM Last year saw the formation of the IPv6 WG from the forced destruction of SIPP -- which won the design competition technically, but lost the final event politically. Since, we have seen the repeated ravages of "design by committee". No opinion too trivial, no thought required, no vision, no common sense. Fields ever bigger, processing times ever slower. The Neighbor Discovery design vision was developed among a small number of architects, which looked at the current environment, and asked for a reduction in latency, self-configuration of both name and address, mobility support, rapid black-hole detection, and a common solution over multiple media. Over the months, the IPv6 committee has eviscerated Neighbor Discovery. ARP latency was restored. Mobility support was removed. Black-hole detection is optional. Support for other media than ethernet is removed. All that is left is a simple ARP replacement, without innovation, coupled to Router Discovery, which although rarely implemented has the benefit of being old. One pedant summarized the position -- "ARP has always been good enough". As to self-configuration, the committee expanded the methods to three, instead of consolidating -- passive stateless, active stateless, and stateful (DHCPv6). Despite the agreement within the DNSIND WG on Wednesday, auto-registration with DNS is "too new" to be acceptable by the conservative IPv6 members, which apparently prefer good old hand configuration of host files, thank you very much. The most positive advance was a general agreement to eliminate the inverse DNS mapping in favor of querying nodes directly. Objections were raised, of course, because each node would have to know its name, which is no longer a requirement of Neighbor Discovery. I am so depressed as to be physically ill.... Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 13 20:44:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26680; Mon, 13 Feb 95 20:44:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26674; Mon, 13 Feb 95 20:44:03 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28870; Mon, 13 Feb 1995 20:37:11 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA14295; Mon, 13 Feb 95 20:37:12 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA23628; Mon, 13 Feb 95 20:33:19 -0800 Received: by xirtlu.zk3.dec.com; id AA09499; Mon, 13 Feb 1995 23:32:23 -0500 Message-Id: <9502140432.AA09499@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Mediocrity In-Reply-To: Your message of "Sat, 11 Feb 95 16:56:24 GMT." <1257.bill.simpson@um.cc.umich.edu> Date: Mon, 13 Feb 95 23:32:17 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, I hope this helps because you have done a great thing with IPv6 system discovery in the IETF. --------------------------- Response ---------------------- This is how I felt when Paul Francis's design of EIDs and PIP routing headers were kaboshed at an IPng Directorate meeting in Chicago June 1994, and we moved to 128bits. I felt ill too because I thought that was the most advanced feature of taking both SIP and PIP and creating what I thought was the most elegant Internet Model for the late 90's and into the year 2000. But as much as I liked it I had to admit that I was supporting virgin territory within networking with the EID and forward-chains from PIP. We all have to give up parts for the whole often in many aspects of life and this always makes me real ill everytime. Mediocrity is going to be the case any time you build a standard IMHO, because you must solve the most general case when there is an engineering trade-off to be made. Unless performance is going to suffer by an order of magnitude or a large cost is going to be incurred, such as my utter disgust, and complete distaste of the IETF making IPv6 security being mandatory to have in all IPv6 implementations. I think this could put Embedded Systems Vendors out of business and I have a real wonder if the light switch can handle and the MD5 algorithm. And I bet Steve still believes 8 bytes is right. The point is we all carry some baggage to achieve IPv6 consensus. Its just the way it is. Sometimes we win and sometimes we loose. But the reason I let it go was I could not prove the SIP+PIP theory with an implementation, at that time anyway. Before I respond to your concerns I believe that what we are doing is trying to get a base set of standards to proposed standard which you know that I did not support until the last 1/2 hour of the IETF interim meeting last week at XEROX PARC. One reason I did give in to the majority was that I hope it causes implementations to take place for IPv6 which are void now (e.g. no one is ready for IPv6 testing at Danvers unfortuneately). The second reason is that these are only "Proposed" and they are not cast in concrete and no vendor should take them to be a done deal until we see some serious interoperability testing. Especially in the area of System Discovery. Thats why we will build prototypes and not products because IPv6 is still an experiment as far as real implementation interoperability. All the architects and politians in the world can say IPv6 is done but until we test the specs its just theory. And thats when us engineers pull in our weight in the IETF and have a hell of a lot to say about what is and what is not a standard. Or else the ETF is defunct and we may as well go start a new IETF. But I believe that will not happen. As to your concerns: ARP like model. The question here is what functionality did ARP provide that MUST be present in IPv6. If its not needed and is superceded with a better solution then I would think that the WG would support you. Try asking folks what they want functionally from ARP and see if you can provide it as an idea? Other than Ethernet. I don't think that has happened. I think people felt that the most common link requirements should be part of the base packet and those that are not should be extensions. The question that is valid; has the WG made the wrong assumption about commonality and large use of a particular datalink. If we have made an error we should fix that. Mobility: I don't think the WG did not want to support Mobility its that we have three drafts to consider and each could affect Mobility in different ways. We MUST get Mobility into System Discovery while its sitting at Proposed Standard. I give you my word I will go hand in hand with you to the IESG to get this done if we get any crap about it. The reason I wanted the Mobility moved out was because I want to understand the affect of all three proposals on IPv6. To leave your solution in there would mean we have to deal with it now. It was my impression with the rush to get to Proposed Standard that Technical Discussion was put on hold in System Discovery. At least thats my reading of what went down on Mobility in System Discovery. Autoconfig: Well I have a problem here too. But I am going to assume the IETF will do the "right thing". We are moving the stateless autoconfig to Proposed and mention the work for DYN DNS and DHCPv6 in process. As you know the authors are hoping to hit proposed standard (thomson-bound-rehkter) after the July IETF. Hopefully the rest of autoconfig and dyn dns will reach Draft Standard at the same time as the stateless because IMHO the market could care less about "just" having stateless and no statefull, and worst yet my reading of the market is any autoconfig without autoregistration is useless. So in this area we agree 80%. But I do think we need stateless autoconfig, which is where I think we disagree. Black Hole Detection: I thought this was to stay in? Why is it gone? Most of All: You should be very proud to have put together what will be the Internet's next generation protocol System Discovery and the person who lead and integrated all ideas into a coherent architecture and model we were able to achieve consensus on in the IETF. I think you have done a good job. Sometimes the conversations were a bit tough, but thats just the way it goes sometimes. take care and don't be ill, feel good for what you did get done, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 13 21:31:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26699; Mon, 13 Feb 95 21:31:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26693; Mon, 13 Feb 95 21:31:24 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00697; Mon, 13 Feb 1995 21:24:31 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA18256; Mon, 13 Feb 95 21:24:33 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA26504; Mon, 13 Feb 95 21:20:25 -0800 Received: by xirtlu.zk3.dec.com; id AA09999; Tue, 14 Feb 1995 00:19:39 -0500 Message-Id: <9502140519.AA09999@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) A thought on addressing In-Reply-To: Your message of "Tue, 07 Feb 95 19:24:18 +0200." <9502071024.AA20012@necom830.cc.titech.ac.jp> Date: Tue, 14 Feb 95 00:19:33 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Masataka, Your issue with Multihoming points to a hole. But do you accept the rest of the draft? UID will not be done in our lifetime in the IETF IMHO. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 13 23:01:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26723; Mon, 13 Feb 95 23:01:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26717; Mon, 13 Feb 95 23:01:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04595; Mon, 13 Feb 1995 22:54:20 -0800 Received: from sgigate.sgi.com by Sun.COM (sun-barr.Sun.COM) id AA27918; Mon, 13 Feb 95 22:54:15 PST Received: from sgihub.corp.sgi.com (sgihub.corp.sgi.com [192.26.51.188]) by sgigate.sgi.com (940519.SGI.8.6.9/8.6.4) with ESMTP id WAA08662; Mon, 13 Feb 1995 22:54:14 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for <@sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com> id WAA16821; Mon, 13 Feb 1995 22:54:13 -0800 Received: from gauss.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com id AA02074; Mon, 13 Feb 95 22:53:50 -0800 Received: from localhost by gauss.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id WAA05211; Mon, 13 Feb 1995 22:53:49 -0800 Message-Id: <199502140653.WAA05211@gauss.asd.sgi.com> From: leedom@gauss.asd.sgi.com (Casey Leedom) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) A thought on addressing Date: Mon, 13 Feb 1995 22:53:48 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM | Date: Wed, 8 Feb 95 11:23:30 JST | From: Masataka Ohta | | > | Date: Tue, 7 Feb 95 19:24:18 JST | > | From: Masataka Ohta | > | | > | And, the only workable solution is, it seems to me, UID based ones. | > | > Could you briefly explain what you mean here? | | | To make IP address consist of a globally unique, but unroutable, ID | and a hierarchically routable parts. Both can be 8 byte long. Hhmmm, I couldn't find an archive of the mailing list in ftp.parc.xerox.com:/pub/ipng. I presume it must be elsewhere. In the mean time let me just boldly guess that you mean that: 1. The globally unique part of a UID would be static and unchanging (in general for a ***host***)? 2. The hierarchically routable part of a UID would change whenever an ***interface*** was moved from one provider connection to another? (Or would it change whenever routes in the network changed???) 3. Host addresses would be looked up via the globally unique part of a UID. That is, a ``hostname'' would be translated into a fairly static, globally unique ***host*** ID and then some lookup service (like DNS?) would be used to get a [list of?] complete UIDs? How would you encode hierarchically routing information when the network isn't a tree? Or is the hierarchically routable part sender relative? Somewhat like the ``provider lose source route'' proposal I heard about recently (i.e. ``well first send it to this autonomous system, then this one, then ...'') | > | > 5.4.1 Solution 1 | > | > | > | > One possible solution is for each multi-homed organization to obtain | > | > its IPv6 address space independently of the providers to which it is | > | > attached. | > | | > | This does not scale. | > | > Why doesn't this scale? (I'm honestly curious; not offering | > criticism.) | | That is already documented in the latter paragraphs of the same section: | ... Ah, it doesn't scale in the sense of routing. Your proposition is that if network address spaces are not allocated/structured at least partly hierarchically that the routing problem will become impossible? That is, core backbone routers are already overwhelmed with too many routes that have no real address to *rough* topological correlation? And the UID solution which embeds topological routing information solves at least part of this problem (based on how close the hierarchically routable part of the UID gets you to the host? If I'm even vaguely close, what would happen in the midst of major network topological reconstructions? I.e. someone adds a new link between two distant parts of the net that weren't previously connected? What would happen if someone deletes a major link? What would happen durring routing flapps/storms? If the answers to these questions are too low level for the list, please feel free to simply send me pointers to the appropriate materials (or ignore me if I'm asking *really* stupid questions!) Casey ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 13 23:14:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26735; Mon, 13 Feb 95 23:14:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26729; Mon, 13 Feb 95 23:13:50 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05101; Mon, 13 Feb 1995 23:06:57 -0800 Received: from sgigate.sgi.com by Sun.COM (sun-barr.Sun.COM) id AA28873; Mon, 13 Feb 95 23:06:58 PST Received: from sgihub.corp.sgi.com (sgihub.corp.sgi.com [192.26.51.188]) by sgigate.sgi.com (940519.SGI.8.6.9/8.6.4) with ESMTP id XAA09734; Mon, 13 Feb 1995 23:06:53 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for <@sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com> id XAA17095; Mon, 13 Feb 1995 23:06:52 -0800 Received: from gauss.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com id AA02422; Mon, 13 Feb 95 23:06:52 -0800 Received: from localhost by gauss.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id XAA05268; Mon, 13 Feb 1995 23:06:50 -0800 Message-Id: <199502140706.XAA05268@gauss.asd.sgi.com> From: leedom@gauss.asd.sgi.com (Casey Leedom) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Mediocrity Date: Mon, 13 Feb 1995 23:06:49 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, I liked your response very much. But it strikes me that, since I've joined this list and watched the discussions go by, this is one of the very few times I've seen it stated that What we're doing right now is just a proposal. It will have to be verified by real, working implementations that demonstrate interoperability. We're drop various proposed mechanisms only when it seems obvious that they either can't be implemented or don't provide enough functionality to justify adding their cost to the core specification. I.e. that this is a pragmatic, iterative *engineering* development and standardization effort. This core philosophy is something that's always attracted me to the IETF and its work (as compared with standards efforts that focus on weird territorialism and political power plays and leaving implementation as an exercise for the reader). I'd like to see this reiterated more often. I got the distinct impression from Bill's letter that some of this philosophical experimentalism had gotten lost in the IPng effort. I sent him a personal note of encouragement for having the passion to try to ``make things better.'' I honestly don't know enough about the technical details to evaluate whether what he discussed would have made things better or not, but that passion to try to come up with the best possible, pragmatic engineering solution is valuable! Casey ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 14 08:22:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26932; Tue, 14 Feb 95 08:22:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26926; Tue, 14 Feb 95 08:22:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10658; Tue, 14 Feb 1995 08:15:31 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA01943; Tue, 14 Feb 95 08:15:30 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA16679; Tue, 14 Feb 95 08:05:16 -0800 Received: by xirtlu.zk3.dec.com; id AA23768; Tue, 14 Feb 1995 11:05:12 -0500 Message-Id: <9502141605.AA23768@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Mediocrity In-Reply-To: Your message of "Mon, 13 Feb 95 23:06:49 PST." <199502140706.XAA05268@gauss.asd.sgi.com> Date: Tue, 14 Feb 95 11:05:05 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Casey, >> What we're doing right now is just a proposal. It will have to be >> verified by real, working implementations that demonstrate >> interoperability. We're drop various proposed mechanisms only when it >> seems obvious that they either can't be implemented or don't provide >> enough functionality to justify adding their cost to the core >> specification. >I.e. that this is a pragmatic, iterative *engineering* development and >standardization effort. This core philosophy is something that's always >attracted me to the IETF and its work (as compared with standards efforts >that focus on weird territorialism and political power plays and leaving >implementation as an exercise for the reader). > I'd like to see this reiterated more often. Just as a historical note regarding other standards. Pre-OSI standards were done as MAP/TOP in 1983-1985 (long before they were standardized as ISO Standards) in the Automotive and Discrete Manufacturing Industry and by some industry members of the European Computer Manufacturing Association (ECMA). For IEEE 1003.1-.XX (POSIX Suite) there were also implementations prior to the ISO Standard. So the "myth" and "marketing hype" that the IETF is the only standards group that does implementations before standards is exactly that, a myth. NIST has been doing this in the U.S. for years too. But the IETF has been able to take existing design and code based on open public domain software like BSD UNIX and change/add to the basic networking paradigm of DARPA work of long ago. Another important difference in the IETF is that it is very near term market conscious which directly implies engineering conscious as opposed to architecture or standards conscious. This is why we see the input to keep the ARP model in System Discovery. Its the process of not breaking existing customer needs and uses today. This was done in POSIX too fyi. We have had this battle in IPng which is engineering vs architecture. Right now engineering needs are losing, simply because we have not been able to test all this with software engineering principles one of which is testing. Thank god Proposed is not in concrete and only means its in the standards track. But realize we are this time changing the OS paradigms a bit with IPv6 from BSD 4.4 and that is a core differentiator in IPv6. Plus we are adding future enablers like Flow ID, End-to-End Option, and access to the Source Route in the IPv6 BSD API as a Model. These will affect implementation design to make sure these enablers work and will not break core designs later. IPv6 transitiion mechanisms have this problem in spades because by definition it is an enabler in the IPv6 protocol suite of drafts. In the case of IPv6 right now the IETF is behind the early processes of ISO OSI and IEEE POSIX before they went to proposed standard because we have tested none of the standards with implementations. So to keep the engineering part of the IETF for IPv6 I hope we go to Stockholm IETF with some implementation experience to fix that which we propose that is not going to work. This is why I felt Stockholm was a better point of reference to go for proposed standards. There is no engineering or market rush to get IPv6 out the door that we could not have waited until July 95. Other than "political" and the IETF change-of-the-guard for IPng reasons. Which is bogus because if management changes the troops should still function. If they don't that is a problem we are not going to avoid because we have made a set of IPng drafts Proposed Standard. The one engineering piece that hurt OSI real bad was transition. This is an engineering variable that the IETF has not had to deal with on the scale that exists to move from IPv4 to IPv6. We have to provide flexibility as engineers in the software paradigm to accomodate end user choices. Mandates don't work in the end user market. This means we have to have a set of transition mechanisms to move end users to IPv6 or permit them to coexist with IPv4 for a long time, which causes translation eventually. More directly take the interfaces from BSD 4.4 paradigm in the network kernel. Those have to be completely altered to support IPv6 and autoconfiguration. Now we have a time-out and deprecated address. When someone says just keep incoming connections available for deprecated addresses (other than timed-out) and have no clue about what that means to the ifnet structure, its timers, and coordination with the TCP/UDP PCBs inside an implementation I have to say whoops listen up. Which I will do once the Address Stateless Autoconfiguration comes out in the next iteration. Doing this simply may be too costly and again as an engineer I need to be worried about cost (or as an Architect IMHO). The IETF also does have a bit of an academic flavor which is as bad as the starchy conservatism of other standards bodies. Either way it causes some politics and egoism that inteferes with real engineering. In addition as I learn more about how the committees are formed and how this process works organizationaly I am appalled (as was brought out at our IPng meeting). All these folks should be elected by the community based on their contributions and work in the IETF. This I guess will be open for discussion in the POISE WG soon which will be good to participate in when it starts. For example Scott and Allison have done a good job in the IETF for IPng and they would be re-elected I am sure. And those who chartered them to build an IPng Area had vision on how to solve the problem and they should be re-elected. Steve Deering and Bob Hinden IMHO picked the right core for IPv6 and that should tell us something too. There is a way to know who did what and why in the IETF for WG Chairs, IESG, and the IAB. A final comment is that what we do here will affect perception in the market of what we have done with the proposed standards. For example I was very quick to get Steve Deering to change Sue's Address Configuruation title to "STATELESS Address Autoconfiguration" so perception is set CORRECTLY in the title. I don't think just providing stateless as the ONLY solution INITIALLY for IPv6 is acceptable. To put my work where my mouth is I spent with Sue and Yakov most of January (about 70 person hours) getting a first draft out of DHCPv6 and we did close to the same to get DNS DYN Updates out. But we won't be able to reference that work in the STATELESS proposed standard. So there is no pointer to anyone reading the proposed standard who is not an IETF member and aware of all the activity about IPv6. I think this is bogus and I thought so at the July Toronto IETF after the IPng announcement regarding the autoconfig charter (which I believe was politically set because of reasons that are beyond me or that I probably don't care about), which did not work anyway in the community. Thanks to Sue's hard work we do have a working stateless autoconfig draft that I "think" is implementable, with TBD on how our engineering interfaces will look in an implementation. We will do our best (and others who may be lined up) to get DHCPv6 and DYN DNS basic prototypes up for Stockholm but I admit that is pushing it with the other IPv6 basic protocol work we all have to do in the implementors community. Stateless has to be right first and IMHO before that we need System Discovery up and running. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 14 09:36:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26975; Tue, 14 Feb 95 09:36:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26969; Tue, 14 Feb 95 09:36:11 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18524; Tue, 14 Feb 1995 09:29:18 -0800 Received: from melimelo.enst-bretagne.fr by Sun.COM (sun-barr.Sun.COM) id AA19693; Tue, 14 Feb 95 09:29:09 PST Received: from rsm.enst-bretagne.fr by melimelo.enst-bretagne.fr (5.67b8/090294); Tue, 14 Feb 1995 18:26:47 +0100 Received: from marple by rsm.enst-bretagne.fr (4.1/SMI-4.1) id AA15029; Tue, 14 Feb 95 18:35:24 +0100 From: lher@rennes.enst-bretagne.fr (Demed L'Her) Received: by marple (4.1/rsalz-13-nov-89); Tue, 14 Feb 95 18:35:23 +0100 Date: Tue, 14 Feb 95 18:35:23 +0100 Message-Id: <9502141735.AA07743@marple> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPng newsgroup Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hello, Does anybody know if there is an IPng Newsgroup ? Thanx ______________________________________________________________ | Demed L'HER / eleve Reseaux & Systemes d'Information | | Ecole Nationale Superieure des Telecom de Bretagne | +------------------------------------------------------------+ | E-mail : lher@rennes.enst-bretagne.fr | | WWW : http://www-rennes.enst-bretagne.fr/~lher | | snail mail : D. L'Her - eleve RSIFI | | ENST de Bretagne | | BP 78 | | 35512 CESSON-SEVIGNE Cedex | | FRANCE | | fax : (33) 99.12.70.19 | |____________________________________________________________| ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 14 09:51:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26987; Tue, 14 Feb 95 09:51:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26981; Tue, 14 Feb 95 09:51:43 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20669; Tue, 14 Feb 1995 09:44:49 -0800 Received: from melimelo.enst-bretagne.fr by Sun.COM (sun-barr.Sun.COM) id AA23491; Tue, 14 Feb 95 09:44:48 PST Received: from rsm.enst-bretagne.fr by melimelo.enst-bretagne.fr (5.67b8/090294); Tue, 14 Feb 1995 18:42:30 +0100 Received: from marple by rsm.enst-bretagne.fr (4.1/SMI-4.1) id AA15233; Tue, 14 Feb 95 18:51:06 +0100 From: lher@rennes.enst-bretagne.fr (Demed L'Her) Received: by marple (4.1/rsalz-13-nov-89); Tue, 14 Feb 95 18:51:05 +0100 Date: Tue, 14 Feb 95 18:51:05 +0100 Message-Id: <9502141751.AA07747@marple> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) providers-based addresses Cc: lher@rennes.enst-bretagne.fr Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have read that "unlike IPv4 addresses, most IPv6 addresses are not centraly allocated" (McGregor94). These addresses will be allocated by the "network providers" if I am correct. But who will be those "network providers" ? Some commercial companies ? (AT&T, Sprint, BT, France Telecom ...?) Does it mean that one will have to get in a commercial process to get an IPng address ? (I ask that because of the vocabulary used in the RFC : subscriber/ provider) Has the IETF (or IANA ?) already allocated some provider-based addresses, or received some applications ? Where can I find further information regarding this ? Thank you for your help. DL ______________________________________________________________ | Demed L'HER / eleve Reseaux & Systemes d'Information | | Ecole Nationale Superieure des Telecom de Bretagne | +------------------------------------------------------------+ | E-mail : lher@rennes.enst-bretagne.fr | | WWW : http://www-rennes.enst-bretagne.fr/~lher | | snail mail : D. L'Her - eleve RSIFI | | ENST de Bretagne | | BP 78 | | 35512 CESSON-SEVIGNE Cedex | | FRANCE | | fax : (33) 99.12.70.19 | |____________________________________________________________| ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 14 13:54:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27131; Tue, 14 Feb 95 13:54:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27048; Tue, 14 Feb 95 11:21:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05142; Tue, 14 Feb 1995 11:15:03 -0800 Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA15414; Tue, 14 Feb 95 11:15:04 PST Received: (jjohnson@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id LAA28711 for ipng@sunroof.eng.sun.com; Tue, 14 Feb 1995 11:15:03 -0800 Date: Tue, 14 Feb 1995 11:15:03 -0800 From: "Jeffrey T. Johnson" Message-Id: <199502141915.LAA28711@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Textual Representation of IPv6 addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The SNMPv2 Working Group is in the midst of an interim meeting, and I have been tasked with determining the DISPLAY-HINT to be associated with an IPv6 address. I have preused the archives of this list, as well as the internet drafts. I want to make sure that I've got this right (and I know from the archives that you'll tell me if I'm wrong ;-) I see three different ways of representing an IPv6 address: IPv4 compatable 0:0:0:0:0:ffff:ddd.ddd.ddd.ddd IPv4 mapped 0:0:0:0:0:0:ddd.ddd.ddd.ddd IPv6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx ddd is 1 to 3 decimal digits xxxx is 1 to 4 hex digits Furthermore, in the "xxxx" case I have seen some instances where a "0" is suppressed, and other cases (i.e. the bsd api draft) where the definition states that there must be at least one digit. I'd like to get some clarificaion. I'd also like clarification on whether alpha hex digits should be upper or lower case. The second problem is how should transport addresses (TCP/IPv6) be represented. For IPv4, the convention is to separate the port from the address by a colon, i.e. ddd.ddd.ddd.ddd:ppppp where ppppp is 1 to 5 decimal digits. Is the IPv6 way something like: xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ppppp, or something different. thanks for any input /jeff -- Jeff Johnson | Cisco Systems, Inc | voice: (408) 526-7789 Software Engineer | 170 West Tasman Drive | fax: (408) 526-4860 Router Management | San Jose, CA 95134 | email: jjohnson@cisco.com The difference between ignorance and apathy? I don't know and I don't care ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 14 15:03:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27225; Tue, 14 Feb 95 15:03:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27219; Tue, 14 Feb 95 15:03:10 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12328; Tue, 14 Feb 1995 14:56:16 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA05830; Tue, 14 Feb 95 14:56:15 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10773; 14 Feb 95 17:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipsec@ans.net, ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-karn-photuris-00.txt Date: Tue, 14 Feb 95 17:27:19 -0500 Message-Id: <9502141727.aa10773@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Photuris Key Management Protocol Author(s) : P. Karn Filename : draft-karn-photuris-00.txt Pages : 13 Date : 02/13/1995 Photuris is a proposed key management protocol that is derived in part from the Diffie-Hellman work. It is being considered for use as a key management protocol for use with IPv4 and 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-karn-photuris-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-karn-photuris-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-karn-photuris-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19950213114407.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-karn-photuris-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-karn-photuris-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950213114407.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 14 22:58:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27736; Tue, 14 Feb 95 22:58:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27729; Tue, 14 Feb 95 22:58:40 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22489; Tue, 14 Feb 1995 22:51:45 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA13008; Tue, 14 Feb 95 22:51:44 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA22831; Tue, 14 Feb 95 22:10:27 -0800 Received: by xirtlu.zk3.dec.com; id AA13913; Wed, 15 Feb 1995 01:09:38 -0500 Message-Id: <9502150609.AA13913@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Textual Representation of IPv6 addresses In-Reply-To: Your message of "Tue, 14 Feb 95 11:15:03 PST." <199502141915.LAA28711@feta.cisco.com> Date: Wed, 15 Feb 95 01:09:32 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >IPv4 mapped 0:0:0:0:0:0:ddd.ddd.ddd.ddd This one is deleted for now per the IETF IPng Interim Meeting last week Feb 9-10. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 14 23:05:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27748; Tue, 14 Feb 95 23:05:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27742; Tue, 14 Feb 95 23:05:12 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22709; Tue, 14 Feb 1995 22:58:17 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA13553; Tue, 14 Feb 95 22:58:19 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA22525; Tue, 14 Feb 95 22:02:22 -0800 Received: by xirtlu.zk3.dec.com; id AA13841; Wed, 15 Feb 1995 01:01:30 -0500 Message-Id: <9502150601.AA13841@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: lher@rsm.enst-bretagne.fr Subject: Re: (IPng) providers-based addresses In-Reply-To: Your message of "Tue, 14 Feb 95 18:51:05 +0100." <9502141751.AA07747@marple> Date: Wed, 15 Feb 95 01:01:24 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I have read that "unlike IPv4 addresses, most IPv6 addresses are not centraly >allocated" (McGregor94). These addresses will be allocated by the "network >providers" if I am correct. But who will be those "network providers" ? >Some commercial companies ? (AT&T, Sprint, BT, France Telecom ...?) NO way is the strategy. What is McGregor94? Look on one of the Internet IDs and pull rekhter drafts and read those. I think the "vision" is there will be a central authority and then International Registries. But this is not figure out yet. >Does it mean that one will have to get in a commercial process to get an IPng >address ? (I ask that because of the vocabulary used in the RFC : subscriber/ >provider) No not necessarily. This could start an economic war. I suppose organizations could buy addresses from those who get blocks of them but I hope this is discouraged. No one should make profit on IPv6 addresses because they created nothing of value for the world. I would hope the world will fund as it does not an IANA or whatever to administer the address space for IPv6. >Has the IETF (or IANA ?) already allocated some provider-based addresses, >or received some applications ? No. Unless its not been announced to the public. Also we have no IETF Draft Standard for this let alone a complete Standard. >Where can I find further information regarding this ? Read Yakov Rekhter drafts and Bob Hinden Address Arch draft. These are being revised right now so you may want to wait a few weeks to pull new ones over. But you could search the drafts now. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 02:28:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27839; Wed, 15 Feb 95 02:28:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27833; Wed, 15 Feb 95 02:27:52 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28958; Wed, 15 Feb 1995 02:20:59 -0800 Received: from concorde.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA01432; Wed, 15 Feb 95 02:18:27 PST Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.9/8.6.9) with ESMTP id LAA04180 for ; Wed, 15 Feb 1995 11:18:22 +0100 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.8/8.6.6) with ESMTP id LAA24625; Wed, 15 Feb 1995 11:17:05 +0100 Message-Id: <199502151017.LAA24625@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Textual Representation of IPv6 addresses In-Reply-To: Your message of Wed, 15 Feb 1995 01:09:32 EST. <9502150609.AA13913@xirtlu.zk3.dec.com> Date: Wed, 15 Feb 1995 11:14:30 +0100 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In your previous mail you wrote: >IPv4 mapped 0:0:0:0:0:0:ddd.ddd.ddd.ddd This one is deleted for now per the IETF IPng Interim Meeting last week Feb 9-10. /jim => If such important things have been decided at the IETF IPng Interim Meeting last week we should have minutes ASAP! About the IPv6 address textual representation we need the exact syntax or better a parser source code in order to avoid ambiguities as in current IPv4 (try "127.011" :-). Regards Francis.Dupont@inria.fr PS: is an audio record available ? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 09:02:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27994; Wed, 15 Feb 95 09:02:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27988; Wed, 15 Feb 95 09:02:46 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20854; Wed, 15 Feb 1995 08:55:51 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA22595; Wed, 15 Feb 95 08:55:53 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.8/BARRNET-RELAY.1) id IAA27611; Wed, 15 Feb 1995 08:52:00 -0800 Received: from [192.216.126.207] (acacia) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA03435; Wed, 15 Feb 95 08:50:23 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Feb 1995 08:49:51 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: Re: (IPng) Textual Representation of IPv6 addresses Cc: bound@zk3.dec.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 1:09 AM 2/15/95, bound@zk3.dec.com wrote: >>IPv4 mapped 0:0:0:0:0:0:ddd.ddd.ddd.ddd > >This one is deleted for now per the IETF IPng Interim Meeting last week >Feb 9-10. Not exactly correct. The address defination for IPv4 mapped will stay in the addressing architecutre document. It may be usefull in the future. It will be removed from the current transition mechanisms document. Hope this helps. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 09:17:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28006; Wed, 15 Feb 95 09:17:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28000; Wed, 15 Feb 95 09:17:18 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22285; Wed, 15 Feb 1995 09:10:23 -0800 Received: from mentat.com by Sun.COM (sun-barr.Sun.COM) id AA25939; Wed, 15 Feb 95 09:10:22 PST Received: from leo.mentat.com ([192.88.122.132]) by mentat.com (4.1/SMI-4.1) id AA10184; Wed, 15 Feb 95 09:10:03 PST Date: Wed, 15 Feb 95 09:10:03 PST From: marc@mentat.com (Marc Hasson) Message-Id: <9502151710.AA10184@mentat.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Textual Representation of IPv6 addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM jjohnson@cisco.com writes: > > I see three different ways of representing an IPv6 address: > IPv4 compatable 0:0:0:0:0:ffff:ddd.ddd.ddd.ddd > IPv4 mapped 0:0:0:0:0:0:ddd.ddd.ddd.ddd > IPv6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx > Don't forget the double-colon for representing strings of 0s, wasn't sure thats what you referred to in your comment about 0 suppression. The text from the addressing architecture document: 2. Due to the method of allocating certain styles of IPv6 addresses, it will be common for there to be a number of zero bits in the middle of the address. In order to make writing this form easier, a special syntax is available to compress the zeros. The use of of two "::" indicate multiple groups of 16-bits of zeros. For example the multicast address: FF01:0:0:0:0:0:0:43 would be represented as: FF01::43 The "::" can only appear once in an address. The "::" can also be used to compress the leading zeros in an address. > The second problem is how should transport addresses (TCP/IPv6) be > represented. For IPv4, the convention is to separate the port from > the address by a colon, i.e. ddd.ddd.ddd.ddd:ppppp where > ppppp is 1 to 5 decimal digits. Is the IPv6 way something like: > xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ppppp, or something > different. I seem to recall something on this being discussed but can't find anything written down, perhaps someone else can. I think your proposal should work fine. As long as the double-colon notation can't be used as the last thing in an IPv6 address (cluster address?) there wouldn't be any ambiguity for a parser. To be more flexible/safer, though, perhaps we should have a different separator between the address and the port such as a "#"? -- Marc -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 09:27:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28036; Wed, 15 Feb 95 09:27:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28030; Wed, 15 Feb 95 09:27:20 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23504; Wed, 15 Feb 1995 09:20:25 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA28174; Wed, 15 Feb 95 09:20:26 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.8/BARRNET-RELAY.1) id JAA27777; Wed, 15 Feb 1995 09:20:25 -0800 Received: from [192.216.126.207] (acacia) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA03522; Wed, 15 Feb 95 09:18:50 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Feb 1995 09:18:17 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: Re: (IPng) Textual Representation of IPv6 addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Francis, >=> If such important things have been decided at the IETF IPng >Interim Meeting last week we should have minutes ASAP! Yes, I agree. We hope to get them out by the end of this week. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 09:32:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28048; Wed, 15 Feb 95 09:32:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28042; Wed, 15 Feb 95 09:32:27 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24127; Wed, 15 Feb 1995 09:25:31 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA29288; Wed, 15 Feb 95 09:25:31 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA17872; Wed, 15 Feb 95 09:18:43 -0800 Received: by xirtlu.zk3.dec.com; id AA27829; Wed, 15 Feb 1995 12:18:41 -0500 Message-Id: <9502151718.AA27829@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Textual Representation of IPv6 addresses In-Reply-To: Your message of "Wed, 15 Feb 95 11:14:30 +0100." <199502151017.LAA24625@givry.inria.fr> Date: Wed, 15 Feb 95 12:18:35 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Francis, > In your previous mail you wrote: >> >IPv4 mapped 0:0:0:0:0:0:ddd.ddd.ddd.ddd >> This one is deleted for now per the IETF IPng Interim Meeting last week >> Feb 9-10. >=> If such important things have been decided at the IETF IPng >Interim Meeting last week we should have minutes ASAP! >About the IPv6 address textual representation we need the exact syntax >or better a parser source code in order to avoid ambiguities as >in current IPv4 (try "127.011" :-). I agree with you. If we don't see it by Friday (Feb 17th) I think we should all start sending hate mail to the Chairs (Steve and Ross). This meeting was too important. I already did my trip report for work but I can't send that one out to the public. Basically what has happened is as follows for transition: 1. Create a new mechanisms draft which will contain encapsulation only for first cut at draft to go to proposed standard. The Transition overview type material will go in Hinden IPng Overview Info RFC. Add some routing context for the mechanism encapsulation draft. 2. Put this out within 3 weeks then we have 2 weeks to review. Then if no major objections this will become one of the proposed standards. [Note there will be about 13 drafts like this we will all have to read pretty soon]. Several issues were raised at the meeting regarding transition. The core ones were that: This is based on the draft-gilligan-ipv6-trans-01.txt spec. a) The translation was still not clean and needed clarity as to its relationship between encapsulation, the node types, and address types. b) The IPv4 Mapped Address was un-needed except for translation and there might be a better way to handle the address type for translation, one of which included overloading the IPv4 Compatible address. This concern also raised as the above the issue that the IPv4 Mapped Address created confusion in the existing mechanism spec and the table defining the type of nodes and the use. Two groups met offline at the end of the day: Group 1: Bob Hinden, Bob Gilligan, Ross Callon. Group 2: Jim Bound, Justin Walker, Tony Hain, Alex Conta, and Heather Gray. Ross Callon had also gave us all an anonymous memo and view of how to use the IPv6 address types to read that evening as homework assignment. We came back next day and Group 1 got to present first. They proposed what I stated above in #1 and #2. This mean't translation was not going to be part of the new spec which mean't that IPv4 Mapped Addresses were going to be part of this spec. Group 2 pretty much agreed and so they did not have to present their views. It was asked what about a translation and "real" routing spec and it was stated those would have to be done or you could treat it as added value. Now this a Jim (me) opinion part. As your (Francis) working on real code too you realize as I do this breaks some code. My feeling is translation is the last thing anyone will have to worry about for awhile. I think we need a translation spec but we don't need IPv4 Mapped Addresses. But I am not going to get into this discussion unless they get put back in the spec at Danvers meeting. We can wait on this one. I think those of us writing code have now some time and freedom to some experimenting to see what will really work. As far as your request for address notation I hope this is in the new Address Arch spec from Bob Hinden coming. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 09:50:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28061; Wed, 15 Feb 95 09:50:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28055; Wed, 15 Feb 95 09:50:06 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26220; Wed, 15 Feb 1995 09:43:11 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03030; Wed, 15 Feb 95 09:43:12 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA18428; Wed, 15 Feb 95 09:35:25 -0800 Received: by xirtlu.zk3.dec.com; id AA28225; Wed, 15 Feb 1995 12:35:21 -0500 Message-Id: <9502151735.AA28225@xirtlu.zk3.dec.com> To: hinden@ipsilon.com (Bob Hinden) Cc: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Subject: Re: (IPng) Textual Representation of IPv6 addresses In-Reply-To: Your message of "Wed, 15 Feb 95 08:49:51 PST." Date: Wed, 15 Feb 95 12:35:15 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob, >>IPv4 mapped 0:0:0:0:0:0:ddd.ddd.ddd.ddd > >This one is deleted for now per the IETF IPng Interim Meeting last week >Feb 9-10. >Not exactly correct. The address defination for IPv4 mapped will stay in the addressing architecutre document. It may be usefull in the future. It will be removed from the current transition mechanisms document. > >Hope this helps. WHOA. Hold on here and lets talk. #1: Unless its in the transition spec it has no point of reference in any draft or in any standard. The address architecture spec will be going to Proposed Standard too. This means anything you reference MUST also be an RFC or whatever. You have no way now to reference an IPv4 Mapped Address. How can you put it in your draft according to the IETF rules? I ask for two reasons one is I don't think you have a reference the other is there are other drafts that could use this trick to reference other work, if you can justify it. #2: The WG did not agree to do this in reviewing your spec after the transition decision. Hence, you can put it in as Author but expect to see a major objection when you go to proposed standard or in our last call review (whatever). #3 The address is simply not needed so you have no technical reason to keep it in the Address Spec? Whats your reason? Unless your spec is not going to proposed and going to Historical (tongue and cheek of course). We got rid of it Bob. Now if you want to make this an issue fine but you should have fought for this at the Meeting not now on the mailing list. If you do want to get into this I am disappointed because I think I would have killed it for now had I not given up when we made the decision on what the next transition draft will be. This was very important but I felt it was gone so let it go. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 10:27:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28091; Wed, 15 Feb 95 10:27:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28085; Wed, 15 Feb 95 10:27:27 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01529; Wed, 15 Feb 1995 10:20:32 -0800 Received: from alink-gw.apple.com by Sun.COM (sun-barr.Sun.COM) id AA11026; Wed, 15 Feb 95 10:20:19 PST Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA19761; Wed, 15 Feb 95 10:20:13 -0800 for ipng@sunroof.eng.sun.com Received: from lilith.lansys.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef) id AA25183; Wed, 15 Feb 1995 10:18:47 +0800 for ipng@sunroof.eng.sun.com Received: (justin@localhost) by lilith.lansys.apple.com (8.6.9/A/UX 3.1) id KAA04015; Wed, 15 Feb 1995 10:20:58 -0800 Date: Wed, 15 Feb 1995 10:20:58 -0800 From: "Justin C. Walker" Message-Id: <199502151820.KAA04015@lilith.lansys.apple.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com In-Reply-To: bound@zk3.dec.com's message of Wed, 15 Feb 95 01:09:32 -0500 <9502150609.AA13913@xirtlu.zk3.dec.com> Subject: (IPng) Textual Representation of IPv6 addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> >IPv4 mapped 0:0:0:0:0:0:ddd.ddd.ddd.ddd >> >> This one is deleted for now per the IETF IPng Interim Meeting last week >> Feb 9-10. My notes have us removing its definition and usage, but keeping it as a place-holder (in the addressing architecture spec). A minor point, to be sure... Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple Business Systems | of boredom Apple Computer, Inc. | For trying to change the system 10500 North De Anza Blvd | from within Cupertino, CA 95014 | LC --------------------------------------*------------------------------------ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 10:58:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28110; Wed, 15 Feb 95 10:58:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28104; Wed, 15 Feb 95 10:58:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06501; Wed, 15 Feb 1995 10:51:11 -0800 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA18184; Wed, 15 Feb 95 10:50:48 PST Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA21863; Wed, 15 Feb 95 13:34:19 EST Received: from cabernet.wellfleet by wellfleet (4.1/SMI-4.1) id AA03764; Wed, 15 Feb 95 13:47:03 EST Date: Wed, 15 Feb 95 13:47:03 EST From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9502151847.AA03764@wellfleet> To: hinden@ipsilon.com, bound@zk3.dec.com Subject: Re: (IPng) Textual Representation of IPv6 addresses Cc: ipng@sunroof.Eng.Sun.COM, rcallon@pobox.wellfleet.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >>IPv4 mapped 0:0:0:0:0:0:ddd.ddd.ddd.ddd > > > >This one is deleted for now per the IETF IPng Interim Meeting last week > >Feb 9-10. > > >Not exactly correct. The address defination for IPv4 mapped will stay in the > >addressing architecture document. It may be useful in the future. It will > >be removed from the current transition mechanisms document. > > > >Hope this helps. > > WHOA. Hold on here and lets talk. > > #1: Unless its in the transition spec it has no point of reference in > any draft or in any standard. The address architecture spec will be > going to Proposed Standard too. This means anything you reference MUST > also be an RFC or whatever. You have no way now to reference an IPv4 > Mapped Address. How can you put it in your draft according to the IETF > rules? I ask for two reasons one is I don't think you have a reference > the other is there are other drafts that could use this trick to > reference other work, if you can justify it. > > #2: The WG did not agree to do this in reviewing your spec after the > transition decision. Hence, you can put it in as Author but expect to > see a major objection when you go to proposed standard or in our last > call review (whatever). > > #3 The address is simply not needed so you have no technical reason to > keep it in the Address Spec? Whats your reason? Unless your spec is > not going to proposed and going to Historical (tongue and cheek of > course). > > We got rid of it Bob. Now if you want to make this an issue fine but > you should have fought for this at the Meeting not now on the mailing > list. If you do want to get into this I am disappointed because I think > I would have killed it for now had I not given up when we made the > decision on what the next transition draft will be. This was very > important but I felt it was gone so let it go. Jim; The precise wording that I recall from the interim meeting was that the 0:0:0:0:0:0: address was reserved for future use by the transition mechanism (with the expectation that this might end up being defined and used with a translation mechanism). However, I think that all that the addressing documents need to say is that the 0:0:0:0:0:0 prefix is reserved. Similarly, all the transition mechanisms document needs to say is that translation is for further study. In the hope of clarifying the discussion for other folks: What happened at the Interim meeting wrt transition was that we discovered (or perhaps admitted) that we do not have agreement on translation, including the fact that we don't have agreement on precisely how to define the "0:0:0:0:0:0:" IPv6 address used with translation. In fact, we don`t even have consensus on whether this separate address form is even needed for translation. However, we do have consensus and optimism on the rest of the translation mechanisms, including dual stack, DNS, manually configured encapsulation, and automatic encapsulation mechanisms, plus the precise definition of the "0:0:0:0:0:FF:" IPv6 address which is used with automatic encapsulation. Also, the very first deployment of IPv6 hosts will use some combination of encapsulation and dual stack. This implies that it is useful and sufficient at this stage to document those mechanisms which we agree on. There were a variety of opinions regarding how critical it is to keep working and define and document a precise and agreed translation mechanism. However, I don`t recall anyone either proposing that we now know how to define this, nor that we slow down the rest of the transition mechanisms to continue argueing over translation. Ross ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 13:11:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28157; Wed, 15 Feb 95 13:11:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28151; Wed, 15 Feb 95 13:11:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25968; Wed, 15 Feb 1995 13:04:29 -0800 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by Sun.COM (sun-barr.Sun.COM) id AA04912; Wed, 15 Feb 95 12:05:29 PST Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA01259; Wed, 15 Feb 95 15:05:23 EST Date: Wed, 15 Feb 95 15:05:23 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9502152005.AA01259@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) IPv4 address representation Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM 1) No decision at any meeting is final until after folks on the mailing list who did not attend the meeting have an opportunity to read, comment on, and possibly object to what the folks at that meeting agreed to. This is per normal IETF rules and YES I have objected via lists in the past (most notably to some Danish insanity regarding MIME character sets about 3 years back). 2) The list has not seen any minutes yet, so the concrete is not poured. 3) Hinden is quite correct per IETF rules to raise issues such as this onto the mailing list. I'm not pro or con on this issue, but I'm not about to be railroaded by anyone. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 13:16:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28169; Wed, 15 Feb 95 13:16:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28163; Wed, 15 Feb 95 13:16:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27132; Wed, 15 Feb 1995 13:09:42 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA06497; Wed, 15 Feb 95 12:13:34 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA27441; Wed, 15 Feb 95 11:52:53 -0800 Received: by xirtlu.zk3.dec.com; id AA01525; Wed, 15 Feb 1995 14:52:43 -0500 Message-Id: <9502151952.AA01525@xirtlu.zk3.dec.com> To: rcallon@pobox.wellfleet.com (Ross Callon) Cc: hinden@ipsilon.com, bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Textual Representation of IPv6 addresses In-Reply-To: Your message of "Wed, 15 Feb 95 13:47:03 EST." <9502151847.AA03764@wellfleet> Date: Wed, 15 Feb 95 14:52:37 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ross, I don't recall agreeing to that, but it appears you, Justin and Bob have the same notes. So I am just drawing a blank on this agreeement. I can deal with saying as you suggested that the 00000 prefix is reserved. But calling it an IPv4 Mapped Address is bogus. And this is OK to put in the spec as it needs no reference either. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 15:29:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28365; Wed, 15 Feb 95 15:29:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28359; Wed, 15 Feb 95 15:29:03 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20930; Wed, 15 Feb 1995 15:22:08 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA29306; Wed, 15 Feb 95 11:39:37 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA17776; Wed, 15 Feb 1995 20:39:22 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA10433; Wed, 15 Feb 1995 20:39:21 +0100 Message-Id: <9502151939.AA10433@dxcoms.cern.ch> Subject: Re: (IPng) Textual Representation of IPv6 addresses To: ipng@sunroof.Eng.Sun.COM Date: Wed, 15 Feb 1995 20:39:21 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9502151735.AA28225@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Feb 15, 95 12:35:15 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob, If I remember the addressing spec, ALL addresses with first byte 00000000 are marked RESERVED except for :: and ::FFFF:. If you simply remove the reference to ::, that encoding automatically remains RESERVED. What could be better than that? Brian [Remember my white paper: "translation considered harmful"? I'm celebrating, I confess. Simplification is good.] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 16:05:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28385; Wed, 15 Feb 95 16:05:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28344; Wed, 15 Feb 95 15:25:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20443; Wed, 15 Feb 1995 15:18:09 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB15841; Wed, 15 Feb 95 15:18:02 PST From: Ran Atkinson Message-Id: <9502151814.ZM2375@bodhi> Date: Wed, 15 Feb 1995 18:14:06 -0500 X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) IPv6 Security Architecture draft Mime-Version: 1.0 Encoding: 2 TEXT BOUNDARY, 7 MESSAGE, 2 TEXT BOUNDARY, 791 MESSAGE, 3 TEXT BOUNDARY Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19502151814.ZM2375.bodhi" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM -- --PART-BOUNDARY=.19502151814.ZM2375.bodhi Encoding: 4 TEXT Content-Type: text/plain; charset=us-ascii Here is IPv6 Sec. Arch. draft Ran --PART-BOUNDARY=.19502151814.ZM2375.bodhi Encoding: 787 text X-Zm-Content-Name: ipv6-esp.txt Content-Type: text/plain ; charset=us-ascii Network Working Group Randall Atkinson Internet Draft Naval Research Laboratory draft-atkinson-ipng-esp-0a.txt 14 February 1995 IPv6 Encapsulating Security Payload (ESP) 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 6 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 "work in progress". This particular Internet Draft is a product of the IETF's IPng working group. It is intended that a future version of this draft be submitted to the IPng Area Directors and the IESG for possible publication as a standards-track protocol. Discussion of this draft takes place on the IPng Working Group mailing list: ipng@sunroof.eng.sun.com 1. INTRODUCTION This memo describes the IPv6 Encapsulating Security Payload (ESP). ESP seeks to provide integrity and confidentiality to IPv6 datagrams. It may also provide authentication, depending on which algorithm and algorithm mode are used. Non-repudiation and protection from traffic analysis are not provided by ESP. The IPv6 Authentication Header (AH) might provide non-repudiation if used with certain authentication algorithms. The IPv6 Authentication Header may be used in conjunction with ESP to provide authentication. Users desiring integrity and authentication without confidentiality should use the IPv6 Authentication Header (AH) instead of ESP. This document assumes that the reader is familiar with the related document "IPv6 Security Architecture", which defines the overall security architecture for IPv6 and provides important background for this specification. Atkinson [Page 1] Internet Draft IPv6 Encapsulating Security 15 February 1995 1.1 OVERVIEW The IPv6 Encapsulating Security Payload (ESP) seeks to provide confidentiality and integrity by encrypting data to be protected and placing the encrypted data in the data portion of the IPv6 Encapsulating Security Payload. Either a transport-layer (e.g. UDP or TCP) frame may be encrypted or an entire IPv6 datagram may be encrypted, depending on the user's security requirements. Encapsulating the protected data is necessary to provide confidentiality for the entire original datagram, but can be very expensive to implement. Use of this specification will increase the IPv6 protocol processing costs in participating systems and will also increase the communications latency. The increased latency is primarily due to the encryption and decryption required for each IPv6 datagram containing an Encapsulating Security Payload. In order for ESP to work properly without changing the entire Internet infrastructure (e.g. non-participating systems), the original IPv6 datagram is placed in the encrypted portion of the Encapsulating Security Payload and that entire ESP frame is placed within an datagram having unencrypted IPv6 headers. The information in the unencrypted IPv6 headers is used to route the secure datagram from origin to destination. An unencrypted IPv6 Routing Header might be included between the IPv6 Header and the Encapsulating Security Payload. An IPv6 Authentication Header may be present both as an header of the unencrypted IPv6 packet and also as a header within the encrypted IPv6 packet. In such a case, the unencrypted Authentication Header is primarily used to provide protection for the contents of the unencrypted IPv6 headers and the encrypted Authentication Header is used to provide authentication for the encrypted IPv6 packet. The encapsulating security payload is structured a bit differently than other IPv6 payloads. The first component of the ESP payload consist of the unencrypted field(s) of the payload. The second component consists of encrypted data. The field(s) of the unencrypted ESP header inform the intended receiver how to properly decrypt and process the encrypted data. The encrypted data component includes protected fields for the security protocol and also the encrypted encapsulated IPv6 datagram. 2. KEY MANAGEMENT Key management is an important part of the IPv6 security architecture. However, it is not included in this specification because of a long history in the public literature of subtle flaws in key management algorithms and protocols. IPv6 tries to decouple the key management mechanisms from the security protocol mechanisms. The only coupling between the key management protocol and the security Atkinson [Page 2] Internet Draft IPv6 Encapsulating Security 15 February 1995 protocol is with the Security Association Identifier (SAID), which is described in more detail below. This decoupling permits several different key management mechanisms to be used. More importantly, it permits the key management protocol to be changed or corrected without unduly impacting the security protocol implementations. Thus, a key management protocol for IPv6 is not specifed within this draft. [NB: It is intended that the key management mechanisms being developed elsewhere in the IETF will be reused for IPv6. In particular, the Eastlake-Kaufman DNS Security work on storing signed public keys in the DNS and Karn's Photuris key management protocol look promising for use with IPv6. ] The key management mechanism is used to negotiate a number of parameters for each security association, including not only the keys but other information (e.g. the cryptographic algorithms and modes, security classification level if any) used by the communicating parties. The key management protocol implementation usually creates and maintains a table containing the several parameters for each current security association. An ESP implementation normally needs to read that security parameter table to determine how to process each datagram containing an ESP (e.g. which algorithm/mode and key to use). There are two approaches to key management. The first approach, called host-to-host, uses a common key to protect all communications between users on host A and users on host B. The second approach, called user-to-user, uses a separate key for each user so that user 1 on host A and user 2 on host A will use different keys when sending to user 3 on host B. With host-to-host but not user-to-user keying, mutually hostile users might be able to deduce the shared key in use (e.g. using a Chosen Plaintext attack). If one were able to deduce the key in use, then one could forge traffic from another user on the compromised system. User-to-user keying is preferable and eliminates this potential problem. The key management requirements for IPv6 Encapsulating Security Payload are discussed more fully in the IPv6 Security Architecture document in Section 4.5 "IPv6 Key Management Requirements". 3. ENCAPSULATING SECURITY PAYLOAD SYNTAX The Encapsulating Security Payload (ESP) may appear anywhere after the IPv6 header. The Internet Assigned Numbers Authority has assigned Protocol Number 50 to IPv6 ESP. Thus the header immediately preceding the ESP header will always contain the value 50 in its Next Header field. ESP consists of an unencrypted header followed by encrypted data. The encrypted data includes both the protected ESP header fields and the protected user data, which is either an entire IPv6 datagram or an upper-layer protocol frame (e.g. TCP or UDP). A Atkinson [Page 3] Internet Draft IPv6 Encapsulating Security 15 February 1995 high-level diagram of a secure IPv6 datagram follows. |<-- Unencrypted -->|<---- Encrypted ------>| +-------------+--------------------+------------+---------------------+ | IPv6 Header | Other IPv6 Headers | ESP Header | encrypted data | +-------------+--------------------+------------+---------------------+ A more detailed diagram of the ESP Header follows. In this diagram, the cleartext fields are detailed. +-------------+--------------------+------------+---------------------+ | Security Association Identifier (SAID), 32 bits | +-------------+--------------------+------------+---------------------+ | Syncronisation Data, variable length | +=============+====================+============+=====================+ | Encrypted Data, variable length | +-------------+--------------------+------------+---------------------+ After decryption, the data transmitted in the above "Encrypted Data" field is formatted as follows: +-------------+--------------------+-----------------+----------------+ | Next Header | Header Length | Reserved | +-------------+--------------------+-----------------+----------------+ | Protected data (either an entire IPv6 datagram | | or a UDP frame or a TCP frame), variable length | +-------------+--------------------+-----------------+----------------+ 3.1 CLEARTEXT FIELDS The IPv6 Header is the conventional IPv6 Header defined by others in a separate Internet Draft. The ESP unencrypted field(s) are as follows: _S_E_C_U_R_I_T_Y _A_S_S_O_C_I_A_T_I_O_N _I_D_E_N_T_I_F_I_E_R (_S_A_I_D) A 32-bit value identifying the security association for this datagram. If no security association has been established, the value of this field shall be 0x0000. A security association is normally one-way. An authenticated communications session between two hosts will normally have two SAIDs in use (one in each direction). The receiving host uses the combination of SAID value and originating address to distinguish the correct association. An ESP implementation will always be able to use the SAID in combination with the 128-bit Destination Address to determine the security association and related security configuration data for all valid incoming packets. Senders to a multicast group may share a common SAID for all communications if all communications are authenticated using the same security configuration parameters (e.g. algorithm, key, security classification level, etc.). In this case, the receiver only knows Atkinson [Page 4] Internet Draft IPv6 Encapsulating Security 15 February 1995 that the message came from a host knowing the security association data for the group and cannot authenticate which member of the group sent the datagram. Multicast groups may also use a separate SAID for each sender. In any event, the combination of Destination Address and SAID is used to determine the correct security association data. If each sender is keyed separately and asymmetric algorithms are used, data origin authentication is also a provided service. Each SAID value implies the key(s) used to encrypt and decrypt the encrypted portion of the ESP payload, the sensitivity level (e.g. Secret, Unclassified) of the user data in the ESP payload, the encryption algorithm being used, the block size (if any) of the encryption algorithm, the authentication algorithm being used (if separate from the encryption algorithm), the block size (if any) of the authentication algorithm, and the presence/absence and size of a cryptographic synchronisation or initialisation vector field at the start of the encrypted portion of the ESP (if no such field is present, then the size is of course zero). _S_Y_N_C_H_R_O_N_I_S_A_T_I_O_N _D_A_T_A This field is present only for algorithms which require a cryptographic synchronisation field for each packet. The value of this field is arbitrary. The length of this field is variable, though for any given algorithm it has a particular known length. It is considered to be plaintext in this document, though most users will not be able to make sense of its contents. Its presence or absence and its size are constant for all secure datagrams of any given SAID value. The ESP specification includes this field so that the payload specification will be independent of the cryptographic algorithm that is being used by the communicating systems. If present, the field contains cryptographic synchronisation data, such as a DES Initialisation Vector, for whichever algorithm is in use. [ISO92b] An ESP implementation will normally use the Security Association Identifier value for the payload being processed to determine whether this field is present and to determine the field's size and use if present. 3.2 ENCRYPTED FIELDS The ESP encrypted fields are as follows: _N_E_X_T _H_E_A_D_E_R This field contains the value indicating which header follows the ESP Encrypted Fields. For example, if an entire IP datagram follows, the field will contain the number 94, which has been allocated by IANA to indicate IP-in-IP encapsulation. [STD-2] _H_E_A_D_E_R _L_E_N_G_T_H This field is contains the length of the set of encrypted ESP fields Atkinson [Page 5] Internet Draft IPv6 Encapsulating Security 15 February 1995 (i.e. Next Header, Header Length, Reserved) minus the 8 byte minimum length. The minimum length is 64-bit aligned to comply with normal IPv6 alignment rules. _R_E_S_E_R_V_E_D This field is currently used primarily for padding out to 64-bit alignment but might be used for other purposes in the future. It MUST be set to zero on transmission and MUST be ignored upon receipt. It is 16 bits long. It is important that all routing headers and other data be included within the encrypted IPv6 datagram, even if the same data is in the unencrypted part of the IPv6 datagram. The receiving system shall ignore all routing information in the unencrypted portion of the received datagram and shall strictly rely on the routing information from the protected payload instead. If this rule is not strictly adhered to, then the system will be vulnerable to various kinds of attacks, including source routing attacks. [Bel89][CERT95] The encrypted IPv6 datagram need not contain any explicit Security Label because the SAID indicates the sensitivity label for the encrypted IPv6 datagram. This is an improvement over the current practices with IPv4 where an explicit Security Label is normally used with Compartmented Mode Workstations and other systems requiring Security Labels. [RFC-1108] [DIA] If it is necessary to pad the protected data (e.g. to an integral block-size of the cryptographic algorithm in use), then the normal IPv6 Padding header is used to provide that padding. This means that ESP will not work with block-oriented algorithms whose block size is not an integral number of 8-bit bytes. 4. ENCAPSULATING SECURITY PROTOCOL PROCESSING This section describes the steps taken when ESP is in use between two communicating parties. Multicast is different from unicast only in the area of key management (See the definition of the SAID, above, for more detail on this). There are two modes of use for ESP. The first mode, which is called "IP-mode", encapsulates an entire IP datagram inside ESP. The second mode, which is called "Transport-Mode", encapsulates a transport-layer (e.g. UDP or TCP) frame inside ESP. These terms should not be misconstrued as restrictive, for example an ICMP/IGMP message might be sent either using the "Transport-mode" or the "IP-mode" depending upon circumstance. This section describes protocol processing for each of these two modes. Atkinson [Page 6] Internet Draft IPv6 Encapsulating Security 15 February 1995 4.1 ESP in IP-mode The sender takes the original IPv6 datagram, encapsulates it into the ESP and then applies the encryption algorithm using the appropriate key for combination of sending userid and the receiving party. If no key has been established, then the key management mechanism is used to establish a encryption key for this communications session prior to the encryption. The (now encrypted) ESP is then encapsulated in a cleartext IPv6 datagram as the last payload. If strict red/black separation is being enforced, then the addressing and other information in the cleartext IPv6 headers and optional payloads might be different from the values contained in the (now encrypted and encapsulated) original datagram. The receiver strips off the cleartext IPv6 header and cleartext optional IPv6 payloads (if any) and discards them. It then decrypts the ESP using the session key that has been established for this traffic. If no encryption key exists for this session, the encrypted ESP is discarded and the failure is recorded in the system or audit log, including the cleartext values for the SAID, date/time, Sending Address, Destination Address, and the Flow ID. The original IPv6 datagram is then removed from the (now decrypted) ESP. This original IPv6 datagram is then processed as per the normal IPv6 protocol specification. In the case of a B1 or Compartmented Mode Workstation, additional appropriate mandatory access controls should be applied. 4.2 ESP in Transport-mode The sender takes the original UDP or TCP or ICMP frame, encapsulates it into the ESP and then applies the encryption algorithm using the appropriate key for the combination of sending userid and receiving party. If no key has been established, then the key management mechanism is used to establish a encryption key for this communications session prior to the encryption. The (now encrypted) ESP is then encapsulated as the last payload of a cleartext IPv6 datagram. The receiver processes the cleartext IPv6 header and cleartext optional IPv6 headers (if any) and temporarily stores pertinent information (e.g. source and destination addresses, Flow ID, Routing Header). It then decrypts the ESP using the session key that has been established for this traffic, using the combination of the destination address and the packet's Security Association Identifier (SAID) to locate the correct key. If no key exists for this session, the encrypted ESP is discarded and the failure is recorded in the system or audit log. If such a failure occurs, the recorded log data should include the cleartext values for the SAID, date/time received, Sending Address, Destination Address, and the Flow ID. The log data may also Atkinson [Page 7] Internet Draft IPv6 Encapsulating Security 15 February 1995 include other information about the failed packet. The original UDP or TCP frame is then removed from the (now decrypted) ESP. The information from the cleartext IPv6 header and the now decrypted UDP or TCP header is jointly used to determine which application the data should be sent to. The data is then sent along to the appropriate application as normally per IPv6 protocol specification. In the case of a B1 or Compartmented Mode Workstation, additional Mandatory Access Controls should be appropriately applied. Atkinson [Page 8] Internet Draft IPv6 Encapsulating Security 15 February 1995 4.3. Combining ESP and the Authentication Header This section describes how to combine the Encapsulating Security Protocol with Authentication Header. There are two different approaches, depending on which part of the data is to be authenticated. The location of the IPv6 Authentication Header makes it clear which set of data is being authenticated. In the first usage, the entire received datagram is authenticated, including both the encrypted and unencrypted portions, while only the data sent after the ESP Header is confidential. In this usage, the sender first applies ESP to the data being protected. Then the other plaintext IPv6 headers are prepended to the ESP header and its now encrypted data. Finally, the IPv6 Authentication Header is calculated over the resulting datagram according to the normal method. Upon receipt, the receiver first verifies the authenticity of the entire datagram using the normal IPv6 Authentication Header process. Then if authentication succeeds, decryption using the normal IPv6 ESP process occurs. If decryption is successful, then the resulting data is passed up to the upper layer. If the authentication process were to be applied only to the data protected by IPv6 ESP and the protected data were an entire IPv6 datagram, then the IPv6 Authentication Header would be placed normally within that protected datagram. However, if the protected data were less than an entire IPv6 datagram, then the IPv6 Authentication Header would be placed within the encrypted payload immediately after the ESP protected header and before any other header or the UDP or TCP frame. If the Authentication Header is encapsulated within the ESP header, both headers have specific security classification levels associated with them, and the two security classification levels are not identical, then an error has occurred. That error should be recorded in the system or audit log using the procedures described previously. It is not necessarily an error for an Authentication Header located outside of the ESP header to have a different security classification level than the ESP header's classification level. This is true because the cleartext IP headers might have a different classification level when the data is encrypted using ESP. 6. TYPICAL USE The ESP supports security between two or more hosts implementing ESP, between two or more gateways implementing ESP, and between a host or gateway implementing ESP and a set of hosts and/or gateways. A security gateway is a system which acts as the communications gateway between external untrusted systems and trusted hosts on their own subnetwork and provides security services for the trusted hosts when Atkinson [Page 9] Internet Draft IPv6 Encapsulating Security 15 February 1995 they communicate with external untrusted systems. A trusted subnetwork contains hosts and routers that trust each other not to engage in active or passive attacks and trust that the underlying communications channel (e.g. an Ethernet) isn't being attacked. Trusted systems always should be trustworthy, but in practice they often are not trustworthy. In the case where a security gateway is providing services on behalf of one or more hosts on a trusted subnet, the security gateway is responsible for establishing the security association on behalf of its trusted host and for providing security services between the security gateway and the external system(s). In this case, only the gateway need implement ESP, while all of the systems behind the gateway on the trusted subnet may take advantage of ESP services between the gateway and external systems. A gateway which receives a datagram containing a recognised sensitivity label from a trusted host should take that label's value into consideration when creating/selecting an SAID for use with ESP between the gateway and the external destination. In such an environment, a gateway which receives a IPv6 packet containing the ESP should appropriately label the decrypted packet that it forwards to the trusted host that is the ultimate destination. The IPv6 Authentication Header should always be used on packets containing explicit sensitivity labels to ensure end-to-end label integrity. If there are no security gateways present in the connection, then two end systems that implement ESP may also use it to encrypt only the user data (e.g. TCP or UDP) being carried between the two systems. ESP is designed to provide maximum flexibility so that users may select and use only the security that they desire and need. 7. SECURITY CONSIDERATIONS This entire draft discusses a security mechanism for use with IPv6. This mechanism is not a panacea, but it does provide an important component useful in creating a secure internetwork. Users need to understand that the quality of the security provided by this specification depends completely on the strength of whichever encryption algorithm that has been implemented, the correctness of that algorithm's implementation, upon the security of the key management mechanism and its implementation, the strength of the key [CN94] and upon the correctness of the ESP and IPv6 implementations in all of the participating systems. If any of these assumptions do not hold, then little or no real security will be provided to the user. Use of high assurance development techniques is recommended for the IPv6 Encapsulating Security Payload. Users seeking protection from traffic analysis might consider the use Atkinson [Page 10] Internet Draft IPv6 Encapsulating Security 15 February 1995 of appropriate link encryption. Description and specification of link encryption is outside the scope of this note. If user-to-user keying is not in use, then the algorithm in use should not be vulnerable to any kind of Chosen Plaintext attack. A Chosen Plaintext attack on DES is described in [BS93]. Use of user-to-user keying is recommended in order to preclude any sort of Chosen Plaintext attack and to generally make cryptanalysis more difficult. ACKNOWLEDGEMENTS Many of the concepts here are derived from or were influenced by the US Government's SP3 security protocol specification, the ISO/IEC's NLSP specification, or from the proposed swIPe security protocol. [SDNS89, ISO92a, IB93, IBK93, ISO92b] The use of DES for confidentiality is closely modeled on the work done for the SNMPv2. [GM93] Steve Bellovin, Steve Deering, and Dave Mihelcic provided useful critiques of earlier versions of this draft. REFERENCES [Atk95a] Randall J. Atkinson, IPv6 Security Architecture, Internet Draft, draft-atkinson-ipng-sec-01.txt, 15 February 1995. [Atk95b] Randall J. Atkinson, IPv6 Authentication Header, Internet Draft, draft-atkinson-ipng-auth-01.txt, 15 February 1995. [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [BS93] Eli Biham and Adi Shamir, "Differential Cryptanalysis of the Data Encryption Standard", Springer-Verlag, New York, NY, 1993. [CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18, No. 23, July 1994. pp. 253-280 [CERT95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org. [DIA] US Defense Intelligence Agency (DIA), "Compartmented Mode Workstation Specification", Technical Report DDS-2600-6243-87. [GM93] James Galvin & Keith McCloghrie, Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. Atkinson [Page 11] Internet Draft IPv6 Encapsulating Security 15 February 1995 [Hin94] Robert Hinden (Editor), IPv6 Specification, Internet Draft, draft-hinden-ipng-ipv6-spec-00.txt, October 1994. [IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of the USENIX Security Symposium, Santa Clara, CA, October 1993. [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio. [ISO92a] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [ISO92b] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, Section 13.4.1, page 33, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [RFC-1108] Steve Kent, "US DoD Security Options for the Internet Protocol (IPSO)", RFC-1108, DDN Network Information Center, November 1991. [NIST77] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [NIST80] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [NIST81] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981. [NIST88] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988. [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, DDN Network Information Center, 20 October 1994. [Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2 [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990. Atkinson [Page 12] Internet Draft IPv6 Encapsulating Security 15 February 1995 DISCLAIMER The views and specification here are those of the author and are not necessarily those of his employer. The Naval Research Laboratory has not passed judgement on the merits, if any, of this work. The author and his employer specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. AUTHOR INFORATION Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Telephone: (DSN) 354-8590 Fax: (DSN) 354-7942 Atkinson [Page 13] Internet Draft IPv6 Encapsulating Security 15 February 1995 APPENDIX A: Use of CBC-Mode DES with IPv6 ESP This appendix describes the application of the Cipher Block Chaining (CBC) mode of the US Data Encryption Standard (DES) algorithm to the IPv6 Encapsulating Security Payload. This mode of DES requires an Initialisation Vector that is 8 bytes long and requires that the encrypted data be a multiple of 8 bytes long. DES is described is several US Government publications. [NIST77, NIST80, NIST81, NIST88] A recent book also provides information on DES. [Sch94] That same reference indicates on page 231 that at least one hardware implementation of DES CBC can encrypt or decrypt at about 1 Gbps. Each ESP header shall contain a 64-bit DES Initialisation Vector in the Cryptographic Synchronisation field when DES-CBC is in use. Each packet needs to contain its own different DES Initialisation Vector. Including the Initialisation Vector in each packet also ensures decryption of each received packet can be performed even though other packets might have been dropped or packets might have been misordered in transit. The method for selection of the Initialisation Vector value is implementation-defined. The secret DES key shared between the communicating parties is 64 bits long, as per the DES specifications [NIST77, NIST80, NIST81, NIST88]. The 64-bit DES key consists of a 56-bit quantity used by the DES algorithm and 8 parity bits arranged such that one parity bit is the least significant bit of each octet. The length of the octet sequence to be encrypted by the DES algorithm must be an integral multiple of 8. When encrypting, any needed padding shall be included by using a IPv6 hop-by-hop padding option. When the Transport-mode of ESP is used, such padding must appear between the encrypted ESP header fields and the start of the UDP or TCP data. If the length of the octet sequence to be decrypted is not an integral multiple of 8 octets, then processing shall be halted, the packet shall be discarded, and the event should be recorded in the system or audit log using implementation-specific methods. Atkinson [Page 14] --PART-BOUNDARY=.19502151814.ZM2375.bodhi-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 19:08:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28504; Wed, 15 Feb 95 19:08:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28498; Wed, 15 Feb 95 19:08:18 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21384; Wed, 15 Feb 1995 19:01:22 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA25455; Wed, 15 Feb 95 19:01:24 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA25652; Wed, 15 Feb 95 18:57:29 -0800 Received: by xirtlu.zk3.dec.com; id AA09696; Wed, 15 Feb 1995 21:56:40 -0500 Message-Id: <9502160256.AA09696@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) IPv4 address representation In-Reply-To: Your message of "Wed, 15 Feb 95 15:05:23 EST." <9502152005.AA01259@itd.nrl.navy.mil> Date: Wed, 15 Feb 95 21:56:34 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, Before I respond to your note. Let me tell you several of us (including me) did point out that we need to provide this to the mailing list. But I was informed offline that this is an official IETF meeting and we can change the specs per an official IETF meeting. I am not saying this is right or wrong. After your mail I am not sure now and I would like to hear an official ruling on this for my own edification and future work in the IETF. >1) No decision at any meeting is final until after folks on the mailing > list who did not attend the meeting have an opportunity to read, > comment on, and possibly object to what the folks at that meeting > agreed to. This is per normal IETF rules and YES I have objected > via lists in the past (most notably to some Danish insanity regarding > MIME character sets about 3 years back). Well I hope the specs are in progress. We will have two weeks to review as I understood the strategy. >2) The list has not seen any minutes yet, so the concrete is not poured. I agree. But the authors of the specs agreed to update them at the meeting so I think that is going to happen as I write this mail as they are under an intense deadline so we can reach Proposed Standards by Danvers MA. I am not saying this is good but what I understand to be. I am not saying this is bad but again what is to be. >3) Hinden is quite correct per IETF rules to raise issues such as this > onto the mailing list. OK What rules did Bob raise? I am totally unclear to what "text" in what "mail" "message" your are referrring to since Feb 13th which was Monday after the meeting? I want to know? Or are you expressing an emotional desire to agree with what you "think" Bob may have said. I am not clear what this sentence references. >I'm not pro or con on this issue, but I'm not about to be railroaded by >anyone. Well I am PRO on several issues but having been railroaded twice in IPng even if its something I am PRO on I would support you to the loss of my PRO if any working group member was being railroaded because the is more important. Everyone should have the time to defend why a change should not take place agreed to at a meeting. But if one can't defend it they loose. Just like my recent mail exchange where I misunderstood what the outcome was of something I agreed to. I loose. Your mail made me feel like we did something wrong in the rules so I want to understand where that is coming from and your feeling of being railroaded. I can see that as we move forward the rules are going to become more important might as well get them on the table. take care, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 22:25:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28576; Wed, 15 Feb 95 22:25:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28315; Wed, 15 Feb 95 15:19:20 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19741; Wed, 15 Feb 1995 15:12:25 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA14813; Wed, 15 Feb 95 15:12:18 PST To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) new IPv6 Security drafts coming in a minute Date: Wed, 15 Feb 95 18:11:29 EST From: Ran Atkinson Message-Id: <9502151811.aa02357@bodhi.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The IPv6 Security Drafts are mostly revised and the tonight version will appear on this list in a few minutes. This afternoon I realised that it was moderately stupid and fairly annoying to have 3 separate discussions about key management. Tomorrow I will move all discussion of key mgmt and key mgmt requirements into the IPv6 Security Architecture document and the other 2 drafts will get cites to that discussion and those requirements. This should make it much more clear to implementers by not saying the same thing in 3 slightly different ways in 3 different places. By the way, I'd urge IPv6 folks to look over Phil Karn's Photuris I-D that was just announced. I believe that draft would be a good basis for refinement/correction and later standardisation for a standards-track key mgmt protocol to support IPv6. Discussion of that draft is mainly occuring on the IPv4 Security Protocol WG (IPsec) mailing list. To subscribe to that list send a request to: ipsec-request@ans.net Sorry for the delays in draft appearance. Ran atkinson@itd.nrl.navy.mil PS: All 3 drafts _will_ go out as usual online I-Ds once I make the key mgmt discussion consolidation and I hope to have that version submitted to the nice I-D folks by tomorrow this time. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 22:29:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28613; Wed, 15 Feb 95 22:29:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28329; Wed, 15 Feb 95 15:24:41 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB20409; Wed, 15 Feb 1995 15:17:44 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA15841; Wed, 15 Feb 95 15:17:28 PST From: Ran Atkinson Message-Id: <9502151812.ZM2361@bodhi> Date: Wed, 15 Feb 1995 18:12:41 -0500 X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) IPv6 Authentication Header draft Mime-Version: 1.0 Encoding: 2 TEXT BOUNDARY, 7 MESSAGE, 2 TEXT BOUNDARY, 680 MESSAGE, 3 TEXT BOUNDARY Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19502151812.ZM2361.bodhi" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM -- --PART-BOUNDARY=.19502151812.ZM2361.bodhi Encoding: 4 TEXT Content-Type: text/plain; charset=us-ascii Here is the Auth header draft in MIME attachment format. Ran --PART-BOUNDARY=.19502151812.ZM2361.bodhi Encoding: 675 text X-Zm-Content-Name: ipv6-auth.txt Content-Description: plain text Content-Type: text/plain ; charset=us-ascii Network Working Group Randall Atkinson Internet Draft Naval Research Laboratory draft-atkinson-ipng-auth-01.txt 14 February 1995 IPv6 Authentication Header 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 6 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". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This particular Internet Draft is a product of the IETF's IPng Working Group. It is intended that a future version of this draft will be submitted for consideration as a standards-track document. Distribution of this document is unlimited. Discussion of this draft may be posted to the IPng WG mailing list: ipng@sunroof.eng.sun.com Administrative requests regarding that mailing list should always be sent to: ipng-request@sunroof.eng.sun.com 1. INTRODUCTION & OVERVIEW The Internet community is working on a transition from version 4 of the Internet Protocol (IPv4) to version 6 of the Internet Protocol (IPv6). This memo describes the IPv6 Authentication Header. This optional header provides strong integrity and authentication for IPv6 datagrams. Non-repudiation might be provided by an authentication algorithm used with the Authentication Header, but it is not provided with all authentication algorithms that might be used. Confidentiality, and protection from traffic analysis are not provided by the Authentication Header. Users desiring confidentiality should consider using the IPv6 Encapsulating Security Protocol (ESP) either in lieu of or in conjunction with the Authentication Header. [NB: All Atkinson [Page 1] Internet Draft IPv6 Authentication Header 4 February 1995 references to "IPv6 Encapsulating Security Protocol" will be replaced with references to the "IPv6 Security Protocol (IPSP)" if/when such a document appears as an online Internet Draft]. This document assumes the reader has previously read and understood the related "IPv6 Security Overview" document which defines the overall security architecture for IPv6 and provides important background information for this specification. The IPv6 Authentication Header seeks to provide security by adding authentication information to an IPv6 datagram. This authentication information is calculated using all of the fields in the IPv6 datagram (including not only the IPv6 Header but also other headers and the user data) which do not change in transit. Fields which need to change in transit (e.g "hop count" or "routing pointer") are omitted from the calculation of the authentication data. This provides significantly more security than is currently present in IPv4 and might be sufficient for the needs of many users. Use of this specification will increase the IPv6 protocol processing costs in participating end systems and will also increase the communications latency. The increased latency is primarily due to the calculation of the authentication data by the sender and the calculation and comparison of the authentication data by the receiver for each IPv6 datagram containing an Authentication Header. The impact will vary with authentication algorithm used and other factors. In order for the Authentication Header to work properly without changing the entire Internet infrastructure, the authentication data is carried in its own payload and systems that aren't participating in the authentication MAY ignore the Authentication Data. The Authentication Header is normally placed after the Hop-by-Hop header, which is examined at each hop, and before the End-to-End Header, which is never examined at an intermediate hop. The information in the other IPv6 headers is used to route the datagram from origin to destination. If a symmetric authentication algorithm is used and intermediate authentication is desired, then the nodes performing such intermediate authentication would need to be provided with the appropriate keys. Possession of those keys would permit any one of those systems to forge traffic claiming to be from the legitimate sender to the legitimate receiver or to modify the contents of otherwise legitimate traffic. In some environments such intermediate authentication might be desirable. [8] If an asymmetric authentication algorithm is used and the routers are aware of the appropriate public keys and authentication algorithm, then the routers possessing the authentication public key could authenticate the traffic being handled without being able to forge or modify otherwise legitimate traffic. Atkinson [Page 2] Internet Draft IPv6 Authentication Header 4 February 1995 2. KEY MANAGEMENT Key management is an important part of the IPv6 security architecture. However, it is not integrated with this specification because of a long history in the public literature of subtle flaws in key management algorithms and protocols. IPv6 tries to decouple the key management mechanisms from the security protocol mechanisms. The only coupling between the key management protocol and the security protocol is with the Security Association Identifier (SAID), which is described in more detail below. This decoupling permits several different key management mechanisms to be used. More importantly, it permits the key management protocol to be changed or corrected without unduly impacting the security protocol implementations. The key management mechanism is used to negotiate a number of parameters for each security association, including not only the keys but also other information (e.g. the authentication algorithm and mode) used by the communicating parties. The key management mechanism creates and maintains a logical table containing the several parameters for each current security association. An implementation of the IPv6 Authentication Header will need to read that logical table of security parameters to determine how to process each datagram containing an Authentication Header (e.g. to determine which algorithm/mode and key to use in authentication). The SAID value is typically used as the index into that logical table of security configuration data. There are two approaches to key management. The first approach, called host-to-host, uses a common key to protect all communications between users on host A and users on host B. The second approach, called user-to-user, uses a separate key for each user so that user 1 on host A and user 2 on host A will use different keys when sending to user 3 on host B. With host-to-host but not user-to-user keying, mutually hostile users might be able to deduce the shared key in use (e.g. using a Chosen Plaintext attack). Chosen Plaintext attacks are known to exist for algorithms of interest to the Internet community (for example see [9]). If one were able to deduce the key in use, then one could forge traffic from another user on the compromised system. User-to-user keying is preferable and eliminates this potential problem. Manual key management is the only key management mechanism required by this specification. A scalable standard Internet key management protocol is needed to make widespread use of this mechanism practical. Work on such a key management protocol is underway in the IETF. Atkinson [Page 3] Internet Draft IPv6 Authentication Header 4 February 1995 3. PAYLOAD SYNTAX The Authentication Header normally appears after the IPv6 Hop-by-Hop Header and before the IPv6 End-to-End Header. The Authentication Header consists of a few clear text fields and then the authentication data. The authentication data is the output of the authentication algorithm calculated over the invariant portions of the entire IPv6 datagram. The Authentication Data field itself is ignored only during the authentication calculation. All other Authentication Header fields are included in the authentication calculation normally. A high-level diagram of an IPv6 datagram with the Authentication Header follows. The IPv6 Authentication Header has been assigned the protocol number 51 by the Internet Assigned Numbers Authority (IANA). The IPv6 header immediately prior to the Authentication Header shall use the number 51 to indicate the the following header is the IPv6 Authentication Header. +-------------+-------------------------+--------------+---------+---------+ | IPv6 Header | Routing/Hop-by-Hop Hdrs | Auth Header | E2E Hdr | TCP/UDP | +-------------+-------------------------+--------------+---------+---------+ The IPv6 Header is the conventional IPv6 Header defined by others in a separate Internet Draft. The IPv6 Authentication Header has the following syntax: +--------------+-----------------+----------------+------------+ | Next Payload | Length | RESERVED | +--------------+-----------------+----------------+------------+ | Security Association Identifier | +--------------+---------------+----------------+--------------+ | Authentication Data (variable number of 64-bit double words) | +--------------+---------------+----------------+--------------+ | (more Authentication Data) | +--------------+---------------+----------------+--------------+ _N_E_X_T _P_A_Y_L_O_A_D 8 bits wide. Identifies the next payload after the Authentication Payload (as is normal for IPv6). _P_A_Y_L_O_A_D _L_E_N_G_T_H 8 bits wide. The length of the Authentication Data field in 64-bit double words. Minimum value is 0 double words, which is only used in the degenerate case of a "null" authentication algorithm. _R_E_S_E_R_V_E_D Reserved for future use. MUST be set to all zeros when sent and ignored upon receipt. Atkinson [Page 4] Internet Draft IPv6 Authentication Header 4 February 1995 _S_E_C_U_R_I_T_Y _A_S_S_O_C_I_A_T_I_O_N _I_D_E_N_T_I_F_I_E_R (_S_A_I_D) A 32-bit pseudo-random value identifying the security association for this datagram. If no security association has been established, the value of this field shall be 0x00000000. The set of SAID values in the range 0x00000001 through 0x000000FF are reserved for future use. A security association is normally one-way. An authenticated communications session between two hosts will normally have two SAIDs in use (one in each direction). The combination of SAID value and destination address uniquely identifies the security association. The destination address may, of course, be a multicast group address. This receiver-orientation implies that, in the case of unicast traffic, the destination system will usually select the SAID value. By having the destination select the SAID value, there is no potential for manually configured security associations to have SAID values that conflict with automatically configured (e.g. via a key management protocol) security associations. For multicast traffic, there are multiple destination systems but a single destination multicast group so some system or person will need to select SAIDs for that multicast group and then communicate the information to all of the legitimate members of that multicast group via mechanisms not defined here. Multicast groups MAY share a common SAID for all communications if all communications are authenticated using the same security configuration parameters (e.g. algorithm, key, etc.). In this case, a receiver only knows that the message came from a system which knew the security association data for that multicast group. A receiver cannot generally authenticate which host sent the multicast traffic when symmetric algorithms are in use. Multicast traffic MAY also use a separate SAID for each sender to the multicast group. In this case, the originating system is fully authenticatable when each sender uses a different SAID and security configuration and asymmetric algorithms are in use. Each SAID value implies the key(s) used with the authentication algorithm, the authentication algorithm and its mode, the block size (if any), initialisation vectors (if any) of the authentication algorithm, and (optionally) the security classification level associated with this key and session. As is discussed in greater detail in the IPv6 Security Architecture document, IPv6 will normally use implicit security classification labels rather than the explicit labels that are used for IPv4. [11] [3] _A_U_T_H_E_N_T_I_C_A_T_I_O_N _D_A_T_A This data carried in this field is variable length, but the field size is always an integral number of 64-bit double words. The authentication data fills the field beginning immediately after the Atkinson [Page 5] Internet Draft IPv6 Authentication Header 4 February 1995 SAID field and continuing until all the authentication data is in place. If the Authentication Data field is longer than necessary to store the actual authentication data, then the unused trailing bit positions MUST be ignored by the receiver. 4. CALCULATION OF THE AUTHENTICATION DATA The authentication data is usually calculated using a message digest algorithm (e.g. MD5) either encrypting that message digest or keying the message digest directly. Only algorithms that are believed to be cryptographically strong one-way functions should be used with this header. Because conventional checksums (e.g. CRC-16) are not cryptographically strong and can be reverse-engineered, they MUST NOT be used with the Authentication Header. If a block-oriented authentication algorithm (e.g. MD5, MD4) is in use and the IPv6 packet is not an integral number of blocks, the authentication data calculation is performed using zero bytes at the end to pad the length out to an integral number of blocks. These block padding bytes are not included in the actual IPv6 datagram and are not sent over the wire because adding padding at that point in IP protocol processing would make implementation of the MTU related calculations very difficult. When a keyed message digest algorithm (e.g. MD5) is used, the secret key is fed into the algorithm first, followed by the invariant fields of the IPv6 datagram in sequence. Fields which will necessarily vary in transit from the sender to the receiver (e.g. Hop Count) are included in the calculation but the value zero is substituted for the actual value of such fields in the IPv6 packet. This substitution of zero is used instead of omitting those fields because it preserves 64-bit alignment throughout the authentication data calculation and thereby can significantly improve performance. At the very end, the secret key is fed in to the keyed message digest algorithm again. The secret key is fed in first because that increases the work function for someone attempting to cryptanalyse the key from knowledge of the packet data and the Authentication Data of the Authentication Header. Feeding the key in first also permits implementations to precompute the start of the hash for a given destination and possibly improve performance thereby. The key is fed in again at the end to provide additional assurance for the authentication mechanism. The sender MUST compute the authentication over the packet as it will appear at the receiver. This requirement is placed in order to allow for future IPv6 optional headers which the receiver might not know about but the sender necessarily knows about if it is including such options in the packet. The sender places the calculated message digest algorithm output into the Authentication Data field within the Atkinson [Page 6] Internet Draft IPv6 Authentication Header 4 February 1995 Authentication Header. Upon receipt of a packet containing an IPv6 Authentication Header, the receiver independently calculates the authentication data for the received packet. It then compares the received Authentication Data field contents with the calculated authentication value. If the two match, then the datagram is accepted as authentic. If they differ, then the receiver SHOULD discard the received IPv6 datagram as non-authentic and MUST audit the authentication failure using normal operating system procedures. Not all of the fields of the IPv6 Hop-by-Hop Options header are included in the authentication calculation. The third-highest-order bit of the Option Type field within the Hop-by-Hop Options Header indicates whether any particular option is included within the authentication calculation or is omitted from the authentication calculation. If the particular option is to be omitted, that option is skipped over during the authentication calculation as if it were not present. Because of this bit encoding, an implementation can authenticate newly defined hop-by-hop options without having to modify the authentication portion of the IPv6 implementation. The IPv6 specification provides additional information on the IPv6 Hop-by-Hop Options Header. [5] 5. CONFORMANCE REQUIREMENTS Implementations that claim conformance or compliance with this specification MUST fully implement the option described here, MUST support user-to-user manual key distribution for use with this option, and MUST support the use of keyed MD5 as described in Appendix A of this document. Support for host-to-host manual key distribution MAY also be present. Support for other authentication algorithms is not mandatory to comply or conform with this specification. Implementors should consult the most recent version of the IAB Official Standards document for further guidance on the status of this document. [NB: MD5 reportedly has a throughput of about 60 Mbps on a fast 64-bit RISC processor with slightly tuned MD5 code. This possibly too slow for the IPv6 Authentication Header to be widely used. Suggestions are sought on alternative authentication algorithms that would be acceptable to the IETF, have significantly faster throughput, are not patent-encumbered, and still retain adequate cryptographic strength for commercial users. NIST's Secure Hash Algorithm (SHA) appears to be even slower than MD5, though some believe it is cryptographically stronger than MD5. Hence, SHA does not appear to be a better choice than MD5 at the present.] Atkinson [Page 7] Internet Draft IPv6 Authentication Header 4 February 1995 6. SECURITY CONSIDERATIONS This entire RFC discusses an authentication mechanism for IPv6. This mechanism is not a panacea to the several security issues in any internetwork, however it does provide a component useful in building a secure internetwork. Users need to understand that the quality of the security provided by this specification depends completely on the strength of whichever cryptographic algorithm has been implemented, the strength of the key being used, the correctness of that algorithm's implementation, upon the security of the key management mechanism and its implementation, and upon the correctness of the IPv6 Authentication Header and IPv6 implementations in all of the participating systems. If any of these assumptions do not hold, then little or no real security will be provided to the user. Implementers are encouraged to use high assurance methods to develop all of the security relevant parts of their products. Users interested in confidentiality should consider using the IPv6 Encapsulating Security Payload (ESP) instead of or in conjunction with this specification. Users seeking protection from traffic analysis might consider the use of appropriate link encryption. Description and specification of link encryption is outside the scope of this note. [7] Users interested in combining the IPv6 Authentication Header with the IPv6 Encapsulating Security Payload should consult the IPv6 Encapsulating Security Payload specification for details. One particular issue is that in some cases a packet which causes an error to be reported back via ICMP might be so large as not to entirely fit within the ICMP message returned. In such cases, it might not be possible for the receiver of the ICMP message to independently authenticate the portion of the returned message. This could mean that the host receiving such an ICMP message would either trust an unauthenticated ICMP message, which might in turn create some security problem, or not trust and hence not react appropriately to some legitimate ICMP message that should have been reacted to. It is not clear that this issue can be fully resolved in the presence of packets that are the same size as or larger than the minimum IPv6 MTU. Similar complications arise if an encrypted packet causes an ICMP error message to be sent and that packet is truncated. Active attacks are now widely known to exist in the Internet [10]. This means that unauthenticated source routing, either unidirectional (receive-only) or with replies following the original received source route represents a significant security risk unless all received source routed packets are authenticated using the IPv6 Authentication Header or some other cryptologic mechanism. It is interesting to read Atkinson [Page 8] Internet Draft IPv6 Authentication Header 4 February 1995 in [10] that the attacks currently visible include a subset of those described in [6]. Atkinson [Page 9] Internet Draft IPv6 Authentication Header 4 February 1995 The basic concept here is derived in large part from the SNMPv2 Security Protocol work described in [1]. Steve Bellovin, Steve Deering, Frank Kastenholz, and Dave Mihelcic provided useful critiques of early versions of this draft. Francis Dupont discovered and pointed out the ICMP security issue noted just above. REFERENCES [1] James Galvin & Keith McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. [2] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, DDN Network Information Center, April 1992. [3] Randall Atkinson, IPv6 Security Architecture, Internet Draft, draft-atkinson-ipng-sec-01.txt, 15 February 1995. [4] Randall Atkinson, IPv6 Encapsulating Security Payload, Internet Draft, draft-atkinson-ipng-esp-01.txt, 15 February 1995. [5] Bob Hinden (Editor), Internet Protocol version 6 (IPv6) Specification, draft-hinden-ipv6-spec-00.txt, October 1994. [6] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [7] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. [8] R. Braden, D. Clark, S. Crocker, & C.Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC-1636, DDN Network Information Center, 9 June 1994, pp. 21-34. [9] Eli Biham & Adi Shamir, "Differential Cryptanalysis of the Data Encryption Standard (DES)", Springer-Verlag, New York, NY, 1993. [10] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org in /pub/cert_advisories. [11] Steve Kent, "US DoD Security Options for the Internet Protocol", RFC-1108, DDN Network Information Center, November 1991. DISCLAIMER The views and specification here are those of the author and are not necessarily those of his employer. The Naval Research Laboratory has not passed judgement on the merits, if any, of this work. The author Atkinson [Page 10] Internet Draft IPv6 Authentication Header 4 February 1995 and his employer specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. AUTHOR INFORATION Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Phone: (DSN) 354-8590 Fax: (DSN) 354-7942 Atkinson [Page 11] Internet Draft IPv6 Authentication Header 4 February 1995 APPENDIX A: USE OF KEYED MD5 WITH THE IPv6 Authentication Header This section describes the use of the MD5 message digest algorithm with the IPv6 Authentication Header to provide integrity and authentication. A 128-bit digest is calculated over the invariant portion of the entire IPv6 datagram and the result is included in the Authentication Data field of the IPv6 Authentication Header. The specification of MD5 in RFC-1321 includes a portable 'C' programming language description of the MD5 algorithm. The secret authentication key used with the IPv6 Authentication Header MUST be 128 bits long. The key SHOULD be a pseudo-random number, not a guessable string of any sort. The 128-bit digest shall be calculated as described in Section 3 of RFC-1321. The "b-bit message" referred to in RFC-1321 shall consist of the 128 bit secret authentication key prepended to the invariant fields of the entire IPv6 datagram in the order they appear in the IPv6 datagram. All IPv6 headers and payloads that are present MUST be included in the computation, with header fields whose value varies in transit (e.g. Hop Count) being assumed to contain all zeros for the purpose of the authentication calculation. For the purposes of the calculation, the Authentication Data field of the IPv6 Authentication Payload is considered to contain all zeros. Because MD5's output is naturally 64-bit aligned, there is no wasted space in the Authentication Data field. Atkinson [Page 12] --PART-BOUNDARY=.19502151812.ZM2361.bodhi-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 22:31:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28625; Wed, 15 Feb 95 22:31:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28335; Wed, 15 Feb 95 15:24:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20424; Wed, 15 Feb 1995 15:17:56 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB15841; Wed, 15 Feb 95 15:17:50 PST From: Ran Atkinson Message-Id: <9502151813.ZM2365@bodhi> Date: Wed, 15 Feb 1995 18:13:22 -0500 X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) IPv6 Encapsulating Security Payload draft Mime-Version: 1.0 Encoding: 2 TEXT BOUNDARY, 7 MESSAGE, 2 TEXT BOUNDARY, 791 MESSAGE, 3 TEXT BOUNDARY Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19502151813.ZM2365.bodhi" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM -- --PART-BOUNDARY=.19502151813.ZM2365.bodhi Encoding: 4 TEXT Content-Type: text/plain; charset=us-ascii Here is revised ESP, again in MIME format. Ran --PART-BOUNDARY=.19502151813.ZM2365.bodhi Encoding: 787 text X-Zm-Content-Name: ipv6-sec.txt Content-Type: text/plain ; charset=us-ascii Network Working Group Randall Atkinson Internet Draft Naval Research Laboratory draft-atkinson-ipng-sec-01.txt 15 February 1995 IPv6 Security Architecture 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 6 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 "work in progress". This particular Internet Draft is a product of the IETF's IPng working group. It is intended that a future version of this draft be submitted to the IESG for publication as a standards-track RFC. Discussion of this draft normally takes place on the IPng Working Group mailing list: ip-ng@sunroof.eng.sun.com To add/drop from that mailing list, send an email request to: ip-ng-request@sunroof.eng.sun.com 1. INTRODUCTION The Internet community is making a transition from version 4 of the Internet Protocol (IPv4) to version 6 of the Internet Protocol (IPv6). [Hi94] This memo describes the security mechanisms integrated into version 6 of the Internet Protocol (IPv6) and the services that they provide. Each security mechanism is specified in a separate document. It also describes how security mechanisms outside the scope of the IPng effort (e.g. key management) relate to the IPv6 security mechanisms. 1.1 Definitions This section provides a few basic definitions that are applicable to this document. Other documents provide more definitions and background information. [VK83, HA94] Atkinson [Page 1] Internet Draft IPv6 Security Architecture 15 February 1995 Authentication The property of knowing that the data received is the same as the data that was sent and that the claimed sender is in fact the actual sender. Integrity The property of ensuring that data is transmitted from source to destination without undetected alteration. Confidentiality The property of keeping communications confidential so that intended participants can know what is being sent but unintended parties are unable to determine what is being sent. Encryption A mechanism commonly used to provide confidentiality. Non-repudiation The property of a receiver being able to prove that the sender of some data did in fact send the data even though the sender might later desire to deny ever having sent that data. SAID Acronym for "Security Association IDentifier" Security Association The set of security information relating to a given network connection or set of connections. This usually includes the cryptographic key, key lifetime, algorithm, algorithm mode, sensitivity level (e.g. Unclassified, Secret, Proprietary), what kind of security service is provided (authentication-only, Transport-Mode Encryption, IP-Mode Encryption, or some combination), and possibly other data. Traffic Analysis A kind of network attack where the adversary is able to make deductions about oneself just by analysing the network traffic patterns (such as frequency of transmission, who is talking with whom, size of packets, Flow Identifier used, etc). 2. DESIGN OBJECTIVES This section describes some of the design objectives of this security architecture and its component mechanisms. The primary objective of this work is to ensure that IPv6 will have solid security mechanisms available to users who desire security. These mechanisms are designed such that Internet users who do not employ these mechanisms will not be adversely affected. These mechanisms are Atkinson [Page 2] Internet Draft IPv6 Security Architecture 15 February 1995 intended to be algorithm-independent so that the cryptographic algorithms can be altered without affecting the other parts of the implementation. Standard default algorithms (i.e. keyed MD5, DES CBC) are specified to ensure interoperability in the global Internet. The selected algorithms are the same as the standard default algorithms used in SNMPv2. The IPv6 Security mechanisms should be useful in enforcing a variety of security policies. 3. IPv6 SECURITY MECHANISMS There are two security mechanisms in IPv6. The first is the Authentication Header which provides integrity and authentication without confidentiality. [Atk94a] The second is the Encapsulating Security Payload which, depending on algorithm and mode, might provide integrity, authentication, and always provides confidentiality. [Atk94b] The IPv6 mechanisms do not provide security against a number of traffic analysis attacks. However, there are several techniques outside the scope of this specification (e.g. bulk link encryption) that might be used to provide protection against traffic analysis. The two IPv6 security mechanisms may be combined. 3.1 AUTHENTICATION HEADER The IPv6 Authentication Header seeks to provide integrity and authentication for IPv6 datagrams. It does this by computing a cryptographic authentication function over the IPv6 datagram and using a secret authentication key in the computation. [Atk94a] The sender computes the authentication data just prior to sending the authenticated IPv6 packet and the receiver verifies the correctness of the authentication data upon reception. Certain fields which must change in transit, such as the Hop Limit field decremented on each hop, are omitted from the authentication calculation. However the omission of the Hop Limit field does not adversely impact the security provided. Non-repudiation might be provided by some authentication algorithms (e.g. asymmetric algorithms when both sender and receiver keys are used in the authentication calculation) used with the Authentication Header, but it is not necessarily provided by all authentication algorithms that might be used with the Authentication Header. The default authentication algorithm is keyed MD5, which like all symmetric algorithms cannot provide non-repudiation. Confidentiality and traffic analysis protection are not provided by the Authenticaton Header. The IPv6 Authentication Header holds authentication information for its IPv6 datagram. This authentication information is calculated using all of the fields in the IPv6 datagram which do not change during transit from the originator to the recipient. All IPv6 headers, payloads, and the user data are included in this calculation. Atkinson [Page 3] Internet Draft IPv6 Security Architecture 15 February 1995 The only exception is that fields which need to change in transit (e.g. IPv6 Header's "Hop Count" or the IPv6 Routing Header's "Next Address") are omitted when the authentication data is calculated. Use of the Authentication Header will increase the IPv6 protocol processing costs in participating systems and will also increase the communications latency. The increased latency is primarily due to the calculation of the authentication data by the sender and the calculation and comparison of the authentication data by each receiver for each IPv6 datagram containing an Authentication Header (AH). The Authentication Header provides much stronger security than exists in most of the current Internet and should not affect exportability or significantly increase implementation cost. While the Authentication Header might be implemented by a security gateway on behalf of hosts on a trusted network behind that security gateway, this mode of operation is not encouraged. Instead, the Authentication Header should be used from origin to final destination. All IPv6-capable hosts MUST implement the IPv6 Authentication Header with at least the MD5 algorithm using a 128-bit key. Other authentication algorithms may be implemented in addition to keyed MD5. 3.2 ENCAPSULATING SECURITY PAYLOAD The IPv6 Encapsulating Security Payload (ESP) seeks to provide integrity, authentication, and confidentiality to IPv6 datagrams. [Atk94b] It does this by encapsulating either an entire IPv6 datagram or only the upper-layer protocol data inside the ESP, encrypting most of the ESP contents, and then appending a new cleartext IPv6 header to the now encrypted Encapsulating Security Payload. This cleartext IPv6 header is used to carry the protected data through the internetwork. The recipient of the cleartext datagram removes and discards the cleartext IPv6 header and cleartext IPv6 options, decrypts the ESP, processes and then removes the ESP headers, and then processes the (now decrypted) original IPv6 datagram or upper-layer protocol data as per the normal IPv6 protocol specification. 3.2.1 Description of the ESP Modes There are two modes within ESP. The first mode, which is known as IP-mode, encapsulates and entire IP datagram within the ESP header. The second mode, which is known as Transport-mode, encapsulates either a UDP or TCP frame inside IP. Atkinson [Page 4] Internet Draft IPv6 Security Architecture 15 February 1995 3.2.2 Usage of ESP ESP works between hosts, between a host and a security gateway, or between security gateways. This support for security gateways permits trustworthy networks behind a security gateway to omit encryption and thereby avoid the performance and monetary costs of encryption, while still providing confidentiality for traffic transiting untrustworthy network segments. When both hosts directly implement ESP and there is no intervening security gateway, then they may use the Transport-mode (where only the upper layer protocol data (e.g. TCP or UDP) is encrypted and there is no encrypted IPv6 header). This mode reduces both the bandwidth consumed and the protocol processing costs for users that don't need to keep the entire IPv6 datagram confidential. ESP works with both unicast and multicast traffic. 3.2.3 Performance Impacts of ESP The encapsulating security approach used by ESP can noticeably impact network performance in participating systems, but should not adversely impact routers or other intermediate systems that are not participating in the particular ESP association. Protocol processing in participating systems will be more complex when encapsulating security is used, requiring both more time and more processing power. Use of encryption will also increase the communications latency. The increased latency is primarily due to the encryption and decryption required for each IPv6 datagram containing an Encapsulating Security Payload. The precise cost of ESP will vary with the specifics of the implementation, including the encryption algorithm, key size, and other factors. Hardware implementations of the encryption algorithm are recommended when high throughput is desired. Because of the performance impact, users not requiring confidentiality will probably prefer to use the IPv6 Authentication Header instead of ESP. For interoperability throughout the worldwide Internet, all conforming implementations of IPv6 Encapsulting Security Payload MUST support the use of the Data Encryption Standard (DES) in Cipher-Block Chaining (CBC) Mode. Other confidentiality algorithms and modes may also be implemented in addition to this mandatory algorithm and mode. Export of encryption and use of encryption are regulated in some countries. [OTA94] 3.3 COMBINING SECURITY MECHANISMS In some cases the IPv6 Authentication Header might be combined with the IPv6 Encapsulating Security Protocol to obtain the desired security properties. The Authentication Header always provides integrity and authentication and can provide non-repudiation if used with certain authentication algorithms (e.g. RSA) . The Encapsulating Security Payload always provides integrity and confidentiality and can Atkinson [Page 5] Internet Draft IPv6 Security Architecture 15 February 1995 also provide authentication if used with certain authenticating encryption algorithms. Adding the Authentication Header to a IPv6 datagram prior to encapsulating that datagram using the Encapsulating Security Protocol might be desirable for users wishing to have strong integrity, authentication, confidentiality, and perhaps also non-repudiation. When the two mechanisms are combined, the placement of the IPv6 Authentication Header makes clear which part of the data is being authenticated. Details on combining the two mechanisms are provided in the IPv6 Encapsulating Security Payload specification. [At94b] 3.4 OTHER SECURITY MECHANISMS Protection from traffic analysis is not provided by any of the security mechanisms described above. It is unclear whether meaningful protection from traffic analysis can be provided economically at the Internet Layer and it appears that few Internet users are concerned about traffic analysis. One traditional method for protection against traffic analysis is the use of bulk link encryption. Another technique is to send false traffic in order to increase the noise in the data provided by traffic analysis. The reader is referred to [VK83] for more information on traffic analysis issues. 4. KEY MANAGEMENT The Key Management protocol that will be used with IPv6 has not been specified yet. However, because the key management protocol is coupled to the other security mechanisms only via the Security Association Identifier (SAID), those other security mechanisms have already been defined. IPv6 is not intended to support so-called "in-band" key management, where the key management data is carried in a distinct IPv6 header. Instead it will primarily use so-called "out-of-band" key management, where the key management data will be carried by an upper layer protocol such as UDP or TCP on some specific port number. This permits clear decoupling of the key management mechanism from the other security mechanisms. What follows in this section is a brief discussion of a few alternative approaches to key management. 4.1 Manual Key Distribution The simplest form of key management is manual key management, where a person manually configures each system with its own key and also with the keys of other communicating systems. This is quite practical in small, static environments but does not scale. It is not a viable medium-term or long-term approach, but might be appropriate and useful in many environments in the near-term. For example, within a small LAN it is entirely practical to manually configure keys for each system. Within a single administrative domain it is practical to Atkinson [Page 6] Internet Draft IPv6 Security Architecture 15 February 1995 configure keys for each router so that the routing data can be protected and to reduce the risk of an intruder breaking into a router. Another case is where an organisation has an encrypting firewall between the internal network and the Internet at each of its sites and it connects two or more sites via the Internet. In this case, the encrypting firewall might selectively encrypt traffic for other sites within the organisation using a manually configured key, while not encrypting traffic with other destinations. It also might be appropriate when only selected communications need to be secured. 4.2 Some Existing Key Management Techniques There are a number of key management algorithms that have been described in the public literature. Needham & Schroeder have proposed a key management algorithm which relies on a centralised key distribution system. [NS78, NS81] This algorithm is used in the Kerberos Authentication System developed at MIT under Project Athena. [KB93] More recently, Diffie & Hellman have devised an algorithm which does not require a centralised key distribution system. [DH76] Unfortunately, the original Diffie-Hellman technique is vulnerable to an active attack. However, this vulnerability can be mitigated by using signed keys to authentically bootstrap into the Diffie-Hellman exchange. 4.3 Automated Key Distribution Widespread deployment and use of IPv6 security will require an Internet-standard scalable key management protocol. Ideally such a protocol would support a number of protocols in the Internet protocol suite, not just IPv6 security. There is work underway within the IETF to add signed host keys to the Domain Name System [EK94] The DNS keys enable the originating party would to authenticate key management messages with the other key management party using an asymmetric algorithm. The two parties would then have an authenticatible communications channel that could be used to create a shared session key using Diffie-Hellman or other means. [DH76] [NB: Phil Karn's recent key management proposal, known as "Photuris" and available as draft-karn-photuris-00.txt, is similar to this and looks very promising for IPv6 key management. ] Further, the security mechanisms can be keyed either on a host-to-host basis, where all users on host 1 share the same key for use on traffic destined for all users on host 2, or on a user-to-user basis, where user A on host 1 has a unique session key with user B on host 2. When host-to-host keying is used and given two users A and B Atkinson [Page 7] Internet Draft IPv6 Security Architecture 15 February 1995 that do not trust each other but do have access to the network connecting their computer with other systems, it is possible for user A to determine the host-to-host key via well known methods and then either read user B's encrypted traffic or forge traffic from user B. When user-to-user keying is used, this particular attack from one user onto another user's traffic is not possible. 4.4 Multicast Key Distribution Multicast key distribution is an active research area in the published literature as of this writing. For multicast groups having relatively few members, manual key distribution or multiple use of existing unicast key distribution algorithms such as modified Diffie-Hellman appears feasible. For very large groups, new scalable techniques will be needed. The use of Core-Based Trees (CBT) to provide session key management as well as multicast routing might be an approach used in the future. [BFC93] 4.5 IPv6 Key Management Requirements All IPv6 implementations MUST support manual key management. All IPv6 implementations SHOULD support an Internet standard key management protocol once the latter is defined. All IPv6 implementations MUST permit the configuration and use of user-to-user keying for traffic originating at that system and MAY additionally permit the configuration of host-to-host keying for traffic originating at that system as an added feature to make manual key distribution easier and give the system administrator more flexibility. A device that encrypts IPv6 packets originated on other systems, for example a dedicated IP encryptor or an encrypting gateway, cannot generally provide user-to-user keying for traffic originating on other systems. Hence, such systems MUST implement support for host-to-host keying for traffic originating on other systems and MAY implement support for user-to-user keying for traffic originating on other systems. The method by which keys are configured on a particular system is implementation-defined. A flat file containing security association identifiers and the security parameters, including the key(s), is an example of one possible method for manual key distribution. 5. USAGE This section describes the use of the security mechanisms provided by IPv6 in several different situations. Atkinson [Page 8] Internet Draft IPv6 Security Architecture 15 February 1995 5.1 USE WITH FIREWALLS Firewalls are not uncommon in the current Internet. While many dislike their presence because they restrict connectivity, they are unlikely to disappear in the near future. Both of the IPv6 mechanisms can be used to increase the security provided by firewalls. Firewalls used with IPv6 will need to be able to parse the header daisy-chain to determine the transport protocol (e.g. UDP or TCP) in use and the port number for that protocol. Firewall performance should not be significantly affected by use of IPv6 because the header format rules in IPv6 make parsing easy and fast. Firewalls can use the Authentication Header to gain assurance that the data (e.g. source, destination, transport protocol, port number) being used for access control decisions is correct and authentic. IPv4 firewalls are unable to authenticate the data being used for access control decisions and necessarily trust data that is not trustworthy. Authentication might be performed not only within an organisation or campus but also end to end with remote systems across the Internet. This use of the Authentication Header with IPv6 provides much more assurance of security than IPv4 provides. Organisations with two or more sites that are interconnected using commercial IP service might wish to use a selectively encrypting firewall. If an encrypting firewall were placed between each site of the Foo Company and the commercial IP service provider, the firewall could provide an encrypted IP tunnel among all of the Foo Company's sites. It could also encrypt traffic between the Foo Company and its suppliers, customers, and other affiliates. Traffic with the NIC, with public Internet archive, or some other organisations might not be encrypted because of the unavailability of a standard key management protocol or as a deliberate choice to facilitate better communications, improved network performance, and increased connectivity. Such a practice could easily protect the organisation's sensitive traffic from eavesdropping and modification. Some organisations (e.g. governments) might wish to use a fully encrypting firewall to provide a protected virtual network over commercial IP service. The difference between that and a bulk IPv6 encryption device is that a fully encrypting firewall would provide filtering of the decrypted traffic as well as providing encryption of IP packets. 5.3 USE WITH IPv6 MULTICAST In the past several years, the Multicast Backbone (MBONE) has grown rapidly. IETF meetings and other conferences are now regularly multicast with real-time audio, video, and whiteboards. Many people are now using teleconferencing applications based on IP Multicast in Atkinson [Page 9] Internet Draft IPv6 Security Architecture 15 February 1995 the Internet or in private internal networks. Hence it is important that the security mechanisms in IPv6 be suitable for use in an environment where multicast is the general case. The Security Association Identifiers (SAIDs) used in the IPv6 security mechanisms are receiver-oriented, making them well suited for use in IP multicast. [Atk94a, Atk94b] Unfortunately, most currently published multicast key distribution protocols do not scale well. However, there is active research in this area. As an interim step, a multicast group could repeatedly use a secure unicast key distribution protocol to distribute the key to all members or the group could pre-arrange keys using manual key distribution. 5.4 USE TO PROVIDE QOS PROTECTION The recent IAB Security Workshop identified Quality of Service protection as an area of significant interest. [BCCH] The two IPv6 security mechanisms are intended to provide good support for real-time services as well as multicasting. This section describes one possible approach to providing such protection. The Authentication Header can be used, with appropriate key management, to provide authentication of packets. This authentication is potentially important in packet classification within routers. The IPv6 Flow Identifier can act as a Low-Level Identifier (LLID). Used together, packet classification within routers becomes straightforward if the router is provided with the appropriate key material. For performance reasons the routers might authenticate only every Nth packet rather than every packet, but this is still a significant improvement over capabilities in the current Internet. Quality of service provisioning is likely to also use the Flow ID in conjunction with a resource reservation protocol, such as RSVP. Thus, the authenticated packet classification can be used to help ensure that each packet receives appropriate handling inside routers. 5.5 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS A multi-level secure (MLS) network is one where a single network is used to communicate data at different sensitivity levels (e.g. Unclassified and Secret). Many governments have significant interest in MLS networking. [DIA] The IPv6 security mechanisms have been designed to support MLS networking. MLS networking requires the use of strong Mandatory Access Controls (MAC) which ordinary users are incapable of controlling or violating. Mandatory Access Controls differ from Discretionary Access Controls in this respect. The Authentication Header can be used to provide strong authentication among hosts in a single-level network. The Authentication Header can also be used to provide strong assurance for both mandatory access control decisions in multi-level networks and Atkinson [Page 10] Internet Draft IPv6 Security Architecture 15 February 1995 discretionary access control decisions in all kinds of networks. If IP sensitivity labels are used and confidentiality is not considered necessary within the particular operational environment, the Authentication Header is used to provide authentication for the entire packet, including cryptographic binding of the sensitivity level to the IPv6 header and user data. This is a significant improvement over labelled IPv4 networks where the label is trusted even though it is not trustworthy because there is no authentication or cryptographic binding of the label to the IP header and user data. The Encapsulating Security Payload can be combined with appropriate key policies to provide full multi-level secure networking. In this case each key must be used only at a single sensitivity level and compartment. For example, Key "A" might be used only for sensitive Unclassified packets, while Key "B" is used only for Secret/No-compartments traffic, and Key "C" is used only for Secret/No-Foreign traffic. In sensitive environments, appropriate organisational policies will dictate the actual key management policy and also the set of algorithms that are appropriate for use. In such environments, the ability to communicate between the Internet and the hosts handling sensitive data is probably undesirable. Hence, systems only handling sensitive information might not implement the Internet standard algorithms and instead only have algorithms approved by appropriate policies for such use. Such systems would not be fully conforming to the IPv6 Encapsulating Security Payload specification with regard to implementation of the mandatory Internet algorithm, but those users might not care or might consider that to be desirable. Encryption is very useful and desirable even when all of the hosts are within a protected environment. The Internet-standard encryption algorithm could be used, in conjuction with appropriate key management, to provide strong Discretionary Access Controls (DAC) in conjunction with either implicit or explicit sensitivity labels. [Ke91] Some environments might consider the Internet-standard encryption algorithm sufficiently strong to provide Mandatory Access Controls (MAC). Full encryption SHOULD be used for all communications between multi-level computers or compartmented mode workstations even when the computing environment is considered to be protected. Atkinson [Page 11] Internet Draft IPv6 Security Architecture 15 February 1995 6. SECURITY CONSIDERATIONS This entire draft discusses the IPv6 Security Architecture. Users need to understand that the quality of the security provided by the mechanisms provided by IPv6 depends completely on the strength of the implemented cryptographic algorithms, the strength of the key being used, the correct implementation of the cryptographic algorithms, the security of the key management protocol, and the correct implementation of IPv6 and the several security mechanisms in all of the participating systems. The security of the implementation is in part related to the security of the operating system which embodies the security implementations. For example, if the operating system does not keep the private cryptologic keys confidential, then traffic using those keys will not be secure. If any of these is incorrect or insufficiently secure, little or no real security will be provided to the user. Because different users on the same system might not trust each other, each user or each session should usually be keyed separately. This will also tend to increase the work required to cryptanalyse the traffic since not all traffic will use the same key. Certain security properties (e.g. traffic analysis protection) are not provided by any of these mechanisms. One possible approach to traffic analysis protection is appropriate use of link encryption. [VK83] Users must carefully consider which security properties they require and take active steps to ensure that their needs are met by these or other mechanisms. Certain applications (e.g. electronic mail) probably need to have application-specific security mechanisms. Application-specific security mechanisms are out of the scope of the IPv6 Security Architecture. Users interested in electronic mail security should consult the RFCs describing the Internet's Privacy-Enhanced Mail system. Users concerned about other application-specific mechanisms should consult the online RFCs to see if suitable Internet Standard mechanisms exist. ACKNOWLEDGEMENTS Many of the concepts here are derived from or were influenced by the US Government's SDNS security protocol specifications, the ISO/IEC's NLSP specification, or from the proposed swIPe security protocol. [SDNS, ISO, IB93, IBK93] The work done for SNMP Security and SNMPv2 Security influenced the choice of default cryptological algorithms and modes. [GM93] Steve Bellovin, Steve Deering, Richard Hale, George Kamis, Phil Karn, Frank Kastenholz, and Dave Mihelcic provided critiques of early versions of this draft. Atkinson [Page 12] Internet Draft IPv6 Security Architecture 15 February 1995 REFERENCES [At94a] Randall Atkinson, IPv6 Authentication Header, Internet Draft, draft-atkinson-ipng-auth-01.txt, 15 February 1995. [At94b] Randall Atkinson, IPv6 Encapsulating Security Payload, Internet Draft, draft-atkinson-ipng-esp-01.txt, 15 February 1995 [BCCH94]R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture", RFC-1636, DDN Network Information Center, June 1994. [BFC93] A. Ballardie, P. Francis, & J. Crocroft, "Core Based Trees: An Architecture for Scalable Inter-Domain Multicast Routing", Proceedings of ACM SIGCOMM 93, ACM Computer Communications Review, Volume. 23, Number 4, October 1993, pp. 85-95. [DIA] US Defense Intelligence Agency, "Compartmented Mode Workstation Specification", Technical Report DDS-2600-6243-87. [DH76] W. Diffie & M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, Vol. IT-22, No. 6, November 1976, pp. 644-654. [EK94] D. Eastlake III & C. Kaufman, "Domain Name System Protocol Security Extensions", Internet Draft, March 1994. [GM93] J. Galvin & K. McCloghrie, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. [HA94] N. Haller & R. Atkinson, "On Internet Authentication", RFC-1704, DDN Network Information Center, October 1994. [Hi94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6) Specification, draft-hinden-ipv6-spec-00.txt, October 1994. [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993. [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio. Atkinson [Page 13] Internet Draft IPv6 Security Architecture 15 February 1995 [Ke91] Steve Kent, US DoD Security Options for the Internet Protocol, RFC-1108, DDN Network Information Center, November 1991. [Ke93] Steve Kent, Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management, RFC-1422, DDN Network Information Center, 10 February 1993. [KB93] J. Kohl & B. Neuman, The Kerberos Network Authentication Service (V5), RFC-1510, DDN Network Information Center, 10 September 1993. [NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers", Communications of the ACM, Vol. 21, No. 12, December 1978, pp. 993-999. [NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisted", ACM Operating Systems Review, Vol. 21, No. 1., 1981. [OTA94] US Congress, Office of Technology Assessment, "Information Security & Privacy in Network Environments", OTA-TCT-606, Government Printing Office, Washington, DC, September 1994. [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990. [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. DISCLAIMER The views expressed in this note are those of the author and are not necessarily those of his employer. The Naval Research Laboratory has not passed judgement on the merits, if any, of this work. The author and his employer specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this design. AUTHOR INFORATION Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Voice: (DSN) 354-8590 Fax: (DSN) 354-7942 Atkinson [Page 14] --PART-BOUNDARY=.19502151813.ZM2365.bodhi-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 22:32:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28637; Wed, 15 Feb 95 22:32:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28344; Wed, 15 Feb 95 15:25:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20443; Wed, 15 Feb 1995 15:18:09 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB15841; Wed, 15 Feb 95 15:18:02 PST From: Ran Atkinson Message-Id: <9502151814.ZM2375@bodhi> Date: Wed, 15 Feb 1995 18:14:06 -0500 X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) IPv6 Security Architecture draft Mime-Version: 1.0 Encoding: 2 TEXT BOUNDARY, 7 MESSAGE, 2 TEXT BOUNDARY, 791 MESSAGE, 3 TEXT BOUNDARY Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19502151814.ZM2375.bodhi" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM -- --PART-BOUNDARY=.19502151814.ZM2375.bodhi Encoding: 4 TEXT Content-Type: text/plain; charset=us-ascii Here is IPv6 Sec. Arch. draft Ran --PART-BOUNDARY=.19502151814.ZM2375.bodhi Encoding: 787 text X-Zm-Content-Name: ipv6-esp.txt Content-Type: text/plain ; charset=us-ascii Network Working Group Randall Atkinson Internet Draft Naval Research Laboratory draft-atkinson-ipng-esp-0a.txt 14 February 1995 IPv6 Encapsulating Security Payload (ESP) 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 6 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 "work in progress". This particular Internet Draft is a product of the IETF's IPng working group. It is intended that a future version of this draft be submitted to the IPng Area Directors and the IESG for possible publication as a standards-track protocol. Discussion of this draft takes place on the IPng Working Group mailing list: ipng@sunroof.eng.sun.com 1. INTRODUCTION This memo describes the IPv6 Encapsulating Security Payload (ESP). ESP seeks to provide integrity and confidentiality to IPv6 datagrams. It may also provide authentication, depending on which algorithm and algorithm mode are used. Non-repudiation and protection from traffic analysis are not provided by ESP. The IPv6 Authentication Header (AH) might provide non-repudiation if used with certain authentication algorithms. The IPv6 Authentication Header may be used in conjunction with ESP to provide authentication. Users desiring integrity and authentication without confidentiality should use the IPv6 Authentication Header (AH) instead of ESP. This document assumes that the reader is familiar with the related document "IPv6 Security Architecture", which defines the overall security architecture for IPv6 and provides important background for this specification. Atkinson [Page 1] Internet Draft IPv6 Encapsulating Security 15 February 1995 1.1 OVERVIEW The IPv6 Encapsulating Security Payload (ESP) seeks to provide confidentiality and integrity by encrypting data to be protected and placing the encrypted data in the data portion of the IPv6 Encapsulating Security Payload. Either a transport-layer (e.g. UDP or TCP) frame may be encrypted or an entire IPv6 datagram may be encrypted, depending on the user's security requirements. Encapsulating the protected data is necessary to provide confidentiality for the entire original datagram, but can be very expensive to implement. Use of this specification will increase the IPv6 protocol processing costs in participating systems and will also increase the communications latency. The increased latency is primarily due to the encryption and decryption required for each IPv6 datagram containing an Encapsulating Security Payload. In order for ESP to work properly without changing the entire Internet infrastructure (e.g. non-participating systems), the original IPv6 datagram is placed in the encrypted portion of the Encapsulating Security Payload and that entire ESP frame is placed within an datagram having unencrypted IPv6 headers. The information in the unencrypted IPv6 headers is used to route the secure datagram from origin to destination. An unencrypted IPv6 Routing Header might be included between the IPv6 Header and the Encapsulating Security Payload. An IPv6 Authentication Header may be present both as an header of the unencrypted IPv6 packet and also as a header within the encrypted IPv6 packet. In such a case, the unencrypted Authentication Header is primarily used to provide protection for the contents of the unencrypted IPv6 headers and the encrypted Authentication Header is used to provide authentication for the encrypted IPv6 packet. The encapsulating security payload is structured a bit differently than other IPv6 payloads. The first component of the ESP payload consist of the unencrypted field(s) of the payload. The second component consists of encrypted data. The field(s) of the unencrypted ESP header inform the intended receiver how to properly decrypt and process the encrypted data. The encrypted data component includes protected fields for the security protocol and also the encrypted encapsulated IPv6 datagram. 2. KEY MANAGEMENT Key management is an important part of the IPv6 security architecture. However, it is not included in this specification because of a long history in the public literature of subtle flaws in key management algorithms and protocols. IPv6 tries to decouple the key management mechanisms from the security protocol mechanisms. The only coupling between the key management protocol and the security Atkinson [Page 2] Internet Draft IPv6 Encapsulating Security 15 February 1995 protocol is with the Security Association Identifier (SAID), which is described in more detail below. This decoupling permits several different key management mechanisms to be used. More importantly, it permits the key management protocol to be changed or corrected without unduly impacting the security protocol implementations. Thus, a key management protocol for IPv6 is not specifed within this draft. [NB: It is intended that the key management mechanisms being developed elsewhere in the IETF will be reused for IPv6. In particular, the Eastlake-Kaufman DNS Security work on storing signed public keys in the DNS and Karn's Photuris key management protocol look promising for use with IPv6. ] The key management mechanism is used to negotiate a number of parameters for each security association, including not only the keys but other information (e.g. the cryptographic algorithms and modes, security classification level if any) used by the communicating parties. The key management protocol implementation usually creates and maintains a table containing the several parameters for each current security association. An ESP implementation normally needs to read that security parameter table to determine how to process each datagram containing an ESP (e.g. which algorithm/mode and key to use). There are two approaches to key management. The first approach, called host-to-host, uses a common key to protect all communications between users on host A and users on host B. The second approach, called user-to-user, uses a separate key for each user so that user 1 on host A and user 2 on host A will use different keys when sending to user 3 on host B. With host-to-host but not user-to-user keying, mutually hostile users might be able to deduce the shared key in use (e.g. using a Chosen Plaintext attack). If one were able to deduce the key in use, then one could forge traffic from another user on the compromised system. User-to-user keying is preferable and eliminates this potential problem. The key management requirements for IPv6 Encapsulating Security Payload are discussed more fully in the IPv6 Security Architecture document in Section 4.5 "IPv6 Key Management Requirements". 3. ENCAPSULATING SECURITY PAYLOAD SYNTAX The Encapsulating Security Payload (ESP) may appear anywhere after the IPv6 header. The Internet Assigned Numbers Authority has assigned Protocol Number 50 to IPv6 ESP. Thus the header immediately preceding the ESP header will always contain the value 50 in its Next Header field. ESP consists of an unencrypted header followed by encrypted data. The encrypted data includes both the protected ESP header fields and the protected user data, which is either an entire IPv6 datagram or an upper-layer protocol frame (e.g. TCP or UDP). A Atkinson [Page 3] Internet Draft IPv6 Encapsulating Security 15 February 1995 high-level diagram of a secure IPv6 datagram follows. |<-- Unencrypted -->|<---- Encrypted ------>| +-------------+--------------------+------------+---------------------+ | IPv6 Header | Other IPv6 Headers | ESP Header | encrypted data | +-------------+--------------------+------------+---------------------+ A more detailed diagram of the ESP Header follows. In this diagram, the cleartext fields are detailed. +-------------+--------------------+------------+---------------------+ | Security Association Identifier (SAID), 32 bits | +-------------+--------------------+------------+---------------------+ | Syncronisation Data, variable length | +=============+====================+============+=====================+ | Encrypted Data, variable length | +-------------+--------------------+------------+---------------------+ After decryption, the data transmitted in the above "Encrypted Data" field is formatted as follows: +-------------+--------------------+-----------------+----------------+ | Next Header | Header Length | Reserved | +-------------+--------------------+-----------------+----------------+ | Protected data (either an entire IPv6 datagram | | or a UDP frame or a TCP frame), variable length | +-------------+--------------------+-----------------+----------------+ 3.1 CLEARTEXT FIELDS The IPv6 Header is the conventional IPv6 Header defined by others in a separate Internet Draft. The ESP unencrypted field(s) are as follows: _S_E_C_U_R_I_T_Y _A_S_S_O_C_I_A_T_I_O_N _I_D_E_N_T_I_F_I_E_R (_S_A_I_D) A 32-bit value identifying the security association for this datagram. If no security association has been established, the value of this field shall be 0x0000. A security association is normally one-way. An authenticated communications session between two hosts will normally have two SAIDs in use (one in each direction). The receiving host uses the combination of SAID value and originating address to distinguish the correct association. An ESP implementation will always be able to use the SAID in combination with the 128-bit Destination Address to determine the security association and related security configuration data for all valid incoming packets. Senders to a multicast group may share a common SAID for all communications if all communications are authenticated using the same security configuration parameters (e.g. algorithm, key, security classification level, etc.). In this case, the receiver only knows Atkinson [Page 4] Internet Draft IPv6 Encapsulating Security 15 February 1995 that the message came from a host knowing the security association data for the group and cannot authenticate which member of the group sent the datagram. Multicast groups may also use a separate SAID for each sender. In any event, the combination of Destination Address and SAID is used to determine the correct security association data. If each sender is keyed separately and asymmetric algorithms are used, data origin authentication is also a provided service. Each SAID value implies the key(s) used to encrypt and decrypt the encrypted portion of the ESP payload, the sensitivity level (e.g. Secret, Unclassified) of the user data in the ESP payload, the encryption algorithm being used, the block size (if any) of the encryption algorithm, the authentication algorithm being used (if separate from the encryption algorithm), the block size (if any) of the authentication algorithm, and the presence/absence and size of a cryptographic synchronisation or initialisation vector field at the start of the encrypted portion of the ESP (if no such field is present, then the size is of course zero). _S_Y_N_C_H_R_O_N_I_S_A_T_I_O_N _D_A_T_A This field is present only for algorithms which require a cryptographic synchronisation field for each packet. The value of this field is arbitrary. The length of this field is variable, though for any given algorithm it has a particular known length. It is considered to be plaintext in this document, though most users will not be able to make sense of its contents. Its presence or absence and its size are constant for all secure datagrams of any given SAID value. The ESP specification includes this field so that the payload specification will be independent of the cryptographic algorithm that is being used by the communicating systems. If present, the field contains cryptographic synchronisation data, such as a DES Initialisation Vector, for whichever algorithm is in use. [ISO92b] An ESP implementation will normally use the Security Association Identifier value for the payload being processed to determine whether this field is present and to determine the field's size and use if present. 3.2 ENCRYPTED FIELDS The ESP encrypted fields are as follows: _N_E_X_T _H_E_A_D_E_R This field contains the value indicating which header follows the ESP Encrypted Fields. For example, if an entire IP datagram follows, the field will contain the number 94, which has been allocated by IANA to indicate IP-in-IP encapsulation. [STD-2] _H_E_A_D_E_R _L_E_N_G_T_H This field is contains the length of the set of encrypted ESP fields Atkinson [Page 5] Internet Draft IPv6 Encapsulating Security 15 February 1995 (i.e. Next Header, Header Length, Reserved) minus the 8 byte minimum length. The minimum length is 64-bit aligned to comply with normal IPv6 alignment rules. _R_E_S_E_R_V_E_D This field is currently used primarily for padding out to 64-bit alignment but might be used for other purposes in the future. It MUST be set to zero on transmission and MUST be ignored upon receipt. It is 16 bits long. It is important that all routing headers and other data be included within the encrypted IPv6 datagram, even if the same data is in the unencrypted part of the IPv6 datagram. The receiving system shall ignore all routing information in the unencrypted portion of the received datagram and shall strictly rely on the routing information from the protected payload instead. If this rule is not strictly adhered to, then the system will be vulnerable to various kinds of attacks, including source routing attacks. [Bel89][CERT95] The encrypted IPv6 datagram need not contain any explicit Security Label because the SAID indicates the sensitivity label for the encrypted IPv6 datagram. This is an improvement over the current practices with IPv4 where an explicit Security Label is normally used with Compartmented Mode Workstations and other systems requiring Security Labels. [RFC-1108] [DIA] If it is necessary to pad the protected data (e.g. to an integral block-size of the cryptographic algorithm in use), then the normal IPv6 Padding header is used to provide that padding. This means that ESP will not work with block-oriented algorithms whose block size is not an integral number of 8-bit bytes. 4. ENCAPSULATING SECURITY PROTOCOL PROCESSING This section describes the steps taken when ESP is in use between two communicating parties. Multicast is different from unicast only in the area of key management (See the definition of the SAID, above, for more detail on this). There are two modes of use for ESP. The first mode, which is called "IP-mode", encapsulates an entire IP datagram inside ESP. The second mode, which is called "Transport-Mode", encapsulates a transport-layer (e.g. UDP or TCP) frame inside ESP. These terms should not be misconstrued as restrictive, for example an ICMP/IGMP message might be sent either using the "Transport-mode" or the "IP-mode" depending upon circumstance. This section describes protocol processing for each of these two modes. Atkinson [Page 6] Internet Draft IPv6 Encapsulating Security 15 February 1995 4.1 ESP in IP-mode The sender takes the original IPv6 datagram, encapsulates it into the ESP and then applies the encryption algorithm using the appropriate key for combination of sending userid and the receiving party. If no key has been established, then the key management mechanism is used to establish a encryption key for this communications session prior to the encryption. The (now encrypted) ESP is then encapsulated in a cleartext IPv6 datagram as the last payload. If strict red/black separation is being enforced, then the addressing and other information in the cleartext IPv6 headers and optional payloads might be different from the values contained in the (now encrypted and encapsulated) original datagram. The receiver strips off the cleartext IPv6 header and cleartext optional IPv6 payloads (if any) and discards them. It then decrypts the ESP using the session key that has been established for this traffic. If no encryption key exists for this session, the encrypted ESP is discarded and the failure is recorded in the system or audit log, including the cleartext values for the SAID, date/time, Sending Address, Destination Address, and the Flow ID. The original IPv6 datagram is then removed from the (now decrypted) ESP. This original IPv6 datagram is then processed as per the normal IPv6 protocol specification. In the case of a B1 or Compartmented Mode Workstation, additional appropriate mandatory access controls should be applied. 4.2 ESP in Transport-mode The sender takes the original UDP or TCP or ICMP frame, encapsulates it into the ESP and then applies the encryption algorithm using the appropriate key for the combination of sending userid and receiving party. If no key has been established, then the key management mechanism is used to establish a encryption key for this communications session prior to the encryption. The (now encrypted) ESP is then encapsulated as the last payload of a cleartext IPv6 datagram. The receiver processes the cleartext IPv6 header and cleartext optional IPv6 headers (if any) and temporarily stores pertinent information (e.g. source and destination addresses, Flow ID, Routing Header). It then decrypts the ESP using the session key that has been established for this traffic, using the combination of the destination address and the packet's Security Association Identifier (SAID) to locate the correct key. If no key exists for this session, the encrypted ESP is discarded and the failure is recorded in the system or audit log. If such a failure occurs, the recorded log data should include the cleartext values for the SAID, date/time received, Sending Address, Destination Address, and the Flow ID. The log data may also Atkinson [Page 7] Internet Draft IPv6 Encapsulating Security 15 February 1995 include other information about the failed packet. The original UDP or TCP frame is then removed from the (now decrypted) ESP. The information from the cleartext IPv6 header and the now decrypted UDP or TCP header is jointly used to determine which application the data should be sent to. The data is then sent along to the appropriate application as normally per IPv6 protocol specification. In the case of a B1 or Compartmented Mode Workstation, additional Mandatory Access Controls should be appropriately applied. Atkinson [Page 8] Internet Draft IPv6 Encapsulating Security 15 February 1995 4.3. Combining ESP and the Authentication Header This section describes how to combine the Encapsulating Security Protocol with Authentication Header. There are two different approaches, depending on which part of the data is to be authenticated. The location of the IPv6 Authentication Header makes it clear which set of data is being authenticated. In the first usage, the entire received datagram is authenticated, including both the encrypted and unencrypted portions, while only the data sent after the ESP Header is confidential. In this usage, the sender first applies ESP to the data being protected. Then the other plaintext IPv6 headers are prepended to the ESP header and its now encrypted data. Finally, the IPv6 Authentication Header is calculated over the resulting datagram according to the normal method. Upon receipt, the receiver first verifies the authenticity of the entire datagram using the normal IPv6 Authentication Header process. Then if authentication succeeds, decryption using the normal IPv6 ESP process occurs. If decryption is successful, then the resulting data is passed up to the upper layer. If the authentication process were to be applied only to the data protected by IPv6 ESP and the protected data were an entire IPv6 datagram, then the IPv6 Authentication Header would be placed normally within that protected datagram. However, if the protected data were less than an entire IPv6 datagram, then the IPv6 Authentication Header would be placed within the encrypted payload immediately after the ESP protected header and before any other header or the UDP or TCP frame. If the Authentication Header is encapsulated within the ESP header, both headers have specific security classification levels associated with them, and the two security classification levels are not identical, then an error has occurred. That error should be recorded in the system or audit log using the procedures described previously. It is not necessarily an error for an Authentication Header located outside of the ESP header to have a different security classification level than the ESP header's classification level. This is true because the cleartext IP headers might have a different classification level when the data is encrypted using ESP. 6. TYPICAL USE The ESP supports security between two or more hosts implementing ESP, between two or more gateways implementing ESP, and between a host or gateway implementing ESP and a set of hosts and/or gateways. A security gateway is a system which acts as the communications gateway between external untrusted systems and trusted hosts on their own subnetwork and provides security services for the trusted hosts when Atkinson [Page 9] Internet Draft IPv6 Encapsulating Security 15 February 1995 they communicate with external untrusted systems. A trusted subnetwork contains hosts and routers that trust each other not to engage in active or passive attacks and trust that the underlying communications channel (e.g. an Ethernet) isn't being attacked. Trusted systems always should be trustworthy, but in practice they often are not trustworthy. In the case where a security gateway is providing services on behalf of one or more hosts on a trusted subnet, the security gateway is responsible for establishing the security association on behalf of its trusted host and for providing security services between the security gateway and the external system(s). In this case, only the gateway need implement ESP, while all of the systems behind the gateway on the trusted subnet may take advantage of ESP services between the gateway and external systems. A gateway which receives a datagram containing a recognised sensitivity label from a trusted host should take that label's value into consideration when creating/selecting an SAID for use with ESP between the gateway and the external destination. In such an environment, a gateway which receives a IPv6 packet containing the ESP should appropriately label the decrypted packet that it forwards to the trusted host that is the ultimate destination. The IPv6 Authentication Header should always be used on packets containing explicit sensitivity labels to ensure end-to-end label integrity. If there are no security gateways present in the connection, then two end systems that implement ESP may also use it to encrypt only the user data (e.g. TCP or UDP) being carried between the two systems. ESP is designed to provide maximum flexibility so that users may select and use only the security that they desire and need. 7. SECURITY CONSIDERATIONS This entire draft discusses a security mechanism for use with IPv6. This mechanism is not a panacea, but it does provide an important component useful in creating a secure internetwork. Users need to understand that the quality of the security provided by this specification depends completely on the strength of whichever encryption algorithm that has been implemented, the correctness of that algorithm's implementation, upon the security of the key management mechanism and its implementation, the strength of the key [CN94] and upon the correctness of the ESP and IPv6 implementations in all of the participating systems. If any of these assumptions do not hold, then little or no real security will be provided to the user. Use of high assurance development techniques is recommended for the IPv6 Encapsulating Security Payload. Users seeking protection from traffic analysis might consider the use Atkinson [Page 10] Internet Draft IPv6 Encapsulating Security 15 February 1995 of appropriate link encryption. Description and specification of link encryption is outside the scope of this note. If user-to-user keying is not in use, then the algorithm in use should not be vulnerable to any kind of Chosen Plaintext attack. A Chosen Plaintext attack on DES is described in [BS93]. Use of user-to-user keying is recommended in order to preclude any sort of Chosen Plaintext attack and to generally make cryptanalysis more difficult. ACKNOWLEDGEMENTS Many of the concepts here are derived from or were influenced by the US Government's SP3 security protocol specification, the ISO/IEC's NLSP specification, or from the proposed swIPe security protocol. [SDNS89, ISO92a, IB93, IBK93, ISO92b] The use of DES for confidentiality is closely modeled on the work done for the SNMPv2. [GM93] Steve Bellovin, Steve Deering, and Dave Mihelcic provided useful critiques of earlier versions of this draft. REFERENCES [Atk95a] Randall J. Atkinson, IPv6 Security Architecture, Internet Draft, draft-atkinson-ipng-sec-01.txt, 15 February 1995. [Atk95b] Randall J. Atkinson, IPv6 Authentication Header, Internet Draft, draft-atkinson-ipng-auth-01.txt, 15 February 1995. [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989. [BS93] Eli Biham and Adi Shamir, "Differential Cryptanalysis of the Data Encryption Standard", Springer-Verlag, New York, NY, 1993. [CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18, No. 23, July 1994. pp. 253-280 [CERT95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org. [DIA] US Defense Intelligence Agency (DIA), "Compartmented Mode Workstation Specification", Technical Report DDS-2600-6243-87. [GM93] James Galvin & Keith McCloghrie, Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. Atkinson [Page 11] Internet Draft IPv6 Encapsulating Security 15 February 1995 [Hin94] Robert Hinden (Editor), IPv6 Specification, Internet Draft, draft-hinden-ipng-ipv6-spec-00.txt, October 1994. [IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of the USENIX Security Symposium, Santa Clara, CA, October 1993. [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio. [ISO92a] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [ISO92b] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, Section 13.4.1, page 33, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [RFC-1108] Steve Kent, "US DoD Security Options for the Internet Protocol (IPSO)", RFC-1108, DDN Network Information Center, November 1991. [NIST77] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [NIST80] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [NIST81] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981. [NIST88] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988. [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, DDN Network Information Center, 20 October 1994. [Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2 [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990. Atkinson [Page 12] Internet Draft IPv6 Encapsulating Security 15 February 1995 DISCLAIMER The views and specification here are those of the author and are not necessarily those of his employer. The Naval Research Laboratory has not passed judgement on the merits, if any, of this work. The author and his employer specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. AUTHOR INFORATION Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Telephone: (DSN) 354-8590 Fax: (DSN) 354-7942 Atkinson [Page 13] Internet Draft IPv6 Encapsulating Security 15 February 1995 APPENDIX A: Use of CBC-Mode DES with IPv6 ESP This appendix describes the application of the Cipher Block Chaining (CBC) mode of the US Data Encryption Standard (DES) algorithm to the IPv6 Encapsulating Security Payload. This mode of DES requires an Initialisation Vector that is 8 bytes long and requires that the encrypted data be a multiple of 8 bytes long. DES is described is several US Government publications. [NIST77, NIST80, NIST81, NIST88] A recent book also provides information on DES. [Sch94] That same reference indicates on page 231 that at least one hardware implementation of DES CBC can encrypt or decrypt at about 1 Gbps. Each ESP header shall contain a 64-bit DES Initialisation Vector in the Cryptographic Synchronisation field when DES-CBC is in use. Each packet needs to contain its own different DES Initialisation Vector. Including the Initialisation Vector in each packet also ensures decryption of each received packet can be performed even though other packets might have been dropped or packets might have been misordered in transit. The method for selection of the Initialisation Vector value is implementation-defined. The secret DES key shared between the communicating parties is 64 bits long, as per the DES specifications [NIST77, NIST80, NIST81, NIST88]. The 64-bit DES key consists of a 56-bit quantity used by the DES algorithm and 8 parity bits arranged such that one parity bit is the least significant bit of each octet. The length of the octet sequence to be encrypted by the DES algorithm must be an integral multiple of 8. When encrypting, any needed padding shall be included by using a IPv6 hop-by-hop padding option. When the Transport-mode of ESP is used, such padding must appear between the encrypted ESP header fields and the start of the UDP or TCP data. If the length of the octet sequence to be decrypted is not an integral multiple of 8 octets, then processing shall be halted, the packet shall be discarded, and the event should be recorded in the system or audit log using implementation-specific methods. Atkinson [Page 14] --PART-BOUNDARY=.19502151814.ZM2375.bodhi-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 23:01:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28672; Wed, 15 Feb 95 23:01:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28666; Wed, 15 Feb 95 23:01:40 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02376; Wed, 15 Feb 1995 22:54:45 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA16610; Wed, 15 Feb 95 22:54:44 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12525; Thu, 16 Feb 1995 17:54:26 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) IPv4 address representation In-Reply-To: Your message of "Wed, 15 Feb 1995 21:56:34 CDT." <9502160256.AA09696@xirtlu.zk3.dec.com> Date: Thu, 16 Feb 1995 17:54:10 +1100 Message-Id: <4399.792917650@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 15 Feb 95 21:56:34 -0500 From: bound@zk3.dec.com Message-ID: <9502160256.AA09696@xirtlu.zk3.dec.com> I was informed offline that this is an official IETF meeting and we can change the specs per an official IETF meeting. Jim, there are two points of view, held by different people, about how IETF decisions get made. One (which was certainly the original philosophy) is that the meetings make decisions, the mailing lists exist purely for discussion, and to allow some work to get done between meetings. The other, which is newer, is that the meetings are useful to quickly get through a lot of work, and perhaps terminate some long running discussions on the lists that hadn't been getting anywhere, but its on the mailing list, and only there, that anything can be done which will ever achieve the status of "that was decided already, no more comment". The former view is largely help by longer term, and regular, IETF attendees, who don't believe mailing lists can ever achieve anything. The latter by people wishing to participate in the IETF, but who simply can't get to every meeting, no matter how much they'd like to. Which is the "official" IETF position is going to be hard to decide, as you have to answer the question first, before you can answer it... My view is that these days the IETF, in either forum, never actually decides anything, everything is always up for review, but that eventually people just get tired of arguing about some point, and whatever the state was at that point gets blessed. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 15 23:29:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28687; Wed, 15 Feb 95 23:29:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28532; Wed, 15 Feb 95 21:12:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28100; Wed, 15 Feb 1995 21:05:29 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA08151; Wed, 15 Feb 95 21:05:32 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA02621; Wed, 15 Feb 95 21:03:36 -0800 Received: by xirtlu.zk3.dec.com; id AA10715; Thu, 16 Feb 1995 00:02:47 -0500 Message-Id: <9502160502.AA10715@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: (IPng) RFC 1001/1002 Date: Thu, 16 Feb 95 00:02:41 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, I am going to check this too. But do we have the FTP issue with RFC 1001 and RFC 1002? If we do we need to say something with all the PCs out there we don't want to break them with IPv6 if we can help it. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 16 04:23:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28849; Thu, 16 Feb 95 04:23:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28843; Thu, 16 Feb 95 04:23:11 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17786; Thu, 16 Feb 1995 04:16:16 -0800 Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA13214; Thu, 16 Feb 95 04:16:15 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id HAA05068 for ipng@sunroof.Eng.Sun.COM; Thu, 16 Feb 1995 07:18:55 -0500 (EST) Date: Thu, 16 Feb 1995 07:18:55 -0500 (EST) From: Scott Bradner Message-Id: <199502161218.HAA05068@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) RFC 1001/1002 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, from RFC1752 Many current IETF standards are affected by IPv6. At least 27 of the current 51 full Internet Standards must be revised for IPv6, along with at least 6 of the 20 Draft Standards and at least 25 of the 130 Proposed Standards. [Postel94] In some cases the revisions consist of simple changes to the text, for example, in a number of RFCs an IP address is referred to in passing as a "32 bit IP address" even though IP addresses are not directly used in the protocol being defined. All of the standards track documents will have to be checked to see if they contain such references. In most of the rest of the cases revisions to the protocols, including packet formats, will be required. In many of these cases the address is just being carried as a data element and a revised format with a larger field for the address will have no effect on the functional paradigm. .... In addition to the standards track RFCs mentioned above there are many Informational and Experimental RFCs which would be affected as well as numerous Internet Drafts (and those standards track RFCs that we missed). We recommend that the IESG commission a review of all standards track RFCs to ensure that a full list of affected documents is compiled. We recommend that the IESG charge current IETF working groups with the task of understanding the impact of IPv6 on their proposals and, where appropriate, revise the documents to include support for IPv6. We recommend that the IESG charter new working groups where required to revise other standards RFCs. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 16 07:48:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28895; Thu, 16 Feb 95 07:48:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28889; Thu, 16 Feb 95 07:48:23 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26649; Thu, 16 Feb 1995 07:41:28 -0800 Received: from chenas.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA09436; Thu, 16 Feb 95 07:41:14 PST Received: from melimelo.enst-bretagne.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA24851; Thu, 16 Feb 1995 16:41:04 +0100 (MET) Received: from rsm.enst-bretagne.fr by melimelo.enst-bretagne.fr (5.67b8/090294); Thu, 16 Feb 1995 16:38:38 +0100 Received: from marple by rsm.enst-bretagne.fr (4.1/SMI-4.1) id AA02175; Thu, 16 Feb 95 16:47:18 +0100 From: lher@rennes.enst-bretagne.fr (Demed L'Her) Received: by marple (4.1/rsalz-13-nov-89); Thu, 16 Feb 95 16:47:17 +0100 Date: Thu, 16 Feb 95 16:47:17 +0100 Message-Id: <9502161547.AA10280@marple> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Address Deployment Cc: lher@rennes.enst-bretagne.fr Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hello, In the Internet Draft "Simple Internet Transition Overview", chapter"IPv6 Address Deployment" we can read : > "Those sites that no longer require IPv4 interoperability may utilize > IPv6-only addresses exclusively" Since the Internet's (which will remain IPv4-based during many years) main interest is precisely the ability it provides to communicate with other organisations, I have the feeling that those sites are not so numerous ... Only organizations that plan to use the Internet as a way to interconnect their IPv6-only sites could be interested in IPv6-only addresses, no ? (at least for a few years). Is there any study regarding the eventual demand of IPv6-only addresses ? Thank you for your time. (if this list is not the right place to ask such questions, please do not hesitate to tell it to me) Dem E-mail : lher@rennes.enst-bretagne.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 16 12:58:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29074; Thu, 16 Feb 95 12:58:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29068; Thu, 16 Feb 95 12:58:04 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07033; Thu, 16 Feb 1995 12:51:09 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA18808; Thu, 16 Feb 95 12:51:08 PST To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) slightly updated IPv6 security drafts Date: Thu, 16 Feb 95 15:46:49 EST From: Ran Atkinson Message-Id: <9502161546.aa03115@bodhi.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I've made the minor edits today and just emailed the corrected updated drafts off to the Internet Drafts folks. They should appear in a few days at the I-D archive site near you. There were no "technical content" changes from the drafts I emailed out preliminarily last night, but a fair number of editorial and cleanup changes. As always, comments about the drafts may be directed either to me personally or to the IPng list as a whole as you all feel is appropriate. I did try to take into account all the list/other feedback I've received since the last set of drafts went out in November 94... Thanks much, Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 16 13:08:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29102; Thu, 16 Feb 95 13:08:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29096; Thu, 16 Feb 95 13:08:45 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09079; Thu, 16 Feb 1995 13:01:49 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA21036; Thu, 16 Feb 95 13:01:48 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA14692; Fri, 17 Feb 1995 08:01:21 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA12015; Fri, 17 Feb 95 06:53:40 +1000 Received: by dcthq2.datacraft.com.au; Fri, 17 Feb 95 7:57:57 +1100 Date: Fri, 17 Feb 95 7:44:03 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: (IPng) A thought on addressing X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM casy, your questions are not stupid. However, the unfortunate fact on this addressing issue is IMHO. One cannot predict (or enforce) what people will do with the design of their networks. One cannot predict what people will do with technology specifications that impacts its operations (ie if one implements x.400 in Fortran and runs it on an AT with 1 meg memory - is the x.400 spec bad?). ditto with mesh networks. The addressing schemes of IP6 like IP4 and OSI etc will have to be administered by groups around the world and interconnectivity/ performance issues will be dealt with on an operational basis. One can only propose address formats and then delegate their administration. One can then design route management schemes based on the rational configurations of the day. One then has to permit flexibility in the technology to deal with redundant/parallel paths - and some evolution will occur here. One cannaot pragmatically design routing algorithms for the extreme .. ie that permit the whole plannet to be mesh connected. hope this helps regards alan@Oz ps perhaps the answer is 42! (hitchhikers guide to the galaxy) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 16 14:01:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29157; Thu, 16 Feb 95 14:01:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29151; Thu, 16 Feb 95 14:01:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22694; Thu, 16 Feb 1995 13:54:32 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA01933; Thu, 16 Feb 95 13:54:28 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08442; 16 Feb 95 16:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-arch-addr-01.txt Date: Thu, 16 Feb 95 16:43:17 -0500 Message-Id: <9502161643.aa08442@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart Note: This announcement is being re-sent with a new filename. 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 : An Architecture for IPv6 Unicast Address Allocation Author(s) : Y. Rekhter, T. Li Filename : draft-ietf-ipngwg-arch-addr-01.txt Pages : 25 Date : 02/14/1995 This document provides an architecture for allocating IPv6 unicast addresses in the Internet. This document does not go into the details of an addressing plan. 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-arch-addr-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-arch-addr-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-arch-addr-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19950214134834.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-arch-addr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-arch-addr-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950214134834.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 16 14:02:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29169; Thu, 16 Feb 95 14:02:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29158; Thu, 16 Feb 95 14:01:47 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22793; Thu, 16 Feb 1995 13:54:52 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA01979; Thu, 16 Feb 95 13:54:42 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08452; 16 Feb 95 16:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-address-format-01.txt Date: Thu, 16 Feb 95 16:43:20 -0500 Message-Id: <9502161643.aa08452@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart Note: This announcement is being re-sent with a new filename. 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 : An IPv6 Global Unicast Address Format Author(s) : Y. Rekhter, P. Lothberg Filename : draft-ietf-ipngwg-address-format-01.txt Pages : 10 Date : 02/14/1995 This document defines an IPv6 global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 address allocation architecture [1], and is intended to facilitate scalable Internet routing. The format defined in this document doesn't preclude the use of other address formats. 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-address-format-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-address-format-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-address-format-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19950214135459.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-address-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-address-format-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950214135459.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 16 18:19:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29275; Thu, 16 Feb 95 18:19:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29269; Thu, 16 Feb 95 18:19:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10037; Thu, 16 Feb 1995 18:12:05 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA24058; Thu, 16 Feb 95 18:12:03 PST Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA23069; Thu, 16 Feb 1995 21:11:59 -0500 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA00316; Thu, 16 Feb 1995 21:11:56 -0500 Received: by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA30281; Thu, 16 Feb 1995 20:47:52 -0500 Date: Thu, 16 Feb 1995 20:47:52 -0500 From: alex conta Message-Id: <9502170147.AA30281@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 Neighbor Discovery - no function similar to 'proxy' ARP Cc: conta@zk3.dec.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As many of you may know, last week in Palo Alto, the IPng working group discussed the IPv6 Neighbor Discovery packet header formats, and also adding several extensions to the existent IPv6 Neighbor Discovery headers extensions. With the editor and author of the document accepting to include only a subset of the extensions proposed during the meeting, the Neighbor Discovery will continue to allow implementing of ONLY a subset of the functions of the ARP based link-layer to IPv4 address mapping used with IPv4 - more precisely, the IPv6 Neighbor Discovery cannot implement a function similar to 'proxy ARP'. Here are more details: As many may know, the ARP packet header format is: struct ether_arp { /* fixed-size header */ u_short ar_hrd; /* format of hardware address */ u_short ar_pro; /* format of protocol address */ u_char ar_hln; /* length of hardware address */ u_char ar_pln; /* length of protocol address */ u_short ar_op; /* one of: */ #define ARPOP_REQUEST 1 /* request to resolve address */ #define ARPOP_REPLY 2 /* response to previous request */ /* variable-size header */ u_char arp_sha[6]; /* sender hardware address */ u_char arp_spa[4]; /* sender protocol address */ u_char arp_tha[6]; /* target hardware address */ u_char arp_tpa[4]; /* target protocol address */ }; which implies that each ARP request and ARP reply header and packet contains a full description of the quadruplet: - source link-layer address - source IPv4 address - target link-layer address - target IPv4 address The quadruplet specifies link-layer addresses completely independent from the link-layer header and addresses contained in it. This allows implementing ARP servers that can be used to resolve the mapping of link-layer addresses to IP v4 addresses for hosts that do not support, or implement ARP, or have for one reason or another the ARP functions disabled. At user command interface level, to the above ARP function corresponds a command 'arp -p...' or 'arp pub ...' which provides the functions necessary to create ARP cache entries with link-layer to IPv4 address mappings for other hosts than the host that owns the ARP cache. In fact, most if not all BSD based IPv4 implementations provide the above mentioned function and command(s). Knowing many instances in which people use or used the function, I think that it is detrimental to the IPv6 Neighbor Discovery to not provide the capability to implement it. In order to retain this function in the IPv6 Neighbor Discovery, four (4) extensions (in fact duplicates and renamed of two existent "extensions") should be added to the IPv6 Neighbor Discovery formats specifications as it follows: Target IPv6 Address (Target Identifier) - duplicate (and renamed) of Change-Identifier +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Length | 0 | Prefix Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Target IPv6 address ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source IPv6 Address (Source Identifier) - duplicate (and renamed) of Change-Identifier +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Length | 0 | Prefix Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Source IPv6 address ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Target Link-Layer Address - duplicate (and renamed) of what used to be named Media-Access +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Length | Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target Link-Layer Address ... +-+-+-+-+-+-+-+-+-+-+-+- Source Link-Layer Address - duplicate (and renamed) of what used to be named Media-Access +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Length | Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Link-Layer Address ... +-+-+-+-+-+-+-+-+-+-+-+- In order to allow implementing the 'proxy' function, with the above extensions, the General Solicitation should always include at least the following extensions: - source IPv6 address - source link-layer address - target IPv6 address and optionally the - target link-layer address (filled with zeros) Similarely, with the above extensions, the General Advertisement should always include at least the following extensions: - source IPv6 address - source link-layer address - target IPv6 address - target link-layer address Alex Conta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 16 19:23:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29310; Thu, 16 Feb 95 19:23:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29304; Thu, 16 Feb 95 19:23:21 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14165; Thu, 16 Feb 1995 19:16:24 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA01949; Thu, 16 Feb 95 19:16:23 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA00857; Thu, 16 Feb 95 19:11:14 -0800 Received: by xirtlu.zk3.dec.com; id AA12594; Thu, 16 Feb 1995 22:11:13 -0500 Message-Id: <9502170311.AA12594@xirtlu.zk3.dec.com> To: Robert Elz Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv4 address representation In-Reply-To: Your message of "Thu, 16 Feb 95 17:54:10 +1100." <4399.792917650@munnari.OZ.AU> Date: Thu, 16 Feb 95 22:11:07 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >My view is that these days the IETF, in either forum, never actually >decides anything, everything is always up for review, but that eventually >people just get tired of arguing about some point, and whatever the >state was at that point gets blessed. Thats scary. I hope we can do better. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 16 23:49:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29435; Thu, 16 Feb 95 23:49:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29294; Thu, 16 Feb 95 19:08:11 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13184; Thu, 16 Feb 1995 19:01:13 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA00333; Thu, 16 Feb 95 19:01:15 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA00338; Thu, 16 Feb 95 18:58:17 -0800 Received: by xirtlu.zk3.dec.com; id AA12475; Thu, 16 Feb 1995 21:58:15 -0500 Message-Id: <9502170258.AA12475@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Suggestion for the coming barage of drafts Date: Thu, 16 Feb 95 21:58:09 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Though I think its OK to send drafts in normal circumstances I am going to agree with Bill Simpson until we get through the core specs. Can we please let all drafts come to the list from IETF announce. This will help us with the mail and make it less intense I think. But if you want to have drafts reviewed first and don't have a place to put them via FTP for the public I will put them on gatekeeper.dec.com IPv6 dir, as a favor. Just an idea. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 16 23:49:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29442; Thu, 16 Feb 95 23:49:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29436; Thu, 16 Feb 95 23:49:20 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26894; Thu, 16 Feb 1995 23:42:22 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA26309; Thu, 16 Feb 95 23:42:03 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 17 Feb 1995 17:41:05 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Fri, 17 Feb 1995 17:41:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 17 Feb 1995 18:38:55 +1000 Date: Fri, 17 Feb 1995 18:38:55 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Feb 17 18:38:54 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 543818170295 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <543818170295*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re: (IPng) IPv4 address representation Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 ---------------------------- Forwarded with Changes --------------------------- From: /DT=RFC-822/DV=owner-ipng@sunroof2.Eng.Sun.COM/O=AARN/ADMD=TELEMEMO/PRMD=OZ.AU/C=AU at DOF-X400 Date: 2/17/95 1:11PM To: Jeff Latimer at DOF-ITB Subject: Re: (IPng) IPv4 address representation ------------------------------------------------------------------------------- ------------------------------ Start of body part 2 >>My view is that these days the IETF, in either forum, never actually >>decides anything, everything is always up for review, but that eventually >>people just get tired of arguing about some point, and whatever the >>state was at that point gets blessed. >Thats scary. I hope we can do better. Is it more to do with not being able to implement competing models in this case rather than a breakdown in general? From what I understand, most of the contentious issues raised here would have been knocked out in the Running Code credo. Or the development groups of competing proposals may well have been tighter. Jeff ------------------------------ End of body part 2 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 17 04:17:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29608; Fri, 17 Feb 95 04:17:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29602; Fri, 17 Feb 95 04:17:14 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08907; Fri, 17 Feb 1995 04:10:19 -0800 Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA26098; Fri, 17 Feb 95 04:10:18 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id HAA03899 for ipng@sunroof.Eng.Sun.COM; Fri, 17 Feb 1995 07:12:57 -0500 (EST) Date: Fri, 17 Feb 1995 07:12:57 -0500 (EST) From: Scott Bradner Message-Id: <199502171212.HAA03899@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Suggestion for the coming barage of drafts Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, I'm not quite sure I parsed your note but just in case, the IESG is now trying to reduce the number of non-internet-draft drafts that are used. The internet draft process makes sure that the review of draft documents is open to all. We have been seeing too many private drafts known only to a specific working group and the trend is getting to be a problem. This is not to say that a group of authors should not keep their work to themselves until it is ready to be put out just that by the time something is ready for a working group to see it the internet drafts process should be used. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 17 06:25:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29649; Fri, 17 Feb 95 06:25:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29643; Fri, 17 Feb 95 06:25:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16060; Fri, 17 Feb 1995 06:18:05 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA07933; Fri, 17 Feb 95 06:18:06 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA13448; Fri, 17 Feb 95 06:11:28 -0800 Received: by xirtlu.zk3.dec.com; id AA11585; Fri, 17 Feb 1995 09:11:26 -0500 Message-Id: <9502171411.AA11585@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv4 address representation In-Reply-To: Your message of "Fri, 17 Feb 95 18:38:55 +1000." <543818170295*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> Date: Fri, 17 Feb 95 09:11:20 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ************************************* >>My view is that these days the IETF, in either forum, never actually >>decides anything, everything is always up for review, but that eventually >>people just get tired of arguing about some point, and whatever the >>state was at that point gets blessed. >Thats scary. I hope we can do better. ******************************** >Is it more to do with not being able to implement competing models in this >case rather than a breakdown in general? From what I understand, most of >the contentious issues raised here would have been knocked out in the >Running Code credo. Or the development groups of competing proposals may >well have been tighter. I think this is it exactly. IPv6 can change much of the entire IPv4 Architecture but has stated it does not. But, arguing competing models cannot be done yet because implementations are still not around. Because IPv6 is new we have nothing but architecture to debate and for a standards process that makes me very nervous. See RFC 1682. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 17 10:20:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29757; Fri, 17 Feb 95 10:20:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29751; Fri, 17 Feb 95 10:20:19 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03357; Fri, 17 Feb 1995 10:13:21 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA21708; Fri, 17 Feb 95 10:13:22 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14546(2)>; Fri, 17 Feb 1995 10:13:08 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Fri, 17 Feb 1995 10:13:02 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng) implementor's meeting in Danvers? Date: Fri, 17 Feb 1995 10:12:50 PST From: Steve Deering Message-Id: <95Feb17.101302pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Is there interest in holding an IPng implementor's meeting on the Sunday before and/or the Friday of IETF in Danvers? We should decide this real soon now, so people can make their travel arrangements accordingly. BTW, if there is a meeting on the Friday, I won't be able to attend. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 17 10:50:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29796; Fri, 17 Feb 95 10:50:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29790; Fri, 17 Feb 95 10:50:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06210; Fri, 17 Feb 1995 10:43:07 -0800 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by Sun.COM (sun-barr.Sun.COM) id AA27728; Fri, 17 Feb 95 10:43:08 PST Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14466; Fri, 17 Feb 95 13:43:03 EST Date: Fri, 17 Feb 95 13:43:03 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9502171843.AA14466@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Support for Proxy ARP function Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alex, I do not believe the "Proxy" function of ARP that you describe is needed in the IPv6 world. It was always a hack in the IPv4 world. Proxy ARP is a _significant_ security hole. I'm loath to reinstate it without A Lot more public list discussion of the subject if it is not in the current draft. A useful start to such discussion might be for you to explain why you believe that function continues to be needed in the IPv6 world in terms that I can follow (I being occasionally a bit slow :-). Thanks, Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 17 10:59:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29812; Fri, 17 Feb 95 10:59:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29806; Fri, 17 Feb 95 10:59:21 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07210; Fri, 17 Feb 1995 10:52:24 -0800 Received: from alink-gw.apple.com by Sun.COM (sun-barr.Sun.COM) id AA29612; Fri, 17 Feb 95 10:52:26 PST Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA03385; Fri, 17 Feb 95 10:52:24 -0800 for ipng@sunroof.eng.sun.com Received: from lilith.lansys.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef) id AA08790; Fri, 17 Feb 1995 10:51:01 +0800 for ipng@sunroof.eng.sun.com Received: (justin@localhost) by lilith.lansys.apple.com (8.6.9/A/UX 3.1) id KAA00410; Fri, 17 Feb 1995 10:52:22 -0800 Date: Fri, 17 Feb 1995 10:52:22 -0800 From: "Justin C. Walker" Message-Id: <199502171852.KAA00410@lilith.lansys.apple.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Steve Deering's message of Fri, 17 Feb 1995 10:12:50 PST <95Feb17.101302pst.12174@skylark.parc.xerox.com> Subject: (IPng) implementor's meeting in Danvers? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> Is there interest in holding an IPng implementor's meeting on the Sunday >> before and/or the Friday of IETF in Danvers? We should decide this real >> soon now, so people can make their travel arrangements accordingly. BTW, >> if there is a meeting on the Friday, I won't be able to attend. I'd like a Sunday meeting. I will have to leave Danvers on Thursday AM, so Friday is out for me as well. Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple Business Systems | of boredom Apple Computer, Inc. | For trying to change the system 10500 North De Anza Blvd | from within Cupertino, CA 95014 | LC --------------------------------------*------------------------------------ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 17 11:04:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29828; Fri, 17 Feb 95 11:04:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29822; Fri, 17 Feb 95 11:04:50 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08009; Fri, 17 Feb 1995 10:57:52 -0800 Received: from clark.net by Sun.COM (sun-barr.Sun.COM) id AA00960; Fri, 17 Feb 95 10:57:52 PST Received: (hcb@localhost) by clark.net (8.6.9/8.6.5) id NAA29307 for ipng@sunroof.Eng.Sun.COM; Fri, 17 Feb 1995 13:57:51 -0500 From: Howard Berkowitz Message-Id: <199502171857.NAA29307@clark.net> Subject: Re: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Fri, 17 Feb 1995 13:57:50 -0500 (EST) In-Reply-To: from "Alan.Lloyd@datacraft.com.au" at Feb 17, 95 07:44:03 am X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yes, but is that 42 decimal, hex, or octal? :-) Howard ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 17 11:19:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29844; Fri, 17 Feb 95 11:19:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29838; Fri, 17 Feb 95 11:19:32 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09557; Fri, 17 Feb 1995 11:12:34 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA04380; Fri, 17 Feb 95 11:12:30 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Support for Proxy ARP function To: ipng@sunroof.Eng.Sun.COM Date: Fri, 17 Feb 1995 19:14:50 +0000 (GMT) Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9502171843.AA14466@itd.nrl.navy.mil> from "Ran Atkinson" at Feb 17, 95 01:43:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I do not believe the "Proxy" function of ARP that you describe is > needed in the IPv6 world. It was always a hack in the IPv4 world. > Proxy ARP is a _significant_ security hole. I'm loath to reinstate > it without A Lot more public list discussion of the subject if it > is not in the current draft. Its regularly a life saver for routing. Yes its badly designed, yes its a misuse but its a very very good one. > A useful start to such discussion might be for you to explain why you > believe that function continues to be needed in the IPv6 world in > terms that I can follow (I being occasionally a bit slow :-). How about because not every machine has decent routing software, sometimes you need to add a device on a remote slip link and you dont own all the other machines that need routes adding. If arp says unknown values must be ignored for future compatibility you can leave it at that and let someone else redo the proxy arp concept and get their paws dirty while you flame them for security lapses 8) Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 17 11:20:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29856; Fri, 17 Feb 95 11:20:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29850; Fri, 17 Feb 95 11:20:18 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09617; Fri, 17 Feb 1995 11:13:20 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA04537; Fri, 17 Feb 95 11:13:20 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Support for Proxy ARP function To: ipng@sunroof.Eng.Sun.COM Date: Fri, 17 Feb 1995 19:14:50 +0000 (GMT) Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9502171843.AA14466@itd.nrl.navy.mil> from "Ran Atkinson" at Feb 17, 95 01:43:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I do not believe the "Proxy" function of ARP that you describe is > needed in the IPv6 world. It was always a hack in the IPv4 world. > Proxy ARP is a _significant_ security hole. I'm loath to reinstate > it without A Lot more public list discussion of the subject if it > is not in the current draft. Its regularly a life saver for routing. Yes its badly designed, yes its a misuse but its a very very good one. > A useful start to such discussion might be for you to explain why you > believe that function continues to be needed in the IPv6 world in > terms that I can follow (I being occasionally a bit slow :-). How about because not every machine has decent routing software, sometimes you need to add a device on a remote slip link and you dont own all the other machines that need routes adding. If arp says unknown values must be ignored for future compatibility you can leave it at that and let someone else redo the proxy arp concept and get their paws dirty while you flame them for security lapses 8) Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 17 11:36:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29880; Fri, 17 Feb 95 11:36:37 PST Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29874; Fri, 17 Feb 95 11:36:29 PST Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA17518; Fri, 17 Feb 1995 11:29:34 -0800 Received: by bobo.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA06814; Fri, 17 Feb 1995 11:29:29 -0800 Date: Fri, 17 Feb 1995 11:29:29 -0800 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199502171929.LAA06814@bobo.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Support for Proxy ARP function Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I do not believe the "Proxy" function of ARP that you describe is > needed in the IPv6 world. It was always a hack in the IPv4 world. > Proxy ARP is a _significant_ security hole. I'm loath to reinstate > it without A Lot more public list discussion of the subject if it > is not in the current draft. The current draft does support proxy arp functionality. The section about general advertisements (in the format spec) states that the source address in the IPv6 header should be "the Identifier specified in the Known-Identifier extension of the solicitation". Thus the spec allows a node to send a general advertisement with a source address that is not one of the source addresses assigned to the node. IMHO this is not a clean design. (This is a long story about who should be allowed to originate datagrams with a given source address. I'll spare you the argments since they are all value judgements relating to design principles.) Also, it makes it very hard to troubleshoot networks with "proxy discovery" since you have to look at link layer address to detect which proxy (if any) responded to the solicitation. > A useful start to such discussion might be for you to explain why you > believe that function continues to be needed in the IPv6 world in > terms that I can follow (I being occasionally a bit slow :-). I agree that there are two questions: - do we need IPv6 proxy discovery - if so, how should it be done (packet formats etc) I've already argued about the second question. The first question is a judgement call. My experience from being involved with operating system transitions is that you want to be very careful about removing capabilities from you users, especially if there is no direct replacement. If you do remove capabilities that the user base depends on they will delay the transition and they are likely to view the "new" as less functional than the "old". This is largely independent of the "goodness" (technical merits) of the capbilities t hat are being used. So IMHO, if we believe that users can seemlessly transition all current uses of proxy arp to IPv6 discovery without using proxy techniques *and* there is no need for proxy discovery in IPv6 itself, then we can remove proxy support from IPv6. Note that if we will have proxy discovery it might make sense to add the proxy advertisements to the list of packets that should be authenticated (Ran's list for "light authentication" that includes TCP SYN, redirects etc) whereas the non-proxy advertisements might not be on this list. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 17 15:16:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00165; Fri, 17 Feb 95 15:16:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00157; Fri, 17 Feb 95 15:16:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05840; Fri, 17 Feb 1995 15:09:30 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA22379; Fri, 17 Feb 95 15:09:30 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06267; 17 Feb 95 13:28 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-atkinson-ipng-sec-01.txt Date: Fri, 17 Feb 95 13:28:53 -0500 Message-Id: <9502171328.aa06267@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Security Architecture Author(s) : R. Atkinson Filename : draft-atkinson-ipng-sec-01.txt Pages : 15 Date : 02/16/1995 The Internet community is making a transition from version 4 of the Internet Protocol (IPv4) to version 6 of the Internet Protocol (IPv6). [Hi94] This memo describes the security mechanisms integrated into version 6 of the Internet Protocol (IPv6) and the services that they provide. Each security mechanism is specified in a separate document. It also describes key management for the IPv6 security mechanisms. 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-atkinson-ipng-sec-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-atkinson-ipng-sec-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-atkinson-ipng-sec-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19950216180311.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-atkinson-ipng-sec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-atkinson-ipng-sec-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950216180311.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 17 15:17:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00186; Fri, 17 Feb 95 15:17:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00173; Fri, 17 Feb 95 15:17:34 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05998; Fri, 17 Feb 1995 15:10:35 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA22615; Fri, 17 Feb 95 15:10:32 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06294; 17 Feb 95 13:29 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-atkinson-ipng-auth-01.txt Date: Fri, 17 Feb 95 13:29:05 -0500 Message-Id: <9502171329.aa06294@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Authentication Header Author(s) : R. Atkinson Filename : draft-atkinson-ipng-auth-01.txt Pages : 10 Date : 02/16/1995 The Internet community is working on a transition from version 4 of the Internet Protocol (IPv4) to version 6 of the Internet Protocol (IPv6). This memo describes the IPv6 Authentication Header. This optional header provides strong integrity and authentication for IPv6 datagrams. Non-repudiation might be provided by an authentication algorithm used with the Authentication Header, but it is not provided with all authentication algorithms that might be used. Confidentiality, and protection from traffic analysis are not provided by the Authentication Header. Users desiring confidentiality should consider using the IPv6 Encapsulating Security Protocol (ESP) either in lieu of or in conjunction with the Authentication Header. [NB: All references to "IPv6 Encapsulating Security Protocol" will be replaced with references to the "IPv6 Security Protocol (IPSP)" if/when such a document appears as an online Internet Draft]. This document assumes the reader has previously read and understood the related "IPv6 Security Overview" document which defines the overall security architecture for IPv6 and provides important background information for this specification. 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-atkinson-ipng-auth-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-atkinson-ipng-auth-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-atkinson-ipng-auth-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19950216180624.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-atkinson-ipng-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-atkinson-ipng-auth-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950216180624.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 17 15:17:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00187; Fri, 17 Feb 95 15:17:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00180; Fri, 17 Feb 95 15:17:37 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06020; Fri, 17 Feb 1995 15:10:40 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB22615; Fri, 17 Feb 95 15:10:40 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06308; 17 Feb 95 13:29 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-atkinson-ipng-esp-01.txt Date: Fri, 17 Feb 95 13:29:08 -0500 Message-Id: <9502171329.aa06308@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Encapsulating Security Payload (ESP) Author(s) : R. Atkinson Filename : draft-atkinson-ipng-esp-01.txt Pages : 13 Date : 02/16/1995 This memo describes the IPv6 Encapsulating Security Payload (ESP). ESP seeks to provide integrity and confidentiality to IPv6 datagrams. It may also provide authentication, depending on which algorithm and algorithm mode are used. Non-repudiation and protection from traffic analysis are not provided by ESP. The IPv6 Authentication Header (AH) might provide non-repudiation if used with certain authentication algorithms. The IPv6 Authentication Header may be used in conjunction with ESP to provide authentication. Users desiring integrity and authentication without confidentiality should use the IPv6 Authentication Header (AH) instead of ESP. This document assumes that the reader is familiar with the related document "IPv6 Security Architecture", which defines the overall security architecture for IPv6 and provides important background for this specification. 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-atkinson-ipng-esp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-atkinson-ipng-esp-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-atkinson-ipng-esp-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19950216180936.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-atkinson-ipng-esp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-atkinson-ipng-esp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950216180936.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 17 21:09:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00425; Fri, 17 Feb 95 21:09:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00414; Fri, 17 Feb 95 21:09:14 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28645; Fri, 17 Feb 1995 21:02:16 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA05808; Fri, 17 Feb 95 21:02:12 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm012-20.dialip.mich.net [141.211.7.188]) by merit.edu (8.6.9/merit-2.0) with SMTP id AAA22646 for ; Sat, 18 Feb 1995 00:02:09 -0500 Date: Sat, 18 Feb 95 04:57:40 GMT From: "William Allen Simpson" Message-Id: <3913.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Support for Proxy ARP function Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: nordmark@jurassic-248.eng.sun.com (Erik Nordmark) > The current draft does support proxy arp functionality. > > The section about general advertisements (in the format spec) states that the > source address in the IPv6 header should be "the Identifier specified > in the Known-Identifier extension of the solicitation". > Thus the spec allows a node to send a general advertisement with a source > address that is not one of the source addresses assigned to the node. > Correct. As was pointed out to him at the interim meeting. Some people just won't give up. Also, the Known-Identifier (was Other-Identifier) could also be used in router advertisements to indicate mobile nodes not on the net (the original intent). Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 18 23:30:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00646; Sat, 18 Feb 95 23:30:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00640; Sat, 18 Feb 95 23:30:06 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12668; Sat, 18 Feb 1995 23:23:06 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA23609; Sat, 18 Feb 95 23:23:06 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 19 Feb 95 16:21:45 +0859 From: Masataka Ohta Message-Id: <9502190722.AA12831@necom830.cc.titech.ac.jp> Subject: re: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Sun, 19 Feb 95 16:21:43 JST In-Reply-To: ; from "Alan.Lloyd@datacraft.com.au" at Feb 17, 95 7:44 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > One can only propose address formats and then delegate their administration. > One can then design route management schemes based on the rational > configurations of the day. One then has to permit flexibility in the > technology to deal with redundant/parallel paths - and some evolution will > occur here. One cannaot pragmatically design routing algorithms for the > extreme .. ie that permit the whole plannet to be mesh connected. It's a lot better to theoretically prove some address format does not work in advance and avoid wasting the whole effort. > ps perhaps the answer is 42! (hitchhikers guide to the galaxy) I'm afraid that IETF is a process to compute THE QUESTION to make IPv6 universe a lot uglier than IPv4. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 19 00:01:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00667; Sun, 19 Feb 95 00:01:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00661; Sun, 19 Feb 95 00:01:14 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13229; Sat, 18 Feb 1995 23:54:13 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA24780; Sat, 18 Feb 95 23:54:14 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 19 Feb 95 16:52:57 +0859 From: Masataka Ohta Message-Id: <9502190753.AA12946@necom830.cc.titech.ac.jp> Subject: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Sun, 19 Feb 95 16:52:55 JST Cc: bound@zk3.dec.com In-Reply-To: <9502140519.AA09999@xirtlu.zk3.dec.com>; from "bound@zk3.dec.com" at Feb 14, 95 12:19 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Masataka, Hi, I'm back from a week of vacation in Val d'Isere. > Your issue with Multihoming points to a hole. But do you accept the > rest of the draft? What, do you mean, is "the rest of the draft"? Are there anything remaining? Well, I do accept that the routable part should have hierarchy but I have my own opinion, based on scalability consideration, on how the hierarchy should be. > UID will not be done in our lifetime in the IETF IMHO. I have already constructively shown a way to do UID easily. Feel free to point out any defects, theoretical or engineering, of it. If you can't, isn't it the time to form a WG to polish it up as an RFC? I don't mind other's who have other (brain-dead, IMHO) idea on UID may write their own. I like freedom. I don't want to be tied to the provider monopoly for the rest of my lifetime. Masataka Ohta PS FYI, my proposal is reposted. What is called "Interface ID" corresponds to UID. Though Interface ID is assigned to a host, not an interface, the difference is not significant and I'm now thinking assigning to to a host is better. IPv6 Numbering Plan for Provider Independence Introduction IPv4 addresses do not contain provider dependent information. Thus, with IPv4 addresses, we can select and change providers without reassigning IP addresses. On the other hand, IPv6 addresses contain provider dependent part for routing aggregation. If host identification is controlled by providers, it is difficult to change providers or have multiple provider. The more serious problem is security. As the host identification is the core for security, subscribers does not want the identification is controlled by providers. This memo proposes an address assignment scheme for IPv6 which allows both routing aggregation and provider independence, supporting 10^12 networks and 10^15 hosts. The proposal also allows efficient forwarding on routers. Anti-trust mechanism for provider ID assignment is also proposed to have geographically-near-optimal and least-costly routing with proper provider selection. Assignment Plan for IPv6 address The 16 byte IPv6 address is divided into four fields: 5 byte "Provider ID", 2 byte "Subscriber ID", 1 byte "Subnet ID" and 8 byte "Interface ID". "Provider ID" and "Subscriber ID" together is called "Provider dependent part". Provider dependent part is supplied by providers and dynamically reconfigurable at system boot time or even during operation. It is expected that routers to providers supply provider dependent part information through anycasting. Interface ID is a globally unique ID of an interface of a host. It is supplied by subscribers. The configuration may be automatic. But it is expected that renumbering is necessary not so often, in general, only when a host is purchased or the host is moved to different suborganization of the provider. Host specific information such as IP address to host name mapping is looked up only through the Masataka Ohta [Page 1] IPv6 Numbering Plan for Provider Independence Interface ID and there is no provider dependence of security. Subnet ID is also supplied by subscribers and identifies a subnet within a subscribers LAN. The configuration may be automatic through nearest routers. Renumbering is necessary when a location of a host is changed to a different subnet. Network layer identification of a host is done through Interface ID just like the current IPv4. Users can change providers at will just by disconnecting one of its external routers and connect it to a new provider. Interfaces of a host of a subscriber belonging to multiple providers may have multiple provider dependent parts but only a single interface ID. Routing is controlled purely by the first 8 bytes of IPv6 address: "Provider ID", "Subscriber ID" and "Subnet ID" and is more efficient than schemes using full 16 bytes. Assignment Plan for Provider ID, Subscriber ID and Subnet ID 5 byte provider ID uniquely identifies a provider in the Internet. 5 byte provider ID combined with 2 byte subscriber ID uniquely identifies a subscriber in the Internet. 1 byte subnet ID uniquely identifies a subnet in a subscribers network. A large subscriber having more than 256 subnets will have multiple subscriber IDs from a provider. A large provider having more than 65536 subscriber IDs or having some geographical constraints will have multiple provider IDs. For geographically-near-optimal routing, a provider ID should not cover an area of 100Km radius. Thus, a large provider must use different provider IDs for hosts located more than 200Km apart. Thus, a subscriber can specify to use a local provider A, then use low-rate long-distance-provider B and finally use the provider A who is also serving the destination. [Note: It is expected that the provider have IX to other providers within the 200Km radius. But that's a operational requirement and should be separated from assignment policy]. About 17,000 IDs are necessary to cover the surface of the Earth. Inter-planetary communication is NOT considered here. Masataka Ohta [Page 2] IPv6 Numbering Plan for Provider Independence Anti-trust mechanism for provider ID assignment is also proposed to have geographically-near-optimal routing. Assignment Plan for Interface ID First three of Interface ID is assigned from IANA to country NICs. Each country NIC use the next three bytes for independent subscribers. A subscriber use the last two bytes for the internal use. Supporting 10^12 networks and 10^15 hosts How the requirement to support 10^12 networks and 10^15 hosts can be satisfied? First, how routing between 10^12 networks is possible? 10^3 hosts within a subnet can easily be identified by the Interface ID. Thus, (Provider ID, Subscriber ID, Subnet ID) must identify 10^12 networks. It is not unnatural that a provider, in average, supports at least 10^3 subscribers. It can also be safely assumed that subnet ID can identify 10^1 subnets. Thus, Provider ID is required to identify 10^8 hosts. Considering that the requirement contains 10^2 safety factor, the least two significant bytes of the Provider ID are reserved for the factor. The remaining 3 bytes (2^24>10^7) are much more than enough to identify 10^6 providers. It is assumed that by the time we support 10^12 networks, flat routing of 10^6 providers is not a problem at all. The reserved lower two bytes of provider ID may also be used for two-level routing among providers. Next, how identification of 10^15 hosts is possible? 10^3 hosts of a subscriber can easily be identified by the last two bytes of Interface ID. For the remaining 10^12 factor, IANA and country NICs are expected to manage the upper 6 bytes completely densely. Thus, it should be possible to support more than 10^14 networks. Conclusion As the 16 byte address space is so large, it is possible to use it wisely to enjoy full provider independence, including provider change without renumbering and long distance provider selection by provider IDs. Masataka Ohta [Page 3] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 19 00:23:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00694; Sun, 19 Feb 95 00:23:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00688; Sun, 19 Feb 95 00:23:09 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13751; Sun, 19 Feb 1995 00:16:11 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA29037; Sun, 19 Feb 95 00:16:09 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 19 Feb 95 17:14:53 +0859 From: Masataka Ohta Message-Id: <9502190815.AA13024@necom830.cc.titech.ac.jp> Subject: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Sun, 19 Feb 95 17:14:52 JST In-Reply-To: <199502140653.WAA05211@gauss.asd.sgi.com>; from "Casey Leedom" at Feb 13, 95 10:53 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Hhmmm, I couldn't find an archive of the mailing list in > ftp.parc.xerox.com:/pub/ipng. Ipng WG is seems to be clerically broken. > I presume it must be elsewhere. I used majordomo mechanism. But it's not formal (if any) protocol of IETF. > In the > mean time let me just boldly guess that you mean that: OK. > 1. The globally unique part of a UID would be static and unchanging (in > general for a ***host***)? Sure. > 2. The hierarchically routable part of a UID would change whenever an Hierarchically routable part of IPv6 address, not UID. UID and the routable part consist the IPv6 address. > ***interface*** was moved from one provider connection to another? > (Or would it change whenever routes in the network changed???) They changes as the connection to providers changes. > 3. Host addresses would be looked up via the globally unique part of a > UID. That is, a ``hostname'' would be translated into a fairly static, > globally unique ***host*** ID and then some lookup service (like DNS?) Sure. > would be used to get a [list of?] complete UIDs? Complete (or rest of) IPv6 addresses. > How would you encode hierarchically routing information when the network > isn't a tree? When the network isn't a tree, each host have multiple routable parts, that is, multiple addresses, while the UID part of the addresses are the same. > Or is the hierarchically routable part sender relative? No. That means variable length address and suitable only for routing headers. > Somewhat like the ``provider lose source route'' proposal I heard about > recently (i.e. ``well first send it to this autonomous system, then this > one, then ...'') No wonder. It was seen everywhere in IETF including PIP and nimrod. But don't forget that UID is for provider independence. AS, like Yakov's proposal, does not scale well with multihoming. My contribution is to show that the part does not have to be so lengthier than fixed 64 bit (or less) to support 10^12 networks and 10^15 hosts. > And the UID solution which embeds topological routing information solves > at least part of this problem (based on how close the hierarchically > routable part of the UID gets you to the host? If I'm even vaguely close, > what would happen in the midst of major network topological > reconstructions? I.e. someone adds a new link between two distant parts > of the net that weren't previously connected? New addresses will be added to DNS gradually (or rapidly) and used by other hosts. > What would happen if > someone deletes a major link? Just as IPv4 hosts with multiple A's, if one address does not work, alternative addresses are tried. But, with UID, we can do so on the fly keeping TCP/UDP conenctions alive. If the deletion is permanent, old addresses will be removed from DNS gradually (or rapidly). > What would happen durring routing > flapps/storms? During routing flapps/storms, you can see routing flapps/storms. And, regarding UID based addressing, IP address unaffected by the routing flapps/storms may be tried so that we must be careful not to make the additional traffic of the trial cause the other flapps/storms. Perhaps, exponential backing-off of the trial is practically enough. > If the answers to these questions are too low level for the list, please > feel free to simply send me pointers to the appropriate materials (or > ignore me if I'm asking *really* stupid questions!) Your questions are very good, I think. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 19 20:41:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01039; Sun, 19 Feb 95 20:41:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01033; Sun, 19 Feb 95 20:41:44 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10947; Sun, 19 Feb 1995 20:34:43 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA19778; Sun, 19 Feb 95 20:34:44 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA08446; Sun, 19 Feb 95 20:34:27 -0800 Received: by xirtlu.zk3.dec.com; id AA04307; Sun, 19 Feb 1995 23:33:29 -0500 Message-Id: <9502200433.AA04307@xirtlu.zk3.dec.com> To: Masataka Ohta Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) A thought on addressing In-Reply-To: Your message of "Sun, 19 Feb 95 16:52:55 +0200." <9502190753.AA12946@necom830.cc.titech.ac.jp> Date: Sun, 19 Feb 95 23:33:22 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Masataka, >Hi, I'm back from a week of vacation in Val d'Isere. Hope you had a good time. >What, do you mean, is "the rest of the draft"? Are there anything >remaining? Well, I do accept that the routable part should have >hierarchy but I have my own opinion, based on scalability >consideration, on how the hierarchy should be. Basically it left 8bytes for an individual site with all the prefix scenarios (registry, provider, subscriber). I liked that aspect of the result a lot. But from your response you have a different idea for hierarchy in mind I presume. Do you accept Yakov's points of registrys in the Format Prefix? >I have already constructively shown a way to do UID easily. >Feel free to point out any defects, theoretical or engineering, of >it. If you can't, isn't it the time to form a WG to polish it up as >an RFC? I don't mind other's who have other (brain-dead, IMHO) idea >on UID may write their own. Ouch. Got me thar sir. I will study the attached by Tuesday and respond if I have any issues. My comment was tongue and cheek from all the EID wars and my previous comments on my love of the PIP EID. I will get back to you. >I like freedom. I don't want to be tied to the provider monopoly for >the rest of my lifetime. Yes me too. Here we agree completely immediately. But I did not think Yakov's draft treaded on our love for freedom from providers. What will do that is the message to this list asking if providers will pass out our addresses. This is what will encroach on our freedoms. Worst yet if anyone charges for these addresses it will encroach on my beliefs of doing work to earn a yen or dollar, or else one is just a middle person (or entity) ripping off the people on the planet earth (and I am a capitalist not socialist). Also we still have a reserved space for geographic based addresses too. >PS >FYI, my proposal is reposted. What is called "Interface ID" corresponds to >UID. Though Interface ID is assigned to a host, not an interface, the >difference is not significant and I'm now thinking assigning to to >a host is better. Well I still have to read your UID draft, but if it is assigned to a host it makes the world less complicated and I "think" DNS does not care. It also makes IPv6 stateless autoconfig names associated with all the addresses per interface and multiple interfaces in the code easier too. One Host name is a good idea off the top of my head. Hmmm now I am thinking in IPv6 that /etc/host type local files will have to have an interface position to differentiate the different interfaces? Hmmm now if we do this do we need to have the same differentiator in DNS AAAA records? I don't like the idea of try and miss and try and miss for the applications to host2addr() call in IPv6? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 19 22:51:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01083; Sun, 19 Feb 95 22:51:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01077; Sun, 19 Feb 95 22:50:57 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13857; Sun, 19 Feb 1995 22:43:55 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA27331; Sun, 19 Feb 95 22:43:54 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 20 Feb 95 15:42:37 +0900 From: Masataka Ohta Message-Id: <9502200642.AA17235@necom830.cc.titech.ac.jp> Subject: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Mon, 20 Feb 95 15:42:35 JST In-Reply-To: <9502200433.AA04307@xirtlu.zk3.dec.com>; from "bound@zk3.dec.com" at Feb 19, 95 11:33 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >Hi, I'm back from a week of vacation in Val d'Isere. > > Hope you had a good time. > > >What, do you mean, is "the rest of the draft"? Are there anything > >remaining? Well, I do accept that the routable part should have > >hierarchy but I have my own opinion, based on scalability > >consideration, on how the hierarchy should be. > > Basically it left 8bytes for an individual site with all the prefix > scenarios (registry, provider, subscriber). I liked that aspect of the > result a lot. But from your response you have a different idea for hierarchy > in mind I presume. Sure. I think we should have 64bit unroutable UID. > Do you accept Yakov's points of registrys in the Format Prefix? No. 7 byte SSC is too short. It should left at least 9 bytes (including 1 byte routable part) for an individual site. Of course, it cause a serious confusion to call that 9 bytes SSC when it actually consists of 8 byte UID and 1 byte routable part. 24bit RSC is a waste of bits. If there are so few large providers, let them use 256 16bit RSCs. It won't explode routing tables. It is unclear whether Yakov's scheme can support 10^12 networks and 10^15 hosts or not. I'm afraid the scheme already wastes too much bits for variable length RSC and such. At least, 48 bit MAC can't uniquely identify 10^15 hosts so that assuming 60bit MAC is necessary. It's architecuraly wrong to let NICs handle routing registries. It should be IEPG (or IOTF) who manage the routing prefixes. How routing prefix is interpreted is under the control of Internet operators. So, let them manage the space of routing prefix. Don't let national registries control routing. NICs should assign UIDs, though. And, finally, UID based addressing changes several fundamental things about addressing so that syntactically keeping the rest is not so meaningful. For example, ARP should use only the UID part of the address. > My comment was tongue and cheek from all > the EID wars and my previous comments on my love of the PIP EID. I will > get back to you. The problem of EID was that it was a concept, not a problem to be solved. If the target is to have provider independence, there are a lot less room for meaningless debates for mobility and TCP. > >I like freedom. I don't want to be tied to the provider monopoly for > >the rest of my lifetime. > > Yes me too. Here we agree completely immediately. > > But I did not think Yakov's draft treaded on our love for freedom from > providers. What we need is the right to quickly change providers, which is strongly related to multihoming, or dynamically choose the best provider from multiple providers, which is multihoming itself. > What will do that is the message to this list asking if > providers will pass out our addresses. Just having an address is nothing if rational connection to the rest of the internet is not assured. > Also we still have a reserved space for geographic based addresses too. Do you want to have two kinds of IPv6? > >FYI, my proposal is reposted. What is called "Interface ID" corresponds to > >UID. Though Interface ID is assigned to a host, not an interface, the > >difference is not significant and I'm now thinking assigning to to > >a host is better. > Hmmm now I am thinking in IPv6 that /etc/host type local files will have > to have an interface position to differentiate the different interfaces? If you want static configuration, that should be the way. For autoconfiguration, routers should broadcast a routing prefix to each link layer segments. > Hmmm now if we do this do we need to have the same differentiator in DNS > AAAA records? While AAAA records is still OK, it might be cleaner to have UID RR and ROUTE RR. It might even better to let hostname node UID RR only and put routing prefix information in in-addr.arpa.-equivalent part of the DNS tree. > I don't like the idea of try and miss and try and miss > for the applications to host2addr() call in IPv6? I think gethostbyname() should return all the routing headers and let the lower OS layer choose the best route. But it has nothing to do with whether the ID is on interface or host. Interfaces with multiple addresses cause no more difficult problem than hosts with multiple interfaces. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 20 10:29:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01405; Mon, 20 Feb 95 10:29:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01399; Mon, 20 Feb 95 10:29:35 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07501; Mon, 20 Feb 1995 10:22:34 -0800 Received: from mvp.com (m.mvp.com) by Sun.COM (sun-barr.Sun.COM) id AA06868; Mon, 20 Feb 95 10:22:32 PST Received: (from george@localhost) by mvp.com (8.6.8/8.6.6) id KAA00667 for ipng@sunroof.eng.sun.com; Mon, 20 Feb 1995 10:22:30 -0800 Date: Mon, 20 Feb 1995 10:22:30 -0800 From: George Mitchell Message-Id: <199502201822.KAA00667@mvp.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Provider Independence Reality Check Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Since this is possibly a Really Dumb Question, I will at least keep it brief. There is a lot of discussion about provider independence on this mailling list, and I agree that provider independence is a good thing. However, as I understand it, the current thinking on how to keep IPv6 addresses provider independent is to split them up into a rout- able part, which will clearly never be provider-independent, and an unroutable part which is permanently bound to an interface and which will be provider-independent. But why do you need the IPv6 address to be at all provider indepen- dent? Surely the proper place to have a permanent, provider-indepen- dent identifier is in the Domain Name System -- not in the IPv6 address itself. Don't we want to use as much of the address as poss- ible to contain routing information to kep the routing problem tractable? Thanks for your attention. -- George Mitchell (george@mvp.com) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 20 11:24:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01428; Mon, 20 Feb 95 11:24:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01422; Mon, 20 Feb 95 11:24:37 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10365; Mon, 20 Feb 1995 11:17:36 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA12859; Mon, 20 Feb 95 11:17:37 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA16003; Mon, 20 Feb 95 11:10:35 -0800 Received: by xirtlu.zk3.dec.com; id AA21739; Mon, 20 Feb 1995 14:09:38 -0500 Message-Id: <9502201909.AA21739@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: (IPng) IPv6 Security Input Date: Mon, 20 Feb 95 14:09:32 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, Here is my general input on the security work, more will come later: For future drafts can you please note the changes or use diffmk so we don't have re-read the whole draft each time. Thanks ... Also the cost to implement IPv6 security is significant and I suggest you take out all references that this cost is not significant in all 3 specs if it occurs. You cannot prove this based on what we know today and putting such a statement in a proposed standard has no value regarding the subject matter. I object to that statement strongly it gives the wrong impression to casual readers. -------------------------------------------------------- draft-atkinson-ipng-sec-01.txt Page 1 Introduction last sentence: >It also describes key management for the IPv6 security mechanisms. No it does not. It speaks of a method to do local key configuration by putting static keys in the implementation and also states this is only good for a LAN. The sentence above should become more accurate as to what the spec actually states about key mgmt. Page 2-3 DESIGN OBJECTIVES Last Sentence Kind of a short DESIGN section don't you think? > The IPv6 Security mechanisms should be useful in enforcing a variety >of security policies. Well I think building a protocol and then not saying how it can be used is questionable as an engineer. But do we realize this means we can implement IPv6 network layer security how ever we want. I think this is good to some degree. But a standard should guarantee some interoperability and degrees of that interoperability. The API should not define this. The API should only support what the lower layer standards can support. I think we need to add some levels of granualarity Here is an example: This mail is taken from mail between Greg Minshall and I and some others to give you an idea of granularity: ********************************************** Packet signing is controlled by a 4-position switch on clients and servers. During connection set up time, the positions of the switches at the two ends are used to decide whether to use packet signing on the connection (and, in fact, whether a connection is possible). If packet signing is used, it is used in both directions. The four positions are: 1. I refuse to participate in packet signing. 2. I won't request packet signing, but will agree to it if my peer so requests. 3. I will request packet signing, but i'm willing to communicate even if my peer won't agree to do packet signing. 4. I insist on packet signing; i won't communicate unless my peer is willing to do packet signing. (As you can see, if one side is set to position 1 and the other is set to position 4, no communications will occur; all other combinations are compatible.) ************************************************ This gets into how one MAY USE IPv6 Security. If we don't say anything we MAY ALL USE IT IN DIFFERENT WAYS? This would mean we have required security but the impelementations are not interoperable. Page 7 - 4.3 Automated Key Distribution first sentence > Widespread deployment and use of IPv6 security will require an > Internet-Standard scalable key management protocol. I agree. So this draft and the other Sec Drafts can never reach full standard until we have one. Its not good to provide a standard to the market that cannot be deployed on a wide scale. Its good you have this in the draft. Paage 8 4.5 IPv6 Key Management Requirements second paragraph > All IPv6 implementations MUST support manual key management. All > IPv6 implementations SHOULD support Internet-Standard key management >protocol... If we make the MUST a SHOULD your OK. If you won't then you have contradicted yourself in 4.3. We are saying its a MUST to do what will not scale but its a SHOULD to do what will scale. This don't add up well. Make the MUST a SHOULD and we can keep heading towards proposed standard and fix it later. 5.3 USE WITH IPv6 MULITCAST Excuse me but there are no IPv6 implementations that have run over the Mbone so I think your giving an illusion to the casual reader of a reality that does not exist. Then when you say Many People are using this it gives again the wrong impression. First the use today is IPv4 not IPv6 and that remains to be proven for IPv6. Second even for IPv4 I know of no customer that uses the Mbone for any business purpose. I know its used in the IETF and even a Rolling Stone concert last year, but your "many" is bleeding edge folks and vendors using it amongst each other and as marketing tool speaking of the Mbone. Now Multicast is different. I "think" what you want to point out in this section is the affect of IPv6 security and possibly response times in a Multicast network (e.g. responses will be slower as the packet runs through the algorithm). As its stands now its just a marketing message for the Mbone which I think is good but not in a potential proposed standard for IPv6. 5.4 USE TO PROVIDE QOS PROTECTION This section did not technically tell me how this is actually done hence I think its void of technical explanation and not sure why its in the document. Also in this section comments like .... "packet classification within routers becomes straightforward "... leaves me not feeling to good again about techical accuracy. I don't know what straightforward implies if I am joe implementor. This section could be expanded upon technically. 5.5 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS You state Authentication can be used for single level networks but never say that for Multi-Level networks. I think this section again needs to be more in depth technically. I will have more input on MLS later. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 20 11:49:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01444; Mon, 20 Feb 95 11:49:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01438; Mon, 20 Feb 95 11:49:16 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11623; Mon, 20 Feb 1995 11:42:14 -0800 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by Sun.COM (sun-barr.Sun.COM) id AA16068; Mon, 20 Feb 95 11:42:15 PST Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16069; Mon, 20 Feb 95 14:42:13 EST Date: Mon, 20 Feb 95 14:42:13 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9502201942.AA16069@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) comments on "IPv6 Global Unicast Addr Format" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Provider-oriented addressing simply will not function for multi-homed sites such as NRL. At last count we had about 8 external IP "providers" for example MILnet, Defense Simulation Internet, DREN, SURAnet, and others. Provider-oriented addressing would limit our connectivity, make address administration extremely painful, and generally cause problems not present with IPv4. One approach is that defined in the above document in Section 3.3 (last paragraph on page 5) and Section 3.6. Another approach that will work and can better follow the network topology would be to have addresses that are oriented around network interconnection points (e.g. CIX, FIX, MAE, and NAP centers, hereafter referred to as "*IX"s). This approach improves somewhat on the proposal in Section 3.3 in the area of routing table and address aggregation by having addresses aggregate on a per-*IX basis in addition to a per-continental level. If national-registries exist, then this would be additional aggregation below the national-registries. This alternate approach would have addresses of the form [Fixed *IX-oriented addressing prefix OR Registry-prefix] + [Identifier of specific *IX] + [Identifier of specific fixed site under that *IX] + [Site-specific address space] Each multiple-homed site would thus get a single fixed routing prefix and that prefix would relate to the specific *IX that the site would connect to via its several service providers. Such addresses would not have a Provider-Specific Component. I would like to see the above draft edited to include mention of and a sample structure defining this approach in addition to those already mentioned in the above draft. Rare comment: I do not believe there ARE any Security Considerations needing mention in the above draft and it might be fair to simply state that "No Security Considerations Exist." rather than state that they aren't discussed. :-) Regards, Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 20 12:40:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01482; Mon, 20 Feb 95 12:40:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01476; Mon, 20 Feb 95 12:40:19 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13832; Mon, 20 Feb 1995 12:33:17 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA21777; Mon, 20 Feb 95 12:33:16 PST Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA27170; Mon, 20 Feb 1995 15:33:09 -0500 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/18Feb95-1123AM) id AA27385; Mon, 20 Feb 1995 15:33:06 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA28286; Mon, 20 Feb 1995 15:09:04 -0500 Message-Id: <9502202009.AA28286@brigit.zk3.dec.com> To: itkinson@itd.nrl.navy.mil Cc: ipng@sunroof2.Eng.Sun.COM, conta@zk3.dec.com Subject: Re: (IPng) Support for Proxy ARP function In-Reply-To: Your message of "Fri, 17 Feb 95 13:43:03 EST." <9502171843.AA14466@itd.nrl.navy.mil> Date: Mon, 20 Feb 95 15:09:04 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Subject: (IPng) Support for Proxy ARP function Alex, I do not believe the "Proxy" function of ARP that you describe is needed in the IPv6 world. It was always a hack in the IPv4 world. Proxy ARP is a _significant_ security hole. I'm loath to reinstate it without A Lot more public list discussion of the subject if it is not in the current draft. A useful start to such discussion might be for you to explain why you believe that function continues to be needed in the IPv6 world in terms that I can follow (I being occasionally a bit slow :-). Thanks, Ran atkinson@itd.nrl.navy.mil Ran, I do not consider it a 'hack'. It is a function that solves a problem. As I stated in my previous message - others added to that as well - the 'proxy ARP' is a function at address resolution protocol level, as well as at networking user command interface level ('arp' command) that was and is used in IPv4, for various purposes, which were described. That it has a 'security' hole, it is a different issue, which does not exist in IPv6. It is my understanding that "IPv6 security" which covers all IPv6 packets, including the neighbor discovery ICMP packets, eliminates the holes that existed in ARP security. In fact it was one of the reasons, IPv6 discovery was implemented above the IPv6 layer, i.e. in ICMP, wasn't it? Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 20 13:02:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01517; Mon, 20 Feb 95 13:02:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01505; Mon, 20 Feb 95 13:02:10 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14809; Mon, 20 Feb 1995 12:55:10 -0800 Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA23492; Mon, 20 Feb 95 12:51:20 PST Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA26182; Mon, 20 Feb 1995 12:51:19 -0800 Date: Mon, 20 Feb 1995 12:51:19 -0800 From: Dave Katz Message-Id: <199502202051.MAA26182@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: itkinson@itd.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM, conta@zk3.dec.com In-Reply-To: conta@zk3.dec.com's message of Mon, 20 Feb 95 15:09:04 -0500 <9502202009.AA28286@brigit.zk3.dec.com> Subject: (IPng) Support for Proxy ARP function Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I do not consider it a 'hack'. It is a function that solves a problem. Proxy ARP wasn't originally called the "ARP Hack" for nothing. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 20 13:02:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01518; Mon, 20 Feb 95 13:02:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01506; Mon, 20 Feb 95 13:02:12 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14809; Mon, 20 Feb 1995 12:55:10 -0800 Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA23492; Mon, 20 Feb 95 12:51:20 PST Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA26182; Mon, 20 Feb 1995 12:51:19 -0800 Date: Mon, 20 Feb 1995 12:51:19 -0800 From: Dave Katz Message-Id: <199502202051.MAA26182@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: itkinson@itd.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM, conta@zk3.dec.com In-Reply-To: conta@zk3.dec.com's message of Mon, 20 Feb 95 15:09:04 -0500 <9502202009.AA28286@brigit.zk3.dec.com> Subject: (IPng) Support for Proxy ARP function Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I do not consider it a 'hack'. It is a function that solves a problem. Proxy ARP wasn't originally called the "ARP Hack" for nothing. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 20 13:18:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01557; Mon, 20 Feb 95 13:18:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01551; Mon, 20 Feb 95 13:18:51 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15616; Mon, 20 Feb 1995 13:11:50 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA25676; Mon, 20 Feb 95 13:11:49 PST Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA28507; Mon, 20 Feb 1995 16:11:47 -0500 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/18Feb95-1123AM) id AA30260; Mon, 20 Feb 1995 16:11:45 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA31813; Mon, 20 Feb 1995 15:47:44 -0500 Message-Id: <9502202047.AA31813@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) Support for Proxy ARP function In-Reply-To: Your message of "Fri, 17 Feb 95 11:29:29 PST." <199502171929.LAA06814@bobo.Eng.Sun.COM> Date: Mon, 20 Feb 95 15:47:44 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: nordmark@jurassic-248.eng.sun.com (Erik Nordmark) Subject: Re: (IPng) Support for Proxy ARP function > I do not believe the "Proxy" function of ARP that you describe is > needed in the IPv6 world. It was always a hack in the IPv4 world. > Proxy ARP is a _significant_ security hole. I'm loath to reinstate > it without A Lot more public list discussion of the subject if it > is not in the current draft. The current draft does support proxy arp functionality. The section about general advertisements (in the format spec) states that the source address in the IPv6 header should be "the Identifier specified in the Known-Identifier extension of the solicitation". Thus the spec allows a node to send a general advertisement with a source address that is not one of the source addresses assigned to the node. IMHO this is not a clean design. (This is a long story about who should be allowed to originate datagrams with a given source address. I'll spare you the argments since they are all value judgements relating to design principles.) Also, it makes it very hard to troubleshoot networks with "proxy discovery" since you have to look at link layer address to detect which proxy (if any) responded to the solicitation. Mea culpa! Reading the draft, I simply thought that 'the Identifier specified in the Known-Identifier extension of the solicitation' is one that belongs to the host that sends the IPv6 packet! I could not imagine that the 'neighbor discovery' would be intentionally and openly in a 'flagrante delicto' with the IPv6 Specifications! (I do not question at all the IPv6 Specification which in my and others opinion is solid and correct.) To suggest sending IPv6 packets that specify an IPv6 source address other than any of the IPv6 addresses of the sender node seems to me absolutely unacceptable, given the definition of the 'source address' field in the IPv6 packet, i.e. 'an (IPv6) address of the initial sender of the packet' [IPv6 Specification]. Not to question even further the security hole, and validity of such a suggestion in the context of IPv6 security extension headers. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 20 13:23:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01569; Mon, 20 Feb 95 13:23:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01563; Mon, 20 Feb 95 13:23:43 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15824; Mon, 20 Feb 1995 13:16:43 -0800 Received: from mutton.csv.warwick.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA26048; Mon, 20 Feb 95 13:16:37 PST Date: Mon, 20 Feb 1995 21:14:56 GMT From: Ian Dickinson Message-Id: <10389.199502202114@mutton.csv.warwick.ac.uk> Received: by mutton.csv.warwick.ac.uk id VAA10389; Mon, 20 Feb 1995 21:14:56 GMT In-Reply-To: Dave Katz "(IPng) Support for Proxy ARP function" (Feb 20, 12:51pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Support for Proxy ARP function Cc: dkatz@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Feb 20, 12:51pm, Dave Katz wrote: } Subject: (IPng) Support for Proxy ARP function > > I do not consider it a 'hack'. It is a function that solves a problem. > > Proxy ARP wasn't originally called the "ARP Hack" for nothing. And I note that no one managed to invent something to supplant it that was elegant and worked with all those old but compliant (at the time) implementations. It isn't pretty, but it's so damn useful. Cheers, -- Ian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 20 13:27:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01581; Mon, 20 Feb 95 13:27:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01575; Mon, 20 Feb 95 13:27:04 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15989; Mon, 20 Feb 1995 13:20:04 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA26056; Mon, 20 Feb 95 13:16:03 PST Received: by rodan.UU.NET id QQydyj12693; Mon, 20 Feb 1995 16:16:02 -0500 Message-Id: To: ipng@sunroof.Eng.Sun.COM Cc: itkinson@itd.nrl.navy.mil, conta@zk3.dec.com From: "Louis A. Mamakos" Subject: Re: (IPng) Support for Proxy ARP function In-Reply-To: Your message of "Mon, 20 Feb 1995 12:51:19 PST." <199502202051.MAA26182@feta.cisco.com> Date: Mon, 20 Feb 1995 16:16:01 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > I do not consider it a 'hack'. It is a function that solves a problem. > > Proxy ARP wasn't originally called the "ARP Hack" for nothing. That's what I called it when I implemented ARP in the Fuzzball code, oh so many years ago. I recall thinking it was unclean, even though it did solve a particular problem (which was other hosts on the Ethernet that didn't do the Fuzzball "hello" routing protocol.) (I think might have been the first ARP hack implementation; forgive me it gave other people bad ideas.) The problem, I think, is a combination of lack of router discover, lack of VLSM, and lack of sufficient routing protocol support. Louis A. Mamakos louie@alter.net, uunet!louie Backbone Architecture & Engineering Guy Voice: +1 703 206 5800 AlterNet / UUNET Technologies, Inc. Fax: +1 703 206 5801 3060 Williams Drive Voice: +1 703 206 5823 (direct) Fairfax, VA 22031 Fax: +1 703 206 5908 (direct) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 20 21:23:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01948; Mon, 20 Feb 95 21:23:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01942; Mon, 20 Feb 95 21:23:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02751; Mon, 20 Feb 1995 21:15:58 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA08204; Mon, 20 Feb 95 21:16:00 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA27184; Mon, 20 Feb 95 21:11:38 -0800 Received: by xirtlu.zk3.dec.com; id AA04229; Tue, 21 Feb 1995 00:10:42 -0500 Message-Id: <9502210510.AA04229@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) A thought on addressing In-Reply-To: Your message of "Mon, 20 Feb 95 15:42:35 +0200." <9502200642.AA17235@necom830.cc.titech.ac.jp> Date: Tue, 21 Feb 95 00:10:36 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Masataka, I always give folks the benefit of the doubt. I should not always do that especially in this discussion. Your draft needs a lot more work and Yakov's is complete without too many holes for what he is proposing. I will review your draft attached. We are trying to go to proposed standard, if you did not know, with a core set of IPv6 drafts and Yakov's work are two of them. When the IPv6 minutes come out this will be explained in more detail. I am taking the time to do this because you threw a challenge to me to review your document. OK I have put about 4 hours into it and researched several mail archives and other text I could find on Multihoming beliefs, which was another 3 hours. Topics: 1. Review of Yakov's docs and what we are talking about to make this clear. 2. Why I would like to see a Geographical Address Plan too. 3. Understanding IPv6 and all the specs. 4. Clarification on Provider Independence and why its important. 5. Comments on your draft IPv6 Numbering Plan for Provider Independence. 6. My conclusion. 1. Review of Yakov's docs and what we are talking about to make this clear. Yakov has two docs (there are other authors): #1. An Architecture for IPv6 Unicast Address Allocation #2. An IPv6 Global Unicast Address Format When I asked you what else is wrong about the doc other than Multihoming you responded what else is there? Well in #1 there are about 15 pages of very good text on the problem at hand and some very well thought out research on the problem at hand for address allocation. Then Multihoming is discussed. Then #2 depicts a plan for "A" provider based address solution. I will come back to the benefit for your concern in topic 4. Bottom line is I do not think the two docs above should receive critisism only because they have not directly solved the Multihoming problem, either have you as you will see in my review of your draft, but either has anyone else. 2. Why I would like to see a Geographical Address Plan too. I believe that we should have several proposals on the table for IPv6 addressing before IPv6 address assignment begins. In addition Geographical addresses at least make the Mutlihoming problem more distinct IMHO. The reason is that each entry to the sites Internet entry can be based on a geographical location, and I believe this is not to much to ask for a provider to be conscious of when setting up a multihome site routing to the multihome site. I hope Steve Deering, Bob Hinden, and Bill Simpson can find the time to put a geographical plan together for us using IPv6. Including a document similar to Yakov #1 describing the Internet environment and a view of the multihoming problem too. I think we need this too in the IETF before we rush to a decision. But I think we can have two address plans in the Internet if we decide that subnets of addresses can exist within an Internet Global topology supporting geographical and provider based addressing. But this would be very hard to manage for providers. 3. Understanding IPv6 and all the specs. I am concerned about your knowledge of all the IPv6 specs. Here is why and it could be I am wrong? But you referenced ARP and gethostbyname() and I think have confused Yakov's docs. This leads me to believe you are not aware of IPv6 system discovery and the BSD API for IPv6 as an example. Also Bob Hinden has an Address Architecture draft that depicts multiple address types that can be specified in IPv6 that in fact do permit different address schemes such as Multicast, Unicast, or NSAPs. Not trying to ding you, but on this mail list we need to assume responses are in synch with at least the 12or15 core specs in addition to the other 10 that will affect IPv6 in the very near term. So if you are in synch I apologize now for saying this. But if you are in synch and ignoring all this work as a pre-requisite to determining solutions to IPv6 then that is not to good. But your responses have me very confused which is the case. 4. Clarification on Provider Independence and why its important. I have received much mail that I don't support providers. This is not the case at all. In fact much of IPv6 and whats important in several specs is because we MUST make sure providers can use IPv6. But my concerns are that any user of IPv6 not have leverage over another such as user over provider, or host over router, or architect over engineer in many of these discussions. The reason is that I am approaching this as an engineer as opposed to a computer scientist. An engineer must consider the market near term and long term. Its important that we have a balance. Yakov's #2 document does give us this with two enhancements to the unicast address: subscriber without provider specific parts and a national address suggestion. As Yakov #1 points out directly (and indirectly in the draft) the Internet has to strike a balance between individualistic needs and cooperation (I did not use the exact words on purpose) regarding address space assignment. I also disagree with you about NICs I think we need them and they should be internationally located and coordinated. The funding for them should come from a World Internet International Fund planned and designed by the Internet Society for the Internet and implemented by the IANA (or what it will become) and have some type of association with a group within the IETF (like the IAB). 5. Comments on your draft IPv6 Numbering Plan for Provider Independence. # IPv6 Numbering Plan for Provider Independence # #Introduction # # IPv4 addresses do not contain provider dependent information. Thus, # with IPv4 addresses, we can select and change providers without # reassigning IP addresses. # # On the other hand, IPv6 addresses contain provider dependent part for # routing aggregation. # # If host identification is controlled by providers, it is difficult to # change providers or have multiple provider. This is true but the Yakov #1 and #2 do not advocate this at all. I know several providers and none want to or will do this. # The more serious problem is security. As the host identification is # the core for security, subscribers does not want the identification # is controlled by providers. Yes and again no one is proposing this at all. # This memo proposes an address assignment scheme for IPv6 which allows # both routing aggregation and provider independence, supporting 10^12 # networks and 10^15 hosts. # The proposal also allows efficient forwarding on routers. You never technically or mathamatically prove this at all. Its just hand waving up front in the draft. At the end you plug numbers into byte assignments but give no examples. OK for mail but not an Internet Draft. # Anti-trust mechanism for provider ID assignment is also proposed to # have geographically-near-optimal and least-costly routing with proper # provider selection. This is I think only a U.S. issue and I know not a Europe issue. Is it an issue in the PAC-RIM area? #Assignment Plan for IPv6 address # The 16 byte IPv6 address is divided into four fields: 5 byte # "Provider ID", 2 byte "Subscriber ID", 1 byte "Subnet ID" and 8 byte # "Interface ID". # "Provider ID" and "Subscriber ID" together is called "Provider # dependent part". I think you need to give us an idea in a draft of a table showing bits and bytes and maybe even a matrix of how these addresses will be viewed Internationally. You also have them fixed which is finite. Yakov #1 has them variable which provides flexibility in assignment for different needs. # Provider dependent part is supplied by providers and dynamically # reconfigurable at system boot time or even during operation. It is # expected that routers to providers supply provider dependent part # information through anycasting. You need to give examples and text of how this will actually work both with Stateless Address Configuration IPv6 algorithms and I think a scenario of how it would work with DHCPv6 too. Also you use the term anycasting. I am familiar with the term for the limited drafts and discussions of the topic in the IETF. Can you expound on your ideas of anycasting? This would definitely affect IPv6 System Discovery and Autoconfiguration as it stands presently. If you have avoided that please share your idea with us. I am sure many of us who want to use anycasting would be interested. # Interface ID is a globally unique ID of an interface of a host. It # is supplied by subscribers. The configuration may be automatic. But # it is expected that renumbering is necessary not so often, in # general, only when a host is purchased or the host is moved to # different suborganization of the provider. Host specific information # such as IP address to host name mapping is looked up only through the This is total handwaving. You can't just say Interface ID or Host ID is globally unique. How do subscribers verify that is true? What part of the adddress states this to the Internet? You say configurarion can be automatic. Again how does this work with Statless or DHCPv6 autoconfig being worked on presently? After our discussion last night I spoke with a colleague about this and he pointed out that IPv4 host assignment works now. You can have the same name for all addresses or only one address. I believe someone would have to convince me the IPv4 model won't work. It also is no change to the DNS. # Interface ID and there is no provider dependence of security. You still have not defined it hence as an engineer I have no way of visualizing how exactly I would implement your notion of an Interface ID and what it does to my existing IPv4 stack as I do with the present work in IPv6, (we will have dual stacks lets make it cost effective) or in any draft including Yakov #1 and #2 (and Hinden Arch Addr spec too) assuming IPv6. # Subnet ID is also supplied by subscribers and identifies a subnet # within a subscribers LAN. The configuration may be automatic through # nearest routers. Renumbering is necessary when a location of a host # is changed to a different subnet. Lets suppose your right how does this work with IPv6 System Discovery processing and will the present formats need extensions? This is handled auotmatically now in IPv6 and it will work I am saying as an engineer because I am trying to implement it. I would not know where to start to even think about implementing your ideas here. # Network layer identification of a host is done through Interface ID # just like the current IPv4. This works in IPv6 and with any spec on the table. So its good your not breaking this. # Users can change providers at will just by disconnecting one of its # external routers and connect it to a new provider. You have not discussed the how and configuration issues. You might have it in your head but you have not written it down in this draft. I would like details otherwise its handwaving. # Interfaces of a host of a subscriber belonging to multiple providers # may have multiple provider dependent parts but only a single # interface ID. What if the machines are at different geographical locations like my organization they cannot have the same Interface ID. Unless you want to define Interface ID better for the community in the draft. # Routing is controlled purely by the first 8 bytes of IPv6 address: # "Provider ID", "Subscriber ID" and "Subnet ID" and is more efficient # than schemes using full 16 bytes. This I think would need at least 3 pages of text for you to prove it and cover all the scenarios. #Assignment Plan for Provider ID, Subscriber ID and Subnet ID # # 5 byte provider ID uniquely identifies a provider in the Internet. # # 5 byte provider ID combined with 2 byte subscriber ID uniquely # identifies a subscriber in the Internet. # # 1 byte subnet ID uniquely identifies a subnet in a subscribers # network. # # A large subscriber having more than 256 subnets will have multiple # subscriber IDs from a provider. 255 subnets will get broken easy. I used to believe this and in SIPP tried to promote 1 byte subnet for PIP routing in SIPP but found out from several end users 255 subnets can break quickly in todays world. Yor suggestion will eat up subscriber address space and thats not good either. # A large provider having more than 65536 subscriber IDs or having some # geographical constraints will have multiple provider IDs. This is why Yakov made it variable and one of the few times I must agree with variable anything in the quest for the right answers for IPv6. In addition your statement is why I would like to see a Geographical Address proposal. # For geographically-near-optimal routing, a provider ID should not # cover an area of 100Km radius. Thus, a large provider must use # different provider IDs for hosts located more than 200Km apart. # Thus, a subscriber can specify to use a local provider A, then use # low-rate long-distance-provider B and finally use the provider A who # is also serving the destination. [Note: It is expected that the # provider have IX to other providers within the 200Km radius. But # that's a operational requirement and should be separated from # assignment policy]. About 17,000 IDs are necessary to cover the # surface of the Earth. Inter-planetary communication is NOT # considered here. I don't believe the number 17,000 please prove it mathamatically. And I know its more than a simple summation and I think would require you to give me a series with a differential equation to prove it. # Anti-trust mechanism for provider ID assignment is also proposed to # have geographically-near-optimal routing. Again I think this is a U.S. only issue and we need to worry about the whole earth. #Assignment Plan for Interface ID # # First three of Interface ID is assigned from IANA to country NICs. # # Each country NIC use the next three bytes for independent # subscribers. Now here you want to use NICs ???? # A subscriber use the last two bytes for the internal use. #Supporting 10^12 networks and 10^15 hosts Show me in bit patterns with the power of 2 clearly labeled in the graph. # How the requirement to support 10^12 networks and 10^15 hosts can be # satisfied? # First, how routing between 10^12 networks is possible? 10^3 hosts # within a subnet can easily be identified by the Interface ID. Thus, # (Provider ID, Subscriber ID, Subnet ID) must identify 10^12 networks. # It is not unnatural that a provider, in average, supports at least # 10^3 subscribers. It can also be safely assumed that subnet ID can # identify 10^1 subnets. Thus, Provider ID is required to identify # 10^8 hosts. Considering that the requirement contains 10^2 safety # factor, the least two significant bytes of the Provider ID are # reserved for the factor. The remaining 3 bytes (2^24>10^7) are much # more than enough to identify 10^6 providers. It is assumed that by # the time we support 10^12 networks, flat routing of 10^6 providers is # not a problem at all. The reserved lower two bytes of provider ID # may also be used for two-level routing among providers. You have not clearly articulated the relationship to Interface ID here. Your figures seem right but with Yakov #2 it has at least as good an address space. So the gain is what? # Next, how identification of 10^15 hosts is possible? 10^3 hosts of a # subscriber can easily be identified by the last two bytes of # Interface ID. For the remaining 10^12 factor, IANA and country NICs # are expected to manage the upper 6 bytes completely densely. Thus, it # should be possible to support more than 10^14 networks. Yakov #2 avoids all the IANA management you suggest by providing blocks of addresses according to the space for providers per Hinden-Addr-Arch. You have added much more overhead and control by an authority than in Yakov #1 or #2. Plus the ideas of registrys make this more manageable. Registrys also give a geographical hint to the routing policy too in Yakov #2. #Conclusion # As the 16 byte address space is so large, it is possible to use it # wisely to enjoy full provider independence, including provider change # without renumbering and long distance provider selection by provider # IDs. So did Yakov #2. 6. My conclusion. You have still not proved a UID can work or defined it clearly. Like I said previously not in my life time I don't think. Actually I have a scheme too but folks are burned out on UIDs and EIDs and it is just is not going to gain consensus in the IETF right now. It changes the core Internet model to a degree that cannot be defended technically with performance and cost assurances. But if you really want to try I think Christian Huitema came closer than anyone to solving it at least for transports, maybe it would apply? I think you have an idea but it will take much more work and lots more words, diagrams, and explanation per your new terminology Interface ID. In addition you need to make sure you don't break other IPv6 specs. Or you could connect with Yakov offline and see if you can improve that spec with him and reach a common ground, if your idea will benefit what is in the spec now. I do not think that is the case per this draft unless it has more context and explanation to see the essence more clearly of what your driving at. Its great to have ideas but they are no value unless they can be communicated clearly and precisely. This is not a language issue but a skill that takes many engineers many many years to learn. I am still learning it and have a ways to go my self to be a master. Steve Deering, Greg Minshall, Bob Hinden, Christian Huitema, Brian Carpenter, and Craig Partridge are Masters at this engineering skill as several examples IMHO. Reading their mail is a learning experience. Finally I am concerned that many of your assumptions need to be tested against the existing IPv6 core specifications. Yakov #2 will work with all of them. take care, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 20 22:17:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01978; Mon, 20 Feb 95 22:17:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01972; Mon, 20 Feb 95 22:17:49 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03944; Mon, 20 Feb 1995 22:10:45 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA11832; Mon, 20 Feb 95 22:10:48 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA00877; Mon, 20 Feb 95 22:05:19 -0800 Received: by xirtlu.zk3.dec.com; id AA04648; Tue, 21 Feb 1995 01:04:23 -0500 Message-Id: <9502210604.AA04648@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider Independence Reality Check In-Reply-To: Your message of "Mon, 20 Feb 95 10:22:30 PST." <199502201822.KAA00667@mvp.com> Date: Tue, 21 Feb 95 01:04:17 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM George, A good question I think. >There is a lot of discussion about provider independence on this >mailling list, and I agree that provider independence is a good thing. >However, as I understand it, the current thinking on how to keep >IPv6 addresses provider independent is to split them up into a rout- >able part, which will clearly never be provider-independent, and an >unroutable part which is permanently bound to an interface and which >will be provider-independent. The issue if provider independence stems I think from wanting avoid a monopoly affect on the Internet. I am not clear this can be avoided regarding routing but I think it can based on how addresses are defined. I think the routable part can be provider independent in draft-ietf-ipngwg-address-format-01.txt. This draft provides for subscribers to select addresses without a provider part too. The cautions are what you have stated below. Now when I say independent I mean from the perspective if xyz gets an address from IANA it will have a format prefix registry components and then subscriber components. They are provider independent. >But why do you need the IPv6 address to be at all provider indepen- >dent? Surely the proper place to have a permanent, provider-indepen- >dent identifier is in the Domain Name System -- not in the IPv6 >address itself. Don't we want to use as much of the address as poss- >ible to contain routing information to kep the routing problem >tractable? Your last statement I found to be the real issue too. But some orgs I won't mention want to switch providers and don't want to readdress their systems or site. You can do this when not using a provider specific part in the address, as describe above. The onus I think is for some providers to really study IPv6 with respect to System Discovery, Autoconfig (Stateless and Statefull), DNS, and the routing protocols and develop adjunct admin protocols that add to these protocols that make readdressing an easy one step process with an applicaiton protocol. This is also whats missing in the admin environment of the autoconfig and DNS even in IPv6 specs. I suggested this as a work item for the IETF Operations Area on the addrconf mail list a few weeks ago. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 20 23:14:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02002; Mon, 20 Feb 95 23:14:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01996; Mon, 20 Feb 95 23:14:03 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05360; Mon, 20 Feb 1995 23:07:00 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA15930; Mon, 20 Feb 95 23:07:01 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14272; Tue, 21 Feb 1995 08:07:00 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA20530; Tue, 21 Feb 1995 08:06:58 +0100 Message-Id: <9502210706.AA20530@dxcoms.cern.ch> Subject: Re: (IPng) comments on "IPv6 Global Unicast Addr Format" To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Feb 1995 08:06:57 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9502201942.AA16069@itd.nrl.navy.mil> from "Ran Atkinson" at Feb 20, 95 02:42:13 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, > > Provider-oriented addressing simply will not function for multi-homed > sites such as NRL. Or CERN, so I analysed this aspect of the Yakov/Li/Lothberg drafts many moons ago. I concluded that there was enough flexibility in the drafts to cover our needs, as long as the RIPE-NCC would give us a top level prefix. I think you have a good idea but it can be done more simply, just by treating *IXen as pseudo-major-providers. However that would mean that a NIC must exist for each *IX - who funds it? So far, the *IXen are very low budget operations IMO. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 20 23:19:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02018; Mon, 20 Feb 95 23:19:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02012; Mon, 20 Feb 95 23:19:03 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05454; Mon, 20 Feb 1995 23:12:00 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA16306; Mon, 20 Feb 95 23:11:56 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 21 Feb 95 16:10:31 +0900 From: Masataka Ohta Message-Id: <9502210710.AA23243@necom830.cc.titech.ac.jp> Subject: Re: (IPng) Provider Independence Reality Check To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Feb 95 16:10:30 JST In-Reply-To: <199502201822.KAA00667@mvp.com>; from "George Mitchell" at Feb 20, 95 10:22 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > However, as I understand it, the current thinking on how to keep > IPv6 addresses provider independent is to split them up into a rout- > able part, which will clearly never be provider-independent, and an > unroutable part which is permanently bound to an interface and which > will be provider-independent. Correct. > But why do you need the IPv6 address to be at all provider indepen- > dent? More correctly speaking, I'd like to keep IP (including v4) address be provider independent. Pre-CIDR Internet is flat routed and IPv4 address is provider independent. But, now, hierarchical routing with address aggregation is being introduced, which makes IP address provider dependent. As CIDR and IPv6 are introducing routable part, which explicitely reflect the provider structure, we have to have UID part to make IPv6 address as provider independent (hopefully) as IPv4 address. > Surely the proper place to have a permanent, provider-indepen- > dent identifier is in the Domain Name System -- not in the IPv6 > address itself. In pre-CIDR ages, it was not in the IP address itself. > Don't we want to use as much of the address as poss- > ible to contain routing information to kep the routing problem > tractable? So? My proposal already contains analysis that 64 bit is more than enough to contain routing information for 10^12 networks and 10^15 hosts. My proposal even allows to detect the geographical locating of the problem. Unlike mine, Yakov's proposal seems to have wasted a lot of bits to disable meaningful tracing. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 00:29:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02054; Tue, 21 Feb 95 00:29:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02048; Tue, 21 Feb 95 00:29:43 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07017; Tue, 21 Feb 1995 00:22:41 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA23416; Tue, 21 Feb 95 00:22:40 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 21 Feb 95 17:21:18 +0900 From: Masataka Ohta Message-Id: <9502210821.AA23667@necom830.cc.titech.ac.jp> Subject: (IPng) National Registry of Routing is Harmful To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Feb 95 17:21:17 JST In-Reply-To: <9502201942.AA16069@itd.nrl.navy.mil>; from "Ran Atkinson" at Feb 20, 95 2:42 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran; As USA being the center of the Internet, it should be difficult for you to seriously think about foreign communication issues. But... > If > national-registries exist, then this would be additional aggregation > below the national-registries. No, absolute NO. You are assuming a country of monopoly. With a monopolized foreign communication provider, national-registry part can aggregate the nation outside the country. But it is not at all necessary to reduce the size of international routing table to several hundreds. So, the aggregation is meaningless. With multiple nation-wide providers, national-registry part does NOT work inside a nation. As the part is identical, the lower bits must be different provider by provider. That unaggregated result, then, will be exported outside the nation as is by each provider, UNLESS foreign communication is monopolized. Moreover, national registry is the obstacle for the routing aggregation inside multi-national providers. Never say "additional aggregation below the national-registries". National registry for routing is the concept useful only for PTTs. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 00:52:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02082; Tue, 21 Feb 95 00:52:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02076; Tue, 21 Feb 95 00:52:19 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07635; Tue, 21 Feb 1995 00:45:17 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA24940; Tue, 21 Feb 95 00:45:17 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 21 Feb 95 17:43:55 +0859 From: Masataka Ohta Message-Id: <9502210844.AA23908@necom830.cc.titech.ac.jp> Subject: Re: (IPng) comments on "IPv6 Global Unicast Addr Format" To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Feb 95 17:43:54 JST In-Reply-To: <9502210706.AA20530@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Feb 21, 95 8:06 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Ran, > > > > Provider-oriented addressing simply will not function for multi-homed > > sites such as NRL. > > Or CERN, so I analysed this aspect of the Yakov/Li/Lothberg drafts > many moons ago. I concluded that there was enough flexibility in the > drafts to cover our needs, as long as the RIPE-NCC would give us a > top level prefix. If every organization has a top level prefix, the result is the current non-CIDR flat routing and the provider independence issue disappear. If only we could simply ignore routing table explosion... Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 01:08:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02133; Tue, 21 Feb 95 01:08:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02127; Tue, 21 Feb 95 01:08:49 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08061; Tue, 21 Feb 1995 01:01:49 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA26331; Tue, 21 Feb 95 01:01:46 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA29654; Tue, 21 Feb 1995 10:01:44 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA27399; Tue, 21 Feb 1995 10:01:41 +0100 Message-Id: <9502210901.AA27399@dxcoms.cern.ch> Subject: Re: (IPng) National Registry of Routing is Harmful To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Feb 1995 10:01:41 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9502210821.AA23667@necom830.cc.titech.ac.jp> from "Masataka Ohta" at Feb 21, 95 05:21:17 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, Don't say "national", say "geographical". There is a natural monopoly in geography. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 02:03:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02174; Tue, 21 Feb 95 02:03:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02168; Tue, 21 Feb 95 02:03:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09669; Tue, 21 Feb 1995 01:56:26 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA00526; Tue, 21 Feb 95 01:56:19 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 21 Feb 95 18:54:53 +0859 From: Masataka Ohta Message-Id: <9502210955.AA24169@necom830.cc.titech.ac.jp> Subject: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Feb 95 18:54:52 JST Cc: bound@zk3.dec.com In-Reply-To: <9502210510.AA04229@xirtlu.zk3.dec.com>; from "bound@zk3.dec.com" at Feb 21, 95 12:10 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Masataka, > > I always give folks the benefit of the doubt. I should not always do that > especially in this discussion. Your draft needs a lot more work and > Yakov's is complete without too many holes for what he is > proposing. Yakov merely proposed that: 1) IPv6 address should be hierarchical 2) The structure of hierarchy Though it also SUGGEST how the hierarchy is structured, it is NOTHING as STANDARD. Unlike my proposal, it leaves the hierarchy boundary undetermined, which needs a lot of more future work than mine. And, I do agree with 1). But, as I have already shown, his proposal is broken for multi-homing. Moreover, as I just pointed out in the other mail, the structure containing national registry is broken. So, Yakov's draft is complete only regarding 1). > We are trying to go to > proposed standard, if you did not know, with a core set of IPv6 drafts and > Yakov's work are two of them. We, including those who at not at the interim meeting, are not. And, the purpose of the standardization process is to reflect reviews. > OK I have put > about 4 hours into it and researched several mail archives and other > text I could find on Multihoming beliefs, which was another 3 hours. I have put only about 2 hours to note the problems of Yakov's proposal on multi-homing and national registry, more than half of which was spent on just reading the unnecessarily lengthy description. > Topics: As your mail is already too lengthy, I only briefly respond here. > 1. Review of Yakov's docs and what we are talking about to make > this clear. There are not so many difference of opinion here, though I think saying "variable length" is the worst engineering. IPv6 is not a toy of computer scientists. > 2. Why I would like to see a Geographical Address Plan too. As I think my proposal already offer all the benefits of Geographical Address Plan, I don't think it necessary. If you have any objection, give your list of what you expect to Geographical Address Plan. > 3. Understanding IPv6 and all the specs. While I do understand how IPv6 should be, I won't be restricted by the part of proposed specs dependent on Yakov's draft. > 4. Clarification on Provider Independence and why its important. Dispite the title, you didn't give any definition of provider independence and just mentioned that it's less important than NIC funding issue, which you misunderstand that I think it unimportant. To me absolutely not as a computer scientist, and not as an engineer, but as a USER, both the provider independence and NIC funding issue are important. NICs should be funded so that users can get its service without difficulty and, at the same time, without spending unreasonable amount of money. As an member of APNG, which launched APNIC, both of which are, unlike Internic, not well funded, I do understand the importance of NIC funding. So, I proposed to use NIC control UID space. > 5. Comments on your draft IPv6 Numbering Plan for Provider > Independence. In short, you misunderstand my proposal, especially on the point where I tried to let IPv6 just as good as IPv4. You think I require a new mechanism on points where the existing ones are good enough. I doubt you understand IPv4. More detailed discussion is given in a separate mail. > 6. My conclusion. No, thank you. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 03:33:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02268; Tue, 21 Feb 95 03:33:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02262; Tue, 21 Feb 95 03:33:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11197; Tue, 21 Feb 1995 03:26:02 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA10239; Tue, 21 Feb 95 03:25:58 PST Received: by mitsou.inria.fr (8.6.9/8.6.9) id MAA28693; Tue, 21 Feb 1995 12:25:56 +0100 Message-Id: <199502211125.MAA28693@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) National Registry of Routing is Harmful In-Reply-To: Your message of "Tue, 21 Feb 1995 10:01:41 +0100." <9502210901.AA27399@dxcoms.cern.ch> Date: Tue, 21 Feb 1995 12:25:54 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM => Ran, => => Don't say "national", say "geographical". There is a natural => monopoly in geography. => => Brian In a deregulated environment, you would be hard pushed to justify a natural monopoly, be it based on political or geographical boundaries. As the price of raw transmission drops, management matters dominates. This means that "business proximity" becomes more natural than geographical proximity. The only "natural" monopoly is where the price of the raw transmission is not expected to drop, i.e. in the local loop. It takes an awful lot of time and energy to bury copper or glass and wire every building in town. But even there, we should rather expect an oligopoly than a monopoly. And who knows what the new radio bands are going to bring? Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 04:39:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02322; Tue, 21 Feb 95 04:39:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02316; Tue, 21 Feb 95 04:39:31 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16740; Tue, 21 Feb 1995 04:32:30 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA15467; Tue, 21 Feb 95 04:32:29 PST Received: by rodan.UU.NET id QQyeas19069; Tue, 21 Feb 1995 07:32:28 -0500 Message-Id: To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Provider-based addressing Date: Tue, 21 Feb 1995 07:32:28 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM this keeps coming up again and again, and i still don't understand what all the furor is about. It is obvious that any multi-homed system can only have one prefix, so the provider who registered and assigned that prefix can aggregate and the other providers must carry an explicit announcement. At least one provider gets to aggregate more completely. This is a win. People need to concentrate on the real technical issue here: flat routing cannot possibly scale. Begin soapbox screed... The reason the network is alive today is because the DNS introduced DELEGATION into the naming system, so that every name resolver doesn't have to know about EVERY possible name. There is a well-defined algorithm for taking a cache-miss and getting the information needed without resorting to the global "/etc/hosts" file. I believe that unless we somehow make it possible for ROUTERS to not have to know every registered system prefix in the universe, the day is not too far off where we will not be able to afford routers with enough memory to hold the infomration (assuming you can put multiple gigabytes on the routers). We MUST create a routing architecture which provides for delegation and/or compression or we will shortly scale ourselves out of existance. Provider-based aggregation is one relatively feasible model for doing routing table compression (it doesn't do delegation - it just reduces how many bits it takes to know "everything"). At least in this case, the technique has architectural implications for the addresses because it is the address that is redundancy being compressed. If someone wishes to propose an alternate addressing model, they must also explain how it achieves either significant route compression or delegation or offer an alternative approach for dealing with route scaling. But for now, provider-based aggregation is the ONLY scheme actually in-hand which can even make a serious dent in the problem, but as is obvious, the containment of entropy is less that adequate. BUT FOR NOW IT'S ALL WE HAVE, unless someone has a miracle in their pocket, which I'm hoping for, by the way. This means that until and unless the problems can be resolved PURELY with the routing architecture, then the Addressing and Route Management problems are inextricably connected. Note that there are various thoughs on how to do real delegation with routers, but it's really a way to minimize the number of systems which contain the entire universe, but we are a LONG way from having those hashed out and viable, much less implemented. So I believe that we must pursue a dual path for now - aggressive route compression with the hope that something like real delegation gets done in time to save us from the inevitable entropy that will eventually defeat the compression scheme. End of soapbox screed. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 04:45:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02338; Tue, 21 Feb 95 04:45:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02332; Tue, 21 Feb 95 04:44:56 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16852; Tue, 21 Feb 1995 04:37:55 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA15837; Tue, 21 Feb 95 04:37:49 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA02633; Tue, 21 Feb 1995 13:37:46 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05139; Tue, 21 Feb 1995 13:37:43 +0100 Message-Id: <9502211237.AA05139@dxcoms.cern.ch> Subject: Re: (IPng) National Registry of Routing is Harmful To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Feb 1995 13:37:43 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199502211125.MAA28693@mitsou.inria.fr> from "Christian Huitema" at Feb 21, 95 12:25:54 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian, I agree. What I was getting at is the same thing I remember saying when the IAB had a brief discussion on the provider v. geographical issue in San Jose. If you go for a geographical address hierarchy, in a competitive multiprovider network, you will need a FIX in every city unless you are prepared to flat route and send all packets via a Very Big Router somewhere. In fact I remember this being debated on big-internet a couple of years ago. I don't think the radio spectrum really fixes it. Spectrum is a scarce resource, especially for long distance use. I agree, over short distances it can create "alternative" local loop capacity and that avoids a natural monopoly. It gets you back to provider-based addressing IMO. I cannot fault the logic of Yakov and his co-authors. Brian >--------- Text sent by Christian Huitema follows: > > => Ran, > => > => Don't say "national", say "geographical". There is a natural > => monopoly in geography. > => > => Brian > > In a deregulated environment, you would be hard pushed to justify a natural > monopoly, be it based on political or geographical boundaries. As the price of > raw transmission drops, management matters dominates. This means that > "business proximity" becomes more natural than geographical proximity. > > The only "natural" monopoly is where the price of the raw transmission is not > expected to drop, i.e. in the local loop. It takes an awful lot of time and > energy to bury copper or glass and wire every building in town. But even > there, we should rather expect an oligopoly than a monopoly. And who knows > what the new radio bands are going to bring? > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 05:21:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02357; Tue, 21 Feb 95 05:21:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02351; Tue, 21 Feb 95 05:21:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17756; Tue, 21 Feb 1995 05:14:27 -0800 Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA18923; Tue, 21 Feb 95 05:14:25 PST Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.9/8.6.9) with ESMTP id IAA11670 for ; Tue, 21 Feb 1995 08:14:20 -0500 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.9/8.6.9) with SMTP id IAA02091 for ; Tue, 21 Feb 1995 08:14:18 -0500 Received: from bobsgrid.is.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA17913; Tue, 21 Feb 95 08:29:25 EST Message-Id: <9502211329.AA17913@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Feb 1995 08:14:09 -0600 To: ipng@sunroof.Eng.Sun.COM From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: (IPng) A NEW thought on addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Friends, I have been a lurker here for the past 2 months, as I have been swamped launching a number of key systems and designing some new ones for this year... But I have been giving this addressing issue a lot of thought. At Toronto, I felt that a provider prefix for some of us 'big guys' was the answer. After all, we are providers for many of our subsidiaries and some suppliers and customers. But more recently I have thought about the multi-addressing nature of IPv6 and how it might work. Consider the following (BTW I think it implies some holes in our auto address config work): Corp FOO has 2 INTERNET providers, A.NET and B.NET. MFG.FOO.COM is restricted to using A.NET, ENG.FOO.COM is restricted to using B.NET, and all others (like FIN.FOO.COM and HR.FOO.COM can use either). It would seem to me that when PRESS.MFG.FOO.COM boots up, it will have 3 addresses: The INTRA-LINK address, a Private address for FOO.COM, and a provider address from A.NET's space. Likewise when CAD.ENG.FOO.COM starts up, it will also have 3 addresses: The Intra-Link, a Private and a provider address from B.NET's space. Systems like WWW.MKTG.FOO.COM will have 4 addresses: The Intra-link, a Private and 2 provider addresses (one from each provider). I am making a GROSS assumption that any of the config options will help create all of these addresses, and that all of the necessary AAAA records will be created. When PRESS.MFG.FOO.COM needs to connect to CAD.ENG.FOO.COM, the gethostbyname() will return 3 AAAA records. PRESS will select the only common address, the Private one, for the connection and off they go. In fact, somehow there will need to be a weighting factor so that all FOO.COM internal connections will perfer the private addresses. But I do not see anything like this in the DNS spec. Remember that a commection between CAD.ENG.FOO.COM to WWW.MKTG.FOO.COM has 2 valid addresses to choose from. The external connection for WWW.MKTG.FOO.COM will be interesting. How can a decision be made which address to use? I might think that in response to an external connection request, it will use the address that the was the destination of the incoming package. But if this is a caching server that is going out to the greater world, WWW should first use one of the provider addresses and if no connection is established, to then try the other provider address. How to do this? Again it looks like a DNS address weighting problem. Perhaps something like route weights in OSPF? So it seems like multihomed networks COULD WORK!!!!! We need to use the speced ability to have multiple addresses per host interface. Now on to the joy of configuring the routers for such usage...... The router folks will need to configure 3 topologies in the router network of FOO.COM. The private topology, the part of the network accessable via A.NET and the part accessable via B.NET. A challenge for sure, unless there is someway to identify a local topology (upper part of the lower half of the address) and valid provider prefixes for the routers? Anyway, some NEW thoughts on this addressing chulent. Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 06:00:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02394; Tue, 21 Feb 95 06:00:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02388; Tue, 21 Feb 95 06:00:44 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19547; Tue, 21 Feb 1995 05:53:42 -0800 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by Sun.COM (sun-barr.Sun.COM) id AA22637; Tue, 21 Feb 95 05:53:42 PST Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA29311; Tue, 21 Feb 95 08:53:41 EST Date: Tue, 21 Feb 95 08:53:41 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9502211353.AA29311@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Proxy ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I think that Proxy ARP should either be justified on technical grounds (i.e. a specific statement that it solves some particular described problem and also why no other mechanism solves that problem sufficiently) or it should be removed. With Router Discovery, the primary installed-base use of Proxy ARP was obviated. With IPv6 Discovery, Proxy ARP doesn't solve any problem that can't be solved by the standard mechanisms in Discovery. If someone thinks that it IS solving some particular problem that neither Discovery nor any other IPv6 mechanism solves, then please describe on this list in public and in detail -- the problem it solves why neither Discovery nor any other mechanism solves it why Proxy ARP does solve it. The only example so far was of a system with a single network (Ethernet,f or example) tap that acquires a SLIP/PPP link and starts routing packets between that SLIP/PPP link and the Ethernet. My assertion is that Router Discovery provided as part of base IPv6 completely solves that problem. Further, all systems which route packets are routers, not hosts, even though they might be sold initially as workstations... So that example does not make the case that we need to retain Proxy ARP. Looking forward to a technical response, Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 06:35:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02423; Tue, 21 Feb 95 06:35:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02417; Tue, 21 Feb 95 06:35:13 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21362; Tue, 21 Feb 1995 06:28:12 -0800 Received: from nbkanata.Newbridge.COM (Newbridge.COM) by Sun.COM (sun-barr.Sun.COM) id AA27355; Tue, 21 Feb 95 06:28:10 PST Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA07773; Tue, 21 Feb 95 09:22:20 EST Received: from mako.newbridge.com by Newbridge.COM (4.1/SMI-4.0) id AA23066; Tue, 21 Feb 95 09:21:50 EST Received: from lobster.Newbridge.COM by mako.newbridge.com (4.1/SMI-4.1) id AA06974; Tue, 21 Feb 95 09:26:47 EST Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA03577; Tue, 21 Feb 1995 09:27:34 +0500 Date: Tue, 21 Feb 1995 09:27:34 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9502211427.AA03577@lobster.Newbridge.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I agree with you. However, at least one geographic scheme I saw did have the same scaling properties as provider based addressing. If addresses are dervice from either a provider or from a *IX (which as Brian put it would be behaving as a pseudo-provider) then one can have a "geographic" based address which is related to the real topology and has at least somewhat reasonable aggregation. I was at first strongly against this because it was described as a "geographic" addressing proposal. But in fact it has nothing in common with the cty/state/country/continent type addressing which was proposed. It doesn't help Newbridge, but nothing is going to help a company with two providers in two different countries connecting at two very different places in the topology. I am not sure that the *IX alternative is a good one, but it does at least meat the starting criteria, unlike other proposals. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. PS M. Ohta is starting to drive me straight up a tree. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 07:33:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02447; Tue, 21 Feb 95 07:33:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02441; Tue, 21 Feb 95 07:33:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24573; Tue, 21 Feb 1995 07:25:59 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA06615; Tue, 21 Feb 95 07:25:56 PST Received: from relay.imsi.com by wintermute.imsi.com id KAA13883 for ; Tue, 21 Feb 1995 10:25:54 -0500 Received: from snark.imsi.com by relay.imsi.com id KAA01177 for ; Tue, 21 Feb 1995 10:25:53 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA00897; Tue, 21 Feb 95 10:25:46 EST Message-Id: <9502211525.AA00897@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) National Registry of Routing is Harmful In-Reply-To: Your message of "Tue, 21 Feb 1995 12:25:54 +0100." <199502211125.MAA28693@mitsou.inria.fr> X-Reposting-Policy: redistribute only with permission Date: Tue, 21 Feb 1995 10:25:45 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian Huitema says: > In a deregulated environment, you would be hard pushed to justify a > natural monopoly, be it based on political or geographical > boundaries. As the price of raw transmission drops, management > matters dominates. This means that "business proximity" becomes more > natural than geographical proximity. > > The only "natural" monopoly is where the price of the raw transmission is not > expected to drop, i.e. in the local loop. It takes an awful lot of time and > energy to bury copper or glass and wire every building in town. But even > there, we should rather expect an oligopoly than a monopoly. And who knows > what the new radio bands are going to bring? In cities like New York, one can expect there to be many, many providers. This is because the density of buildings is such that, having brought fiber to one customer, you have effectively brought it to dozens if not hundreds of others as a side effect. There are already no less than three complete networks spanning the city (NYNEX, the local cable companies which have brought fiber to every block, and several small competing phone companies) and we can expect more to show up. Any scheme that assumes that people will stick with a particular provider is completely doomed in such an environment. With time, we can expect that people will switch providers very frequently. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 08:06:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02559; Tue, 21 Feb 95 08:06:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02553; Tue, 21 Feb 95 08:06:30 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27109; Tue, 21 Feb 1995 07:59:28 -0800 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA12462; Tue, 21 Feb 95 07:59:28 PST Subject: (IPng) Addrconf prefix To: IPng Mailing list Date: Tue, 21 Feb 1995 11:00:06 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9502211600.aa01783@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Have we determined bit values for the intra-link scope prefix. By, "intra-link scope prefix" I mean an address may consist of: Do we have any value for that yet? I've been using (in Net/2) and will use (in 4.4) fe00:0000:0000:0000:0000: until I hear differently. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 08:28:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02599; Tue, 21 Feb 95 08:28:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02587; Tue, 21 Feb 95 08:28:44 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29213; Tue, 21 Feb 1995 08:21:43 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA17133; Tue, 21 Feb 95 08:21:41 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA09705; Tue, 21 Feb 1995 17:21:33 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA12513; Tue, 21 Feb 1995 17:21:27 +0100 Message-Id: <9502211621.AA12513@dxcoms.cern.ch> Subject: Re: (IPng) National Registry of Routing is Harmful To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Feb 1995 17:21:26 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9502211525.AA00897@snark.imsi.com> from "Perry E. Metzger" at Feb 21, 95 10:25:45 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, ... > Any scheme that assumes that people will stick with a particular > provider is completely doomed in such an environment. With time, we > can expect that people will switch providers very frequently. Yes. That is why auto-config and auto-DNS-registration are mandatory for IPv6 to scale better than IPv4. Unless, as Mike O'D says, somebody has a miracle in their pocket. Brian P.S. excuse me everybody, but didn't we already discuss all this? Like last year or the year before? I think I'm going to put this thread on my drop list shortly. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 08:29:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02600; Tue, 21 Feb 95 08:29:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02593; Tue, 21 Feb 95 08:28:50 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29226; Tue, 21 Feb 1995 08:21:47 -0800 Received: from venera.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA17162; Tue, 21 Feb 95 08:21:47 PST Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Tue, 21 Feb 1995 08:21:46 -0800 From: bmanning@ISI.EDU Posted-Date: Tue, 21 Feb 1995 08:20:57 -0800 (PST) Message-Id: <199502211620.AA13872@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 21 Feb 1995 08:20:57 -0800 Subject: Re: (IPng) comments on "IPv6 Global Unicast Addr Format" To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Feb 1995 08:20:57 -0800 (PST) In-Reply-To: <9502210706.AA20530@dxcoms.cern.ch> from "Brian Carpenter CERN-CN" at Feb 21, 95 08:06:57 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > I think you have a good idea but it can be done more simply, just > by treating *IXen as pseudo-major-providers. However that would > mean that a NIC must exist for each *IX - who funds it? So far, > the *IXen are very low budget operations IMO. > This is not exactly correct. A single NIC can accomodate seeveral exchange points. They just have to keep the addressing mapped to the correct point. -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 08:42:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02629; Tue, 21 Feb 95 08:42:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02623; Tue, 21 Feb 95 08:41:57 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00615; Tue, 21 Feb 1995 08:34:55 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA19966; Tue, 21 Feb 95 08:34:52 PST Received: from relay.imsi.com by wintermute.imsi.com id LAA14120 for ; Tue, 21 Feb 1995 11:34:51 -0500 Received: from snark.imsi.com by relay.imsi.com id LAA01700 for ; Tue, 21 Feb 1995 11:34:51 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA01030; Tue, 21 Feb 95 11:34:43 EST Message-Id: <9502211634.AA01030@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) National Registry of Routing is Harmful In-Reply-To: Your message of "Tue, 21 Feb 1995 17:21:26 +0100." <9502211621.AA12513@dxcoms.cern.ch> X-Reposting-Policy: redistribute only with permission Date: Tue, 21 Feb 1995 11:34:42 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "Brian Carpenter CERN-CN" says: > Yes. That is why auto-config and auto-DNS-registration > are mandatory for IPv6 to scale better than IPv4. My one problem is that no one has demonstrated these working in practice. We are supposed to believe in rough consensus *and* working code. The code is still missing. This whole thing makes me nervous in the absense of field experience. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 08:46:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02642; Tue, 21 Feb 95 08:46:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02636; Tue, 21 Feb 95 08:46:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00972; Tue, 21 Feb 1995 08:39:13 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA20870; Tue, 21 Feb 95 08:39:09 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) comments on "IPv6 Global Unicast Addr Format" To: ipng@sunroof.Eng.Sun.COM Date: Tue, 21 Feb 1995 16:41:35 +0000 (GMT) In-Reply-To: <199502211620.AA13872@zed.isi.edu> from "bmanning@ISI.EDU" at Feb 21, 95 08:20:57 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have one single very specific issue that I find very important. Having seen the effective misuse of monopolies by some address allocators and domain allocators its important that the system is devolved through all the providers. With DNS you can (fortunately) already go for a .com or .org when you see the price of a .be (for example). Its vital address allocation stays fairly handled, and handling it by delegating chunks down and down seems to the only way to ensure that. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 09:05:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02708; Tue, 21 Feb 95 09:05:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02702; Tue, 21 Feb 95 09:05:04 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02747; Tue, 21 Feb 1995 08:58:01 -0800 Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA03012; Tue, 21 Feb 95 08:58:00 PST Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.9/8.6.9) with ESMTP id LAA19539 for ; Tue, 21 Feb 1995 11:57:55 -0500 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.9/8.6.9) with SMTP id LAA02702 for ; Tue, 21 Feb 1995 11:57:54 -0500 Received: from bobsgrid.is.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA20423; Tue, 21 Feb 95 12:13:03 EST Message-Id: <9502211713.AA20423@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Feb 1995 11:57:43 -0600 To: ipng@sunroof.Eng.Sun.COM From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: (IPng) Provider-based addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 07:32 AM 2/21/95 -0500, "Mike O'Dell" wrote: >It is obvious that any multi-homed system can only have one prefix, Huh?????? Why????? In the specs, any interface can have multiple addresses. I did not see any text that said they all had to have the same prefix!!! This is for single-homed systems too! Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 09:50:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02811; Tue, 21 Feb 95 09:50:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02805; Tue, 21 Feb 95 09:49:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08482; Tue, 21 Feb 1995 09:42:55 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA14029; Tue, 21 Feb 95 09:42:55 PST Received: from relay.imsi.com by wintermute.imsi.com id MAA14471; Tue, 21 Feb 1995 12:42:42 -0500 Received: from webster.imsi.com by relay.imsi.com id MAA02452; Tue, 21 Feb 1995 12:42:41 -0500 Received: from localhost by webster.imsi.com (4.1/SMI-4.1) id AA05162; Tue, 21 Feb 95 12:42:36 EST Message-Id: <9502211742.AA05162@webster.imsi.com> To: rgm3@is.chrysler.com Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing In-Reply-To: Your message of "Tue, 21 Feb 1995 11:57:43 CST." <9502211713.AA20423@clncrdv1.is.chrysler.com> Date: Tue, 21 Feb 1995 12:42:36 -0500 From: Rens Troost Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>>>> "Robert" == Robert Moskowitz writes: Robert> In the specs, any interface can have multiple addresses. I Robert> did not see any text that said they all had to have the same Robert> prefix!!! This is for single-homed systems too! How does the other endpoint know what the set of possible destination addresses for a target interface is? Your proposal requires separate transport-level addresses layered on top of the network addresses to allow multiple-path routing. Also, said information would have to propagate and be cached at routers along the entire path. It's a tough problem. -Rens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 10:00:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02828; Tue, 21 Feb 95 10:00:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02822; Tue, 21 Feb 95 10:00:17 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10042; Tue, 21 Feb 1995 09:53:14 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA16493; Tue, 21 Feb 95 09:53:15 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14528(5)>; Tue, 21 Feb 1995 09:44:40 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Tue, 21 Feb 1995 09:44:32 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng) v6 ICMP message types Date: Tue, 21 Feb 1995 09:44:26 PST From: Steve Deering Message-Id: <95Feb21.094432pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The rules for not sending ICMP error messages in response to ICMP error messages requires that implementations have a compiled-in list of which ICMP message types are error messages. That rules out the safe introduction of new ICMP error message types in the future. For the IPv6 version of ICMP, I am thinking of encoding in the message type whether or not the message is an error message, so that a compiled-in list will not be necessary and future error message types can be correctly recognized. Here's a possible encoding of the messages defined in the v6 ICMP spec, using the high-order bit of the message type to identify error messages: 0 - Echo Request 1 - Echo Reply 2 - Node Name Request 3 - Node Name Reply 4 - Group Membership Query 5 - Group Membership Report 6 - Group Membership Termination 128 - Destination Unreachable 129 - Packet Too Big 130 - Time Exceeded 131 - Parameter Problem I'd appreciate comments ASAP, especially from v6 implementors and from authors of other specs that define v6 ICMP message types (e.g., Neighbor Discovery). Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 10:01:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02840; Tue, 21 Feb 95 10:01:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02834; Tue, 21 Feb 95 10:01:24 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10212; Tue, 21 Feb 1995 09:54:21 -0800 Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA16722; Tue, 21 Feb 95 09:54:20 PST Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.9/8.6.9) with ESMTP id MAA19691 for ; Tue, 21 Feb 1995 12:54:14 -0500 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.9/8.6.9) with SMTP id MAA02859 for ; Tue, 21 Feb 1995 12:54:14 -0500 Received: from bobsgrid.is.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA20920; Tue, 21 Feb 95 13:09:17 EST Message-Id: <9502211809.AA20920@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Feb 1995 12:53:57 -0600 To: rens@imsi.com From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: (IPng) Provider-based addressing Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 12:42 PM 2/21/95 -0500, Rens Troost wrote: > >>>>>> "Robert" == Robert Moskowitz writes: > > Robert> In the specs, any interface can have multiple addresses. I > Robert> did not see any text that said they all had to have the same > Robert> prefix!!! This is for single-homed systems too! > >How does the other endpoint know what the set of possible destination >addresses for a target interface is? All addresses HAD BETTER be recorded in the DNS. This poises an interesting question about 'private addresses'. Let us assume that in the world of IPv6 with authenticated and encrypted connections being standardly available, firewalls will rarely be needed ( ;) ). Either an AXFER or an IXFER from FOO.COM would have to exclude the internal addresses, or outside systems would have to know to ignore them. >Your proposal requires separate transport-level addresses layered on top of >the network addresses to allow multiple-path routing. Why? I do not see that. The IP address is sufficient. Yes I am an EID proponent, I have mobile processes, check out APPN, this is ONE THING IT DOES RIGHT. But EIDs are a simplifier, not a requirement. >Also, said information would have to propagate and be cached at routers along >the entire path. That is DNS's job, isn't it? >It's a tough problem. And IPv6 is not? Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 10:20:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02893; Tue, 21 Feb 95 10:20:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02882; Tue, 21 Feb 95 10:20:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00928; Tue, 21 Feb 1995 10:12:59 -0800 Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA21482; Tue, 21 Feb 95 10:12:55 PST Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id NAA09576 for ipng@sunroof.Eng.Sun.COM; Tue, 21 Feb 1995 13:12:53 -0500 Date: Tue, 21 Feb 1995 13:12:53 -0500 From: Vadim Antonov Message-Id: <199502211812.NAA09576@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Mike O'Dell wrote: >It is obvious that any multi-homed system can only have one prefix, so >the provider who registered and assigned that prefix can aggregate and >the other providers must carry an explicit announcement. At least one >provider gets to aggregate more completely. This is a win. Not. In general case both providers need to propagate the specific route to the multi-homed addressing domain. >People need to concentrate on the real technical issue here: > flat routing cannot possibly scale. Better put it this way: "Economically viable Internet cannot be built with flat routing." Sure, you can put CM-5s for routing processors and make the flat routing work. >Begin soapbox screed... >I believe that unless we somehow make it possible for ROUTERS to not >have to know every registered system prefix in the universe, the day >is not too far off where we will not be able to afford routers with >enough memory to hold the infomration (assuming you can put multiple >gigabytes on the routers). There's nothing wrong with gigabytes of memory per box -- except for the price. The CPU perfomance is tougher. >If someone wishes to propose an alternate addressing model, they must >also explain how it achieves either significant route compression or >delegation or offer an alternative approach for dealing with route >scaling. My estimates show that the global routing table with the present Internet topology can be reduced to something like 200 entries. Makes it possible to keep the entire forwarding table in associative memory :-) >But for now, provider-based aggregation is the ONLY scheme actually >in-hand which can even make a serious dent in the problem, but as is >obvious, the containment of entropy is less that adequate. BUT FOR >NOW IT'S ALL WE HAVE, unless someone has a miracle in their pocket, >which I'm hoping for, by the way. The problem with provider-based aggregation is purely political. Everybody and his dog is a "provider" nowadays. The address allocation should *not* be expressed in "provider/non-provioder" terms but rather in purely in terms of topology and routing policy. >This means that until and unless the problems can be resolved PURELY >with the routing architecture, then the Addressing and Route >Management problems are inextricably connected. Is there a single person who does not undrstand that yet? >So I believe that we >must pursue a dual path for now - aggressive route compression with >the hope that something like real delegation gets done in time to save >us from the inevitable entropy that will eventually defeat the >compression scheme. There's the third way i keep preaching for -- abandon static address allocation altogether and do dynamic hierarchial address allocation. Sure, you'll have to trash the present DNS and replace it with something doing auto-registration and strong consistency; but if mobility is indeed the requirement it is going to happen anyway. And then, the dynamic address allocation brings the real benefits to end-users, literally allowing zero-administration networking. No more CNEs :-) --vadim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 10:21:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02906; Tue, 21 Feb 95 10:21:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02900; Tue, 21 Feb 95 10:21:23 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01117; Tue, 21 Feb 1995 10:14:22 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA21718; Tue, 21 Feb 95 10:14:09 PST Received: from relay.imsi.com by wintermute.imsi.com id NAA14604; Tue, 21 Feb 1995 13:14:04 -0500 Received: from webster.imsi.com by relay.imsi.com id NAA02737; Tue, 21 Feb 1995 13:14:04 -0500 Received: from localhost by webster.imsi.com (4.1/SMI-4.1) id AA05430; Tue, 21 Feb 95 13:13:59 EST Message-Id: <9502211813.AA05430@webster.imsi.com> To: rgm3@is.chrysler.com (Robert Moskowitz) Cc: rens@imsi.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing In-Reply-To: Your message of "Tue, 21 Feb 1995 12:53:57 CST." <9502211809.AA20920@clncrdv1.is.chrysler.com> Date: Tue, 21 Feb 1995 13:13:58 -0500 From: Rens Troost Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>>>> "Robert" == Robert Moskowitz writes: I'm not sure ipng is the right place to talk about this...I'll be glad to continue this in personal mail if people want to. Robert> Why? I do not see that. The IP address is sufficient. Yes Robert> I am an EID proponent, I have mobile processes, check out Robert> APPN, this is ONE THING IT DOES RIGHT. But EIDs are a Robert> simplifier, not a requirement. I didn't say EIDs were a requirement; I said a separate transport-level address was a requirement. What you propose with DNS is just such an address. An EID is another. Rens> Also, said information would have to propagate and be cached Rens> at routers along the entire path. Robert> That is DNS's job, isn't it? How would this work in practice? Say a packet came in for an address that was unreachable. Would the router do an inverse lookup in the IP6.INT. domain for the address, and then an AAAA lookup on the results of that? Geological time in comparison to usual packet processing times. I guess it could be used to build a redirect cache, but it sure sounds complicated. I'm a proponent of EIDs in theory. Implementation experience needed. -Rens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 11:31:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02986; Tue, 21 Feb 95 11:31:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02980; Tue, 21 Feb 95 11:31:13 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10567; Tue, 21 Feb 1995 11:24:12 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA09546; Tue, 21 Feb 95 11:24:03 PST Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA16658; Tue, 21 Feb 1995 14:23:50 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA30853; Tue, 21 Feb 1995 14:23:46 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA31663; Tue, 21 Feb 1995 13:59:45 -0500 Message-Id: <9502211859.AA31663@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) v6 ICMP message types In-Reply-To: Your message of "Tue, 21 Feb 95 09:44:26 PST." <95Feb21.094432pst.12174@skylark.parc.xerox.com> Date: Tue, 21 Feb 95 13:59:45 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Steve Deering Subject: (IPng) v6 ICMP message types Return-Path: owner-ipng@sunroof2.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reply-To: ipng@sunroof.eng.sun.com The rules for not sending ICMP error messages in response to ICMP error messages requires that implementations have a compiled-in list of which ICMP message types are error messages. That rules out the safe introduction of new ICMP error message types in the future. For the IPv6 version of ICMP, I am thinking of encoding in the message type whether or not the message is an error message, so that a compiled-in list will not be necessary and future error message types can be correctly recognized. Here's a possible encoding of the messages defined in the v6 ICMP spec, using the high-order bit of the message type to identify error messages: 0 - Echo Request 1 - Echo Reply 2 - Node Name Request 3 - Node Name Reply 4 - Group Membership Query 5 - Group Membership Report 6 - Group Membership Termination 128 - Destination Unreachable 129 - Packet Too Big 130 - Time Exceeded 131 - Parameter Problem I'd appreciate comments ASAP, especially from v6 implementors and from author ***s of other specs that define v6 ICMP message types (e.g., Neighbor Discovery). Steve So if TYPE bit 7 = 0 the ICMP message is informational. if bit 7 = 1 the ICMP message is an error message. I like the idea. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 11:31:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02998; Tue, 21 Feb 95 11:31:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02987; Tue, 21 Feb 95 11:31:37 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10612; Tue, 21 Feb 1995 11:24:34 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA09651; Tue, 21 Feb 95 11:24:32 PST Received: by rodan.UU.NET id QQyebt28609; Tue, 21 Feb 1995 14:24:30 -0500 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing In-Reply-To: Your message of "Tue, 21 Feb 1995 11:57:43 CST." <9502211713.AA20423@clncrdv1.is.chrysler.com> Date: Tue, 21 Feb 1995 14:24:30 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob, all, it's obvious that my "obvious" comment wasn't obvious at all...... what I meant was that short of multi-addressing like Bob proposed, if you want to have only one prefix inside a site that is multihomed, then there is only one prefix. 1 == 1 is the obvious part. Bob's multi-addressing proposal is interesting - i'm still not sure what it really buys, but i'm still thinking. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 11:56:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03027; Tue, 21 Feb 95 11:56:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03021; Tue, 21 Feb 95 11:56:20 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13846; Tue, 21 Feb 1995 11:49:18 -0800 Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA14915; Tue, 21 Feb 95 11:49:17 PST Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id OAA10176 for ipng@sunroof.Eng.Sun.COM; Tue, 21 Feb 1995 14:49:14 -0500 Date: Tue, 21 Feb 1995 14:49:14 -0500 From: Vadim Antonov Message-Id: <199502211949.OAA10176@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Mike O'Dell worte: >Bob's multi-addressing proposal is interesting - i'm still not sure >what it really buys, but i'm still thinking. There's a big fundamental problem with the multi-addressing -- the originator of the connection has to choose which address to use and therefore has to make the routing decision. Obviously, to make intelligent desision he needs the knowledge of which path is better, therefore he needs the full routing table. Didn't we already stumble upon that problem with multi-homed hosts? The solution was that there's no solution at all -- so we're stuck with DNS resolvers doing routing decisions. Axiom #1: Hosts don't know anything about the network topology and routing policies (and don't have to). (That kills source-based routing, too). --vadim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 12:07:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03082; Tue, 21 Feb 95 12:07:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03076; Tue, 21 Feb 95 12:07:23 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15259; Tue, 21 Feb 1995 12:00:21 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA17629; Tue, 21 Feb 95 12:00:18 PST Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA05866 for ipng@sunroof.eng.sun.com; Tue, 21 Feb 95 15:00:08 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id MAA19107; Tue, 21 Feb 1995 12:00:08 -0800 Message-Id: <199502212000.MAA19107@aland.bbn.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing In-Reply-To: Your message of Tue, 21 Feb 95 14:49:14 -0500. <199502211949.OAA10176@titan.sprintlink.net> From: Craig Partridge Date: Tue, 21 Feb 95 12:00:06 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Axiom #1: Hosts don't know anything about the network topology and routing policies (and don't have to). Well, except that in IPv4, they know their subnet and net masks, and thus can distinguish between a local network destination and a remote one. Can one (and I haven't dug into the specs) do similar things like match provider prefixes at the host and decide which interface to use based on which provider prefix matches? Should one do this? Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 14:10:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03146; Tue, 21 Feb 95 14:10:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03140; Tue, 21 Feb 95 14:10:12 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00025; Tue, 21 Feb 1995 14:03:09 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA15178; Tue, 21 Feb 95 14:03:08 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA01816; Tue, 21 Feb 95 13:57:32 -0800 Received: by xirtlu.zk3.dec.com; id AA28022; Tue, 21 Feb 1995 16:57:23 -0500 Message-Id: <9502212157.AA28022@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing In-Reply-To: Your message of "Tue, 21 Feb 95 12:00:06 PST." <199502212000.MAA19107@aland.bbn.com> Date: Tue, 21 Feb 95 16:57:16 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Axiom #1: Hosts don't know anything about the network topology > and routing policies (and don't have to). >Well, except that in IPv4, they know their subnet and net masks, and thus >can distinguish between a local network destination and a remote one. >Can one (and I haven't dug into the specs) do similar things like match >provider prefixes at the host and decide which interface to use based on >which provider prefix matches? Should one do this? The way it is right now. We would have a route as in 4.4 passed from transport to ip6_output (just like bsd 4.X). Then that is passed to ifnet routine. Somewhere depending on how / when you want to the code will look at the prefix for the subnet (provided by system discovery/autoconfig) and if not on this destination send to default router or specified router from advertisements. So its not that we (a host) will look at provider or subscriber or other parts of the non-link-local (another decision at XEROX meeting was to call our local-use address link-local) address but at the prefix for this interface to see if its a local xmit of the packet. Now this gets much more complicated when you begin to add transition to the above steps and then you may look at the route entry and determine by the address if its ipv4, ipv6, or ipv4/ipv6 but this is transition stuff and really is not part of the prefix issue. The bottom line is at the infnet you need to know what prefix your using for an interface and we do need to know this on the host. And system discovery will give us that information in the specs presently. So I am happy in this area as an implementor and it is as it should be. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 14:34:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03163; Tue, 21 Feb 95 14:34:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03157; Tue, 21 Feb 95 14:34:43 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02968; Tue, 21 Feb 1995 14:27:39 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA21177; Tue, 21 Feb 95 14:27:21 PST Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA24134; Tue, 21 Feb 1995 17:27:09 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA15878; Tue, 21 Feb 1995 17:27:07 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA32615; Tue, 21 Feb 1995 17:03:06 -0500 Message-Id: <9502212203.AA32615@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) Proxy ARP In-Reply-To: Your message of "Tue, 21 Feb 95 08:53:41 EST." <9502211353.AA29311@itd.nrl.navy.mil> Date: Tue, 21 Feb 95 17:03:05 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Subject: (IPng) Proxy ARP I think that Proxy ARP should either be justified on technical grounds (i.e. a specific statement that it solves some particular described problem and also why no other mechanism solves that problem sufficiently) or it should be removed. With Router Discovery, the primary installed-base use of Proxy ARP was obviated. With IPv6 Discovery, Proxy ARP doesn't solve any problem that can't be solved by the standard mechanisms in Discovery. Ran, I thought that your IPv6 security concerns were answered by my previous mail, and am glad to learn through your message that indeed that is the case. As far as the technical concerns that you still have (security concerns are easy to qualify as "specific", although it does not mean they would not be technical (-: ) I am not sure how the Neighbor Discovery draft would be changed, if you are going to get convinced that they are correct. Furthermore, as far as technical details, it seems that one part of my first message and my last message were somehow left out from your above considerations: As I said in my yesterday message, I think Neighbor Discovery MUST comply with the IPv6 header field definitions from the IPv6 SPecifications - in particulari I have in mind the IPv6 Source Address field. Given the above, I do not see how you can implement 'proxy' with the current Neighbor Discovery, and still comply with the IPv6 specifications. If someone thinks that it IS solving some particular problem that neither Discovery nor any other IPv6 mechanism solves, then please describe on this list in public and in detail -- the problem it solves why neither Discovery nor any other mechanism solves it why Proxy ARP does solve it. The only example so far was of a system with a single network (Ethernet,f or example) tap that acquires a SLIP/PPP link and starts routing packets between that SLIP/PPP link and the Ethernet. My assertion is that Router Discovery provided as part of base IPv6 completely solves that problem. Further, all systems which route packets are routers, not hosts, even though they might be sold initially as workstations... So that example does not make the case that we need to retain Proxy ARP. As I mentioned above (why currently Neighbor Discovery cannot in full compliance with IPv6 Specificatiosn provide full ARP functions), and as I mentioned in my first message (problem that ARP proxy solves): "This (proxy ARP) allows implementing ARP servers on nodes that can be used to resolve the mapping of link-layer addresses to IP v4 addresses for nodes that do not support, or implement ARP, or have for one reason or another the ARP functions disabled." This servers can be used permanently or temporarely. I know for a fact that people use permanent ARP servers - - because they want to have full control of Link-Layer to IP Layer address mapping in one place - the server host. I also know for a fact that people use temporary ARP servers - because temporarely they have hardware or link-layer software that does not function properly, which prevents them from using ARP on particular machine(s), and therefore another machine answers ARP requests on these machine(s) behalf. - because temporarely they have hardware or link-layer software that does not support broadcasting or multicasting, which prevents them from using ARP on particular machine(s)... The above applies to IPv6 Neighbor Discovery. ... On a different note, Ran, you ask for precise details, which I think were given by several people in several messages (already), I would like also to see some precise details in an answer: when continuing to support in a new generation address resolution a certain function of the old generation address resolution, a simple transposition of the old header formats to the new generation would have been enough, WHY IS IT, that it is preffered, as a better solution, a reduction of the old header formats to fewer fields, to the point were to support an old function, there is a need to suggest to mock around with the source field of the IPv6 header? Again, the transposition of the old generation header fields to the IPv6 Neighbor Discovery - the addition of the extensions suggested in my first message - allow implementing all old generation address resolution functions, and does not prevent the existence of any of the new functions that were or will be introduced in IPv6. Even though this is not the unique solution, I would like to hear what is the issue with that. Looking forward to a technical response, Ran atkinson@itd.nrl.navy.mil There is an important non-technical response that Eric Nordmark formulated a couple of days ago, with which I and other in Digital and perhaps other vendors agree because of their own experience: " My experience from being involved with operating system transitions is that you want to be very careful about removing capabilities from your users, especially if there is no direct replacement. If you do remove capabilities that the user base depends on they will delay the transition and they are likely to view the "new" as less functional than the "old". This is largely independent of the "goodness" (technical merits) of the capbilities that are being used." Additionally, also as a non-technical side of the response, I think it is principially wrong, to propose a draft as a standard, for a new generation of address resolution, to be followed by everyone, when it prevents one or more vendors to implements functions that they ask for because they and their customers think or consider useful in the old generation of the address resolution. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 15:45:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03205; Tue, 21 Feb 95 15:45:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03199; Tue, 21 Feb 95 15:45:27 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11000; Tue, 21 Feb 1995 15:38:23 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA05372; Tue, 21 Feb 95 15:38:19 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA14843; Wed, 22 Feb 1995 10:24:56 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA26512; Wed, 22 Feb 95 09:17:33 +1000 Received: by dcthq2.datacraft.com.au; Wed, 22 Feb 95 10:23:21 +1100 Date: Wed, 22 Feb 95 9:55:53 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: (IPng) IPv6 Security Input X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ran, re the doc. I have been involved with DMS X.400 and MSP (SDNS) for a while. One aspect of SDNS is the requirement for Certification Authority which provides key and dig sigs for descrete Distinguished Names as per X.500 and X.509. In SDNS/X.400 each message path is verified at origination and destination by verifying certificates and certification paths. This from a system perspective does create some significant issues eg secure directories, management of keys, sigs, certs and revocation lists. Also the SDNS Message List Agent (for message distribution) requires full support of security based services because it gateways different security domains. (The MLA could be seen as a Secure Distribution / Multicast point in the message distribution. The point I am making is that I do have difficulty with designing network level (or messaging) protocol formats without a system model, when that system model to implement is in the order of 1000? times more complex than the protocol definition. I think saying that the admin of keys, sigs and certs, CRLs, KRLs and directory systems off the agenda is not quite right. I would like to see that the IP6 security is more aligned to SDNS WRT to its system model. Certainly the use of X.500 and X.509 should stated. Because without global names and certificates.... security on a global network does not work. Not having read all the RFCs I may not be aware of already documented work. But not having any reference to X.509/500 in the docs I get concerned. Can I assist in this area at the IETF 32? Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 15:54:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03223; Tue, 21 Feb 95 15:54:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03217; Tue, 21 Feb 95 15:54:36 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12000; Tue, 21 Feb 1995 15:47:32 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AB07370; Tue, 21 Feb 95 15:47:18 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA15909; Wed, 22 Feb 1995 10:46:18 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA26594; Wed, 22 Feb 95 09:38:40 +1000 Received: by dcthq2.datacraft.com.au; Wed, 22 Feb 95 10:44:43 +1100 Date: Wed, 22 Feb 95 10:40:10 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: (IPng) National Registry of Routing is Harmful X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM masataka, national registries are also useful for people who work with national registries and build X.400, X.500, NSAP based networks, carrier numbering plan based networks and register object identifiers for managed objects and document types and all those tiddly things that make consistent IT systems. I think that must be all of us! PS PTTs are being deregulated and WILL have to go to either a national registry or register themselves under ISO/ITU arcs.. see X.660. Alternative.... chaos. Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 16:15:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03246; Tue, 21 Feb 95 16:15:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03240; Tue, 21 Feb 95 16:15:44 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14957; Tue, 21 Feb 1995 16:08:41 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA12046; Tue, 21 Feb 95 16:08:37 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA16778; Wed, 22 Feb 1995 11:08:24 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA26624; Wed, 22 Feb 95 09:57:14 +1000 Received: by dcthq2.datacraft.com.au; Wed, 22 Feb 95 11:03:22 +1100 Date: Wed, 22 Feb 95 10:59:32 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: (IPng) National Registry of Routing is Har mful X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM file note: I switched my service providers a thousand times this month and the thousand bills I recieved was ten times more than if I had stayed with one. Also many of my customers could not contact me and I lost business.. Next month I will go broke! why do people make statements such as: that people will switch providers on a daily basis and this will apply all over the world????? Regards alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 16:31:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03268; Tue, 21 Feb 95 16:31:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03262; Tue, 21 Feb 95 16:31:03 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16855; Tue, 21 Feb 1995 16:23:59 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA15736; Tue, 21 Feb 95 16:23:51 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA17434; Wed, 22 Feb 1995 11:23:25 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA26698; Wed, 22 Feb 95 10:15:45 +1000 Received: by dcthq2.datacraft.com.au; Wed, 22 Feb 95 11:21:53 +1100 Date: Wed, 22 Feb 95 11:15:30 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: (IPng) Provider-based addressing X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=YES Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM begin 600 attach.Z M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C M8\B1)4&&/!G#1DD0-6[(D%$#1DL:,3;&D+&S!D@8&8,*'4JTZ,0Z<^B$D;,1 M`)LW8\*P,4KQ:=2I5+-JWO6>64`4$'39HY(-K484,G#0@T;]H$/`,B MC!LR(.#(>6,G#9DR,7L.`\-5I@"QC47E1N[C?5> M?.[-Q<98]-F'GW]WP"966FNU]59='@]6!<;<\@GAH3PD26? M"#!PZ.%8VHDE%1OJZ96&'=V-=>*,*K(XAY)#E-?>'6,Y!AD:8=@!)HALI0&7 M;)B)]1P>=4%6QGV,[55'6ZR!<*&>;(#PAADVCI4$%#:XIV$9/QAV%XVW@8"= MEI7FM5=??P4F*:5E=:=N:;"1IAQ2U76&6+&5<1Y:=QS$F`(PSE&' M&*[)D<:5@2E(F!)(0:9=6>4M1D<(2A(F!8!+30?"878!\80>"H!E[KGHIJON MNNRVZ^Z[\,8K[[STUFOOO?CFJ^^^_/;K[[\`!RSPP`07;/#!"">L\,(,-^SP MPQ!'+/'$%%=L\<489ZSQQAQW[/''((L\\X\]^SSST`'+?301!=M]-%()ZWTTDPW[?334$ Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03428; Tue, 21 Feb 95 19:15:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03422; Tue, 21 Feb 95 19:14:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02428; Tue, 21 Feb 1995 19:07:49 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA15773; Tue, 21 Feb 95 19:07:49 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 22 Feb 1995 13:07:10 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 22 Feb 1995 13:06:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 22 Feb 1995 14:04:15 +1000 Date: Wed, 22 Feb 1995 14:04:15 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Feb 22 14:04:15 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 150414220295 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <150414220295*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re: (IPng) Proxy ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Additionally, also as a non-technical side of the response, I think it is >principially wrong, to propose a draft as a standard, for a new generation >of address resolution, to be followed by everyone, when it prevents one or >more vendors to implements functions that they ask for because they and their >customers think or consider useful in the old generation of the address >resolution. Yes we have to carry the baggage of the past to weigh down the future. If ARP can be carried out by other mechanisms then how much baggage do we need? Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 21:22:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03931; Tue, 21 Feb 95 21:22:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03925; Tue, 21 Feb 95 21:22:29 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07964; Tue, 21 Feb 1995 21:15:26 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA02047; Tue, 21 Feb 95 21:15:25 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 22 Feb 1995 15:14:58 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 22 Feb 1995 15:14:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 22 Feb 1995 16:13:16 +1000 Date: Wed, 22 Feb 1995 16:13:16 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Feb 22 16:13:15 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 151316220295 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <151316220295*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: re: Re: (IPng) National Registry of Routing is Har mful Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >file note: >I switched my service providers a thousand times this month and the thousand I know that multiple carriers have trunks into major buildings today and the PABX owners have agreements to switch voice services between carriers depending tariffing changes etc. May be once a day/week/month. Depending on how this provider concept works out, the market will be that dynamic. In that case provider switching must be painless. I suppose the issue will be how private networks interact with providers and how private address plans interwork with providers. Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 21 21:54:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03949; Tue, 21 Feb 95 21:54:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03943; Tue, 21 Feb 95 21:54:09 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08996; Tue, 21 Feb 1995 21:47:06 -0800 Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA04656; Tue, 21 Feb 95 21:46:58 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 22 Feb 1995 15:46:13 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 22 Feb 1995 15:43:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 22 Feb 1995 16:40:16 +1000 Date: Wed, 22 Feb 1995 16:40:16 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Feb 22 16:40:15 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 154016220295 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <154016220295*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: re: Re: (IPng) Provider-based addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM You were saying? begin 600 attach.Z M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C M8\B1)4&&/!G#1DD0-6[(D%$#1DL:,3;&D+&S!D@8&8,*'4JTZ,0Z<^B$D;,1 M`)LW8\*P,4KQ:=2I5+-JWO6>64`4$'39HY(-K484,G#0@T;]H$/`,B MC!LR(.#(>6,G#9DR,7L.`\-5I@"QC47E1N[C?5> M?.[-Q<98]-F'GW]WP"966FNU]59='@]6!<;<\@GAH3PD26? M"#!PZ.%8VHDE%1OJZ96&'=V-=>*,*K(XAY)#E-?>'6,Y!AD:8=@!)HALI0&7 M;)B)]1P>=4%6QGV,[55'6ZR!<*&>;(#PAADVCI4$%#:XIV$9/QAV%XVW@8"= MEI7FM5=??P4F*:5E=:=N:;"1IAQ2U76&6+&5<1Y:=QS$F`(PSE&' M&*[)D<:5@2E(F!)(0:9=6>4M1D<(2A(F!8!+30?"878!\80>"H!E[KGHIJON MNNRVZ^Z[\,8K[[STUFOOO?CFJ^^^_/;K[[\`!RSPP`07;/#!"">L\,(,-^SP MPQ!'+/'$%%=L\<489ZSQQAQW[/''((L\\X\]^SSST`'+?301!=M]-%()ZWTTDPW[?334$ Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04021; Wed, 22 Feb 95 01:25:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04015; Wed, 22 Feb 95 01:25:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16113; Wed, 22 Feb 1995 01:18:37 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA26414; Wed, 22 Feb 95 01:18:29 PST Received: by mitsou.inria.fr (8.6.9/8.6.9) id KAA04059; Wed, 22 Feb 1995 10:18:10 +0100 Message-Id: <199502220918.KAA04059@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) v6 ICMP message types In-Reply-To: Your message of "Tue, 21 Feb 1995 09:44:26 PST." <95Feb21.094432pst.12174@skylark.parc.xerox.com> Date: Wed, 22 Feb 1995 10:18:08 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, I understand your desire to separate error reports from basic information functions such as echo or names. But then, we should think a little bit further. Echo requests, as well as name requests, are commonly used by applications. This is very different from the classic ICMP errors, which are triggered in real time by IP packets. In particular, the demux rules of echos are much nearer from those of UDP than from those of ICMP. Separating by a higher bit in the code is a reasonable first step. Using a new protocol type, on the other hand, would allow UDP like demuxing. In fact, I wonder why echo requests or name requests could not be simply carried by UDP, using a well known port number. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 01:44:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04039; Wed, 22 Feb 95 01:44:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04033; Wed, 22 Feb 95 01:44:19 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB16626; Wed, 22 Feb 1995 01:37:17 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA27882; Wed, 22 Feb 95 01:36:50 PST Received: by mitsou.inria.fr (8.6.9/8.6.9) id KAA04091; Wed, 22 Feb 1995 10:36:36 +0100 Message-Id: <199502220936.KAA04091@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing In-Reply-To: Your message of "Tue, 21 Feb 1995 14:49:14 EST." <199502211949.OAA10176@titan.sprintlink.net> Date: Wed, 22 Feb 1995 10:36:35 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Axiom #1: Hosts don't know anything about the network topology > and routing policies (and don't have to). Vadim, You are almost right in practice, surely wrong in theory. A fundamental point of the Internet architecture is that the network should be kept as simple as possible, and that one should not place in it a function that can as well be performed by the hosts. There is no theoretical reason to believe that hosts cannot assess multiple addresses for a partner. For example, they could try them all, meter which one results in the best performance, and pick precisely that one. Granted, this is not implemented yet. But it could be a safe thing to do before launching a very large file transfer. You can find a detailed discussion of a possible solution in . On the other hand, there are many theoretical reasons to believe that the network cannot know in detail which address is best. The main reason is aggregation, which leads to brushing the details away. Another reason is the structure of BGP (or IDRP) which carries administrative preferences rather than plain metrics. Then, the network cannot know which one of two Internet cards just went west, or whether both your radio connection and your Ethernet connection are active. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 02:04:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04064; Wed, 22 Feb 95 02:04:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04058; Wed, 22 Feb 95 02:04:42 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17154; Wed, 22 Feb 1995 01:57:40 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA29274; Wed, 22 Feb 95 01:57:38 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 22 Feb 95 18:56:19 +0900 From: Masataka Ohta Message-Id: <9502220956.AA00392@necom830.cc.titech.ac.jp> Subject: (IPng) Detailed discussion with Jim on Masataka's draft To: ipng@sunroof.Eng.Sun.COM Date: Wed, 22 Feb 95 18:56:16 JST In-Reply-To: <9502210510.AA04229@xirtlu.zk3.dec.com>; from "bound@zk3.dec.com" at Feb 21, 95 12:10 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > # If host identification is controlled by providers, it is difficult to > # change providers or have multiple provider. > > This is true but the Yakov #1 and #2 do not advocate this at all. With Yakov, host identification is controlled by providers. Using ICMP for address->host mapping is no good with reasons I posted to namedropers ML yesterday. > I know several providers and none want to or will do this. Then, we can't use Yakov's scheme. > # The proposal also allows efficient forwarding on routers. > > You never technically or mathamatically prove this at all. It's easy. As IPv6 packet is 8 byte aligned, and not 16 byte aligned, it make processing efficient to split the role of 128bit address at 64bit boudary. > # Anti-trust mechanism for provider ID assignment is also proposed to > # have geographically-near-optimal and least-costly routing with proper > # provider selection. > > This is I think only a U.S. issue and I know not a Europe issue. Is it > an issue in the PAC-RIM area? It's a global issue. Why, do you think, people say geography-based addressing? > #Assignment Plan for IPv6 address > > # The 16 byte IPv6 address is divided into four fields: 5 byte > # "Provider ID", 2 byte "Subscriber ID", 1 byte "Subnet ID" and 8 byte > # "Interface ID". > > # "Provider ID" and "Subscriber ID" together is called "Provider > # dependent part". > > I think you need to give us an idea in a draft of a table showing bits > and bytes and maybe even a matrix of how these addresses will be viewed > Internationally. What? "Internationally"? All the IP address is international, of course. Is it what you are asking? > You also have them fixed which is finite. Yakov #1 > has them variable which provides flexibility in assignment for different > needs. Assigning multiple fixed length chunks for large entities is a lot better than murmuring "variable length" and not defining anything. > # Provider dependent part is supplied by providers and dynamically > # reconfigurable at system boot time or even during operation. It is > # expected that routers to providers supply provider dependent part > # information through anycasting. > > You need to give examples and text of how this will actually work both > with Stateless Address Configuration IPv6 algorithms and I think a > scenario of how it would work with DHCPv6 too. As Yakov's draft does not include such text, I don't have to. Or, do you want to say Yakov's draft is incomplete? > Also you use the term anycasting. I am familiar with the term for the > limited drafts and discussions of the topic in the IETF. Can you > expound on your ideas of anycasting? The ability to contact routers from hosts. > # Interface ID is a globally unique ID of an interface of a host. It > # is supplied by subscribers. The configuration may be automatic. But > # it is expected that renumbering is necessary not so often, in > # general, only when a host is purchased or the host is moved to > # different suborganization of the provider. Host specific information > # such as IP address to host name mapping is looked up only through the > > This is total handwaving. You can't just say Interface ID or Host ID is > globally unique. You can't just say IPv4 address is globally unique. So? > How do subscribers verify that is true? Do you know what "in-addr.arpa." domain is for Ipv4? > You say configurarion can be automatic. Again how does this work with > Statless or DHCPv6 autoconfig being worked on presently? For stateless autoconfig, use MAC for ID. > After our discussion last night I spoke with a colleague about this and > he pointed out that IPv4 host assignment works now. You can have the > same name for all addresses or only one address. I believe someone > would have to convince me the IPv4 model won't work. It also is no > change to the DNS. It seems to me that you are totally confused here. What do you want to say? Are you saying that IID works just as IPv4. > # Interface ID and there is no provider dependence of security. > > You still have not defined it hence as an engineer I have no way of > visualizing how exactly I would implement your notion of an Interface ID > and what it does to my existing IPv4 stack as I do with the present work > in IPv6, (we will have dual stacks lets make it cost effective) or in any > draft including Yakov #1 and #2 (and Hinden Arch Addr spec too) assuming > IPv6. Do you know what "in-addr.arpa." domain is for Ipv4? > # Subnet ID is also supplied by subscribers and identifies a subnet > # within a subscribers LAN. The configuration may be automatic through > # nearest routers. Renumbering is necessary when a location of a host > # is changed to a different subnet. > > Lets suppose your right how does this work with IPv6 System Discovery > processing and will the present formats need extensions? I see no such description in Yakov's draft. > This is > handled auotmatically now in IPv6 and it will work I am saying as an > engineer because I am trying to implement it. Then, it's your job to figure out the detail of how IPv6 System Discovery can cooperate with my scheme. > # Users can change providers at will just by disconnecting one of its > # external routers and connect it to a new provider. > > You have not discussed the how and configuration issues. I did provide a section on configuration issues. > You might have > it in your head but you have not written it down in this draft. I would > like details otherwise its handwaving. I think you should wave your neck and read my draft again. > # Interfaces of a host of a subscriber belonging to multiple providers > # may have multiple provider dependent parts but only a single > # interface ID. > > What if the machines are at different geographical locations like my > organization they cannot have the same Interface ID. What? Why do you think different machines have the same Interface ID? > Unless you want to > define Interface ID better for the community in the draft. I don't call non-unique something ID. > # Routing is controlled purely by the first 8 bytes of IPv6 address: > # "Provider ID", "Subscriber ID" and "Subnet ID" and is more efficient > # than schemes using full 16 bytes. > > This I think would need at least 3 pages of text for you to prove it and > cover all the scenarios. With 64bit CPU, it's too obvious. Even for 128bit ones (or equivalent hardware implementation), the fact that IPv6 packet is 64bit aligned makes it handling of full 128bit address less efficient. Just 3 lines. > # A large subscriber having more than 256 subnets will have multiple > # subscriber IDs from a provider. > > 255 subnets will get broken easy. So? That's exactly why I wrote: > # A large subscriber having more than 256 subnets will have multiple > # subscriber IDs from a provider. > # A large provider having more than 65536 subscriber IDs or having some > # geographical constraints will have multiple provider IDs. > > This is why Yakov made it variable and one of the few times I must agree > with variable anything in the quest for the right answers for IPv6. Not at all. Fixed length chunk just works. > # For geographically-near-optimal routing, a provider ID should not > # cover an area of 100Km radius. Thus, a large provider must use > # different provider IDs for hosts located more than 200Km apart. > # Thus, a subscriber can specify to use a local provider A, then use > # low-rate long-distance-provider B and finally use the provider A who > # is also serving the destination. [Note: It is expected that the > # provider have IX to other providers within the 200Km radius. But > # that's a operational requirement and should be separated from > # assignment policy]. About 17,000 IDs are necessary to cover the > # surface of the Earth. Inter-planetary communication is NOT > # considered here. > > I don't believe the number 17,000 please prove it mathamatically. Haven't you learned mathematics in junior high school? The area of the surface of a sphere (in this case, the Earth) is 4*PI*(radius)^2. The area covered by 100Km radius circle is PI*(100Km)^2. For such rough estimation, you don't have to take spherical geometry into consideration. Now, think. > And I know its more than a simple summation and I think would require > you to give me a series with a differential equation to prove it. You surely need division but I have no idea how you can make use of differential equation. > # Anti-trust mechanism for provider ID assignment is also proposed to > # have geographically-near-optimal routing. > > Again I think this is a U.S. only issue and we need to worry about the > whole earth. The whole earth needs geographically-near-optimal routing. > #Assignment Plan for Interface ID > # > # First three of Interface ID is assigned from IANA to country NICs. > # > # Each country NIC use the next three bytes for independent > # subscribers. > > Now here you want to use NICs ???? Of course. Why not? > #Supporting 10^12 networks and 10^15 hosts > > Show me in bit patterns with the power of 2 clearly labeled in the > graph. What? we are discussing with basis of 10, not 2. > # How the requirement to support 10^12 networks and 10^15 hosts can be > # satisfied? > > # First, how routing between 10^12 networks is possible? 10^3 hosts > # within a subnet can easily be identified by the Interface ID. Thus, > # (Provider ID, Subscriber ID, Subnet ID) must identify 10^12 networks. > # It is not unnatural that a provider, in average, supports at least > # 10^3 subscribers. It can also be safely assumed that subnet ID can > # identify 10^1 subnets. Thus, Provider ID is required to identify > # 10^8 hosts. Considering that the requirement contains 10^2 safety > # factor, the least two significant bytes of the Provider ID are > # reserved for the factor. The remaining 3 bytes (2^24>10^7) are much > # more than enough to identify 10^6 providers. It is assumed that by > # the time we support 10^12 networks, flat routing of 10^6 providers is > # not a problem at all. The reserved lower two bytes of provider ID > # may also be used for two-level routing among providers. > > You have not clearly articulated the relationship to Interface ID here. No, of course. I wrote "routing" at first. > Your figures seem right but with Yakov #2 it has at least as good an address > space. So the gain is what? The gain? It's fixed 8 byte, not something with undefined length. > # Next, how identification of 10^15 hosts is possible? 10^3 hosts of a > # subscriber can easily be identified by the last two bytes of > # Interface ID. For the remaining 10^12 factor, IANA and country NICs > # are expected to manage the upper 6 bytes completely densely. Thus, it > # should be possible to support more than 10^14 networks. > > Yakov #2 avoids all the IANA management you suggest by providing blocks > of addresses according to the space for providers per Hinden-Addr-Arch. With my scheme, it is possible to delegate chunk (not necessarily a contigeous block, which is the difference) of addresses to providers. But, it's not so much necessary. Can you say dynamic DNS? > You have added much more overhead and control by an authority than in > Yakov #1 or #2. No. Unlike Yakov, I removed the providers' control to the authority of identification. > Plus the ideas of registrys make this more manageable. > Registrys also give a geographical hint to the routing policy too in > Yakov #2. You are confusing the roles of routable part and ID part. Provider ID with 100Km locality already gives the hint. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 05:56:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04180; Wed, 22 Feb 95 05:56:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04174; Wed, 22 Feb 95 05:56:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28143; Wed, 22 Feb 1995 05:49:25 -0800 Received: from mulga.cs.mu.OZ.AU by Sun.COM (sun-barr.Sun.COM) id AA20879; Wed, 22 Feb 95 05:49:23 PST Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23354 Thu, 23 Feb 1995 00:49:21 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Addressing plans Date: Thu, 23 Feb 1995 00:47:55 +1100 Message-Id: <5244.793460875@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM People, I'm getting a little tired of all these meaningless provider/geographical tirades, and proofs, and frankly, nonsense. Unless we totally switch routing paradigms - perhaps to something like mo's (and others) suggested route servers, with routers asking something else smarter for routing info when needed - there's only one addressing scheme with which routing will scale, and that's something that as best as its able follows the topology of the actual network. That's the only way that permits routing information to be condensed to a degree that it can support networks of the size we're planning on rational hardware. Now by adding suitable constraints you can label topological addressing as "provider", or "geographical", or something else. Provided you're willing to live with the constraints either of those can work. For provider addressing you have to require that providers be internally connected - that doesn't seem like a big deal, but I don't expect it to happen, I very much expect small(ish) providers to appear serving markets in several areas (say Melbourne, London, and New York), each of those connected to the internet, but not connected to each other (other than via the internet). Such a provider simply cannot have a (single) pool of addresses that are allocated to clients. For geographic addressing you have to constrain the topology of the net so that parts of the net inside one of your defined geographical areas are connected - that I expect to be even less likely. Consider a bunch or providers moving to cover the population of Mexico City, or Brazillia, or something, each with some number of customers in that area, and a link back to their headquarters in LA, or NY, or Lisbon, or Tokyo - with the nets inside Mexico or Brazil not connected at all. Regardless of how easy it is to show that there's plenty of addressing to cover 100 sq km areas, without some kind of non-existant (now) requirement, providers just aren't going to link to everyone else in every geographic area they touch. All we can expect is topographic addressing, which I agree is not easy as long as the topology isn't a tree, which of course, it's nothing like at all. What's worse for the apparent current purpose is that we can't possibly predict what the net topology is going to be like a year from now, let alone when IPv6 becomes widely deployed enough to need any of this addressing (for the forseeable future IPv4 compatability addressing is all that's going to be used). True, this means that we're in no position to start producing detailed addressing plans, but personally I don't see that as a drawback at all - there have been enough drafts, of various kinds, produced to convince me that it can be done when its required to be done. Beyond that its an operational matter. Further, there's no reason at all that, beyond being topologiclaly based, the overall assignment strategy needs to be consistent throughout the net. In some areas the (paying) users can simply tell their providers that if they don't link to other providers in the area, and use a common (geographically based) pool of addresses to cover the area, then they won't get any business. In other areas, probably those covered by less providers, the users may be quite happy with addresses from the provider's pool of numbers, unrelated to geography. What's more we don't need any bits in the address, at all, to say which is which, as no-one (other than the users and providers directly owning them) cares. What is clear, is that as topology neither is, nor ever will be, fixed, we simply have to support addressing changes (or a totally new routing structure). Someone recently said this hasn't been demonstrated yet, and that's true. Personally I think we'd all be much better off if we were all writing code to see if we can make this work, rather than these arguments and counter arguments about addressing plans that are simply not needed now, and won't be for years. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 06:56:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04250; Wed, 22 Feb 95 06:56:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04244; Wed, 22 Feb 95 06:56:52 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00463; Wed, 22 Feb 1995 06:49:49 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA28664; Wed, 22 Feb 95 06:49:50 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA23456; Wed, 22 Feb 95 06:47:10 -0800 Received: by xirtlu.zk3.dec.com; id AA16326; Wed, 22 Feb 1995 09:46:01 -0500 Message-Id: <9502221446.AA16326@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Detailed discussion with Jim on Masataka's draft In-Reply-To: Your message of "Wed, 22 Feb 95 18:56:16 +0200." <9502220956.AA00392@necom830.cc.titech.ac.jp> Date: Wed, 22 Feb 95 09:45:55 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Masakta, No point in continuing this discussion your questions have become rude and insulting. Unacceptable. I do not support your draft nor do I consider it a solution. Others may but I don't. So go convince someone else your scheme will work I am off this thread. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 07:10:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04264; Wed, 22 Feb 95 07:10:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04258; Wed, 22 Feb 95 07:09:54 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01141; Wed, 22 Feb 1995 07:02:51 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA00784; Wed, 22 Feb 95 07:02:51 PST Received: by rodan.UU.NET id QQyeeu26122; Wed, 22 Feb 1995 10:02:43 -0500 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: re: Re: (IPng) National Registry of Routing is Har (fwd) To: Alan.Lloyd@datacraft.com.au Date: Wed, 22 Feb 1995 10:02:43 -0500 (EST) Cc: ipng@sunroof.Eng.Sun.COM X-Mailer: ELM [version 2.4 PL17] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...] >file note: >I switched my service providers a thousand times this month and the thousand >bills I recieved was ten times more than if I had stayed with one. Also many >of my customers could not contact me and I lost business.. Next month I will >go broke! 1000 seems exssave, but 50 may not be. >why do people make statements such as: that people will switch providers on >a daily basis and this will apply all over the world????? While the example is exssave, what if you had service from two providors - one with a uncongested backbone and a per-datagram fee, and another with a flat rate fee, and a backbone that was congested from 11:00am to 2:00pm, and you wish to avoid the congestion and minimise the per datagram charge? That's 2 changes a day, for ~60 changes a month, and if the per-datagram charge is large enough then this is quite possabbly going to happen. What if you have some metered-by-the-minute accounts with a small number of providors via some wireless network, and a notebook with a GPS that changed it's providor every time you got signifigantly closer to one cell then another? Somehow I think our "providor change" mechanisim may be too slow to deal with this. What if you still have the notebook & multiple accounts, but this time you just have it configured to dial a (normal wired modem) to whoever is a local call? What if you have a small number of accounts with dial-up providors that constantly have busy roteries, and you configure your PPP software to dial them round robin when you get a bussy signal? This may be cheeper then getting one account with a providor that has enough modems, or dedicates one to you. And finally, even if someone only changed providors once a year, it would be really nice if there was minimal downtime. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 07:11:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04276; Wed, 22 Feb 95 07:11:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04270; Wed, 22 Feb 95 07:11:51 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01296; Wed, 22 Feb 1995 07:04:48 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA01182; Wed, 22 Feb 95 07:04:46 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA24712; Wed, 22 Feb 95 07:01:48 -0800 Received: by xirtlu.zk3.dec.com; id AA16901; Wed, 22 Feb 1995 10:00:47 -0500 Message-Id: <9502221500.AA16901@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Addressing plans In-Reply-To: Your message of "Thu, 23 Feb 95 00:47:55 +1100." <5244.793460875@munnari.OZ.AU> Date: Wed, 22 Feb 95 10:00:41 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Kre, Your right and I won't contribute to the discussion anymore. I actually stopped writing code because I thought it would go somewhere. I was wrong sorry to eat up everyones mail box with my thoughts that didn't help at all. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 07:12:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04288; Wed, 22 Feb 95 07:12:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04282; Wed, 22 Feb 95 07:12:30 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01344; Wed, 22 Feb 1995 07:05:27 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA01320; Wed, 22 Feb 95 07:05:27 PST Received: from relay.imsi.com by wintermute.imsi.com id KAA18567 for ; Wed, 22 Feb 1995 10:05:26 -0500 Received: from snark.imsi.com by relay.imsi.com id KAA13112 for ; Wed, 22 Feb 1995 10:05:26 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02383; Wed, 22 Feb 95 10:05:07 EST Message-Id: <9502221505.AA02383@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) National Registry of Routing is Har mful In-Reply-To: Your message of "Wed, 22 Feb 1995 10:59:32 +1100." X-Reposting-Policy: redistribute only with permission Date: Wed, 22 Feb 1995 10:05:06 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan.Lloyd@datacraft.com.au says: > file note: > I switched my service providers a thousand times this month and the thousand > bills I recieved was ten times more than if I had stayed with one. Also many > of my customers could not contact me and I lost business.. Next month I will > go broke! > > why do people make statements such as: that people will switch providers on > a daily basis and this will apply all over the world????? Maybe it won't apply all over the world -- countries with antequated telecom structures run by their governments won't be doing this any time soon. I assure you, however, that this will indeed be the case in the US. This isn't even a question of opinion like your quaint affection for ISO standards. As just one example, I know of companies that use their PBX sofware to change long distance carriers on a call by call and hour by hour basis depending on rates. Its easy to do and saves tons of money. Not everyone lives in a country with an antequated telecommunications structure. If you insist, we can argue this out in detail, but you are just plain wrong here. In the long run, companies in first world countries like the U.S. will switch internet carriers the way they switch phone companies now -- routinely. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 07:49:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04323; Wed, 22 Feb 95 07:49:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04317; Wed, 22 Feb 95 07:49:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03430; Wed, 22 Feb 1995 07:42:12 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA08090; Wed, 22 Feb 95 07:42:12 PST Received: from relay.imsi.com by wintermute.imsi.com id KAA18832 for ; Wed, 22 Feb 1995 10:42:11 -0500 Received: from snark.imsi.com by relay.imsi.com id KAA13620 for ; Wed, 22 Feb 1995 10:42:10 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02453; Wed, 22 Feb 95 10:41:51 EST Message-Id: <9502221541.AA02453@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing In-Reply-To: Your message of "Tue, 21 Feb 1995 13:12:53 EST." <199502211812.NAA09576@titan.sprintlink.net> X-Reposting-Policy: redistribute only with permission Date: Wed, 22 Feb 1995 10:41:51 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Vadim Antonov says: > Mike O'Dell wrote: > >People need to concentrate on the real technical issue here: > > > flat routing cannot possibly scale. > > Better put it this way: > > "Economically viable Internet cannot be built with flat routing." Flat routing isn't possible. However, we have to be careful to make sure that our non-flat routing works properly. In particular, the internet exhibits very low levels of locality of communication -- there is no greater reason to assume someone will communicate within their provider than that they would communicate with someone on another provider -- users rarely even know who their counterparty's provider is. There is also no more likelyhood that my email is going to someone in an adjacent state than that it is going to the opposite coast or even another country. The only locality we tend to see is within organizations -- your NFS traffic tends to stay on your lan, and lots of your email stays inside your company. Once you pass the border router all bets are off. My worry here is that we are building a routing system that encourages the construction of network chokepoints -- a treework rather than a network, to quote one person. This could ultimately prove to be a huge obstacle to the future growth of traffic on the net. If 90% of network traffic ends up having to cross small chokepoints we have not done our job properly. > There's the third way i keep preaching for -- abandon static address > allocation altogether and do dynamic hierarchial address allocation. > Sure, you'll have to trash the present DNS and replace it with something > doing auto-registration and strong consistency; but if mobility is > indeed the requirement it is going to happen anyway. I'd love to see a concrete proposal to see how to do this. Sadly, in the absense of an actual detailed proposal its hard to know if it would work. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 08:39:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04355; Wed, 22 Feb 95 08:39:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04349; Wed, 22 Feb 95 08:39:07 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06968; Wed, 22 Feb 1995 08:32:03 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA17306; Wed, 22 Feb 95 08:32:03 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14527(5)>; Wed, 22 Feb 1995 08:31:47 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Wed, 22 Feb 1995 08:31:36 -0800 To: Christian Huitema Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) v6 ICMP message types In-Reply-To: Christian.Huitema's message of Wed, 22 Feb 95 01:18:08 -0800. <199502220918.KAA04059@mitsou.inria.fr> Date: Wed, 22 Feb 1995 08:31:34 PST From: Steve Deering Message-Id: <95Feb22.083136pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian, > Separating by a higher bit in the code is a reasonable first step. Using a > new protocol type, on the other hand, would allow UDP like demuxing. In > fact, I wonder why echo requests or name requests could not be simply > carried by UDP, using a well known port number. This suggestion has come up before on this list. The best arguments I heard for keeping ping (ICMP Echo) as part of ICMP were: (1) It makes it more likely that every node will in fact include support for a ping responder, because ICMP is a mandatory part of every IP implementation and the ping responder code is trivial to include while writing the code to handle the other types of ICMP messages. (2) That's the way it's done in IPv4 and it's not so broken as to be worth all the arguments that would come up if we tried to change it. If we were starting from a clean slate, rather than doing a new version of an existing protocol with a large installed base of "current practice", I'd probably argue in favor of an XNS-like demuxing mechanism, where the ports are considered part of the addresses, so hosts demux first on port number and then on packet type (TCP/UDP/error/etc.). But we're not starting from a clean slate. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 08:54:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04375; Wed, 22 Feb 95 08:54:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04369; Wed, 22 Feb 95 08:54:00 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08364; Wed, 22 Feb 1995 08:46:57 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA20453; Wed, 22 Feb 95 08:46:54 PST Received: by mitsou.inria.fr (8.6.9/8.6.9) id RAA05100; Wed, 22 Feb 1995 17:46:18 +0100 Message-Id: <199502221646.RAA05100@mitsou.inria.fr> To: Steve Deering Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) v6 ICMP message types In-Reply-To: Your message of "Wed, 22 Feb 1995 08:31:34 PST." <95Feb22.083136pst.12174@skylark.parc.xerox.com> Date: Wed, 22 Feb 1995 17:46:16 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > But we're not starting from a clean slate. So be it... Let's at least apply your fix, and make sure that we can do easy demuxing at the client sites. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 09:57:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04436; Wed, 22 Feb 95 09:57:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04430; Wed, 22 Feb 95 09:57:13 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16111; Wed, 22 Feb 1995 09:50:06 -0800 Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA01286; Wed, 22 Feb 95 09:49:58 PST Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id MAA12714 for ipng@sunroof.Eng.Sun.COM; Wed, 22 Feb 1995 12:49:12 -0500 Date: Wed, 22 Feb 1995 12:49:12 -0500 From: Vadim Antonov Message-Id: <199502221749.MAA12714@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian Huitema wrote: avg> Axiom #1: Hosts don't know anything about the network topology avg> and routing policies (and don't have to). >You are almost right in practice, surely wrong in theory. I suppose we're not building theoretical networks? :-) >A fundamental point >of the Internet architecture is that the network should be kept as simple as >possible, and that one should not place in it a function that can as well be >performed by the hosts. Well... There's a way to keep gateways simple and still not burden hosts with forwarding decisions (except, of course, the case of multiple gateways off the LAN). I understand the principle a bit differently: there should be a clear separation of functions between the network and hosts; i.e. network should deliver datagrams to the destination in the way it thinks the best (from the network's point of view) and hosts should do transport level not assuming anything from the network except that it somehow sometimes deliver the datagrams. The only place where the principle is not applied is the cooperative congestion control (i.e. the network expects some behaviour from "well-behaved" hosts). >There is no theoretical reason to believe that hosts cannot assess multiple >addresses for a partner. Sure, as there is no theoretical reason to avoid keeping the complete map of Internet in each host. >For example, they could try them all, meter which one >results in the best performance, and pick precisely that one. Granted, this is >not implemented yet. Gak, gak, what a disgusting hack! :-) >But it could be a safe thing to do before launching a >very large file transfer. You can find a detailed discussion of a possible >solution in . >On the other hand, there are many theoretical reasons to believe that the >network cannot know in detail which address is best. The main reason is >aggregation, which leads to brushing the details away. With the present network topology (which is not going to change radically any time soon) you can do very significant aggregation while still maintaining optimal routing. Compression of information can (and should) be done in a way which does not affect routing decisions. It is not practical with manually configured aggregation but there's a simple method to do automatic aggregation _if_ addresses are allocated in a proper way. >Another reason is the >structure of BGP (or IDRP) which carries administrative preferences rather >than plain metrics. >From the point of view of network administrator the best path is the one which has the lowest administrative metric (and conforms to the routing policy). There are different reasons to prefer paths which are not "optimal" in a sense of some physical metric, primarily because the administrative metrics are composites of physical networks *and* routing policies. BGP (and for that matter IDRP) aren't the gospel :-) I asked Yakov to consider adding a real metric to BGP (better yet, a vector of per-hop metrics, allowing the netadmins to calculate the weighted sums). Right now there is a global BGP metric called "as path length", and it is used extensively. To fool it we asked cisco people (Paul, Ravi and Tony) to add a knob to insert additional as numbers into the path; and now we use that kludge so extensively that a major part of Sprint's routing policy depends on it. What was not mentioned there is that allowing end-hosts to make routing decisions (particularly by using source routing) violates the right of network service providers to use the policies they want to (and they _own_ the networks). Essentially, making hosts to make routing decisions violates the property rights of network operators, so i do not think any proposal which assumes that will ever find support from network operators (and support from network operators is what differentiates the dead technologies from what is going to be deployed and used; because it is network operators who is making decisions where to invest money in the network infrastructure). The Internet is 90% politics :-) --vadim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 10:22:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04481; Wed, 22 Feb 95 10:22:50 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04475; Wed, 22 Feb 95 10:22:42 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id KAA09048; Wed, 22 Feb 1995 10:15:17 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id KAA23023; Wed, 22 Feb 1995 10:15:13 -0800 Date: Wed, 22 Feb 1995 10:15:13 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199502221815.KAA23023@elrond.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng) requirements for the IPv6 security I-Ds Cc: atkinson@itd.nrl.navy.mil, nessett@jurassic X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, Some time ago I sent email to this list raising some questions about what exactly we are trying to accomplish with the security headers in IPv6. I also attended the Palo Alto meeting in an attempt to raise these issues, but we didn't cover the security drafts there, since Ran Atkinson was unable to attend and since the revised I-Ds were not yet available. Let me try again in a somewhat more iterative manner. The first question that, I believe, needs to be raised is whether ICMP messages require security protection? I think most believe that they do (Scott Bradner specifically said they do at the Palo Alto meeting, but others may disagree). If they do require protection, the next question that comes to my mind is whether only end-to-end ICMP messages require protection or do ICMP messages from intermediate routers as well? For example, Bill Simpson has stated to me that only end-to-end ICMP messages require protection. The example he gave was the remote redirect message (which can come only from the remote host). However, some may believe that ICMP messages such as destination unreachable, or packet too big may also require security protection (at least an authentication/integrity check) to avoid denial of service attacks. What is the view of the community? Regards, Dan Nessett ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 10:33:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04493; Wed, 22 Feb 95 10:33:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04487; Wed, 22 Feb 95 10:32:51 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20728; Wed, 22 Feb 1995 10:25:44 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA08275; Wed, 22 Feb 95 10:25:43 PST From: Ran Atkinson Message-Id: <9502221323.ZM6717@bodhi> Date: Wed, 22 Feb 1995 13:23:07 -0500 X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Proxy ARP Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alex, Thanks for your detailed note. It was most helpful in understanding better where you are coming from. I disagree with your belief that Proxy ARP is, itself, a user feature. I believe that "Address Resolution" is the user feature and that Proxy ARP was a method of providing that feature in IPv4 prior to Router Discovery and prior to IPv6 Discovery. That user feature is very important, but is already provided for by IPv6 Neighbor Discovery. Proxy ARP is and remains a well-known security hole because it lets arbitrary systems reply to an ARP request. With Discovery as an ICMP function, a host desiring link address resolution can verify the response as being from the target host itself via the DNS key management infrastructure (or manual key distribution, which is very practical since neighbor discovery is a link-oriented function) being done by Eastlake-Kaufman in conjunction with the IPv6 Authentication Header. A Proxy response cannot be trusted even if authenticated because the authentication provided is only of the form "this sender did send this packet" not of the form "this sender sent this packet and is the legitimate resolution server for your target". If we have the case of hosts not on the local subnet, then under IPv6 all hosts will use Router Discovery to find a plausible next-hop router. In the case of a system which is forwarding packets between some LAN connection and one or more SLIP/PPP connections, that system is a router and must implement and use the router part of Router Discovery. The other case you describe has to do with systems that do not have link-layer hardware correctly supporting broadcast/multicast. Such systems cannot be made IPv6 compliant, even if a Proxy ARP mechanism were defined. So, I don't see a case for reinstating Proxy ARP into IPv6 as a full-fledged function. I also note that several old-timers with much real-world operational experience share this view and have always referred to Proxy ARP as a "hack". No user feature is removed by this, so your concerns about OS transitions appear to be misplaced in this particular instance. Regards, Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 10:36:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04508; Wed, 22 Feb 95 10:36:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04502; Wed, 22 Feb 95 10:36:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21167; Wed, 22 Feb 1995 10:28:55 -0800 Received: from CLYNN.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA08929; Wed, 22 Feb 95 10:28:49 PST Message-Id: <9502221828.AA08929@Sun.COM> Date: Wed, 22 Feb 95 11:48:53 EST From: Charles Lynn To: ipng@sunroof.Eng.Sun.COM Cc: CLynn@BBN.COM Subject: Re: (IPng) IPv6 Security drafts Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, A few comments on the security, authentication, and ESP drafts. I would like to see a STRONG statement that ESP "Transport-mode" means ANY IP Protocol that a box implements, not just TCP, UDP, and ICMP. There are many references to "TCP" and "UDP" throughout the security drafts that I would like generalized something like "IP Protocol". In fact, why are there two ESP modes? Isn't IP-Mode just a special case of Transport-mode when the transport-level protocol is IP-in-IP encapsulation, IP Protocol 94? It seems to me that a single mode with additional text saying that when an entire IP packet (for ANY IP Version that a box implements) is to be included in the Protected Data field, that the ESP Next Header field should contain 94. Is there any reason why "IP in IP (encasulation)", IP Protocol 4, MUST NOT be used in the ESP Next Header field to achieve the same effect? I.e., that IP Multicast tunnels would need three IP headers (IPv6 Clear, (ESP/94), IPv6 Cypher, (Transport/4), IPv6 Multicast Cypher) when using ESP. Since the sec draft contains a lot from the other two, comments on one draft may be applicable to another. ------------------------------------------------------------------------------ draft-atkinson-ipng-sec-01.txt dated 15 February 1995 The specifications does not say much about end-system to intermediate system authentication (as opposed to intermediate system verification of end-to-end authentication). Is seems likely that a different (assymetric?) key might be used for the two cases. Previously, Steve Deering suggested that a hop-by-hop authentication option could be added to support this service. It could be used, for example, to validate setup messages (that may or may not carry piggybacked end-to-end messages). Would it make sense to add text to this effect to the sec draft? It seems that there may be more than just header fields that change during transit. Flowspec fields are one example that comes to mind. They may contain end-system requirements/authorizations, such as maximum delay and cost, that should be authenticated, as well as cumulative fields, such as estimated delay, cost, loss, etc., that cannot be. Does the security architecture require that these fields be moved up into some yet to be defined hop-by-hop header option so that they can be skipped, or that the AH code be made aware of higher level/"transport" protocols' variable fields? page 3-4 | for its IPv6 datagram. This authentication information is calculated | using all of the fields in the IPv6 datagram which do not change | during transit from the originator to the recipient. All IPv6 | headers, payloads, and the user data are included in this calculation. | The only exception is that fields which need to change in transit (e.g. | IPv6 Header's "Hop Count" or the IPv6 Routing Header's "Next Address") | are omitted when the authentication data is calculated. Why is the IPv6 Routing Header's "Next Addr" (or ERP's NextHopPtr) field special cased? Note that page 6 of draft-atkinson-ipng-auth-01.txt states: | The sender MUST compute the authentication over the packet as it | will appear at the receiver. This requirement is placed in order to | allow for future IPv6 optional headers which the receiver might not | know about but the sender necessarily knows about if it is including | such options in the packet. The sender places the calculated message so it would seem to cover the Routing Header case as well. Also, note there would be an extensibility issue as the pointer field position/size may vary between different Routing Header versions. What mechanism(s) are to be used to incorporate additional IP extension headers that have fields that change in transit? Since the IETF standardizes protocols, not implementations, we probably cannot dictate, e.g., some table that says for IP Protocol N, Version V, fields from bit m1 through l1, ..., mk through lk, should be set to zero. Is there anything that we can require? In the End-to-end case, it might be easy when adding those extension headers/protocols to modify the AH code directly to skip fields that change. This assumes that source to a vendor's AH code is available, or that a freely available replacement is. Has anyone analyzed the security consequences of "various parties" modifying AH code in a box? Would anybody trust that the modified code to be as error free as the vendor's original code? Even this would not work for end-system to intermediate system authentication as I suspect it would be very hard for an end-user to modify code in an intermediate system. page 4 | 3.2 | datagrams. [Atk94b] It does this by encapsulating either an entire | IPv6 datagram or only the upper-layer protocol data inside the ESP, | encrypting most of the ESP contents, and then appending a new | 3.2.1 Description of the ESP Modes | There are two modes within ESP. The first mode, which is known as | IP-mode, encapsulates and entire IP datagram within the ESP header. | The second mode, which is known as Transport-mode, encapsulates either | a UDP or TCP frame inside IP. See comments at the beginning of this message. page 5 | 3.2.2 Usage of ESP | network segments. When both hosts directly implement ESP and there is | no intervening security gateway, then they may use the Transport-mode | (where only the upper layer protocol data (e.g. TCP or UDP) is | encrypted and there is no encrypted IPv6 header). This mode reduces See comments at the beginning of this message. page 9 | 5.1 USE WITH FIREWALLS | Firewalls used with IPv6 will need to be able to parse the header | daisy-chain to determine the transport protocol (e.g. UDP or TCP) in | use and the port number for that protocol. Firewall performance | should not be significantly affected by use of IPv6 because the header | format rules in IPv6 make parsing easy and fast. Maybe for AH, but if one can find the transport protocol & port numbers with ESP, something is broken. This suggests that vendors might want some way indicate an ESP header in their filter language. The problem should be noted in the text. page 12 | 6. SECURITY CONSIDERATIONS | consult the RFCs describing the Internet's Privacy-Enhanced Mail | system. I would include references to RFCs 1421, 1422, 1423, 1424. ------------------------------------------------------------------------------ draft-atkinson-ipng-auth-01.txt dated 14 February 1995 In addition to above comments, page 2 | headers and the user data) which do not change in transit. Fields | which need to change in transit (e.g "hop count" or "routing pointer") | are omitted from the calculation of the authentication data. This See comments on the routing pointer above, and remove it here. page 4, change | +-------------+-------------------------+--------------+---------+---------+ | | IPv6 Header | Routing/Hop-by-Hop Hdrs | Auth Header | E2E Hdr | TCP/UDP | | +-------------+-------------------------+--------------+---------+---------+ | The IPv6 Header is the conventional IPv6 Header defined by others in to +-------------+-------------------------+-----------+---------+-----------+ | IPv6 Header | Hop-by-Hop/Routing Hdrs | Auth Hdr | E2E Hdr | Transport | +-------------+-------------------------+-----------+---------+-----------+ The IPv6 Header is the conventional IPv6 Header defined in page 5 | SECURITY ASSOCIATION IDENTIFIER (SAID) | By having the destination select the SAID value, there is no potential | for manually configured security associations to have SAID values that | conflict with automatically configured (e.g. via a key management | protocol) security associations. This implies that dynamic methods have access to all SAIDs allocated, and a mechanism to allow additional manual SAIDs to be allocated while dynamic are active. Right? | AUTHENTICATION DATA | This data carried in this field is variable length, but the field ---- -> The page 6 | 4. CALCULATION OF THE AUTHENTICATION DATA | of the IPv6 datagram in sequence. Fields which will necessarily vary | in transit from the sender to the receiver (e.g. Hop Count) are | included in the calculation but the value zero is substituted for the | actual value of such fields in the IPv6 packet. This substitution of page 7 | Not all of the fields of the IPv6 Hop-by-Hop Options header are ... | calculation. If the particular option is to be omitted, that option | is skipped over during the authentication calculation as if it were | not present. Because of this bit encoding, an implementation can "skipped over" is ambiguous, to me, and seems weaker than necessary. Are other options repacked? Including any "transport" headers/data? Skipping seems to break any alignment that existed for the rest of the packet. Or does "skipped over" mean that the options are zeroed? Either means that the receiver cannot tell what options were present. How about leaving the Option Type and Option Data Length fields intact and just zeroing the data area? | 5. CONFORMANCE REQUIREMENTS | RISC processor with slightly tuned MD5 code. This possibly too slow ^-- "is" page 12 | APPENDIX A: USE OF KEYED MD5 WITH THE IPv6 Authentication Header | the authentication calculation. For the purposes of the calculation, | the Authentication Data field of the IPv6 Authentication Payload is | considered to contain all zeros. Because MD5's output is naturally Would this be true for any algorithm? If so, should be stated in section 4. ------------------------------------------------------------------------------ draft-atkinson-ipng-esp-0a.txt dated 14 February 1995 page 4 | +-------------+--------------------+-----------------+----------------+ | | Next Header | Header Length | Reserved | | +-------------+--------------------+-----------------+----------------+ | | Protected data (either an entire IPv6 datagram | | | or a UDP frame or a TCP frame), variable length | | +-------------+--------------------+-----------------+----------------+ No IP version number, i.e., "entire IPv6 datagram" to "entire IP datagram" -- look at the IP version bits in the IP header and change "a UDP frame or a TCP frame" to "any IP Protocol frame". | 3.1 CLEARTEXT FIELDS | The IPv6 Header is the conventional IPv6 Header defined by others in to The IPv6 Header is the conventional IPv6 Header defined in | SECURITY ASSOCIATION IDENTIFIER (SAID) | will normally have two SAIDs in use (one in each direction). The | receiving host uses the combination of SAID value and originating | address to distinguish the correct association. An ESP implementation Motivation for "originating address" is missing. Since the receiving host (hosts for multicast) picks the SAID value, what does use of originating address provide? Trying to allow multiple senders to a multicast address have separate parameters but a common SAID? (The next paragraphs discuss common SAID for all sources with same parameters (key) & separate SAID per sender.) page 5 | start of the encrypted portion of the ESP (if no such field is | present, then the size is of course zero). The size quantity in not a header field -- "Header Length" is. | NEXT HEADER | This field contains the value indicating which header follows the | ESP Encrypted Fields. For example, if an entire IP datagram follows, | the field will contain the number 94, which has been allocated by IANA | to indicate IP-in-IP encapsulation. [STD-2] See comment at beginning about IP Protocol 4. pages 5-6 | HEADER LENGTH | This field is contains the length of the set of encrypted ESP fields | (i.e. Next Header, Header Length, Reserved) minus the 8 byte minimum | length. The minimum length is 64-bit aligned to comply with normal | IPv6 alignment rules. If I read this correctly, there is only 32-bit alignment of the Encrypted Data with respect to the IPv6 Header. Also, due to the "minus 8", there are at least 4 bytes of ?zeros? after Reserved when, e.g., Header Length is zero. The length does not include any padding as mentioned in the last paragraphs of APPENDIX A, and section 3.2: | If it is necessary to pad the protected data (e.g. to an integral | block-size of the cryptographic algorithm in use), then the normal | IPv6 Padding header is used to provide that padding. This means that | ESP will not work with block-oriented algorithms whose block size is | not an integral number of 8-bit bytes. I do not understand this well enough to implement it; see example at the end of this message. Does this mean that the padding is only there for the computation, and not in the transmitted packet? (If so, it seems like a lot of work to cut/pad/splice bytes into the crypto unit.) If the pad is transmitted (possible MTU interactions here), seems to require a copy of the protected data after decrypting to get things aligned for subsequent processing. Neither seems better than the proposal at San Jose. page 6 | frame inside ESP. These terms should not be misconstrued as | restrictive, for example an ICMP/IGMP message might be sent either | using the "Transport-mode" or the "IP-mode" depending upon | circumstance. This section describes protocol processing for each of | these two modes. Is there a requirement, maybe in some other draft, that will make it clear whether, e.g., the ICMP message is an IPv4 ICMP message or an IPv6 ICMP message. It looks like the ICMP Type values overlap, so they could not be used to differentiate; a BAD IDEA, IMHO. page 7 | payload. If strict red/black separation is being enforced, then the Aren't the terms "red" and "black" being depreciated? | The sender takes the original UDP or TCP or ICMP frame, encapsulates ... any "transport" | appropriate key for the combination of sending userid and receiving "sending userid" is not defined. Is this text only for key per user mode, or for key per host mode as well? page 10 | and external systems. A gateway which receives a datagram containing | a recognised sensitivity label from a trusted host should take that | label's value into consideration when creating/selecting an SAID for | use with ESP between the gateway and the external destination. In ... | forwards to the trusted host that is the ultimate destination. The | IPv6 Authentication Header should always be used on packets containing | explicit sensitivity labels to ensure end-to-end label integrity. How is a sensitivity label communicated between the host and a security gateway in IPv6? Is it via some IPv6 End-to-End Option? Should some RFC/internet-draft be referenced here? page 14 | APPENDIX A: Use of CBC-Mode DES with IPv6 ESP | The length of the octet sequence to be encrypted by the DES | algorithm must be an integral multiple of 8. When encrypting, any | needed padding shall be included by using a IPv6 hop-by-hop padding | option. When the Transport-mode of ESP is used, such padding must | appear between the encrypted ESP header fields and the start of the | UDP or TCP data. If the length of the octet sequence to be decrypted Where does the padding appear in IP-mode? A diagram would be useful, both here and in the main text. I still do not understand how to implement padding. Using the proposed IPv6 ICMP Types in Steve Deering's message of Tue, 21 Feb 1995 09:44:26 PST, for an ICMP Echo Reply containing 10 bytes of data, is the following correct? +---------------+---------------+---------------+---------------+ | Security Association Identifier (SAID), 32 bits | +---------------+---------------+---------------+---------------+ | Syncronisation Data, first 32 bits | +---------------+---------------+---------------+---------------+ | Syncronisation Data, last 32 bits | +===============+===============+===============+===============+ | 1 - ICMP | 0 | 0 | 0 | +---------------+---------------+---------------+---------------+ | 0 | 0 | 0 | 0 | +---------------+---------------+---------------+---------------+ | 1 - Pad | 0 | 1 - Echo Reply| 0 - Code | +---------------+---------------+---------------+---------------+ | Checksum | Identifier | +---------------+---------------+---------------+---------------+ | Sequence Number | 10 bytes Data ... | +---------------+---------------+---------------+---------------+ | ... | +---------------+---------------+---------------+---------------+ | ... | +---------------+---------------+---------------+---------------+ If not, what have I misunderstood? If so, how can the receiver tell that the pad option is there and it isn't really an ICMP Echo Reply message with 12 bytes of data, i.e., +===============+===============+===============+===============+ | 1 - ICMP | 0 | 0 | 0 | +---------------+---------------+---------------+---------------+ | 0 | 0 | 0 | 0 | +---------------+---------------+---------------+---------------+ | 1 - Echo Reply| 0 - Code | Checksum = 0x0100 | +---------------+---------------+---------------+---------------+ | Identifier | Sequence Number | +---------------+---------------+---------------+---------------+ | 12 bytes Data ... | +---------------+---------------+---------------+---------------+ | ... | +---------------+---------------+---------------+---------------+ | ... | +---------------+---------------+---------------+---------------+ Note that for a TCP example, the 32-bit natural alignment assumed by a lot of deployed code on RISC processors will not be happy when accessing the sequence number and ack fields, etc. I do not think that padding between the ESP header and the data to be protected is a good idea. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 11:24:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04606; Wed, 22 Feb 95 11:24:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04600; Wed, 22 Feb 95 11:24:41 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27935; Wed, 22 Feb 1995 11:17:36 -0800 Received: from tiny.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA18166; Wed, 22 Feb 95 11:11:17 PST Received: from titan.sprintlink.net (titan.sprintlink.net [199.0.55.78]) by tiny.sprintlink.net (8.6.9/8.6.9) with ESMTP id OAA11348 for ; Wed, 22 Feb 1995 14:07:59 -0500 Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id OAA13182 for ipng@sunroof.Eng.Sun.COM; Wed, 22 Feb 1995 14:06:39 -0500 Date: Wed, 22 Feb 1995 14:06:39 -0500 From: Vadim Antonov Message-Id: <199502221906.OAA13182@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry E. Metzger wrote: >Flat routing isn't possible. Tell that to the people who are doing cellular telephony. Do not forget that the Internet is not the largest network out there and we have a lot to learn from the telephony. >My worry here is that we are building a routing system that encourages >the construction of network chokepoints -- a treework rather than a >network, to quote one person. This could ultimately prove to be a huge >obstacle to the future growth of traffic on the net. If 90% of network >traffic ends up having to cross small chokepoints we have not done our >job properly. Well, i do not see it to be a problem as long as we don't concentrate lots of small service providers at exchange points. If small service providers are reaching exchange points through large (nation- or word-wide service prividers) those large providers can achieve very high level of aggregation w/o sacrificing optimality of routing. It is very much like what SprintLink is doing now -- by using one-per-POP geographical CIDR blocks and aggregating 6500+ networks into some 24 routes (could be only 6 if InterNIC allocated bigger blocks at a time). avg> There's the third way i keep preaching for -- abandon static address avg> allocation altogether and do dynamic hierarchial address allocation.a avg> Sure, you'll have to trash the present DNS and replace it with something avg> doing auto-registration and strong consistency; but if mobility is avg> indeed the requirement it is going to happen anyway. >I'd love to see a concrete proposal to see how to do this. Sadly, in >the absense of an actual detailed proposal its hard to know if it >would work. I'm writing a series of drafts covering more-less everything from IP datagram format to DNSng and the routing protocol right now. Unfortunately i can't do it fast (in my copious free time left after many worries of running one of the largest networks...), but i have the overview paper nearly completed. When i feel that i made it readable enough (English is not my native language) i'll put in on Sprint's FTP server. --vadim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 11:30:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04622; Wed, 22 Feb 95 11:30:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04616; Wed, 22 Feb 95 11:29:56 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28656; Wed, 22 Feb 1995 11:22:52 -0800 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by Sun.COM (sun-barr.Sun.COM) id AA21362; Wed, 22 Feb 95 11:22:43 PST Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14723; Wed, 22 Feb 95 11:21:49 EST Date: Wed, 22 Feb 95 11:21:49 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9502221621.AA14723@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) key mgmt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan Lloyd, SDNS is known to be broken for Internet use in places. It was less broken before ISO got their hands on it, but ISO's NLSP made things worse (e.g. the NLSP spec is MUCH less readable than SP3D was). The IETF has previously made an explicit decision not to just reuse SDNS for various reasons, including because it is not a good solution to our problem. That decision was made by other working groups prior to the existence of the IPng working group. Further, we tried X.509 certificates and found that they aren't practical either. The dependence of PEM on X.509 is one reason that PEM is not yet widespread. We don't plan to repeat that mistake either. I have been told by IESG members that X.509 is NOT in the plans for the future Internet because of our strongly negative experience to date. The Internet key management problem is easily addressed in a scalable manner and that work IS underway, but in a different working group under the Security Area, which is as it should be. The plan is very simple: 1) Put signed keys (which are NOT X.509 certificates) into the DNS in a manner consistent with the DNS using the technique developed by Eastlake-Kaufman. I believe that proposal will be a standards- track RFC soon if it isn't already (the WG appeared to have consensus on this in San Jose but someone would need to ask the chair for an official read on consensus). There is at least an I-D available on the Eastlake-Kaufman proposal. 2) Use a Diffie-Hellman protocol to generate and distribute unicast session keys. This protocol should use the DNS keys to bootstrap authentically into the D-H exchange and thereby obviate the man- in-the-middle attack. See draft-karn-photuris-00.txt for the December version of a draft describing a protocol of this genre. Phil Karn is doing a good job of developing this protocol within the appropriate working group within the Security Area. There is no value in IPv6 doing key management differently than other protocols will do it. There is much value in reusing the same key management infrastructure. So, for IPv6 we plan to reuse the good work under development within the Security Area of the IETF. Ran atkinson@Itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 13:05:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04779; Wed, 22 Feb 95 13:05:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04773; Wed, 22 Feb 95 13:05:37 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09835; Wed, 22 Feb 1995 12:58:31 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA17513; Wed, 22 Feb 95 12:57:35 PST Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA11892; Wed, 22 Feb 1995 15:57:26 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA20659; Wed, 22 Feb 1995 15:57:22 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA00491; Wed, 22 Feb 1995 15:33:20 -0500 Message-Id: <9502222033.AA00491@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) Proxy ARP In-Reply-To: Your message of "Wed, 22 Feb 95 13:23:07 EST." <9502221323.ZM6717@bodhi> Date: Wed, 22 Feb 95 15:33:20 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Ran Atkinson Subject: (IPng) Proxy ARP Alex, I disagree with your belief that Proxy ARP is, itself, a user feature. I believe that "Address Resolution" is the user feature and that Proxy ARP was a method of providing that feature in IPv4 prior to Router Discovery and prior to IPv6 Discovery. Ran, I said repeatedly that Proxy ARP is a function of IPv4 address resolution, and if implemented it is a feature of the networking software that a user or many user may indirectly take advantage of. Let's not get bogged down in meaningless interpretations... ...That user feature is very important, but is already provided for by IPv6 Neighbor Discovery. In reference to the proxy use cases I mentioned, you seem to ignore the issue of Neighbor Discovery compliance with the IPv6 specifications, or perhaps you support the idea of originating packets with source addresses that do not belong to the originator host? ... A Proxy response cannot be trusted even if authenticated because the authentication provided is only of the form "this sender did send this packet" not of the form "this sender sent this packet and is the legitimate resolution server for your target". I thought there is more to IPv6 security than authentication. Can't proxy be secured further if needed? I thought it did, and that we agreed on that. Furthermore, security is an argument only to those environments where it applies or is desired. None of those that I was talking about it was a real issue. ... router discovery... I didn't have a problem with cases in which router discovery applies. The other case you describe has to do with systems that do not have link-layer hardware correctly supporting broadcast/multicast. You seem to have missed or ignored other cases. ....Such systems cannot be made IPv6 compliant, even if a Proxy ARP mechanism were defined. This is a weak argument to me because as we learned with IPv4 and others, compliance is asymptotic. Sounds to me like a car designer saying that the new designed car cannot ride with a spare tire. If the only use of broadcasting/multicasting in a host is for Neighbor Discovery, with proxy, one host could be used for IPv6 networking, until software or hardware is fixed or upgraded. And no user that counts the money spent on networking would dislike this. On the opposite... (I am sorry, I don't mean to say that because you are at NRL you do not count the money, you most likely do, but probably didn't face this problem as others did...) So, I don't see a case for reinstating Proxy ARP into IPv6 as a full-fledged function. I do not see a good case for not supporting it, in particular because it does not cost anything or affect any of the other IPv6 Discovery features. I also note that several old-timers with much real-world operational experience share this view and have always referred to Proxy ARP as a "hack". No user feature is removed by this, so your concerns about OS transitions appear to be misplaced in this particular instance. Regards, Ran atkinson@itd.nrl.navy.mil But you ignore the several old-timers with real-world vendor and customer experience that expressed their view too, that it is ultimatley a feature of the system networking software that can affect positively one user, or many users, as known from the real-world of vendors and customers. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 13:07:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04791; Wed, 22 Feb 95 13:07:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04785; Wed, 22 Feb 95 13:06:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10049; Wed, 22 Feb 1995 12:59:47 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA17955; Wed, 22 Feb 95 12:59:04 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14421(5)>; Wed, 22 Feb 1995 12:58:44 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Wed, 22 Feb 1995 12:58:40 -0800 To: Charles Lynn Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) IPv6 Security drafts In-Reply-To: clynn's message of Wed, 22 Feb 95 08:48:53 -0800. <9502221828.AA08929@Sun.COM> Date: Wed, 22 Feb 1995 12:58:28 PST From: Steve Deering Message-Id: <95Feb22.125840pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Charlie, > Is there a requirement, maybe in some other draft, that will make it > clear whether, e.g., the ICMP message is an IPv4 ICMP message or an > IPv6 ICMP message. It looks like the ICMP Type values overlap, so > they could not be used to differentiate; a BAD IDEA, IMHO. Yesterday, I applied to IANA for a new Protocol Number for the IPv6 version of ICMP. We decided in San Jose that it should have a distinct Next Header value from IPv4's ICMP. (The fact that I am responding only to that part of your message does not imply that the other parts deserve no comment; that was just the easy part. Thanks for the thorough review.) Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 14:23:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04820; Wed, 22 Feb 95 14:23:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04814; Wed, 22 Feb 95 14:23:50 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19897; Wed, 22 Feb 1995 14:16:47 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA08570; Wed, 22 Feb 95 14:16:45 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA08867; Thu, 23 Feb 1995 09:16:34 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA29785; Thu, 23 Feb 95 08:09:05 +1000 Received: by dcthq2.datacraft.com.au; Thu, 23 Feb 95 9:15:23 +1100 Date: Thu, 23 Feb 95 8:58:35 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: (IPng) National Registry of Routing is Har mful X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM jeffs comment re pabxs and switching providers. YES it all relies on consistent numbering plans and carriers understanding each others DNICs, etc. plus a few bilateral agreements to say the least. ditto multi homed X.400 PRMDs. The point. By specifying a "provider" field in an address form one implies that commercial arrangements must exist between providers to do transit routing. Once one has assumed that, then one must set up formal arrangements for registering providers and some degree of common terms of reference for bilateral aggreements and provider responsibility. (otherwise chaos) Registration points at the national level and guidelines such as X.660 provide the mechanisms for this for other technologies. Again NSAP formats kept the majority of its fields to routing levels as do carrier numbering plans. Their specification was divorced from the operational issues. Having subsriber, provider terms in address forms one introduces operational and political debate into the addressing schemes and that makes it an open ended discussion. Bottom lines. keep addressing form definitions to routing levels. Keep operational semantics separate. The issue here is to get the admin of the address space bolted down to registration authorities and sub RAs and some recognised terms of reference for RAs and Providers. Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 14:50:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04836; Wed, 22 Feb 95 14:50:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04830; Wed, 22 Feb 95 14:50:44 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23509; Wed, 22 Feb 1995 14:43:41 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA14738; Wed, 22 Feb 95 14:43:32 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA09525; Thu, 23 Feb 1995 09:43:20 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA29907; Thu, 23 Feb 95 08:35:49 +1000 Received: by dcthq2.datacraft.com.au; Thu, 23 Feb 95 9:42:06 +1100 Date: Thu, 23 Feb 95 9:36:50 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: (IPng) National Registry of Routing is Har mful X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM perry, I would love to call you on this one but the jack plug on my phone has got caught up in my government protected kangeroo. Regards alan PS my home phone is connected to two of our carriers. Please come to Aus cos we do have cars, TVs, Health Systems, Mobiles, Earth stations, Food, AND we are connected to the internet! ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 15:05:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04853; Wed, 22 Feb 95 15:05:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04847; Wed, 22 Feb 95 15:05:32 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25398; Wed, 22 Feb 1995 14:58:28 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA17487; Wed, 22 Feb 95 14:56:11 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA10172; Thu, 23 Feb 1995 09:56:06 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA29937; Thu, 23 Feb 95 08:48:41 +1000 Received: by dcthq2.datacraft.com.au; Thu, 23 Feb 95 9:55:04 +1100 Date: Thu, 23 Feb 95 9:51:35 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: (IPng) key mgmt X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, thanks for the response. Is there any thing available re SDNS deficiencies, etc. Can we meet at Danvers and chalk and talk for a while as I would come to grips with some of issues from both sides of the fence (IETF key mgt and SDNS stuff). Thanks and regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 18:17:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04889; Wed, 22 Feb 95 18:17:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04883; Wed, 22 Feb 95 18:17:42 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17140; Wed, 22 Feb 1995 18:10:38 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA28476; Wed, 22 Feb 95 18:10:36 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA19983; Thu, 23 Feb 1995 13:10:23 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA00575; Thu, 23 Feb 95 12:02:29 +1000 Received: by dcthq2.datacraft.com.au; Thu, 23 Feb 95 13:08:56 +1100 Date: Thu, 23 Feb 95 12:52:32 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) my messed up mail X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=YES Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM begin 600 attach.Z M'YV0:=R,>7/&31HZ;URTF7,&@,.'$"-*G$BQHL6+&"N"V&BC(P@`&T'$H$'C M8\B1)4&&7"F#1HR--6[(D''#Q@T8-S?&D!%C)T@8&8,*'4JTZ,0Z<^B$D;,1 M`)LW8\*P,4KQ:=2I5+-JWO6?/T3)HR>#0*4/&!8@&"I*P#;@& MQ&*F9_B6N1,F#X@S;PC/>1/XC1NT(,P$/%-&3MJ`(`Y:IM+6])TT;-C<=5O' MC9XT<.!0#H$9,]W0212":IY)(*`JCB ` end ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 19:17:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04931; Wed, 22 Feb 95 19:17:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04925; Wed, 22 Feb 95 19:17:35 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21593; Wed, 22 Feb 1995 19:10:30 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA06920; Wed, 22 Feb 95 19:10:18 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA03605; Wed, 22 Feb 95 19:08:14 -0800 Received: by xirtlu.zk3.dec.com; id AA03918; Wed, 22 Feb 1995 22:07:16 -0500 Message-Id: <9502230307.AA03918@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Proxy ARP In-Reply-To: Your message of "Wed, 22 Feb 95 15:33:20 EST." <9502222033.AA00491@brigit.zk3.dec.com> Date: Wed, 22 Feb 95 22:07:10 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Its seems to me we have to solve three issues: 1. Do we need what IPv4 proxy arp does today in IPv6. I have heard about equal pro and con on this. But the con has been its a hack and stating its a "hack" is not a good argument unless they technically describe what they mean by its a hack, at least for me. Also lots of Terminal Servers use Proxy Arp I will add to the list of pro. 2. What are the security implications. I think this applies to Dan Nessett's issues regarding ICMP security too. Which IMHO is a big issue. 3. I think the most important issue is does system discovery violate in any way the use of an IPv6 source address as below: >In reference to the proxy use cases I mentioned, you seem to ignore the >issue of Neighbor Discovery compliance with the IPv6 specifications, or >perhaps you support the idea of originating packets with source addresses >that do not belong to the originator host? I think solving first #3 is the most important issue to the working group and either deciding we have an issue or we do not. I think we have an issue here. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 19:31:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04947; Wed, 22 Feb 95 19:31:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04941; Wed, 22 Feb 95 19:31:33 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22482; Wed, 22 Feb 1995 19:24:28 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA08548; Wed, 22 Feb 95 19:24:30 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14511(4)>; Wed, 22 Feb 1995 19:24:09 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Wed, 22 Feb 1995 19:23:59 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net, deering@parc.xerox.com Subject: (IPng) ICMP name query messages Date: Wed, 22 Feb 1995 19:23:54 PST From: Steve Deering Message-Id: <95Feb22.192359pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At the IPng WG meeting at PARC (the minutes of which are being edited at this moment and will appear very shortly), we decided to explore an alternative mechanism to the IN-ADDR domain tree for mapping IPv6 addresses into names. The change was proposed by several individuals who had attended the DNS enhancements meeting at Stanford earlier that same week, and was well received by the IPng meeting attendees. It's a wonderfully simple idea: if you want to find out what name belongs an IP address, send a query message to that address, asking what its name is. The proposal is that the query and response be two new types of ICMP message. Whether or not it is *too* simple an idea is curently being debated on the namedroppers list. One of the concerns is the effect of such a change on the load imposed on the Internet. It is argued that it would be disasterous to give up the caching behavior that currently results in most addr->name queries being answered nearby the querier. However, I suspect that concern is overblown. The reason why caching is essential in the current scheme is to relieve the load on the DNS servers, each of which are serving on behalf of a large number of nodes. In the proposed ICMP approach to addr->name mapping, the load is maximally distributed among nodes -- each node handles queries for only its own names. There's also a potential concern about traffic load on the links to the queried machines, but I can't imagine that one extra packet exchange at the beginning of an FTP or telnet session is going to break the Internet -- if it does, we're doomed anyway. (Of course, a querying host should cache the anser it gets so that subsequent lookups of the same address from the same host are handled locally within the host.) Anyway, in the fervent hope that the namedropping experts will conclude that the simple ICMP approach is adequate, I'd like to get some feedback on some details of the ICMP proposal. After the meeting at PARC, Alex Conta went home and added a pair of new messages to the IPv6 ICMP draft, as part of the the final clean-up work for getting the draft into RFC-able state. Independently, Bill Simpson wrote up a draft spec for two new ICMP messages, which was posted to the namedroppers list a few days ago; it's not clear whether Bill's proposal is targeted at IPv4, IPv6, or both (I assume the latter). The required function being very simple, the two drafts are very similar; however, being written by Alex and Bill, wherever it was possible to be different, they are. :-) I'd like to get comments on the following: - Alex called his messages Node Name Request/Reply. Bill called his messages Domain Name Request/Reply. I moderately prefer Alex's names, because I think of Domains as big things, while these messages are intended to get the names of little things (single nodes). If this were one of those verbose standards organizations, we'd have to call them Node's Fully-Qualified Domain Request/Reply. On the other hand, for IPv4 usage, I could imagine resitance to the use of the term "Node", because it's not part of the v4 jargon. - In Alex's proposal, both the Request and Reply messages include a field identifying the particular address being queried. In Bill's proposal, the queried address is only present as the destination of the Request and the source of the Reply. The issue here is probably the same as underlies the curent debate over proxy ARP for IPv6 -- do we need/want to allow/disallow a proxy to answer an ICMP Name Request without having to "lie" in the source address field of the reply? Any chance of coming to agreement on this one (vain hope)? - Well-known multicast addresses can have names. Cluster/pack addresses can have names in IPv6. How is the address->name mapping done for those types of addresses? Is every member of a well-known multicast group or a pack expected to know the name of that group/pack. - What's the right response if the possessor of an address does not have a name for that address. A zero-length name string? - Can Name Requests be sent to multicast or pack addresses? Alex says yes; Bill says no. Alex's proposal allows a query for a unicast address to be sent to a multicast address. - In Alex's proposal, the fully qualified name is expressed as a as a character string preceded by a length byte. In Bill's proposal, the FQN is expressed as a sequence of name components, each preceded by a length byte and terminated with a zero byte. Is there any particular reason to prefer one of those encodings over the other? - If there are multiple names for a particular address and they don't all fit inthe same packet (i.e., it would exceed the PMTU of the return path), what should be done? Exclude the extra names that don't fit? Spread the names across multiple Reply messages? - Is it necessary/desirable to limit the length of time that a querier remembers a reverse name mapping? If so, should that time be an architectural constant, a value returned in the Reply message, a local configuration option, or something else? That's all for this message. (Whew!) Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 19:54:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04971; Wed, 22 Feb 95 19:54:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04965; Wed, 22 Feb 95 19:54:03 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23712; Wed, 22 Feb 1995 19:46:58 -0800 Received: from sgigate.sgi.com by Sun.COM (sun-barr.Sun.COM) id AA11085; Wed, 22 Feb 95 19:46:55 PST Received: from sgihub.corp.sgi.com (sgihub.corp.sgi.com [192.26.51.188]) by sgigate.sgi.com (950215.405.SGI.8.6.10/8.6.4) with ESMTP id TAA11569; Wed, 22 Feb 1995 19:46:50 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id TAA26784; Wed, 22 Feb 1995 19:46:48 -0800 Received: from gauss.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com id AA11223; Wed, 22 Feb 95 19:46:48 -0800 Received: from localhost by gauss.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id TAA02026; Wed, 22 Feb 1995 19:46:28 -0800 Message-Id: <199502230346.TAA02026@gauss.asd.sgi.com> From: leedom@gauss.asd.sgi.com (Casey Leedom) To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net, deering@parc.xerox.com Subject: Re: (IPng) ICMP name query messages Date: Wed, 22 Feb 1995 19:46:08 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, I'll just ask the obvious question to get it out of the way: What about security issues with regard to spoofing? I'm going to guess that the response is that once you get the name back from the remote host you're supposed to pass it to DNS and make sure that the original address is listed as one of the legitimate addresses for that host[name]. Casey ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 20:37:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04991; Wed, 22 Feb 95 20:37:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04985; Wed, 22 Feb 95 20:37:45 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26254; Wed, 22 Feb 1995 20:30:39 -0800 Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA16487; Wed, 22 Feb 95 20:30:41 PST Message-Id: <9502230430.AA16487@Sun.COM> From: smb@research.att.com Received: by gryphon; Wed Feb 22 23:02:09 EST 1995 To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net, deering@parc.xerox.com Subject: Re: (IPng) ICMP name query messages Date: Wed, 22 Feb 95 23:02:08 EST Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, I'll just ask the obvious question to get it out of the way: What about security issues with regard to spoofing? I'm going to guess that the response is that once you get the name back from the remote host you're supposed to pass it to DNS and make sure that the original address is listed as one of the legitimate addresses for that host[name]. That could certainly be done; if you want any sort of security even today, you have to do that cross-check. But that's the wrong answer. The right answer is that name-based authentication and address-based authentication are bad ideas anyway, and are fundamentally incompatible with other IPv6 features such as really *using* source routing. If you want security, you *must* do cryptographic authentication. My concern is somewhat different: it's going to confuse log files. It will be especially bad when trying to interpret logs after the fact, when (a) the dial-up connection has dropped; (b) the mobile host has moved out of range; (c) the caller has dynamically reconfigured in order to accomdate provider-based addressing; (d) the Internet's routing is hosed, but traceroute doesn't tell you who to call because you can't get to the offending host; (e) ........ (your reason here). Not that these mean it's a bad idea -- in fact, I find its simplicity attractive -- but there are operational issues. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 22 22:22:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05041; Wed, 22 Feb 95 22:22:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05035; Wed, 22 Feb 95 22:22:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00053; Wed, 22 Feb 1995 22:14:56 -0800 Received: from cheops.anu.edu.au by Sun.COM (sun-barr.Sun.COM) id AA25809; Wed, 22 Feb 95 22:14:56 PST Message-Id: <9502230614.AA25809@Sun.COM> Received: by cheops.anu.edu.au (1.38.193.3/16.2) id AA18354; Thu, 23 Feb 95 17:14:54 +1100 From: Darren Reed Subject: Re: (IPng) ICMP name query messages To: ipng@sunroof.Eng.Sun.COM Date: Thu, 23 Feb 1995 17:14:54 +1100 (EDT) In-Reply-To: <95Feb22.192359pst.12174@skylark.parc.xerox.com> from "Steve Deering" at Feb 22, 95 07:23:54 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...] > - Alex called his messages Node Name Request/Reply. Bill called his > messages Domain Name Request/Reply. I moderately prefer Alex's > names, because I think of Domains as big things, while these > messages are intended to get the names of little things (single > nodes). If this were one of those verbose standards organizations, > we'd have to call them Node's Fully-Qualified Domain Request/Reply. > On the other hand, for IPv4 usage, I could imagine resitance to the > use of the term "Node", because it's not part of the v4 jargon. Maybe you want to break this ICMP type up...have a "node name request/reply" as being one code (just returns the hostname) and another return the FQDN. Or maybe you could add features like use the code as number of domains to descend into, with 0xff being FQDN (for hosts in domains like foo.pc.eng.uni-bar.iso). But that probably isn't needed or even desired. [...] > - In Alex's proposal, the fully qualified name is expressed as a > as a character string preceded by a length byte. In Bill's > proposal, the FQN is expressed as a sequence of name components, > each preceded by a length byte and terminated with a zero byte. > Is there any particular reason to prefer one of those encodings > over the other? And FQDN's of length 256 ? How about just using a null terminated string, with zero length being a null in the first position. [...] > - Is it necessary/desirable to limit the length of time that a > querier remembers a reverse name mapping? If so, should that > time be an architectural constant, a value returned in the Reply > message, a local configuration option, or something else? What about doing retries, backoff, etc. Does all this belong in with ICMP ? darren ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 01:09:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05073; Thu, 23 Feb 95 01:09:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05067; Thu, 23 Feb 95 01:09:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05761; Thu, 23 Feb 1995 01:02:21 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA09182; Thu, 23 Feb 95 01:01:47 PST Received: by mitsou.inria.fr (8.6.9/8.6.9) id KAA07572; Thu, 23 Feb 1995 10:01:37 +0100 Message-Id: <199502230901.KAA07572@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net, deering@parc.xerox.com Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Wed, 22 Feb 1995 19:23:54 PST." <95Feb22.192359pst.12174@skylark.parc.xerox.com> Date: Thu, 23 Feb 1995 10:01:35 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, I belong to those who have some reservations and find that the proposal is a bit too simple. My two main concerns are: 1) First, a problem of deployment. Autoconfig is typically used by small machines, many of which have a single task OS, or are in general ill equipped to be used as servers. Think of portables. Each request will fire up the CPU and drain the batteries. 2) Second, a problem of trust. How can I prove that the host responding to the getnamebyaddress request is not serving me with a phony answer? It appears that the current DNS implementation solves problem 1. The queries can be resolved by servers, these servers can be replicated, the responses can be cached. The planned DNS security extensions also provide a response to the second problem, as the responses can be signed by an authority. The proposed solution is thus a bit weak. It solve one problem, dynamic updates of the inverse tree, but opens at least two other questions, performance and security. I would suggest that whoever proposed the change works a little more on it. There should be a way to solve the first problem, e.g. by using an implicit naming and caching fabric, in a similar way to the DNS "NS" records. It may even be that we can achieve the desired effect by using the straight DNS protocol, with a simple twist to the bind implementation. Suppose that I am the name server for the address prefix and that I receive a request to solve the address . If the response is present in cache, I can just as well forward it. If it is not, I may send a request to the host . There may also be a way to solve the second problem, e.g. by having some authorized agent sign on the user. In short, I would add the ICMP "tell me your name" request, but I would also keep the IN-ADDR spec as is. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 02:53:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05165; Thu, 23 Feb 95 02:53:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05159; Thu, 23 Feb 95 02:53:43 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08321; Thu, 23 Feb 1995 02:46:40 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA16853; Thu, 23 Feb 95 02:46:26 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) requirements for the IPv6 security I-Ds To: ipng@sunroof.Eng.Sun.COM Date: Thu, 23 Feb 1995 10:45:49 +0000 (GMT) Cc: atkinson@itd.nrl.navy.mil, Danny.Nessett@Eng In-Reply-To: <199502221815.KAA23023@elrond.Eng.Sun.COM> from "Dan Nessett" at Feb 22, 95 10:15:13 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The first question that, I believe, needs to be raised is whether ICMP messages > require security protection? I think most believe that they do (Scott > Bradner specifically said they do at the Palo Alto meeting, but others > may disagree). They need authentication at the very least. How about An authenticated connection will only take cautious advisory notice of unauthenticated ICMP. An end point should sign any ICMP reply for a signed packet if able to do so. As a simple example EfNET irc is plagued by idiots sending faked icmp and will be a fine use of AH when its available for its security - and with those kind of ICMP rules with ICMP protected sensibly too. An ESP connection will only believe ICMP replies in ESP and an end point should not generate ICMP's for the _payload_ contents of an ESP encapsulated packet unless they too are encrypted (so information doesn't 'leak' out) I'd probably add a third rule that ICMP or other replies to clear text sessions should never be sent using ESP - to stop people using things like fast ping sessions with large data blocks for cryptographic attack. > host). However, some may believe that ICMP messages such as destination > unreachable, or packet too big may also require security protection (at > least an authentication/integrity check) to avoid denial of service attacks. Definitely they do - and thats from experience of real world idiots at work. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 05:28:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05225; Thu, 23 Feb 95 05:28:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05219; Thu, 23 Feb 95 05:28:07 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18490; Thu, 23 Feb 1995 05:21:03 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA29351; Thu, 23 Feb 95 05:21:03 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA21602; Thu, 23 Feb 95 05:17:06 -0800 Received: by xirtlu.zk3.dec.com; id AA12958; Thu, 23 Feb 1995 08:16:04 -0500 Message-Id: <9502231316.AA12958@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net, deering@parc.xerox.com, bound@zk3.dec.com Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Wed, 22 Feb 95 19:46:08 PST." <199502230346.TAA02026@gauss.asd.sgi.com> Date: Thu, 23 Feb 95 08:15:58 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I'll just ask the obvious question to get it out of the way: > What about security issues with regard to spoofing? >I'm going to guess that the response is that once you get the name back >from the remote host you're supposed to pass it to DNS and make sure that >the original address is listed as one of the legitimate addresses for that >host[name]. This should be optional. Not required. If the host is not within my root zone then it will have found from a DNS server elsewhere which can take more than 10 seconds. Thats too long for many applications to wait. This gets back to ICMP security and possibly using DNSSEC with the ICMP ery for the name. Which should also be optional. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 05:43:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05237; Thu, 23 Feb 95 05:43:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05231; Thu, 23 Feb 95 05:43:40 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19090; Thu, 23 Feb 1995 05:36:36 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA01032; Thu, 23 Feb 95 05:36:35 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA23067; Thu, 23 Feb 95 05:34:36 -0800 Received: by xirtlu.zk3.dec.com; id AA13673; Thu, 23 Feb 1995 08:33:31 -0500 Message-Id: <9502231333.AA13673@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net, deering@parc.xerox.com Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Wed, 22 Feb 95 23:02:08 EST." <9502230430.AA16487@Sun.COM> Date: Thu, 23 Feb 95 08:33:25 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >If you want security, you *must* do cryptographic authentication. While we figure this out lets not do anything that causes vendors to not be able to get through export controls per any non-authentication (meaning encryption) security requirements. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 06:15:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05264; Thu, 23 Feb 95 06:15:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05258; Thu, 23 Feb 95 06:15:20 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20140; Thu, 23 Feb 1995 06:08:16 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA04642; Thu, 23 Feb 95 06:08:14 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-01.dialip.mich.net [141.211.7.12]) by merit.edu (8.6.10/merit-2.0) with SMTP id JAA26266; Thu, 23 Feb 1995 09:08:08 -0500 Date: Thu, 23 Feb 95 13:01:46 GMT From: "William Allen Simpson" Message-Id: <3948.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net Subject: (IPng) Re: ICMP name query messages Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Steve Deering > suspect that concern is overblown. The reason why caching is essential > in the current scheme is to relieve the load on the DNS servers, each of > which are serving on behalf of a large number of nodes. In the proposed > ICMP approach to addr->name mapping, the load is maximally distributed > among nodes -- each node handles queries for only its own names. > There's > also a potential concern about traffic load on the links to the queried > machines, but I can't imagine that one extra packet exchange at the beginning > of an FTP or telnet session is going to break the Internet -- if it does, > we're doomed anyway. Remember, the FTP and Telnet servers are already doing this "extra packet exchange", but to the overloaded servers, rather than the distributed hosts. > After the meeting at PARC, Alex Conta > went home and added a pair of new messages to the IPv6 ICMP draft, as part > of the the final clean-up work for getting the draft into RFC-able state. > Independently, Bill Simpson wrote up a draft spec for two new ICMP messages, > which was posted to the namedroppers list a few days ago; it's not clear > whether Bill's proposal is targeted at IPv4, IPv6, or both (I assume the > latter). At the IPv6 meeting, I stood up and volunteered to write the text before the end of the meeting, which I actually did! If Alex then left and rolled his own, that's merely a deliberate attempt at confusion. None of us have seen Alex's text, so I'm replying blind. > - Alex called his messages Node Name Request/Reply. Bill called his > messages Domain Name Request/Reply. I moderately prefer Alex's > names, because I think of Domains as big things, while these > messages are intended to get the names of little things (single > nodes). The terminology in every other RFC is a "Domain Name", which is the title I used. > If this were one of those verbose standards organizations, > we'd have to call them Node's Fully-Qualified Domain Request/Reply. > On the other hand, for IPv4 usage, I could imagine resitance to the > use of the term "Node", because it's not part of the v4 jargon. > I really prefer not to use the term "node" in this context. A node has to do with routing, not naming. > - In Alex's proposal, both the Request and Reply messages include > a field identifying the particular address being queried. In > Bill's proposal, the queried address is only present as the > destination of the Request and the source of the Reply. The issue > here is probably the same as underlies the curent debate over > proxy ARP for IPv6 -- do we need/want to allow/disallow a proxy > to answer an ICMP Name Request without having to "lie" in the > source address field of the reply? Any chance of coming to > agreement on this one (vain hope)? > It is not exactly the same issue. It is not possible for a node to proxy for another, unless it answers the other's unicast address. > - Well-known multicast addresses can have names. Cluster/pack > addresses can have names in IPv6. How is the address->name mapping > done for those types of addresses? Is every member of a well-known > multicast group or a pack expected to know the name of that > group/pack. > If they are well-known, you won't need to query for them, because they are already "known". Moreover, it is illegal for a multicast/cluster to be the Source of IP. Since this is a technique which learns the name of an unknown sender, it will never be used for multicast/cluster. You cannot receive a multicast for an address you have not explicitly joined. If you have already joined the group (learned its address from its name), why would you ask the name of the group? The mapping from name to address is useful, but the reverse is not. Unless, you think we are going to type in multicast addresses by hand, and then need to query the name. > - What's the right response if the possessor of an address does not > have a name for that address. A zero-length name string? > In mine, no name strings, just like DNS. > - Can Name Requests be sent to multicast or pack addresses? > Alex says yes; Bill says no. Alex's proposal allows a query > for a unicast address to be sent to a multicast address. > Evil! > - In Alex's proposal, the fully qualified name is expressed as a > as a character string preceded by a length byte. In Bill's > proposal, the FQN is expressed as a sequence of name components, > each preceded by a length byte and terminated with a zero byte. > Is there any particular reason to prefer one of those encodings > over the other? > Yes, mine is the standard technique for carrying DNS names. I used (extracted) the text directly from RFC-1034. > - If there are multiple names for a particular address and they > don't all fit inthe same packet (i.e., it would exceed the > PMTU of the return path), what should be done? Exclude the > extra names that don't fit? Spread the names across multiple > Reply messages? > Good question. My latest draft (not yet posted) says: When no names are known, the field is eliminated (zero length), but the Reply is sent as an authoritative indication. When more than one name is known, all such names SHOULD be listed. When other names are known at the same host or router, from a different interface or address, these names MAY be listed, too. Any name which cannot entirely fit within the Reply MTU is removed. Any change we can keep this on the namedroppers list, as the draft says? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 06:30:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05276; Thu, 23 Feb 95 06:30:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05270; Thu, 23 Feb 95 06:30:34 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20896; Thu, 23 Feb 1995 06:23:30 -0800 Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA06859; Thu, 23 Feb 95 06:23:30 PST Message-Id: <9502231423.AA06859@Sun.COM> From: smb@research.att.com Received: by gryphon; Thu Feb 23 09:20:43 EST 1995 To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net Subject: Re: (IPng) Re: ICMP name query messages Date: Thu, 23 Feb 95 09:20:43 EST Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > - Can Name Requests be sent to multicast or pack addresses? > Alex says yes; Bill says no. Alex's proposal allows a query > for a unicast address to be sent to a multicast address. > Evil! I'll reply to this on the ipng list as well, because my answer is relevant to it. In my opinion, the multicast specs should say that a port or service (i.e., ICMP) MUST NOT reply to any broadcast or multicast message unless specifically conditioned to do so. I'm trying to prevent things like sending a message to the UDP echo or chargen ports with the session directory multicast group address and the return address of someone you really don't like... More generally, if a service is not expecting to be used in a multicast context, it probably can't provide its services in a meaningful fashion. I realize that this isn't a new concept, in the sense that various RFCs have already dealt with things like broadcast ICMP echo messages. Multicast is worse than broadcast, because broadcast, even if directed, is limited to one network; multicast can span the world. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 06:39:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05308; Thu, 23 Feb 95 06:39:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05302; Thu, 23 Feb 95 06:39:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21324; Thu, 23 Feb 1995 06:32:21 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA08304; Thu, 23 Feb 95 06:32:20 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA27724; Thu, 23 Feb 95 06:23:03 -0800 Received: by xirtlu.zk3.dec.com; id AA15848; Thu, 23 Feb 1995 09:21:58 -0500 Message-Id: <9502231421.AA15848@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net, deering@parc.xerox.com Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Wed, 22 Feb 95 19:23:54 PST." <95Feb22.192359pst.12174@skylark.parc.xerox.com> Date: Thu, 23 Feb 95 09:21:52 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, Before I reply to your mail and one of the folks that was at the Stanford DNS meeting, I want to point out that when this suggestion was made to IPng WG two caveats were stated: 1. This would only be for IPv6 NOT IPv4. 2. We stated that this suggestion was on the table in the IETF before and was rejected. But so far we have not been able to recapture that history in the IETF. Maybe Paul Mockapetris can help us with Historical precedence here? And what happened? Also before I reply there is a variable that was pointed to already by Steve Bellovin (besides the obvious security one) and that is the operational issues. Some input has already come in that the in.arpa tree is out of synch now and not kept up-to-date by several folks that are or are aware of what is used and what is not used in the DNS customer environment. I would like to think customer environment and not just the Internet OK. Customers may or may not be on the Internet and if they are today its behind a firewall. >Whether or not it is *too* simple an idea is curently being debated on >the namedroppers list. One of the concerns is the effect of such a >change on the load imposed on the Internet. It is argued that it would >be disasterous to give up the caching behavior that currently results in >most addr->name queries being answered nearby the querier. However, I >suspect that concern is overblown. The reason why caching is essential >in the current scheme is to relieve the load on the DNS servers, each of >which are serving on behalf of a large number of nodes. In the proposed >ICMP approach to addr->name mapping, the load is maximally distributed >among nodes -- each node handles queries for only its own names. There's >also a potential concern about traffic load on the links to the queried >machines, but I can't imagine that one extra packet exchange at the beginning >of an FTP or telnet session is going to break the Internet -- if it does, >we're doomed anyway. (Of course, a querying host should cache the anser it >gets so that subsequent lookups of the same address from the same host are >handled locally within the host.) I question whether the caching is actually being used to the degree suggested and would like some operation folks to please respond to this mail so we can get expert operations input on this one not just engineering projections (steve d. this time I think the engineer should listen). Examples are John Curran, Brian Carpenter, Robert Elz (who also wear engineering hats but can get this data for in.arpa real use).. Alan at OZ what about you? I am going to check how much Digital does it too. Sun, HP, IBM, etc....how about you folks? We should also hear from Chrysler (Bob can you connect with friends maybe at GM and Ford and ask them). Eric at Boeing. We have a lot of folks out here using DNS. I think Perry Metzger also can get some real data. Folks we need real data on this one not guesses. Or just tech weenine wishes for the world. OK thats the operational issue. Hopefully we will hear back. > - Alex called his messages Node Name Request/Reply. Bill called his > messages Domain Name Request/Reply. I moderately prefer Alex's > names, because I think of Domains as big things, while these > messages are intended to get the names of little things (single > nodes). If this were one of those verbose standards organizations, > we'd have to call them Node's Fully-Qualified Domain Request/Reply. > On the other hand, for IPv4 usage, I could imagine resitance to the > use of the term "Node", because it's not part of the v4 jargon. First we should not attempt this IMHO for v4. But in v6 I like the name Node. Because various node types may reply per the IPv6 definitions of what a Node is presently. Both Alex and Bill (I have read both drafts as reviewer of both) have the field semantics correct (its a FQDN in the field), or at least called a domain name. Gee maybe Alex and Bill can go offline and agree too (that would be nice). > - In Alex's proposal, both the Request and Reply messages include > a field identifying the particular address being queried. In > Bill's proposal, the queried address is only present as the > destination of the Request and the source of the Reply. The issue > here is probably the same as underlies the curent debate over > proxy ARP for IPv6 -- do we need/want to allow/disallow a proxy > to answer an ICMP Name Request without having to "lie" in the > source address field of the reply? Any chance of coming to > agreement on this one (vain hope)? OUCH. I should pass on this. But.. The issue is overloading and passing the request to upper layers. If the address is passed to an application or a real query service then with Bills scheme the address has to be extracted and put into the UDPorTCP data emulated for the upper layer. [NO PORT MAY BE WAITING DEPENDING ON THE IMPLEMENTATION] This is then an extraction of the address from the IPv6 header. Now this may be a bad argument because the socket structure would have to be built in the kernel. As I said I will just pass. This is an architecture issue Alex and Bill debate and needs to be resolved in general IPv6. > - Well-known multicast addresses can have names. Cluster/pack > addresses can have names in IPv6. How is the address->name mapping > done for those types of addresses? Is every member of a well-known > multicast group or a pack expected to know the name of that > group/pack. If you use the IPv4 model its optional. I think this is a good idea and definitely should not be prohibited. > - What's the right response if the possessor of an address does not > have a name for that address. A zero-length name string? I think this came up because we did it in ICMP. In a OS kernel implementation using scanf is usually not done. We check a length (or determine one from predefined conditions) and for example construct an mbuf section to provide the data to other parts of the network kernel implementation. Parsing strings for a null terminated /0 is not a usual practice for protocol parsing in a kernel (where ICMP usually lives). If we move this message to a UDP application and not ICMP then I would agree a null string is fine. Otherwise it seems a length is a wise cheap addition. > - Can Name Requests be sent to multicast or pack addresses? > Alex says yes; Bill says no. Alex's proposal allows a query > for a unicast address to be sent to a multicast address. The result of such a query could cause multiple responses and in fact many. Is there another approach to get this address? > - In Alex's proposal, the fully qualified name is expressed as a > as a character string preceded by a length byte. In Bill's > proposal, the FQN is expressed as a sequence of name components, > each preceded by a length byte and terminated with a zero byte. > Is there any particular reason to prefer one of those encodings > over the other? I think I gave you input on this above and one view of the world. > - If there are multiple names for a particular address and they > don't all fit inthe same packet (i.e., it would exceed the > PMTU of the return path), what should be done? Exclude the > extra names that don't fit? Spread the names across multiple > Reply messages? First I think multiple names should be prevented this is not a good model and should be fixed in IPv6. But if that cannot be fixed then the ICMP should specifiy an option type when there are multiple names. We just did this in DHCPv6 draft and can share this protocol design with Alex and Bill. The reason that a single response should be assumed is that this will be the usual case and as you point out you can break the PMTU and thats not cool for an implementation in IPv6. With an option and length (note in DHCPv6 we used the same model you came up with for IPv6 header processing so we used your idea fyi) its a hint that you MAY break the PMTU and can the redirect code path once the hint is known for an implementation. But I would prefer in IPv6 one host name per address and really ONE HOST NAME PER NODE WOULD BE EVEN BETTER. > - Is it necessary/desirable to limit the length of time that a > querier remembers a reverse name mapping? If so, should that > time be an architectural constant, a value returned in the Reply > message, a local configuration option, or something else? Yes this is necessary and was also asked for in the IPv6 host2addr() (new api for gethostbyname() in IPv6) per a timer that could be passed by the application to the DNS resolver, if the response takes too long by the DNS resolver. The other point is that if we don't do this IMHO we need a protocol to take the stateless address configuration spec when it uses an algorithm to build addresses based on known topology and build an administrative protocol that populates the in.arpa tree with the addresses and names would be a wildcard *. Then names would be added later either by a client host or by DHCPv6 on behalf of clients. So getting rid of in.arpa tree is a big win for stateless address configuration. I can explain this in detail if we want to enter that requirment or if its not obvious to all. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 06:45:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05320; Thu, 23 Feb 95 06:45:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05314; Thu, 23 Feb 95 06:45:48 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21650; Thu, 23 Feb 1995 06:38:44 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA09302; Thu, 23 Feb 95 06:38:44 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA28871; Thu, 23 Feb 95 06:34:26 -0800 Received: by xirtlu.zk3.dec.com; id AA16418; Thu, 23 Feb 1995 09:33:25 -0500 Message-Id: <9502231433.AA16418@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net Subject: Re: (IPng) Re: ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 95 13:01:46 GMT." <3948.bsimpson@morningstar.com> Date: Thu, 23 Feb 95 09:33:19 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, We really need the minutes. I recall that it was to be added to the ICMP spec. If so Alex did the right thing putting it in the spec. I have seen both as I have been reviewer of ICMP since Ramesh Govindan worked with Steve on this draft. I am not taking sides just trying to verify what happened at the meeting. [ipng group I screwed up with Bob Hinden and missed the result of an address decision and had to eat crow on that one. Have I screwed this one up to? Bill if I did I apologize now as I did to Bob.] /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 06:50:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05335; Thu, 23 Feb 95 06:50:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05329; Thu, 23 Feb 95 06:49:55 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB21849; Thu, 23 Feb 1995 06:42:51 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA10098; Thu, 23 Feb 95 06:42:51 PST Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA22749; Thu, 23 Feb 95 06:38:57 -0800 Received: from cfsctc.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA12515; Thu, 23 Feb 95 09:39:30 -0500 Message-Id: <9502231439.AA12515@us1rmc.bb.dec.com> Received: from cfsctc.enet; by us1rmc.enet; Thu, 23 Feb 95 09:39:30 EST Date: Thu, 23 Feb 95 09:39:30 EST From: "Steve Huston, 508-952-3306" To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net Apparently-To: namedroppers@rs.internic.net, ipng@sunroof.eng.sun.com Subject: RE: (IPng) ICMP name query messages Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Is there some potential problems with getting the names of hosts that are behind firewalls? If some TCP protocols are allowed through, it may still be that the ICMP requests won't be allowed. Can they be set to only allow some ICMP request numbers through? Steve Huston Blue Sky Software Corporation ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 06:50:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05347; Thu, 23 Feb 95 06:50:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05339; Thu, 23 Feb 95 06:50:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21864; Thu, 23 Feb 1995 06:43:11 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA10153; Thu, 23 Feb 95 06:43:11 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA29281; Thu, 23 Feb 95 06:38:40 -0800 Received: by xirtlu.zk3.dec.com; id AA16554; Thu, 23 Feb 1995 09:37:41 -0500 Message-Id: <9502231437.AA16554@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net Subject: Re: (IPng) Re: ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 95 09:20:43 EST." <9502231423.AA06859@Sun.COM> Date: Thu, 23 Feb 95 09:37:35 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve Deering put this on BOTH LISTS. It should be his decision if its not to be on BOTH LISTS. If you can't take it get out of the discussion. This is critical we resolve this and we need both folks to accomplish that. Unless Steve wants to change it or Randy Bush (DNS WG Chair) objects I ask all please to respond to both addresses. I am getting it twice too. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 07:03:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05361; Thu, 23 Feb 95 07:03:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05355; Thu, 23 Feb 95 07:03:49 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22616; Thu, 23 Feb 1995 06:56:45 -0800 Received: from comet.connix.com by Sun.COM (sun-barr.Sun.COM) id AA12994; Thu, 23 Feb 95 06:56:42 PST Received: from connix.com (localhost [127.0.0.1]) by comet.connix.com (8.6.5/8.6.5) with ESMTP id JAA05037; Thu, 23 Feb 1995 09:56:40 -0500 Message-Id: <199502231456.JAA05037@comet.connix.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net Subject: Re: (IPng) Re: ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 1995 13:01:46 GMT." <3948.bsimpson@morningstar.com> Date: Thu, 23 Feb 1995 09:56:40 -0500 From: Gary Wright Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "William Allen Simpson" writes: > You cannot receive a multicast for an address you have not explicitly > joined. If you have already joined the group (learned its address from > its name), why would you ask the name of the group? How about if you inherted a socket accross a fork/exec and you want to figure out the name associated with an address? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 07:07:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05373; Thu, 23 Feb 95 07:07:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05367; Thu, 23 Feb 95 07:07:34 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22927; Thu, 23 Feb 1995 07:00:30 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA13989; Thu, 23 Feb 95 07:00:12 PST Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA17737 for ipng@sunroof.eng.sun.com; Thu, 23 Feb 95 09:59:43 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id GAA20656; Thu, 23 Feb 1995 06:59:48 -0800 Message-Id: <199502231459.GAA20656@aland.bbn.com> To: deering@parc.xerox.com Cc: namedroppers@rs.internic.net Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of Wed, 22 Feb 95 19:23:54 -0800. <95Feb22.192359pst.12174@skylark.parc.xerox.com> From: Craig Partridge Date: Thu, 23 Feb 95 06:59:46 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve: One thing I didn't see in your note about ICMP name queries is the issue of accuracy (I won't say security, because that's not quite right, though there are security elements here). Currently, given address 1.2.3.4 one queries the IN-ADDR domain, for net 1, which is presumably maintained by the person who manages net 1. As a result, we can have some limited confidence that the name returned for 1.2.3.4, say a.b.net, is probably the correct name. Under the new scheme, the name you get back from the query for 1.2.3.4 is whatever the user of the host decides to make it (given that most hosts these days are single user PCs). As a result, I predict that any logging (say by FTP or LOGIN) of who uses a system will be completely worthless. We also have to worry about whether j-random user will get the name information right. In particular, I'll wager this inverse stuff requires additional configuration information to be stuffed somewhere, raising the likelihood of mismatching host names. Now, having said all this, I'll agree that IN-ADDR has been a notably unsuccessful activity -- lots of IN-ADDR domains are poorly maintained -- and I'd welcome a good alternative. Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 07:09:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05385; Thu, 23 Feb 95 07:09:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05379; Thu, 23 Feb 95 07:09:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22991; Thu, 23 Feb 1995 07:01:58 -0800 Received: from mutton.csv.warwick.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA13738; Thu, 23 Feb 95 06:59:49 PST Date: Thu, 23 Feb 1995 14:59:17 GMT From: Ian Dickinson Message-Id: <15701.199502231459@mutton.csv.warwick.ac.uk> Received: by mutton.csv.warwick.ac.uk id OAA15701; Thu, 23 Feb 1995 14:59:17 GMT In-Reply-To: "William Allen Simpson" "(IPng) Re: ICMP name query messages" (Feb 23, 1:01pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ICMP name query messages Cc: namedroppers@rs.internic.net Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I find this whole concept extremely disturbing. It is nice and simple, but there seems to be no way to exercise any policy over the name space. We keep a certain amount of control over our name space - addressing and domains. This would effectively make any policy purely advisory, rather than enforcable, which is just what our undergrad spods would like. Cheers, -- Ian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 07:10:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05397; Thu, 23 Feb 95 07:10:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05391; Thu, 23 Feb 95 07:09:50 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23041; Thu, 23 Feb 1995 07:02:46 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA14501; Thu, 23 Feb 95 07:02:36 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Re: ICMP name query messages To: ipng@sunroof.Eng.Sun.COM Date: Thu, 23 Feb 1995 15:02:25 +0000 (GMT) Cc: namedroppers@rs.internic.net In-Reply-To: <199502231456.JAA05037@comet.connix.com> from "Gary Wright" at Feb 23, 95 09:56:40 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > "William Allen Simpson" writes: > > You cannot receive a multicast for an address you have not explicitly > > joined. If you have already joined the group (learned its address from > > its name), why would you ask the name of the group? > > How about if you inherted a socket accross a fork/exec and you want > to figure out the name associated with an address? Or another one - you are running a packet snooper or traffic logger on your multicast router Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 07:20:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05409; Thu, 23 Feb 95 07:20:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05403; Thu, 23 Feb 95 07:20:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23898; Thu, 23 Feb 1995 07:13:11 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA16469; Thu, 23 Feb 95 07:13:11 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm012-18.dialip.mich.net [141.211.7.186]) by merit.edu (8.6.10/merit-2.0) with SMTP id KAA29033 for ; Thu, 23 Feb 1995 10:13:08 -0500 Date: Thu, 23 Feb 95 14:54:00 GMT From: "William Allen Simpson" Message-Id: <3954.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Gratuitous ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM It has come to my attention that in MacTCP and 4.4BSD there is a bug. When the interface initializes, it sends a Gratuitous ARP Request with its address as both source and target. This is apparently an attempt to discover if there are duplicate IP addresses. The problem is that when there _IS_ a duplicate, ARP processing will update old cache entries with the new MAC address. Meanwhile, the latest interface shuts down, since it gets a reply. All existing connections are now pointing at the new interface, which doesn't know about them, and hang. The quick fix for MacTCP and 4.4BSD is to use 0.0.0.0 as the source, which hopefully won't update any cache. The question for us: do we want to add Self Solicitation for discovery of duplicate addresses? We could also separately check for duplicate link addresses, using 0.0.0.0 as the IP Destination. That's 2 multicast packets (including Router solicitation), plus a link unicast, from every node at the initialization of every interface. I am of the opinion that it is not worth the bother. KRE has expressed the opposite view in the Apple Networking Forum. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 07:27:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05435; Thu, 23 Feb 95 07:27:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05429; Thu, 23 Feb 95 07:27:24 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24591; Thu, 23 Feb 1995 07:20:20 -0800 Received: from venera.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA17894; Thu, 23 Feb 95 07:20:19 PST Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Feb 1995 07:20:17 -0800 From: bmanning@ISI.EDU Posted-Date: Thu, 23 Feb 1995 07:19:24 -0800 (PST) Message-Id: <199502231519.AA17673@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Thu, 23 Feb 1995 07:19:25 -0800 Subject: Re: (IPng) ICMP name query messages To: ipng@sunroof.Eng.Sun.COM Date: Thu, 23 Feb 1995 07:19:24 -0800 (PST) In-Reply-To: <95Feb22.192359pst.12174@skylark.parc.xerox.com> from "Steve Deering" at Feb 22, 95 07:23:54 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM There are a number of replies to this already, but you asked Steve, so here are my uninformed comments: > - Alex called his messages Node Name Request/Reply. Bill called his > messages Domain Name Request/Reply. I moderately prefer Alex's Node Name gets the nod here. I beleive it is more descriptive and less burdened with previous semantics > > - In Alex's proposal, both the Request and Reply messages include > a field identifying the particular address being queried. In > Bill's proposal, the queried address is only present as the > destination of the Request and the source of the Reply. The issue Again, I think that Alex's approach is preferable. > - Well-known multicast addresses can have names. Cluster/pack > addresses can have names in IPv6. How is the address->name mapping > done for those types of addresses? Is every member of a well-known > multicast group or a pack expected to know the name of that > group/pack. Yes. > > - What's the right response if the possessor of an address does not > have a name for that address. A zero-length name string? Hummm... > > - Can Name Requests be sent to multicast or pack addresses? > Alex says yes; Bill says no. Yes, they are identifyable "nodes" and so must be able to participate. > - In Alex's proposal, the fully qualified name is expressed as a > as a character string preceded by a length byte. In Bill's > proposal, the FQN is expressed as a sequence of name components, > each preceded by a length byte and terminated with a zero byte. > Is there any particular reason to prefer one of those encodings > over the other? I think that Alex's approach is cleaner and we don't have to worry about determining the end of sequence, which would have to be done with Bill's proposal > - If there are multiple names for a particular address and they > don't all fit inthe same packet (i.e., it would exceed the > PMTU of the return path), what should be done? Exclude the > extra names that don't fit? Spread the names across multiple > Reply messages? Multiple replies. > - Is it necessary/desirable to limit the length of time that a > querier remembers a reverse name mapping? If so, should that > time be an architectural constant, a value returned in the Reply > message, a local configuration option, or something else? Humm... --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 07:29:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05447; Thu, 23 Feb 95 07:29:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05441; Thu, 23 Feb 95 07:29:34 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24752; Thu, 23 Feb 1995 07:22:29 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA18377; Thu, 23 Feb 95 07:22:28 PST Received: from relay.imsi.com by wintermute.imsi.com id KAA25387; Thu, 23 Feb 1995 10:22:17 -0500 Received: from snark.imsi.com by relay.imsi.com id KAA26710; Thu, 23 Feb 1995 10:22:16 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02230; Thu, 23 Feb 95 10:22:15 EST Message-Id: <9502231522.AA02230@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 1995 09:39:30 EST." <9502231439.AA12515@us1rmc.bb.dec.com> X-Reposting-Policy: redistribute only with permission Date: Thu, 23 Feb 1995 10:22:14 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "Steve Huston, 508-952-3306" says: > Is there some potential problems with getting the names of hosts > that are behind firewalls? If some TCP protocols are allowed through, > it may still be that the ICMP requests won't be allowed. Can they > be set to only allow some ICMP request numbers through? This is a frequent way that I set up firewall systems. Beyond this, I have an issue with authentication. This completely breaks the reverse record authentication that was previously possible using the Eastlake-Kaufman public key hacks to the DNS. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 07:37:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05471; Thu, 23 Feb 95 07:37:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05453; Thu, 23 Feb 95 07:37:32 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25478; Thu, 23 Feb 1995 07:30:27 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA19766; Thu, 23 Feb 95 07:30:27 PST Received: from relay.imsi.com by wintermute.imsi.com id KAA25435 for ; Thu, 23 Feb 1995 10:30:26 -0500 Received: from snark.imsi.com by relay.imsi.com id KAA26785 for ; Thu, 23 Feb 1995 10:30:25 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02250; Thu, 23 Feb 95 10:30:24 EST Message-Id: <9502231530.AA02250@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Gratuitous ARP In-Reply-To: Your message of "Thu, 23 Feb 1995 14:54:00 GMT." <3954.bsimpson@morningstar.com> X-Reposting-Policy: redistribute only with permission Date: Thu, 23 Feb 1995 10:30:24 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "William Allen Simpson" says: > The question for us: do we want to add Self Solicitation for discovery > of duplicate addresses? [...] > I am of the opinion that it is not worth the bother. KRE has expressed > the opposite view in the Apple Networking Forum. Less than three days ago, "self solicitation" saved my buttocks. Someone brought up a second machine on an etherthernet with the same IP address and had this feature not been in place a production network would have been brought to its knees. I'm in favor of any feature that has shown great operational utility, and this is certainly one of them. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 07:46:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05483; Thu, 23 Feb 95 07:46:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05477; Thu, 23 Feb 95 07:46:37 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26298; Thu, 23 Feb 1995 07:39:32 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA21407; Thu, 23 Feb 95 07:39:29 PST Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA19232; Thu, 23 Feb 1995 10:39:20 -0500 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/18Feb95-1123AM) id AA32373; Thu, 23 Feb 1995 10:39:17 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA20533; Thu, 23 Feb 1995 10:15:15 -0500 Message-Id: <9502231515.AA20533@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net, conta@zk3.dec.com Subject: Re: (IPng) Re: ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 95 13:01:46 GMT." <3948.bsimpson@morningstar.com> Date: Thu, 23 Feb 95 10:15:15 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: "William Allen Simpson" Subject: (IPng) Re: ICMP name query messages At the IPv6 meeting, I stood up and volunteered to write the text before the end of the meeting, which I actually did! If Alex then left and rolled his own, that's merely a deliberate attempt at confusion. None of us have seen Alex's text, so I'm replying blind. The entire IPng working group discussed whether to include this feature in the IPv6 ICMP specifications. There is an IPv6 ICMP specification, and the authors or editors are alive and active. So your volunteering may make sense to you, but it does not to me, and I do not remember agreeing to anything like that, so you went and wrote a 1 page draft for 2 ICMP messages, when there is an ICMP draft!? I am sorry to say it, but it is your attempt that creates confusion and a conflictual situation! Furthermore, a quite long discussion in Palo Alto took place in the IPng working group, the decision affects IPv6 ICMP, but the IPng working group had to find out from Steve about your draft! ..... Any change we can keep this on the namedroppers list, as the draft says? This discussion should be done on the IPng list as well, since we are discussing an IPv6 ICMP feature. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 08:05:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05509; Thu, 23 Feb 95 08:05:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05503; Thu, 23 Feb 95 08:04:56 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27668; Thu, 23 Feb 1995 07:57:51 -0800 Received: from uu4.psi.com by Sun.COM (sun-barr.Sun.COM) id AA24639; Thu, 23 Feb 95 07:57:51 PST Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA00916 for ipng@sunroof.eng.sun.com; Thu, 23 Feb 95 10:57:37 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id HAA20901; Thu, 23 Feb 1995 07:53:57 -0800 Message-Id: <199502231553.HAA20901@aland.bbn.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net Subject: Re: (IPng) Re: ICMP name query messages In-Reply-To: Your message of Thu, 23 Feb 95 10:15:15 -0500. <9502231515.AA20533@brigit.zk3.dec.com> From: Craig Partridge Date: Thu, 23 Feb 95 07:53:56 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alex and Bill: Before this gets into a bigger fight about who had authority to do what, let me point out that the real problem is minutes. If there were meeting minutes distributed within a day or two that said who had signed up to do what, we wouldn't be worrying about who was supposed to write the draft (or at least, you both would have seen the issue before you started writing). Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 08:15:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05521; Thu, 23 Feb 95 08:15:42 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05515; Thu, 23 Feb 95 08:15:31 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA16469; Thu, 23 Feb 1995 08:08:14 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA23551; Thu, 23 Feb 1995 08:08:09 -0800 Date: Thu, 23 Feb 1995 08:08:09 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199502231608.IAA23551@elrond.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages Cc: namedroppers@rs.internic.net, deering@parc.xerox.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, In regards to the following point : > In the proposed > ICMP approach to addr->name mapping, the load is maximally distributed > among nodes. I believe the security of this approach was briefly discussed in Palo Alto and the concerns that some of us expressed were assuaged by proposing systems do a forward lookup of the name they received from the remote system, verifying the name<->address mapping. Consequently, I don't think the load is going to be distributed among the nodes overall. In particular there will be a DNS lookup for the addr->name translation for verification purposes. If we are going to be serious about security, I think the accepted proposal (whether it is Alex's, Bill's or a combination of these) should specify that the name->addr lookup in DNS be part of the procedure for addr->name mapping using the new ICMP messages. Regards, Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 08:24:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05533; Thu, 23 Feb 95 08:24:34 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05527; Thu, 23 Feb 95 08:24:26 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA16978; Thu, 23 Feb 1995 08:17:06 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA23557; Thu, 23 Feb 1995 08:17:05 -0800 Date: Thu, 23 Feb 1995 08:17:05 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199502231617.IAA23557@elrond.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages Cc: namedroppers@rs.internic.net, deering@parc.xerox.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, Recently, you made the following point : > That could certainly be done; if you want any sort of security even > today, you have to do that cross-check. But that's the wrong answer. > The right answer is that name-based authentication and address-based > authentication are bad ideas anyway, and are fundamentally incompatible > with other IPv6 features such as really *using* source routing. > > If you want security, you *must* do cryptographic authentication. I don't believe the new ICMP messages are intended for authentication. They are for translation. That is, a node want's to know the DNS name that is associated with a particular IP address. Right now there is a reverse lookup (i.e., addr->name) supported by the DNS database. The proposal is to distribute the reverse database. The security issue is preventing a machine lying about its DNS name. This is prevented by having the querying machine lookup the name it receives in the ICMP response and compare the address it receives from DNS with the one it used for the ICMP query. The security then rests on the security of the DNS system, which is where it now rests. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 08:31:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05545; Thu, 23 Feb 95 08:31:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05539; Thu, 23 Feb 95 08:31:48 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00157; Thu, 23 Feb 1995 08:24:43 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA29736; Thu, 23 Feb 95 08:24:33 PST Received: by mitsou.inria.fr (8.6.9/8.6.9) id RAA09235; Thu, 23 Feb 1995 17:24:27 +0100 Message-Id: <199502231624.RAA09235@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net, deering@parc.xerox.com Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 1995 08:08:09 PST." <199502231608.IAA23551@elrond.Eng.Sun.COM> Date: Thu, 23 Feb 1995 17:24:26 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >If we are going to be serious about security, I think the accepted proposal >(whether it is Alex's, Bill's or a combination of these) should specify >that the name->addr lookup in DNS be part of the procedure for addr->name >mapping using the new ICMP messages. I am sorry, but the two are not equivalent. The current in-addr hierarchy authorizes the owner of network to sign that host has the domain name . The direct hierarchy authorizes the owner of domain to sign that host has the address . In one case, you trust a network provider. In the other case, you trust the domain server. On the whole, however, the best analysis was put up by Steve Bellovin. Host addresses should not be used for security, nor in fact identification. Period. Which leaves us with only one blessed usage for "gethostbyaddress", i.e. statistics. I believe that relying on portable PCs to provide on-line statistics is shortsighted. Defining a "what is your name" ICMP has some value. But we should not come to a point where *only* the host can give this information. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 08:41:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05557; Thu, 23 Feb 95 08:41:11 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05551; Thu, 23 Feb 95 08:41:03 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA17768; Thu, 23 Feb 1995 08:33:35 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA23561; Thu, 23 Feb 1995 08:33:33 -0800 Date: Thu, 23 Feb 1995 08:33:33 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199502231633.IAA23561@elrond.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Subject: Re: (IPng) ICMP name query messages Cc: namedroppers@rs.internic.net, deering@parc.xerox.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, Your recent point : > >I'm going to guess that the response is that once you get the name back > >from the remote host you're supposed to pass it to DNS and make sure that > >the original address is listed as one of the legitimate addresses for that > >host[name]. > > This should be optional. Not required. If the host is not within my > root zone then it will have found from a DNS server elsewhere which can > take more than 10 seconds. Thats too long for many applications to > wait. is understandable from a performance perspective, but not from a security one. Unless the end system does the forward lookup, it will be vulnerable to spoofing attacks. This could have adverse consequences in audit trails that are intended to document activity that later can be used to track down intruder activity. I am a little puzzled by the performance concern, however. Right now all addr->name translations are performed through DNS. Why does the forward verification make things any worse? Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 09:07:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05598; Thu, 23 Feb 95 09:07:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05592; Thu, 23 Feb 95 09:06:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03793; Thu, 23 Feb 1995 08:59:54 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA07545; Thu, 23 Feb 95 08:59:28 PST Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA22175; Thu, 23 Feb 1995 11:58:37 -0500 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/18Feb95-1123AM) id AA06226; Thu, 23 Feb 1995 11:58:31 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA01514; Thu, 23 Feb 1995 11:34:29 -0500 Message-Id: <9502231634.AA01514@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net, conta@zk3.dec.com Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 95 17:24:26 +0100." <199502231624.RAA09235@mitsou.inria.fr> Date: Thu, 23 Feb 95 11:34:29 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Christian Huitema Subject: Re: (IPng) ICMP name query messages .... Which leaves us with only one blessed usage for "gethostbyaddress", i.e. statistics. I believe that relying on portable PCs to provide on-line statistics is shortsighted. I think I expressed a quite similar view to Steve. I do not think that using ICMP will fix the DNS reverse lookup problem, perhaps just one aspect of it, but using ICMP creates or has its problems as well. Defining a "what is your name" ICMP has some value. But we should not come to a point where *only* the host can give this information. Christian Huitema Agree again. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 09:14:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05613; Thu, 23 Feb 95 09:14:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05607; Thu, 23 Feb 95 09:14:36 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04612; Thu, 23 Feb 1995 09:07:30 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA09408; Thu, 23 Feb 95 09:07:28 PST Received: from ipsilon.com by nic1.barrnet.net (8.6.8/BARRNET-RELAY.1) id JAA06912; Thu, 23 Feb 1995 09:07:24 -0800 Received: from [192.216.126.207] (acacia) by ipsilon.com (4.1/SMI-4.1MDV1.0) id AA15400; Thu, 23 Feb 95 09:05:48 PST X-Sender: hinden@servo.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="========================_10869324==_" Date: Thu, 23 Feb 1995 09:05:22 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: (IPng) Draft IPng W.G. Meeting Minutes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --========================_10869324==_ Content-Type: text/plain; charset="us-ascii" Attached is the draft version of the minutes from the Feb. 9 & 10, 1995 IPng working group meeting. Please send typographical corrections to me directly. Issues about decisions should go to the mailing list. Many thanks to Frank Solensky who produced these minutes. Bob --========================_10869324==_ Content-Type: text/plain; name="IPng-Meeting.Feb95"; charset="us-ascii" Content-Disposition: attachment; filename="IPng-Meeting.Feb95" DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT [Questions or comments that came up in my own mind while writing up these notes are identified within square brackets like these. -- FTS] Internet Engineering Task Force IPng Work Group Meeting Minutes Xerox PARC, Palo Alto, CA February 9 & 10, 1995 Introduction ------------ The IPng working group held a two day meeting at Xerox PARC in Palo Alto, CA on February 9 and 10, 1995. The meeting was hosted by Steve Deering of Xerox PARC. These minutes were produced by Frank Solensky. Core Documents -------------- The first item of business was to identify which of the IPv6-related documents are considered to be the 'core' set; that is, those that must be placed into the standards track before the IPng Area will be able to disband. The list of documents follows, with a preliminary timetable for the working group last call, as constructed by A.Mankin and listed in chronological order. They will be submitted into the standards track in approximately the same order, staggered so as to avoid overwhelming the community with too many documents at one time. The 'last call' on all of them should be issued before the Danvers IETF in April. (T ~= Feb 10) A Unicast Address Architecture T A Global Unicast Address Format T IPv6 Base Specification T + 1 week ICMPv6 T + 1 week DNS (AAAA records) T + 1 week IPv6 Address Architecture T + 2 weeks (pack authors + 1 wk) Discovery Formats T + 2 weeks (?) Discovery Processing T + 2 weeks (?) Transition Mechanisms + Routing Aspects T + 3 weeks Address Autoconfiguration T + 3 weeks Security Architecture ? Security Authentication ? ESP Encryption ? The following documents are considered to be part of the 'core' set as well but will be submitted as Informational or Experimental RFCs rather than Proposed Standards. BSD API T ? IPng Overview (including Transition Overview) T + 3 weeks Security API ? OSI NSAP Mappings (experimental) ? The following will be submitted as an Informational RFC independently of the working group. Discovery Requirements The following documents have been identified as not being part of the 'core' set and not considered critical path at this time. This DOES NOT mean that they are considered any less important or that the described functionality therein will eventually be designated as optional. Header Compression Mobility (Perkins proposal) Mobility (Simpson proposal) Mobility (Teraoka proposal) Explicit Route Protocol (ERP) FOOBAR DHCPv6 DNS Autoregistration These documents are in progress within other IETF Areas and have no impact on the dissolution of the IPng Area. OSPF RIP-II IDRP Other documents that need to be updated for support of IPv6 follow. It is unlikely that these changes will occur within the next couple of weeks, so the IPv6 documents will reference the IPv4 behavior of freely available reference implementations. IGMPv2 (IPv4 update to RFC-1112) MTU Discovery IPng Address Architecture ------------------------- B.Hinden is currently working on an update to this document and identified the following changes: - Add to the addressing model section some text about load sharing and unnumbered links. - Rewrite cluster address section to be consistant with pack address concept advocated by D.Estrin, Y.Rehkter and T.Li. Some questions about pack addresses were raised by S.Deering and forwarded to Estrin, Rehkter and Li. B.Hinden has written some new text based reading the pack definition and Deering's comments and made it consistent with the rest of the document. This text will be sent to Estrin, Rehkter and Li for review. - Reserve a 'well-known' link-local prefix for the link-local address to meet the requirements of the addrconf group. - A definition of a 'pack router' needs to be included. - wordsmithing changes. D.Haskin requested the addition of some text that explicitly indicates that the value of the address extension field within a pack address may be set to zero (as opposed to the definition of cluster address which did not allow zero values); this address would describe a cluster or pack that is contained within the a larger one. B.Simpson wanted to add a prefix to the intra-link scope address to indicate the media type in use, citing the case where a multi-homed host (ie: the 'not router') is connected to three different media: if it learns an address over each interface, each having the same value, it can't tell if it is one device that is connected over each interface or is instead different devices using the same address. However, this proposal didn't sufficiently take care of this case where all three media were all Local Talk, so the recommendation was dropped. Someone asked if the neighbor discovery section still needed to reserve the 'all hosts' address since we haven't come up with a case where it would be used; the general consensus was that this should continue to be reserved. Intra-link multicast scope addresses: text should be added that the scope diameter is defined by the organization using the address as opposed to a placeholder for something to be further defined within this document. Scope levels for multicast addresses: as discussed at the implementor's meeting in San Jose, two multicast addresses using different scope values but equal through the rest of the address are considered to be separate and distinct multicast addresses. No attempt will be made to provide IPv4/IPv6 address translation on multicast addresses. This should be mentioned in the SIT document. IANA will be asked to either obtain a new 24-bit IEEE address prefix or request the donation of a multicast block currently associated with some company's unicast block for the use of 'well known' IPv6 multicast addresses. The mapping between the IPv6 multicast address and the ethernet address will be based on the low-order 24 bits rather than the current practice of 23 bits. It was suggested that the names 'intra-link' and 'inter-link' scope addresses be changed to 'link-local' and 'site-local' in order to avoid confusion. The precise term to be used for packs/clusters/ whatever will be selected by T.Li and Y.Rekhter. After these changes are made, there will be a working group 'last call' on the resulting document. Assuming no issues come up within the following two weeks, it will then be submitted to the full IETF list for its last call before being submitted for Proposed Standard. IPv6 Base Specification ----------------------- Flow IDs: The current version of the document specifies only that a flow ID value of zero is reserved and has no special handling requirements by the intermediate routers. S.Deering reports that the end-to-end working group had requested consideration of a requirement to use non-zero valued flow IDs on all TCP connections. They had suggested potential arguments for this approach but had not yet provided a detailed proposal for initializing the flow IDs or managing them all in router processing. The rough consensus among those present was that while this work is important, it wasn't on the critical path to getting early implementations going. F.Solensky asks if we might be putting ourselves into the chicken-and-egg IPv4 ToS dilemma: S.Bradner reminds the group that Proposed Standard is still a very early stage of the standards process so that this risk is relative small; in order to prevent this from occuring, we should not advance the document to Draft Standard until the field and its usage are specified. E.Nordmark pointed out that the spec states that the host learns the flow ID values from the routers but had no provisions for timing out the implied state mechanism behind this operation. R.Elz had suggested on the mailing list that if a router had not seen traffic over a given flow within three seconds, it should time the flow out; G.Minshall cautions that exclusine reliance on this could lead to the BSD ARP problem: a babbling flow cause routers to never time out an entry. D.Haskin was concerned that three seconds might be too small: use of a fixed low resolution timer (ie: BSD slow timeouts) would cause some percentage of flows to exist longer than they should while use of a high-resolution timer means that the router spends a greater number of cycles updating these timers; a longer time interval lessens this overhead. He asked for a ten second timeout instead, the rough concensus was to split the difference at six seconds. Outstanding question: a host reboots and forgets the state that it had set up earlier with other nodes. Is the host prevented from setting up a new flow as a result? People in the room generally felt that the amount of time it takes a host to reboot is almost always greater than the six-second timer, so this shouldn't be a major issue. A suggestion was made by the ERP authors that the originator of the flow should specify what to do when the router loses state. The end2end group indicated that this was not the case and that this occur as part of the flow setup protocol itself rather than using bits within the flow ID field to accomplish this. Text needs to be added pointing out that header compression should not depend upon the existance of flow ids: the two concepts are orthoginal. Explicit Routing Protocol (ERP): In San Jose, one of the work items was to replace the 'type 0' routing header with references to the Explicit Routing Protocol. The header format from ERP has been agreed upon and will replace the former 'type 0' routing header. However, the SDR WG is not ready to submit ERP's proposal for a last call, so the IPv6 base specification should not include specifics on the protocol processing of the ERP header. Minimum MTU/Reassembly sizes: Prior to this meeting, both the minimum MTU and reassembly sizes were 1500 (or 1492) bytes. Several compelling points came up during this part of the meeting that lead the group to lower both back values down to 576 bytes: - the LocalTalk problem: the maximum packet size for LocalTalk is 587 bytes. While there was a preference to recommend that media with small MTUs devise a link-level fragmentation/reassembly scheme that would take place only for that single hop, there was also recognition of the fact that the group did not have the means to mandate this; even if it did, it was unrealistic to believe that it would be feasible to upgrade the entire installed base. - Defining the minimum MTU at a relatively high value would lead towards fragmentation when a packet grows while in transit (ie: tunneling). Current MTU Discovery algorithms don't indicate when or how much packet growth occurs. - Use of a reassembly size greater than the minimum MTU could encourage people to not implement MTU discovery. Retransmissions would require the sending of multiple packets when the most likely case is that only a single packet was lost in transit. - While DNS was a large motivating factor for the large MTU sizes, people who had attended the DNS meeting earlier in the week indicated that anticipated future uses such as the exchange of public keys would necessitate moving away from UDP as the transport protoco, opting for either TCP or Transactional TCP instead. Other items: S.Deering is working on an update to the MTU Discovery RFC that includes changes made to the algorithms based on implementation experience. The new algorithm will also be incorporated into the IPv6 Base Specification. A suggestion was made that the MTU Discovery RFC update be written in a manner that did not limit itself to IPv4. A person relatively new to IPng was surprised to learn that the IPv6 header was not checksummed, others he had asked about this were equally surprised to learn that they had forgot the rationale. It might be advisable to add a paragraph that provides a description that the IPv4 checksum was itself not highly reliable and that the authentication header provides a higher degree of protection when it is used. A Unicast Address Architecture: ------------------------------- While some have reservations about the underlying approach, the document itself seems to be technically accurate and consistant. Someone asked if the document should be submitted as an Informational RFC rather than as a Proposed Standard; there didn't seem to be strong feelings one way or the other. The Working Group Last Call should be issued on the current draft as is. A Global Unicast Address Format: -------------------------------- S.Deering expressed concern that the plan places an emphasis on aligning address assignments on byte boundaries but didn't feel that this was a major issue. The Working Group Last Call can be issued on the current draft as is. ICMPv6: ------- Text indicating that the received 'Echo Request' message must be delivered to the upper layer needs to be softened: while it's true that an incoming 'Echo Reply' must be delivered up to a waiting process (usually the one that generated the original Request message), there is a lower likelihood of a process waiting to receive incoming 'Echo Request' messages. The description of the codes for the ICMP Destination Unreachable message (type 3) needs to be modified so that it is consistant with the most recent draft of Router Requirements which in some places obsoletes RFC-1122. Specific changes discussed were: - message code 6 should be removed - codes 0 and 1 need modification - use of the code 7 is to be resolved between the authors. - there was some question as to whether it is possible or important to make the distinction between the last hop router being unable to deliver a packet and any other router as implied in some of the other codes. Some feel that the transmission of an 'administratively prohibited' error message back to the originating host presents a compromise in security. If there is some other document either prohibits this or makes it a configurable option, this document should reiterate that recommendation. The description of the ICMP Packet Too Big message (section 3.2) should mention that it can be sent in response to a packet with a multicast destination address (as described in rule D.2 on page 6). Some Type and Code values are listed as 'TBD's; specific values need to be assigned before the document can be advanced. The description and format of a request/reply message pair for accessing the fully-qualified name of the node should be added: this came up as part of the discussion that removes the requirement for reverse DNS lookups (see 'DNS (AAAA records)'). Text needs to be added referring to the use of IGMP messages, either referencing a soon-to-be-written update to RFC-1112 or incoprorating their descriptions into this document. Message description and formats should be specified as well. [Minor: The phrase "node or router" appears in some places in the document; these should instead be either "node" or "host or router" as per the convention we've agreed to on the list. This may be occuring in other documents as well; I noticed it here just now.. -- FTS] [I've got "security SAID" jotted down and don't recall what this was in reference to. Another note reads "Source node isolated? Can get from IPv6 header" -- FTS] DNS (AAAA records): ------------------- There is a growing aversion to the continued support for inverse domain name lookups and reverse DNS in general: updating the reverse tree manually is becoming increasingly difficult task, updating it dynamically is very hard. Further, the continued support of reverse lookups may be creating a false sense of security. Recognition of these external factors lead the group to consider removing the references to the inverse tree from the current draft, stating instead that there is no inverse tree and providing the rationale. Drawing this line in the sand would then provide the IETF an opprutunity to face the question as to whether it feels that continued support for this is either required or even desirable. It was noted that this proposition would require that an alternative proposal be presented. An easily implemented alternative is the creation of a new ICMP request/reply message pair for requesting the fully- qualified name of a node that would be initiated when an application issues a gethostbyname() procedure call. This would require the node knows its fully-qualified name within the kernel and would represent a change to some systems. A major advantage of this approach is that the automatic DNS updates become easier since the reverse mapping tree does not also need to be updated. R.Callon notes that this is an improvement over reverse name lookups in that it relies only on the already existing routing infrastructure rather that both that and the domain name system (which in turn relies on the routing infrastructure for its updates). FOOBAR: ------- D.Piscatello has agreed to update to RFC-1545 but the time at which this could be completed is uncertain. The only issue identified during a cursory review of the document during the meeting was that the address family types had to be included: a more through analysis needs to be undertaken. BSD API: -------- There was a request for the addition of a timeout parameter on the addr2hostname procedure. [Page 15: "addr2hostname() performs an inverse lookup in the name service"... If the reverse DNS changes are made, this text would have to be modified. -- FTS] addr2ascii(): the buffer supplied must be at least 46 bytes, not 40 as listed. [After the meeting it was noted that the only time that the last four bytes would be in dotted-decimal notation is when the address is either IPv4-only or IPv4-compatible. In both cases, the "::" convention would prevent the resulting string from getting that large.] A reference to the "::" zero-suppression convention should be included for both addr2ascii() and ascii2addr(). Also, both functions should mention that the buffers holding the network addresses store them in network byte order. An explicit reference to the security API document needs to be added. Security API: ------------- References to BSD-specific features (ie: SIGURG) should be removed from the document. A general question came up about ICMP and security: if there is a goal to make all ICMP messages secure, it becomes problematic to take a node "out of the box" and have it interoperate right away -- generally, some manual configuration needs to occur in order for the node to be capable of decrypting the ICMP messages it receives. The mailing list last call on this document should be issued before the Danvers IETF. IPng Overview: -------------- While the document will be submitted as part of the core group, it will be as an informational RFC rather than a proposed standard. The Reverse Source Route section of the document needs to be updated to reflect some recent changes. There should be a mention of the fact that IPv6 Address Translation is considered as an area for further study, possibly with some mention of the guidelines for its use and its visibility. IPv6 Transition Mechanisms + Routing Aspects: --------------------------------------------- On Thursday afternoon, Bob Gilligan started the discussion on issues in the Transition Mechanisms spec. Jim Bound suggested that DHCPv6 be listed as one of the mechanisms by which a node could acquire an IPv4-compatible address. Bob agreed to make the change to the spec. On Friday morning, Ross Callon presented a list of transition mechanisms which he thought there was general agreement on, prioritizing them in an easy-to-hard order: - A "dual stack" node using IPv4 with native IPv4 addresses, and IPv6 with native IPv6 addresses. Can directly interoperate with both IPv4 and IPv6 nodes. - Dual node using manually configured IPv4 tunnels for exchanging IPv6 packets over IPv4 routing areas. - Dual nodes reachable only via IPv4 routers, using the IPv4-compatible (::FFFF:) address format with encapsulation and (auto-)tunneling to such nodes. - Dual nodes encapsulate to the 6-bone using an IPv4 well-known address (WKA). It was noted that if an host has an IPv4-compatible address assigned to it, it will be required to support automatic decapsulation on received packets and encapsulate transmitted ones. Ross also proposed that there is not general agreement on: - Header translation. - Use of the IPv4-mapped (::) address format in header translation. There was general consensus that the transition mechanisms spec should specify only the four items on Ross's first list (IPv4-compatible addresses and tunneling), and should not specify or discuss the items on the second list (IPv4-mapped addresses and header translation). There was consensus that the IPv4-mapped address format would continue to be "reserved" in the Addressing Architecture document. There was some further discussion of the organization of the transition documents. The group agreed that the Transition Mechanisms spec should be made into a single standalone document by adopting a short (approx 1 page) introduction from the Transition Overview document, and adding some explanation of routing from the Routing Issues document written by Ross Callon and Dimitry Haskin. Ross and/or Dimitry Haskin agreed to donate the words from the Routing Issues document. Bob Gilligan agreed to make the necessary changes to the Transition Mechanisms document and re-issue a new internet-draft within 3 weeks. There was some discussion of the SIT Overview document. There was agreement that much of the information from this document could be merged into the IPng Overview document that Bob Hinden is authoring. Someone suggested that the document should note that automatic tunnels are always IPv6 over IPv4 tunnels, while manually configured ones can be either IPv4 over IPv6 or vice versa. There was some discussion on the use of a well-known IPv4 address as the default tunnel to reach the 6-bone. An IPv6 island ('host' being the degenerate case) that needs to send IPv6 packets across an IPv4 stub/area to reach a destination on the 6-bone could do so by tunneling to the well-known IPv4 address. A dual router bordering the 6-bone can advertise reachability to this address into the IPv4 area. Greg Minshall noted that there may be a patent issue with Peer Logic when using this approach; Bill Simpson notes ham radio as prior art. Address Configuration: ---------------------- Automatic address configuration: There is a growing consensus that the attempt to design a single mechanism for address autoconfiguration that covers all scenerios from the dentist's office to the large, centrally administered site is too ambitious. There will instead be two separate configuration mechanisms developed and proposed; one for the "plug & play" (stateless) environment, one for dynamic protocols with central administration (stateful, DHCPv6). The document that will be submitted as part of the core group is the stateless version so that early implementations may proceed; work on the stateful version will continue within the DHCP group. The working group will change the name of the document to "IPv6 Stateless Address Autoconfiguration" so that there is less of a chance that this proposal is interpreted as being the only manner in which IPv6 will perform address autoconfiguration. The order in which operations occur in the stateless case are: - Address autoconfiguration - Router advertises subnet parameters (ie: max ttl) - Service Location - Auto registration with DNS Stateless address autoconfig breaks down into two cases: the passive case being where the host performs the concatenation between the prefix and its address token; the active case where the host sends a query to the router (or some other server) which in turn determines the full address (via a concatenation operation, DHCP query, etc) before returning it to the host. A drawback of the first approach is that the mechanism becomes difficult or impossible to change once it is deployed. The Passive Stateless autoconfiguration approach also requires that one and only one link-specific algorithm is used for the host to select its address. These potential drawbacks were not considered to be showstoppers and the passive mode was agreed to. DNS Autoregistration: S.Thompson gave an overview of the discussions of the DNSIND working group that took place earlier in the week. There was progress made on the coming up with an approach for automatic name registration and address configuration. Some of the security details still needed to be worked out, along with some concern that the stateless approach would be vunerable. The group felt it should limit itself to the IPv4 approach at this time, working with the DNSIND group to be sure that the hooks that they determine are necessary would be available. S.Deering notes that name registration need not be bound to the address allocation. Router advertisement messages in the passive stateless case would indicate which address mode was in use, if further configuration was necessary and includes an indication of valid and deprecated subnet prefixes. It might be necessary to override this information, and allow for the case where the site cannot reach the DHCP server. The host behavior in the passive case is as follows: - on initializatiom, the host forms the link-local scope address and sends a router solicitation message. - The router advertisement message indicates 'stateless' or DHCP (the host waits 3x max router solicitation interval, then performs DHCP queries). - on receiving the address prefix router advertisement message (includes the lifetime field): > if it is a renewal, validates existing address with existing prefix, > else if new, adds new address with new prefix, > otherwise, deprecates the address. This last point was dropped however, when it was determined that it could cause problems when multiple routers were present: depreciation should only occur when explicitly requested. - when the entry times out (the router is down and stops advertising; the prefix is no longer advertised but not explicitly dropped either), the host accepts packets addressed to the old address. The old address gets lower priority than the link-local for source addresses. Existing open connections (ie: TCP) would continue to use the old address; new incoming connections get the link-local address instead. The main body of the text will describe the general approach of the proposal and indicate that the media-specific details will vary. An appendix will be added that describes how address configuration occurs within an IEEE-style address environment as an example. The goal is to have a new version of the draft available in two weeks, three at most. Neighbor Discovery Format: Neighbor Discovery Processing: ------------------------------ The current Format draft included the change discussed at the San Jose meeting that set the granularity of the LifeTime field in the I-Am-Here advertisement message at one millisecond rather than one second in order so that it would have the same granularity as that used for SNMP timer values. There was, however, some question as to what field width was agreed upon at that meeting and what that width should be. In his capacity as Area Director, S.Bradner advised that the field should be changed to a 32-bit value so as to avoid future problems should a maximum interval of ten seconds eventually prove to be too low for some situations. Rather than using the Known-Identifier field to sometimes refer to an identified assoicated with the sender and sometimes the receiver, it was suggested that these be modified into separate Source-Identifier and Destination (or Target)-Identifier extentions so as to clarify the specification and the protocol. The format would be identical to that of the current Known-Identifier extention. An extended discussion was initiated by an observation that the IPv6 address is not included within the General Solicitation message; this broadened into a philosophical difference in opinion over proxy servers. A.Conta and E.Nordmark took the position that proxy servers offer greater flexibility while S.Deering and B.Simpson saw them as compromising the overall robustness and security of the network. It was decided that this aspect of the document would be left unchanged for now; support for proxy service is a higher-level issue that reaches well beyond the scope of this individual document. There was some question within the group about the situations in which the Node Heard and System Heard messages would be used; B.Simpson offered a 'half-link' scenerio in which communications between two hosts and a router could take place but two-way exchanges were not guaranteed -- a common case within ham radio stations -- and allows the two hosts to learn when they can avoid the router in the middle and communicate directly. The rough consensus among those present was that while the proposal itself is intriguing, it was a problem that deserved greater attention and needed a more exhausitve explanation than that currently provided within the Neighbor Discovery Message Formats document. Further, since the documents that are related to mobility are not going to included among the core set, the group requested that references to the Node Heard messages be omitted at this time, replaced instead with a two or three paragraphs that indicate that the protocol can be extended to support mobility. System Heard messages would be used over those link-level protocols where the media- specific problems it is designed to solve are likely to be a concern. B.Simpson expressed a concern that these changes might cause support for mobility to never be deployed; S.Deering reiterated his goal of ensuring that no shipping IPv6 router is unable to support mobility, S.Bradner later reminded the group that Proposed Standard documents are not considered to be in their final form. Another discussion took place over the proposed usage of General Soliciatation and General Advertisement messages for address resolution. Two concerns were expressed: the first being that address resolution has traditionally been implemented in a manner that is cognizant of the characteristics of the link layer protocol rather than using a general-case approach for all media, the second being that the proposal requires the exchange of four messages since the receipt of a General Solicitation message could not instanciate address mapping in the route cache for the sender of the General Soliciataion message. The group wanted to limit discovery to two messages in order to avoid sending more multicast/broadcast messages than IPv4 ARP Request/Reply exchanges and suggested that the approach currently described in the Discovery document be moved into "IP-over-" documents, to be used only in those environments where it would be beneficial. --========================_10869324==_-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 10:00:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05643; Thu, 23 Feb 95 10:00:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05637; Thu, 23 Feb 95 10:00:38 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB10115; Thu, 23 Feb 1995 09:53:32 -0800 Received: from auspex-gw.Auspex.COM by Sun.COM (sun-barr.Sun.COM) id AA20813; Thu, 23 Feb 95 09:53:33 PST Received: from auspex.Auspex.COM (auspex-e5.auspex.com) by auspex-gw.Auspex.COM (4.1 1/7/93 /SMI-4.1) id AA24730; Thu, 23 Feb 95 09:53:30 PST Received: from coastsider.auspex.com by auspex.Auspex.COM (4.1/SMI-4.1) id AA17579; Thu, 23 Feb 95 09:53:29 PST Date: Thu, 23 Feb 95 09:53:29 PST From: wayne@auspex.com (Wayne Hathaway) Message-Id: <9502231753.AA17579@auspex.Auspex.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM About the proposed "who are you?" ICMP message, I have concerns about its efficacy, but I will keep these to myself since I don't have the DNS experience to appreciate all the issues. HOWEVER, since I work at a company that makes multihomed hosts big time, I would like make one point about terminology: What we are talking about is *NOT* a "host name" or a "node name," nor even an "interface" name. Instead, it is an *IP ADDRESS* name, since it is merely a character string that has been assigned to a particular IP address, where that IP address has been assigned to a particular interface on a particular machine. [Whew!] Putting this another way, consider the following sequence of "definitions": HOST/NODE: A computer. INTERFACE: A connection between a host/node and an internet. A host/node can have multiple interfaces. IP ADDRESS: A path through an internet to an interface. An interface can have multiple IP addresses. DOMAIN NAME: A string that maps to an IP address. An IP address can have multiple domain names. At this point I think it is obvious that the relationship between a host/node and a domain name is VERY tenuous! This is why I get concerned when I see things like: "But I would prefer in IPv6 one host name per address and really ONE HOST NAME PER NODE WOULD BE EVEN BETTER." Many of our servers have 20 or 30 interfaces each; what's the "one host name" of such a server? And back to ICMP, do we really want to return 20 or 30 names for a single query? Not to mention the SPACE that 20 or 30 fully qualified domain names would require -- anybody for a 64Kbyte MTU? :-) As to why this makes any difference, consider an analogy: Think about those answering services that one-man businesses like plumbers and tax preparers use. What they say when they answer the phone is determined by what line they are answering: 555-1234 rings, answer "Joe's Plumbing"; 555-6666 rings, answer "EasyTax." Now if I say "What business is at 555-1234?" do I want the answer "Joe's Plumbing" or "Sam's Answering Service"? Do I care about "EasyTax" at all? Or do I in fact want Sam's complete client list? So exactly what do we want when we say "What host is at 1.2.3.4?" By the way, people make money printing reverse telephone directories. Why? Why don't the people who buy reverse directories just call the number and ask who's there? Maybe understanding this would help in understanding the issues in replacing IN-ADDR. Anyway, I realize the multihomed host problem is insoluble :-), but please, let's not go out of our way to make it worse. Wayne Hathaway Internet: wayne@auspex.com Auspex Systems Phone: 408-986-2044 5200 Great America Parkway FAX: 408-986-2020 Santa Clara, CA 95054 PS: About Jim's quote above, I *DO* like the idea of an interface-independent hostname, and think such a thing would be very useful for multihomed hosts. But it should be part of an overall multihomed hosts solution, and not an ad hoc "nickname" or something. And of course such a name would be in ADDITION to the address-specific names... ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 10:35:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05693; Thu, 23 Feb 95 10:35:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05687; Thu, 23 Feb 95 10:35:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15096; Thu, 23 Feb 1995 10:28:18 -0800 Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA29718; Thu, 23 Feb 95 10:28:17 PST Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id NAA17770 for ipng@sunroof.Eng.Sun.COM; Thu, 23 Feb 1995 13:28:12 -0500 Date: Thu, 23 Feb 1995 13:28:12 -0500 From: Vadim Antonov Message-Id: <199502231828.NAA17770@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I belong to those who have some reservations and find that the proposal is a >bit too simple. My two main concerns are: >1) First, a problem of deployment. Autoconfig is typically used by small > machines, many of which have a single task OS, or are in general ill > equipped to be used as servers. Think of portables. Each request will > fire up the CPU and drain the batteries. No problem. In the Real World (tm) reverse DNS queries are only used to "authenticate" the originators of connections (and for diagnostic purposes, but so are pings which sure drain the batteries). >2) Second, a problem of trust. How can I prove that the host responding to the > getnamebyaddress request is not serving me with a phony answer? That is also not a problem -- when you got the name, do direct lookup. Exactly the same way paranoid resolvers are doing today. >There may also be a way to solve the second problem, e.g. by having some >authorized agent sign on the user. In short, I would add the ICMP "tell me >your name" request, but I would also keep the IN-ADDR spec as is. Where would you hide from angry netadmins? Mongolia will be reasonably safe for some time, i venture to guess :) Featurism is evil. --vadim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 10:48:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05722; Thu, 23 Feb 95 10:48:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05716; Thu, 23 Feb 95 10:48:42 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16790; Thu, 23 Feb 1995 10:41:37 -0800 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA03330; Thu, 23 Feb 95 10:41:36 PST Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA24586; Thu, 23 Feb 95 13:31:53 EST Received: from andover.wellfleet by wellfleet (4.1/SMI-4.1) id AA24842; Thu, 23 Feb 95 13:44:54 EST Date: Thu, 23 Feb 95 13:44:54 EST From: dimitry_haskin@wellfleet.com (Dimitry Haskin) Message-Id: <9502231844.AA24842@wellfleet> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Draft IPng W.G. Meeting Minutes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > D.Haskin requested the addition of some text that explicitly indicates > that the value of the address extension field within a pack address may > be set to zero (as opposed to the definition of cluster address which > did not allow zero values); this address would describe a cluster or pack > that is contained within the a larger one. > This is not accurate description of my request -- it has nothing to do with cluster/pack addresses. It is just that, since the current (old) Address Architecture draft prohibits the value zero at each level of the unicast address hierarchy and it has been decided to remove this restriction, I requested to explicetly state in the updated draft that zero can be a valid number at some levels of the unicast address hierarchy. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 11:03:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05738; Thu, 23 Feb 95 11:03:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05732; Thu, 23 Feb 95 11:03:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18666; Thu, 23 Feb 1995 10:55:53 -0800 Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA06566; Thu, 23 Feb 95 10:55:33 PST Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.6.10/8.6.10) with ESMTP id NAA16952; Thu, 23 Feb 1995 13:55:30 -0500 Message-Id: <199502231855.NAA16952@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net, deering@parc.xerox.com Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 1995 10:01:35 +0100." <199502230901.KAA07572@mitsou.inria.fr> From: Valdis.Kletnieks@vt.edu Date: Thu, 23 Feb 1995 13:55:30 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Thu, 23 Feb 1995 10:01:35 +0100, Christian Huitema said: > 1) First, a problem of deployment. Autoconfig is typically used by small > machines, many of which have a single task OS, or are in general ill > equipped to be used as servers. Think of portables. Each request will > fire up the CPU and drain the batteries. Umm.. I admit being a bit confoozled here. Are there any cases where (for instance) a portable would get such an ICMP request unless either (a) it had just sent a packet to somebody who was checking back who it came from (and thus the CPU is fired up already) or it's somebody probing preparatory to initiating a connection (in which case we'll get fired up in a few milliseconds ANYHOW)? As an example - my systems tend to generate a lot of IDENTD calls, because we run a copy of tcp_wrapper that supports this. But I don't go poking anybody's identd port unless they're already poking at me.... Valdis Kletnieks Computer Systems Engineer Virginia Tech ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 11:58:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05796; Thu, 23 Feb 95 11:58:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05790; Thu, 23 Feb 95 11:58:27 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26273; Thu, 23 Feb 1995 11:51:21 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA19305; Thu, 23 Feb 95 11:51:14 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA00626; Thu, 23 Feb 95 11:48:04 -0800 Received: by xirtlu.zk3.dec.com; id AA27107; Thu, 23 Feb 1995 14:46:42 -0500 Message-Id: <9502231946.AA27107@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net, deering@parc.xerox.com Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 95 17:24:26 +0100." <199502231624.RAA09235@mitsou.inria.fr> Date: Thu, 23 Feb 95 14:46:35 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM IDEA ??????? >Defining a "what is your name" ICMP has some value. But we should not come to >a point where *only* the host can give this information. I agree with Christian here. I think we need the ICMP msg. But can we r-think another approach to getting the address. Sue, Yakov, and I are working on DYN Update now and (Paul Vixie). How about the four of us think about this and see if we can come up with a proposal that is more useful and will be used and not with a new tree as in.arpa now. We have a month until Danvers I think at least we can look at the problem. I for one want to scan the code a bit too. So for the ICMP spec we leave it in and move that draft to where we want to get it and lets a few us go do some research for a better answer. If Yakov, Sue, and Paul are game I can put some cycles into this. Then we can report back to the WGs what we find. I still hope we hear from those operators too on how this is being used today. This would be work ONLY FOR IPv6 I don't think we should be messing around with IPv4. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 12:14:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05832; Thu, 23 Feb 95 12:14:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05826; Thu, 23 Feb 95 12:14:31 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28429; Thu, 23 Feb 1995 12:07:24 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA22832; Thu, 23 Feb 95 12:07:14 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA02020; Thu, 23 Feb 95 12:02:41 -0800 Received: by xirtlu.zk3.dec.com; id AA27549; Thu, 23 Feb 1995 15:01:16 -0500 Message-Id: <9502232001.AA27549@xirtlu.zk3.dec.com> To: Danny.Nessett@Eng (Dan Nessett) Cc: ipng@sunroof.Eng.Sun.COM, namedroppers@rs.internic.net, deering@parc.xerox.com Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 95 08:33:33 PST." <199502231633.IAA23561@elrond.Eng.Sun.COM> Date: Thu, 23 Feb 95 15:01:10 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Danny, >Your recent point : >> >I'm going to guess that the response is that once you get the name back >> >from the remote host you're supposed to pass it to DNS and make sure that >> >the original address is listed as one of the legitimate addresses for that >> >host[name]. >> >> This should be optional. Not required. If the host is not within my >> root zone then it will have found from a DNS server elsewhere which can >> take more than 10 seconds. Thats too long for many applications to >> wait. >is understandable from a performance perspective, but not from a security >one. Unless the end system does the forward lookup, it will be vulnerable to >spoofing attacks. This could have adverse consequences in audit trails that >are intended to document activity that later can be used to track down >intruder activity. I agree with you and thats why I think we need it. But the reason I want it to be an option is that looking for the name might be on my LAN which is in my building in fact in my office. By now I think when people see my name in mail regarding security it means I coming from the perspective that all security causes a performance hit. This means cost. Many users simply do not have a security problem and never will. On the Internet or if your network is open to an attack yes you MUST have security. But to say I MUST use it on my LAN or a non-Internet customer MUST use it in their engineering plant (as an example) is first confusing all markets to be the same and two simply not required. >I am a little puzzled by the performance concern, however. Right now all >addr->name translations are performed through DNS. Why does the forward >verification make things any worse? But with ICMP its a message to a Node and then a response with a name. If the Node does not know its name it does not respond or send a NAK. If the host when it receives the ICMP message now check the name thats more CPU cycles, code exeucution, and a DNS access that I do not think is necessary in all cases as I stated above. Dan this is not to you but: I am not AGAINST security. I AM AGAINST PUTTING A BUSINESS REQUIREMENT ON VENDORS THAT IS NOT FOR ALL CUSTOMERS IN A STANDARD. BUILD THE SECURITY STANDARD IN THE PROTOCOL. MAKE IT OPTIONAL AND IF THE MARKET WANTS IT THEN THEY WILL NOT BUY VENDORS SYSTEMS WITHOUT IT. THE IETF HAS DONE THEIR JOB BY SPECIFYING IT AND THEN TESTING IT WITH IMPLEMENTATIONS BUT PLEASE STAY OUT OF THE BUSINESS OF PRIVATE ENTERPRIZE WHEN YOU HAVE NO EXPERTISE N MAKING PROFIT AND DEALING WITH LIVE CUSTOMERS. OUR (IETF) MISSION IS TO BUILD STANDARDS NOT MAKE THE WORLD REPENT FOR THEIR SINS OF NOT USING SECURITY IN NETWORKING. THE ENTIRE MANDATE OF SECURITY IS JUST TO 'SOCIALISTIC' FOR MY TASTES AND I STILL BELIEVE IN ADAM SMITHS WEALTH OF THE NATIONS AS A BUSINESS AND CREATIVE PRINCIPAL orry this is a U.S. centric view on my part). /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 12:27:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05861; Thu, 23 Feb 95 12:27:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05855; Thu, 23 Feb 95 12:27:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29774; Thu, 23 Feb 1995 12:20:23 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA25671; Thu, 23 Feb 95 12:20:24 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA03375; Thu, 23 Feb 95 12:15:52 -0800 Received: by xirtlu.zk3.dec.com; id AA28110; Thu, 23 Feb 1995 15:14:48 -0500 Message-Id: <9502232014.AA28110@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Draft IPng W.G. Meeting Minutes In-Reply-To: Your message of "Thu, 23 Feb 95 09:05:22 PST." Date: Thu, 23 Feb 95 15:14:42 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob/Frank Thanks. Nothing jumped out to me that was incorrect. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 12:49:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05914; Thu, 23 Feb 95 12:49:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05908; Thu, 23 Feb 95 12:49:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02469; Thu, 23 Feb 1995 12:42:21 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA00676; Thu, 23 Feb 95 12:42:20 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA05326; Thu, 23 Feb 95 12:35:31 -0800 Received: by xirtlu.zk3.dec.com; id AA28939; Thu, 23 Feb 1995 15:34:28 -0500 Message-Id: <9502232034.AA28939@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 95 09:53:29 PST." <9502231753.AA17579@auspex.Auspex.COM> Date: Thu, 23 Feb 95 15:34:22 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Wayne, Your mail made me think more. Its good to get real world input we need more of that IMHO. But just so I am clarified correctly. My comment on host name had this vision: just_for.jones.com AAAA AF:BA:GF:CC:12:E2:7B:21 AAAA AF:BA:GF:CC:12:E2:7B:22 AAAA AF:BA:GF:CC:12:E2:7B:23 AAAA AF:BA:GF:CC:12:E2:7B:24 ....................... The point is that the DNS can support multiple addresses for a host. This reduces the efficiency of an application if it has to attempt each address on a send. So if each address only has one host name then that efficiency is guaranteed. So now I am thinking (really off the top of my head): If we say in IPv6 a host name can only have one address I think that will get to where my vision should be. I think this supports your multi-home interfaces too. But this does not support naming your interface right? So do we need a new DNS AAAI record to store the interface name? FYI in the present DHCPv6 draft in the protocol we key off the interface (as specified in stateless addr conf) to support maintaining state for each host client at the server. So we have client interface (which we identify as 64bit random number right now) addr1 addr2 addr3 But if we did not name an interface then I guess if I wanted to build a multihome host server I could maintain the state similar to the suggestion in DHCPv6 and there is no need to name an interface maybe? So how about in IPv6 a host name can only be associated with one IPv6 address? Comments??? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 13:19:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05936; Thu, 23 Feb 95 13:19:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05930; Thu, 23 Feb 95 13:19:32 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05622; Thu, 23 Feb 1995 13:12:28 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA06567; Thu, 23 Feb 95 13:12:13 PST Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA20812 for ipng@sunroof.eng.sun.com; Thu, 23 Feb 95 16:12:02 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id NAA21423; Thu, 23 Feb 1995 13:12:07 -0800 Message-Id: <199502232112.NAA21423@aland.bbn.com> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of Thu, 23 Feb 95 15:34:22 -0500. <9502232034.AA28939@xirtlu.zk3.dec.com> From: Craig Partridge Date: Thu, 23 Feb 95 13:12:06 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM So how about in IPv6 a host name can only be associated with one IPv6 address? Jim: I think this breaks the real-world customer. If you map one name to one address then the user needs to guess which name is the right one to connect to a host. There are often situations in which one interface is accessible but another is not. The simplest is that an interface may have broken and the host is awaiting an overnight board swap. Firewalls and filters also cause cases where depending on where a host resides in the network, different interfaces are accessible or inaccessible. So instead of giving you my address as craig@bbn.com (and figuring your mailer is smart enough to find a working address) or FTP server address (figuring your mailer is smart enough to find one that works), I have to give you list "well, if BBN.COM doesn't work try CRAIG@IF2.BBN.COM or CRAIG@IF3.BBN.COM". My business card will have to expand dramatically just to list all my e-mail addresses. I think the whole concept of name mapping is that I give you a NAME, and the application is smart enough to figure out how to connect you there. Most Internet applications already know how to deal with a list of addresses. They may not do perfectly smart things with the list (they may just cycle through each entry until one works), but at least they are fairly robust about providing connectivity. In a world in which we are moving to give people universal phone numbers and the like, I think individually name each interface (where interfaces are just artefacts of being connected to a network) is a mistake. Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 13:40:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05957; Thu, 23 Feb 95 13:40:07 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05951; Thu, 23 Feb 95 13:40:00 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id NAA11752; Thu, 23 Feb 1995 13:32:39 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id NAA23685; Thu, 23 Feb 1995 13:32:27 -0800 Date: Thu, 23 Feb 1995 13:32:27 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199502232132.NAA23685@elrond.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages Cc: namedroppers@rs.internic.net, deering@parc.xerox.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian, The point you make, viz. : > I am sorry, but the two are not equivalent. The current in-addr hierarchy > authorizes the owner of network to sign that host has the > domain name . The direct hierarchy authorizes the owner of domain > to sign that host has the address . In one > case, you trust a network provider. In the other case, you trust the domain > server. is a good one. There is, as you point out, a change in the trust model for translating addresses into domain names. However, when you write : > On the whole, however, the best analysis was put up by Steve Bellovin. Host > addresses should not be used for security, nor in fact identification. Period you are confusing translation with authentication. No one is saying (at least I am not) that you should be using the DNS reverse lookup or its proposed ICMP equivalent for identifying a host. Just because a host with a particular IP address responds that its name is foo.bar.com and just because that agrees with the data in a DNS database doesn't mean you have identified the host. Without a separate means of host authentication (e.g., use of the IPv6 authentication header) you have no way of knowing that the host to which you are communicating is the one to which you sent the IP message (e.g., any host that can view a IP packet on its way to the destination host can respond to it). So, the reverse lookup is simply a way of translating identifiers more suitable for machine handling (e.g., IP addresses) into identifiers more suitable for human reading (e.g., DNS names). Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 14:53:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05987; Thu, 23 Feb 95 14:53:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05981; Thu, 23 Feb 95 14:53:06 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16591; Thu, 23 Feb 1995 14:46:00 -0800 Received: from sgigate.sgi.com by Sun.COM (sun-barr.Sun.COM) id AA23838; Thu, 23 Feb 95 14:43:35 PST Received: from sgihub.corp.sgi.com (sgihub.corp.sgi.com [192.26.51.188]) by sgigate.sgi.com (950215.405.SGI.8.6.10/8.6.4) with ESMTP id OAA10021; Thu, 23 Feb 1995 14:43:22 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id OAA20806; Thu, 23 Feb 1995 14:43:20 -0800 Received: from gauss.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:anderson@lll-crg.llnl.gov id AA17738; Thu, 23 Feb 95 14:42:50 -0800 Received: from localhost by gauss.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id OAA03072; Thu, 23 Feb 1995 14:38:19 -0800 Message-Id: <199502232238.OAA03072@gauss.asd.sgi.com> From: leedom@gauss.asd.sgi.com (Casey Leedom) To: president@whitehouse.gov (President Bill Clinton), vicepresident@whitehouse.gov (Vice President All Gore) Cc: annagram@hr.house.gov (Honerable Anna Eshoo) Subject: (IPng) Please drop cryptology export controls Date: Thu, 23 Feb 1995 14:36:26 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Casey Leedom Mail Stop: 8U-590 Silicon Graphics, Inc. 2011 N. Shoreline Blvd Mountain View, CA 94043-1389 To: President Bill Clinton, Vice President All Gore Cc: The Honerable Anna Eshoo Re: Please drop cryptology export controls Dear Mr. President and Vice President, This is a post script to my message of yesterday. I'm reading the discussions on the next generation Internet Protocol (IPng) mailing list. On that mailing list, the brightest engineers and networking experts we have are agonizing about how to provide security in the next generation of Internet protocols. One of the constant themes of conflict is: 1. Any security scheme is meaningless if we don't include cryptography in the base document and implementation requirements. 2. If we do include cryptography in the base document and implementation requirements vendors won't be able to export their products. This will prevent them from marketing those products internationally (and also prevent vendors in other countries from marketing their products in this country). Thus no one will buy off on the new protocol and people will use the current protocol until it fails because it can no longer scale up with use. This problem ***MUST*** be addressed. Please, please, *PLEASE* drop the export restrictions on cryptography!!! Sincerely, Casey Leedom ----- Attachment: my letter of February 22, 1995: Date: Wed, 22 Feb 1995 14:34:21 -0800 From: leedom@gauss.asd.sgi.com (Casey Leedom) To: president@whitehouse.gov (President Bill Clinton), vicepresident@whitehouse.gov (Vice President Al Gore) cc: annagram@hr.house.gov (Honerable Anna Eshoo) Subject: Please drop cryptology export controls Dear Mr. President and Vice President, With the recent computer breakins at the San Diego Computer Center it should now be obvious that cryptography is desperately needed if the Internet is to be made commercially viable. I know that you and others in the government are very much against wide spread uncontrolled (by the government) use of cryptography on the Internet. But by now it must be obvious to you that no one is going to buy into a government controlled escrow scheme. Non-government controlled cryptography will happen. Nothing you can do short of destroying the Internet can stop that. You can only slow it down by your opposition. Unfortunately, everyone will suffer in the mean time because the Internet will continue to be a less safe place to do business. Please abandon you efforts to establish government control of cryptography and let the Internet move forward. Sincerely, Casey Leedom leedom@sgi.com Silicon Graphics, Inc. ----- End of attachment ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 15:11:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06004; Thu, 23 Feb 95 15:11:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05998; Thu, 23 Feb 95 15:10:59 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18629; Thu, 23 Feb 1995 15:03:54 -0800 Received: from sgigate.sgi.com by Sun.COM (sun-barr.Sun.COM) id AA28159; Thu, 23 Feb 95 15:03:52 PST Received: from sgihub.corp.sgi.com (sgihub.corp.sgi.com [192.26.51.188]) by sgigate.sgi.com (950215.405.SGI.8.6.10/8.6.4) with ESMTP id PAA14787; Thu, 23 Feb 1995 15:03:24 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) id PAA23661; Thu, 23 Feb 1995 15:03:23 -0800 Received: from gauss.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com id AA18604; Thu, 23 Feb 95 15:03:21 -0800 Received: from localhost by gauss.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id PAA03138; Thu, 23 Feb 1995 15:03:01 -0800 Message-Id: <199502232303.PAA03138@gauss.asd.sgi.com> From: leedom@gauss.asd.sgi.com (Casey Leedom) To: ipng@sunroof.Eng.Sun.COM, namedroppers@rs.internic.net Subject: Re: (IPng) ICMP name query messages Date: Thu, 23 Feb 1995 15:02:47 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM | Date: Thu, 23 Feb 95 06:59:46 -0800 | From: Craig Partridge | | ... IN-ADDR has been a notably unsuccessful activity -- lots of IN-ADDR | domains are poorly maintained -- and I'd welcome a good alternative. I think the answer here is somewhat obvious. Don't require an interface that requires entering the data twice. If you need an inverse mapping of a transformation, generate it automatically. At all the places I know of that do maintain their IN-ADDR domains well, they do it with various perl, etc. script hacks to translate some master database into the DNS databases. This situation would be helped a lot if some standardization were developed. Casey ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 15:27:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06045; Thu, 23 Feb 95 15:27:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06039; Thu, 23 Feb 95 15:27:37 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20406; Thu, 23 Feb 1995 15:20:31 -0800 Received: from venera.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA02391; Thu, 23 Feb 95 15:20:30 PST Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id ; Thu, 23 Feb 1995 14:31:19 -0800 From: bmanning@ISI.EDU Posted-Date: Thu, 23 Feb 1995 14:30:29 -0800 (PST) Message-Id: <199502232230.AA18364@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Thu, 23 Feb 1995 14:30:29 -0800 Subject: Re: (IPng) ICMP name query messages To: ipng@sunroof.Eng.Sun.COM Date: Thu, 23 Feb 1995 14:30:29 -0800 (PST) In-Reply-To: <9502232034.AA28939@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Feb 23, 95 03:34:22 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > But just so I am clarified correctly. My comment on host name had this > vision: > > just_for.jones.com AAAA AF:BA:GF:CC:12:E2:7B:21 > AAAA AF:BA:GF:CC:12:E2:7B:22 > AAAA AF:BA:GF:CC:12:E2:7B:23 > AAAA AF:BA:GF:CC:12:E2:7B:24 > ....................... > just_for.jones.com AAAA AF:BA:GF:CC:12:E2:7B:21 AAAA 22:CC:DB:99:83::01 eds_too.smith.city.hou.tx.us. AAAA AF:BA:GF:CC:12:E2:7B:21 --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 15:28:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06064; Thu, 23 Feb 95 15:28:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06046; Thu, 23 Feb 95 15:28:00 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20450; Thu, 23 Feb 1995 15:20:55 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA02476; Thu, 23 Feb 95 15:20:54 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm037-19.dialip.mich.net [141.211.7.92]) by merit.edu (8.6.10/merit-2.0) with SMTP id SAA11817 for ; Thu, 23 Feb 1995 18:20:52 -0500 Date: Thu, 23 Feb 95 23:03:13 GMT From: "William Allen Simpson" Message-Id: <3960.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net Subject: Re: (IPng) Re: ICMP name query messages Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bound@zk3.dec.com > Steve Deering put this on BOTH LISTS. It should be his decision if its > not to be on BOTH LISTS. If you can't take it get out of the > discussion. OK, I will. I'm not sending anything further on this topic to IPng. And as to your contention that this was intended for IPv6 only, I will simply assume that you forgot that I first raised it for Sue, Yakov, and your DYN UPD draft in DNSIND. Then when people said it was a good idea that made some of the security update problems in DNSIND go away, I raised it for Sue, Yakov, and your IPv6 auto-configuration as well. I'll do the IPv4 version, somebody else can do the IPv6 version, and never the twain shall meet. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 15:28:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06070; Thu, 23 Feb 95 15:28:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06052; Thu, 23 Feb 95 15:28:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20454; Thu, 23 Feb 1995 15:21:00 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA02469; Thu, 23 Feb 95 15:20:53 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm037-19.dialip.mich.net [141.211.7.92]) by merit.edu (8.6.10/merit-2.0) with SMTP id SAA11814 for ; Thu, 23 Feb 1995 18:20:50 -0500 Date: Thu, 23 Feb 95 22:55:58 GMT From: "William Allen Simpson" Message-Id: <3959.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Draft IPng W.G. Meeting Minutes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I see that the minutes do not note that I raised the Domain Name query proposal, or that I announced that I had finished writing it before the end of the meeting, and read part out load. SOOOO much for minutes.... And I note that somebody decided that we were going to have separate discovery over foo documents. I certainly didn't agree to that. The first, of course, would have to be discovery over Ethernet, which would be done at the same time as discovery over Frame Relay, discovery over SNA, discovery over ISDN, discovery over PPP, etc etc etc. I'm sure this mammoth effort will be completed sometime in the next decade, just as soon as somebody funds me to do so. Otherwise, forget it. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 15:28:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06071; Thu, 23 Feb 95 15:28:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06063; Thu, 23 Feb 95 15:28:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20479; Thu, 23 Feb 1995 15:21:10 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA02515; Thu, 23 Feb 95 15:21:06 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA27855; Thu, 23 Feb 95 14:38:35 -0800 Received: by xirtlu.zk3.dec.com; id AA03998; Thu, 23 Feb 1995 17:38:28 -0500 Message-Id: <9502232238.AA03998@xirtlu.zk3.dec.com> To: Craig Partridge Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 95 13:12:06 PST." <199502232112.NAA21423@aland.bbn.com> Date: Thu, 23 Feb 95 17:38:22 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, Your points are all valid. Steve D. also pointed an issue out to me too. How multipe names could be used at the same address. I am now moving to its OK to have multiple names for one address is OK. But this could break your real world model too. Having 1 address only for a name (or anyname). Maybe I am concerned to much with the code and DNS implementation and performance. But I am going to keep pushing a little bit here. Right now all I will get back on host2addr() is multiple addresses and the address family for those addresses. If I get back 20 addresses my cycle is going to get pretty poor performance if I pick the wrong address 19 times. You can't even count on a hash I don't think and there is presently no input parameter to provide a hint, unless you want to handle this in the app, which I guess may work. Now I am trying to automate the world so I am assuming no manual intervention or special deals like this is a real time app so only give DNS one address for this name. Our engineering solution must be self contained. What / How much will break because there is only one address for any host name? On my business card I put bound@zk3.dec.com. Someone else may have craig@bbn.com and they both can be at the same address. The gain is complete freedom and guarantee from parsing multiple addresses in an application or anyother code that uses a name to determine an address. Also it would still be OK to have a duplicate name as long as its in a different DNS domain (not a brother in the tree per RFC 1034). Does this help? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 15:36:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06093; Thu, 23 Feb 95 15:36:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06087; Thu, 23 Feb 95 15:36:06 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21289; Thu, 23 Feb 1995 15:29:01 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA04457; Thu, 23 Feb 95 15:29:00 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA28017; Thu, 23 Feb 95 14:40:30 -0800 Received: by xirtlu.zk3.dec.com; id AA04047; Thu, 23 Feb 1995 17:40:26 -0500 Message-Id: <9502232240.AA04047@xirtlu.zk3.dec.com> To: Craig Partridge Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 95 13:12:06 PST." <199502232112.NAA21423@aland.bbn.com> Date: Thu, 23 Feb 95 17:40:19 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, Your points are all valid. Steve D. also pointed an issue out to me too. How multiple names could be used at the same address. I am now moving to its OK to have multiple names for one address. But this could break your real world model too. Having 1 address only for a name (or anyname). Maybe I am focused to much with the code and DNS implementation and performance. But I am going to keep pushing a little bit here. Right now all I will get back on host2addr() is multiple addresses and the address family for those addresses. If I get back 20 addresses my cycle is going to get pretty poor performance if I pick the wrong address 19 times. You can't even count on a hash I don't think and there is presently no input parameter to provide a hint, unless you want to handle this in the app, which I guess may work. Now we are trying to automate the world so I am assuming no manual intervention or special deals like this is a real time app so only give DNS one address for this name. Our engineering solution must be self contained. What / How much will break because there is only one address for any host name? On my business card I put bound@zk3.dec.com. Someone else may have craig@bbn.com and they both can be at the same address. The gain is complete freedom and guarantee from parsing multiple addresses in an application or anyother code that uses a name to determine an address. Also it would still be OK to have a duplicate name as long as its in a different DNS domain (not a brother in the tree per RFC 1034). Does this help? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 18:13:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06148; Thu, 23 Feb 95 18:13:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06142; Thu, 23 Feb 95 18:12:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08814; Thu, 23 Feb 1995 18:05:47 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA05181; Thu, 23 Feb 95 18:05:45 PST Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA17389 for ipng@sunroof.eng.sun.com; Thu, 23 Feb 95 21:05:37 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id SAA21522; Thu, 23 Feb 1995 18:05:37 -0800 Message-Id: <199502240205.SAA21522@aland.bbn.com> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of Thu, 23 Feb 95 17:38:22 -0500. <9502232238.AA03998@xirtlu.zk3.dec.com> From: Craig Partridge Date: Thu, 23 Feb 95 18:05:36 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM What / How much will break because there is only one address for any host name?... Jim: What you are describing is the state of the Internet, circa 1985, when BSD's gethostbyname() returned only one address. Now I'm speaking as one of the folks who helped force the change in gethostbyname() in 1986 but I still think it is a fair characterization to say that the one name one address rule was hell. Examples (I worked at CSNET in those days) 1. A mail queue backs up to some major e-mail site (often ucbvax or UUCP at the time when there was a gateway at seismo). Why? One of their interfaces is down, and the *%$! software didn't try for one of the other ones (which we could reach). 2. User reports they can't telnet to machine BAR. But we can. Reason? Turns out our host tables returns different choices of address... One ends up asking the user to tell you what TELNET prints out as the address it is trying. Now I understand that you're proposing to change things so that there's one name per address and vice-versa. But that doesn't change the problem just moves it. For instance, if my machine had 3 interfaces, say IF0.BBN.COM, IF1.BBN.COM and IF2.BBN.COM, I'd want users of telnet, SMTP, FTP et al. to get to my machine via whichever one works for them. And I don't want them to have remember 3 different names. That's a lousy way to treat a customer. So instead, I'll do just about anything to find a way to map a single name, like BBN.COM into three names -- add more MX RR's in email. Develop (say) TL RRs for telnet that map a name to multiple addresses and FT RRs for FTP. So now all the applications can grok multiple addresses, but instead of one way to do it (via AAAA RRs) we have multiple ways, one per application. Seems the application coding just got worse, not better. Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 20:09:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06171; Thu, 23 Feb 95 20:09:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06165; Thu, 23 Feb 95 20:09:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15393; Thu, 23 Feb 1995 20:02:19 -0800 Received: from ncc.ripe.net by Sun.COM (sun-barr.Sun.COM) id AA18420; Thu, 23 Feb 95 20:02:18 PST Received: from belegen.ripe.net by ncc.ripe.net with SMTP id AA10708 (5.65a/NCC-2.18); Fri, 24 Feb 1995 05:02:08 +0100 Message-Id: <9502240402.AA10708@ncc.ripe.net> To: ipng@sunroof.Eng.Sun.COM From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 1995 13:28:12 EST." <199502231828.NAA17770@titan.sprintlink.net> Date: Fri, 24 Feb 1995 05:02:07 +0100 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Thu, 23 Feb 1995 13:28:12 -0500 Vadim Antonov wrote: > >I belong to those who have some reservations and find that the proposal is a > >2) Second, a problem of trust. How can I prove that the host responding to t he > > getnamebyaddress request is not serving me with a phony answer? > > That is also not a problem -- when you got the name, do direct lookup. > Exactly the same way paranoid resolvers are doing today. Not having seen minutes yet (hint) - additional question: how is 'backup resolution' going to be handled in this ICMP reverse name scheme? i.e. If I see in my logs that there has been traffic from host ip:v6:num:ber, but the box is currently down, then how would I find out its hostname? DNS at least has possibilities for a backup. I'm not saying DNS is better, just wondering how this will work. Geert Jan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 20:59:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06234; Thu, 23 Feb 95 20:59:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06228; Thu, 23 Feb 95 20:59:40 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17788; Thu, 23 Feb 1995 20:52:34 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA24605; Thu, 23 Feb 95 20:52:34 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA09711; Thu, 23 Feb 95 23:08:48 CST Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA23627; Thu, 23 Feb 95 22:52:06 CST Date: Thu, 23 Feb 95 22:52:06 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9502240452.AA23627@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I confess to some puzzlement as to what problem this ICMP message is supposed to solve. It won't work through firewalls, it won't work for hosts that happen to be down, it doesn't provide an answer with any slight semblence of authority, and it probably doesn't do a lot of other things either. The issue of what to do with multihomed hosts does not appear to be well thought out. The issue of what to do when there are multiple names associated with an IP address does not seem to be well thought out (especially when the host in question is wildly unlikely to know all the names attached to an address). What precisely does it *do*? Where's the up side? How does it improve IPv? Andrew ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 21:04:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06266; Thu, 23 Feb 95 21:04:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06254; Thu, 23 Feb 95 21:03:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17941; Thu, 23 Feb 1995 20:56:47 -0800 Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA25108; Thu, 23 Feb 95 20:56:48 PST Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id XAA20343 for ipng@sunroof.Eng.Sun.COM; Thu, 23 Feb 1995 23:56:47 -0500 Date: Thu, 23 Feb 1995 23:56:47 -0500 From: Vadim Antonov Message-Id: <199502240456.XAA20343@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Not having seen minutes yet (hint) - additional question: how is > 'backup resolution' going to be handled in this ICMP reverse name scheme? > i.e. If I see in my logs that there has been traffic from > host ip:v6:num:ber, but the box is currently down, then how > would I find out its hostname? > DNS at least has possibilities for a backup. I'm not saying DNS > is better, just wondering how this will work. It shouldn't work. Host could move to another address since then; and with laptoys it is getting more and more likely scenario. Hint -- do not collect addresses in log files, particularly addresses longer than names :-) --vadim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 21:07:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06316; Thu, 23 Feb 95 21:07:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06292; Thu, 23 Feb 95 21:06:51 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18127; Thu, 23 Feb 1995 20:59:45 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA25554; Thu, 23 Feb 95 20:59:46 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-09.dialip.mich.net [141.211.7.145]) by merit.edu (8.6.10/merit-2.0) with SMTP id XAA24052 for ; Thu, 23 Feb 1995 23:59:43 -0500 Date: Fri, 24 Feb 95 04:09:18 GMT From: "William Allen Simpson" Message-Id: <3965.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) v6 ICMP message types Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Here's a possible encoding of the messages defined in the v6 ICMP spec, > using the high-order bit of the message type to identify error messages: > > 0 - Echo Request > 1 - Echo Reply > 2 - Node Name Request > 3 - Node Name Reply > 4 - Group Membership Query > 5 - Group Membership Report > 6 - Group Membership Termination > > 128 - Destination Unreachable > 129 - Packet Too Big > 130 - Time Exceeded > 131 - Parameter Problem > > I'd appreciate comments ASAP, especially from v6 implementors and from authors > of other specs that define v6 ICMP message types (e.g., Neighbor Discovery). I don't think error returns should occur for a Solicitations or Advertisements, including Local and Remote Redirects. Error returns might be useful for Mobile Registration Request and Reply. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 21:07:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06318; Thu, 23 Feb 95 21:07:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06297; Thu, 23 Feb 95 21:06:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18130; Thu, 23 Feb 1995 20:59:47 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA25557; Thu, 23 Feb 95 20:59:48 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-09.dialip.mich.net [141.211.7.145]) by merit.edu (8.6.10/merit-2.0) with SMTP id XAA24056 for ; Thu, 23 Feb 1995 23:59:46 -0500 Date: Fri, 24 Feb 95 04:14:52 GMT From: "William Allen Simpson" Message-Id: <3966.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) DNS address exclusion Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: rgm3@is.chrysler.com (Robert Moskowitz) > All addresses HAD BETTER be recorded in the DNS. This poises an interesting > question about 'private addresses'. Let us assume that in the world of IPv6 > with authenticated and encrypted connections being standardly available, > firewalls will rarely be needed ( ;) ). Either an AXFER or an IXFER from > FOO.COM would have to exclude the internal addresses, or outside systems > would have to know to ignore them. > I agree. Somebody also has to filter out link-scope addresses, except when the query source is on the same link. I already proposed this for the DNS, and was shouted down at Toronto. DNS writers think it too hard. (I think it's quite easy, but I've only ever written a resolver.) > That is DNS's job, isn't it? > > >It's a tough problem. > > And IPv6 is not? > Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 21:07:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06319; Thu, 23 Feb 95 21:07:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06304; Thu, 23 Feb 95 21:06:56 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18134; Thu, 23 Feb 1995 20:59:49 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA25565; Thu, 23 Feb 95 20:59:51 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-09.dialip.mich.net [141.211.7.145]) by merit.edu (8.6.10/merit-2.0) with SMTP id XAA24059 for ; Thu, 23 Feb 1995 23:59:48 -0500 Date: Fri, 24 Feb 95 04:24:22 GMT From: "William Allen Simpson" Message-Id: <3967.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Provider-based addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Vadim Antonov > The address allocation should *not* be expressed in "provider/non-provioder" > terms but rather in purely in terms of topology and routing policy. > > There's the third way i keep preaching for -- abandon static address > allocation altogether and do dynamic hierarchial address allocation. > Sure, you'll have to trash the present DNS and replace it with something > doing auto-registration and strong consistency; but if mobility is > indeed the requirement it is going to happen anyway. > > And then, the dynamic address allocation brings the real benefits to > end-users, literally allowing zero-administration networking. > No more CNEs :-) > At last, another person with sense (enough to agree with me). Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 21:07:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06320; Thu, 23 Feb 95 21:07:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06310; Thu, 23 Feb 95 21:07:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18139; Thu, 23 Feb 1995 20:59:53 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA25575; Thu, 23 Feb 95 20:59:55 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-09.dialip.mich.net [141.211.7.145]) by merit.edu (8.6.10/merit-2.0) with SMTP id XAA24065 for ; Thu, 23 Feb 1995 23:59:52 -0500 Date: Fri, 24 Feb 95 04:34:12 GMT From: "William Allen Simpson" Message-Id: <3969.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) v6 ICMP message types Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > If we were starting from a clean slate, rather than doing a new version > of an existing protocol with a large installed base of "current practice", > I'd probably argue in favor of an XNS-like demuxing mechanism, where the > ports are considered part of the addresses, so hosts demux first on port > number and then on packet type (TCP/UDP/error/etc.). But we're not > starting from a clean slate. > And I'd argue (as I did previously to joining SIP), that we abandon separate transport protocol types altogether, and just use the port to identify transport as well. The well-known port would uniquely identify transport setup (for example, DNS UDP 1000, DNS TCP 1001), and the return port would function like a combination Flow Label and SAID, identifying all the negotiated parameters for a connection on a receiver basis. (This is long before we agreed on the Flow and SAID terms and semantics.) Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 21:12:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06376; Thu, 23 Feb 95 21:12:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06370; Thu, 23 Feb 95 21:12:41 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18457; Thu, 23 Feb 1995 21:05:35 -0800 Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA26265; Thu, 23 Feb 95 21:05:36 PST Message-Id: <9502240505.AA26265@Sun.COM> From: smb@research.att.com Received: by gryphon; Fri Feb 24 00:04:33 EST 1995 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ICMP name query messages Date: Fri, 24 Feb 95 00:04:32 EST Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM If we're going to rely on the host to announce its own name, maybe it could live in an IP option. This option would always be sent with a TCP SYN packet (or at least by default), and could be with UDP if the application desired to. If it didn't arrive, the recipient could always send the ICMP message. If you want something (more) trustworthy, you do the forward lookup on either answer. I do feel compelled to point out that I'm not joking. If folks have a decent handle on which services are *likely* to want the caller's name -- and I think we do, though there are certainly no guarantees -- this should result in less network traffic. And it's no less reliable than the ICMP suggestion. It could also answer one of the objections: an application that wanted to claim one of a set of host names could easily do so; the kernel need only validate that the chosen name was in fact one of the legal names for that host, based on boot-time configuration. --Steve Bellovin ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 21:24:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06419; Thu, 23 Feb 95 21:24:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06413; Thu, 23 Feb 95 21:24:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18919; Thu, 23 Feb 1995 21:16:58 -0800 Received: from mulga.cs.mu.OZ.AU by Sun.COM (sun-barr.Sun.COM) id AA27543; Thu, 23 Feb 95 21:16:56 PST Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17747 Fri, 24 Feb 1995 16:16:54 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Gratuitous ARP In-Reply-To: Your message of "Thu, 23 Feb 1995 14:54:00 GMT." <3954.bsimpson@morningstar.com> Date: Fri, 24 Feb 1995 16:15:24 +1100 Message-Id: <5396.793602924@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Thu, 23 Feb 95 14:54:00 GMT From: "William Allen Simpson" Message-ID: <3954.bsimpson@morningstar.com> The question for us: do we want to add Self Solicitation for discovery of duplicate addresses? I am of the opinion that it is not worth the bother. KRE has expressed the opposite view in the Apple Networking Forum. First a quick note on context. Probably its not surprising, but the ANF wasn't considering IPv6, rather, inspired by a message from Bill on the many merits of MacTCP, it was discussing IPv4. The issues are quite different, in IPv4 you have a situation where addresses are configured in many cases by morons (OK, for some of you, the politically correct word is "customers"), who have no idea at all what they're doing, and frequently simply copy entire configurations from one system to another (addresses included). In IPv6 the plan (which I hope wasn't changed a couple of weeks ago) is to have essentially all addresses autoconfigured. Autoconfigured addresses, one hopes, are much less likely to be duplicates. For IPv6, I'd personally tend to suggest that if an address has been autoconfigured, simply use it. On the other hand, if it has been human configured, then go ahead and validate that its not a duplicate. How one determines where the address came from in some stacks is another issue. If the traffic overheads in doing this (either the load on the net, or the load on nodes in processing it) becomes great, then a simple answer for affected sites would be to stop configuring addresses, and allow autoconf to supply them instead, which seems worthwhile to me. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 23 22:48:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06466; Thu, 23 Feb 95 22:48:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06460; Thu, 23 Feb 95 22:48:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21769; Thu, 23 Feb 1995 22:40:59 -0800 Received: from mulga.cs.mu.OZ.AU by Sun.COM (sun-barr.Sun.COM) id AA04089; Thu, 23 Feb 95 22:40:53 PST Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19574 Fri, 24 Feb 1995 17:21:01 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM, namedroppers@rs.internic.net Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 1995 09:21:52 CDT." <9502231421.AA15848@xirtlu.zk3.dec.com> Date: Fri, 24 Feb 1995 17:19:32 +1100 Message-Id: <5402.793606772@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Thu, 23 Feb 95 09:21:52 -0500 From: bound@zk3.dec.com Message-ID: <9502231421.AA15848@xirtlu.zk3.dec.com> I question whether the caching is actually being used to the degree suggested and would like some operation folks to please respond to this mail so we can get expert operations input on this one not just engineering projections Since I was explicitly (for some reason) included in that list I will see if I can dig out some numbers, and send them later. I will say that in this part of the world we make HEAVY use of DNS caching - that is, all DNS requests leaving Aust are supposed to pass through a DNS forwarder box whose sole purpose in life is to cache DNS query/responses. This does seem to be quite effective in limiting DNS traffic leaving the country. Just under 3% (by bytes) of our outgoing traffic is DNS, which of course includes replies to queries from the world, and about 1.75% of incoming traffic (bytes) is DNS. Most of the disparity is because we have far more incoming traffic of other kinds than outgoing, but in absolute counts, we send more outgoing bytes than we receive incoming, which would tend to suggest that we send more replies than queries. On the more general issue, I think its pretty clear to many people by now that I don't believe that any kind of address->name mapping is going to be feasible for IPv6. I suspect that if we attempt "icmp to the node" the thing will fall apart much quicker than an "in-addr.arpa lookalike", but I believe this is just a matter of timing, neither of those is going to last in the long term. The icmp method has the advantages that its simple, and very responsive to addressing changes - as soon as a new address is in use the associated name will be available. On the other hand it retains no history at all, an address that has passed out of use, even just temporarily (node has crashed) won't have any address to name mapping available, and it doesn't seem to lend itself easily to caching. It also puts names down into the IP stack at a level they've never been before, names have always been purely application level entities. DNS methods, whatever the details, have, or can have, quite good caching, they make data available quite reliably, or can be mode to do so, including, where appropriate, historical data that has aged away but hasn't had to be replaced due to reuse. However they're cumbersome (at best) to update, especially rapidly, and considerably more complex. The ICMP method also has the disadvantage that its hard to see any way that we can expect the data to be accurate, unless we also invent a node name autoconfiguration method (and always use it), which then adds to this method most of the disadvantages of the DNS method (there's a big database somewhere that's difficult to automatically update), without the advantages. Note, as has been said before, "accuracy" here has nothing to do with "security" - you can provably get the answer from the correct node, and still get the wrong answer. Validating the answer by doing a forward lookup is fine, but if you mostly get "invalid" as the response, then you might just as well have not bothered doing the lookup in the first place. On the issue of in-addr.arpa accuracy Casey Leedom said: At all the places I know of that do maintain their IN-ADDR domains well, they do it with various perl, etc. script hacks to translate some master database into the DNS databases. Well, I think I maintain mine well, and I don't do that. It also turns out to be hard to do (not impossible, just hard) in environments where the "some master database" that would be needed to generate all the relevant DNS files has to be maintained by multiple organisations for administrative or political reasons (of course, directly maintaining the files has many of the same problems, but usually on a slightly smaller scale). If you can get away with centralised control, a scheme like that can work well, to really work well, automation is needed. The icmp method does much of that, if there was some way to expect the data to be correct. Its hard to see how the "some master database" people are going to be able to continue to operate once DNS dynamic updates, a must for IPv6, start to become prevalent. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 02:17:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06580; Fri, 24 Feb 95 02:17:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06574; Fri, 24 Feb 95 02:17:21 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28434; Fri, 24 Feb 1995 02:10:15 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA24575; Fri, 24 Feb 95 02:10:12 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10357; Fri, 24 Feb 1995 11:09:20 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA11607; Fri, 24 Feb 1995 11:09:17 +0100 Message-Id: <9502241009.AA11607@dxcoms.cern.ch> Subject: Re: (IPng) A NEW thought on addressing To: addrconf@cisco.com, ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Fri, 24 Feb 1995 11:09:17 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9502231305.AA10616@clncrdv1.is.chrysler.com> from "Robert Moskowitz" at Feb 23, 95 07:50:06 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob, > The following note was posted on the IPng list on the 21st. If you saw it > there and had nothing to say, please excuse cluttering up these lists. But > for us corporate creatures and some other big sites like CERN and NRL, > multiconnected nets will be a reality. True, but I have no problem with the analysis in Rekhter/Li and the proposal in Rekhter/Lothberg. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 02:39:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06597; Fri, 24 Feb 95 02:39:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06591; Fri, 24 Feb 95 02:39:17 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29019; Fri, 24 Feb 1995 02:32:12 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA26516; Fri, 24 Feb 95 02:32:10 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14098; Fri, 24 Feb 1995 11:31:56 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA12346; Fri, 24 Feb 1995 11:31:54 +0100 Message-Id: <9502241031.AA12346@dxcoms.cern.ch> Subject: Re: (IPng) Gratuitous ARP To: ipng@sunroof.Eng.Sun.COM Date: Fri, 24 Feb 1995 11:31:54 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9502231530.AA02250@snark.imsi.com> from "Perry E. Metzger" at Feb 23, 95 10:30:24 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I concur with Perry. Three days without a duplicate IP address can only mean a holiday weekend around here. Murphy's law applies in all cases (except in experiments to prove Murphy's law). Discovery should assume that discovery can go wrong. Brian >--------- Text sent by Perry E. Metzger follows: > > > "William Allen Simpson" says: > > The question for us: do we want to add Self Solicitation for discovery > > of duplicate addresses? > [...] > > I am of the opinion that it is not worth the bother. KRE has expressed > > the opposite view in the Apple Networking Forum. > > Less than three days ago, "self solicitation" saved my > buttocks. Someone brought up a second machine on an etherthernet with > the same IP address and had this feature not been in place a > production network would have been brought to its knees. I'm in favor > of any feature that has shown great operational utility, and this is > certainly one of them. > > Perry > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 04:11:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06699; Fri, 24 Feb 95 04:11:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06693; Fri, 24 Feb 95 04:11:07 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04898; Fri, 24 Feb 1995 04:04:01 -0800 Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA07255; Fri, 24 Feb 95 04:03:58 PST Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.9/8.6.9) with ESMTP id HAA10944 for ; Fri, 24 Feb 1995 07:03:55 -0500 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.9/8.6.9) with SMTP id HAA11957 for ; Fri, 24 Feb 1995 07:03:54 -0500 Received: from bobsgrid.is.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA23624; Fri, 24 Feb 95 07:19:07 EST Message-Id: <9502241219.AA23624@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Feb 1995 07:03:42 -0500 To: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: (IPng) ICMP name query messages Cc: namedroppers@rs.internic.net, deering@parc.xerox.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 09:21 AM 2/23/95 -0500, bound@zk3.dec.com wrote: >I question whether the caching is actually being used to the degree >suggested and would like some operation folks to please respond to this >mail so we can get expert operations input on this one not just >engineering projections (steve d. this time I think the engineer >should listen). Examples are John Curran, Brian Carpenter, Robert Elz >(who also wear engineering hats but can get this data for in.arpa real >use).. Alan at OZ what about you? I am going to check how much Digital >does it too. Sun, HP, IBM, etc....how about you folks? We should also hear >from Chrysler (Bob can you connect with friends maybe at GM and Ford and ask >them). Eric at Boeing. We have a lot of folks out here using DNS. I think >Perry Metzger also can get some real data. Folks we need real data on >this one not guesses. Or just tech weenine wishes for the world. At Chrysler. No caching if we can help it. But then we run a schizoid DNS. The outside world looks like a bunch of MX records like: *.EDU. IN MX 10, mailhub.chrysler.com. All key DNS servers (a couple per campus) secondaries all domains (lots of memory). Fairly flat hierarchy. Trying to keep it to one level below Chrysler.com. in-addr.arpa is built programmatically. No trust of people doing it. One system is the primary for the whole in-addr tree. You see we are heavy into variable OSPF, and also some of our domains are functional, spanning geography. So we broke the in-addr.arpa ownership enough to right code to build it. As far as GM and FORD? GM is typically 4 levels deep: prog.c4.gmeds.com. Each area has independent control of their tree (Chrysler has 2 organizations running the whole DNS, pretty much). FORD is flat like us, 3 levels, but that is all I know of them. TCP/IP was mostly engineering there, but the new reorg is may change that big time. Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 06:25:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06745; Fri, 24 Feb 95 06:25:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06739; Fri, 24 Feb 95 06:25:20 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB09429; Fri, 24 Feb 1995 06:18:13 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA21017; Fri, 24 Feb 95 06:18:13 PST Received: by rodan.UU.NET id QQyemb08767; Fri, 24 Feb 1995 09:18:09 -0500 Message-Id: To: avg@sprint.net Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) dynamic addressing Date: Fri, 24 Feb 1995 09:18:09 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ok Vadim, you've certainly whetted my appetite. I'd be delighted with "tastes grea, less filling". Really. from where can I ftp the document which discusses the details of your propsal? -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 06:54:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06761; Fri, 24 Feb 95 06:54:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06755; Fri, 24 Feb 95 06:54:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11026; Fri, 24 Feb 1995 06:46:55 -0800 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by Sun.COM (sun-barr.Sun.COM) id AA25640; Fri, 24 Feb 95 06:46:53 PST Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA17308; Fri, 24 Feb 95 09:46:50 EST Date: Fri, 24 Feb 95 09:46:50 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9502241446.AA17308@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Neighbor Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I object to breaking the currently clean and clearly implementable (we have code) general Discovery documents into link-specific ones. There are security benefits from having a single general-purpose mechanism rather than a bunch of link-specific ones. Also, this approach means that I can implement Discovery once in my kernel without a bunch of special tests that are link-specific. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 07:05:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06778; Fri, 24 Feb 95 07:05:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06772; Fri, 24 Feb 95 07:05:32 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11692; Fri, 24 Feb 1995 06:58:25 -0800 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by Sun.COM (sun-barr.Sun.COM) id AA27373; Fri, 24 Feb 95 06:58:25 PST Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA18048; Fri, 24 Feb 95 09:58:23 EST Date: Fri, 24 Feb 95 09:58:23 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9502241458.AA18048@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) more on Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ignoring mobility for now, NodeHeard messages are very useful to those of us with lower bandwidth links (e.g. V.34 or lower modem PPP links, which are increasingly widespread in the operational Internet, low-bandwidth radio links, and others). I object to dropping NodeHeard because it makes IPv6 significantly less usable over links currently widely used to carry IPv4. I will work with Bill Simpson offline to get clearer explanatory text for these messages incorporated into the Discovery drafts. That proposed text can then be generally reviewed for accepability by the entire WG. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 08:47:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06837; Fri, 24 Feb 95 08:47:08 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06831; Fri, 24 Feb 95 08:47:00 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA08287; Fri, 24 Feb 1995 08:39:34 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA24123; Fri, 24 Feb 1995 08:39:28 -0800 Date: Fri, 24 Feb 1995 08:39:28 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199502241639.IAA24123@elrond.Eng.Sun.COM> To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net Subject: (IPng) out-of-band key management is like virtual circuits X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, I think it might be useful to approach the in-band/out-of-band key management issue from another perspective. Out-of-band management assumes either that a synchronized security assocation already exists between the source and destination hosts or that when an IP packet is processed, the key management software is called to establish this context. Those familiar with X.25 will recognize this as a virtual circuit model of operation. In fact I think it is a fair characterization that out-of-band key management imposes a "security virtual circuit" model on IP security (both IPv4 and IPv6). In-band key management, on the other hand, is philosophically similar to dynamic connection management, which is the technique employed by TCP. When a connection is required, information is included within the TCP header (e.g., syn flag, isn) to allow the construction of a connection record at the destination. Similarly, the destination returns information (syn ack, its isn), to allow the source to complete the construction of its connection record. An important point that some may have overlooked is that the current draft of the IPv6 security Architecture I-D (I couldn't find an security architecture I-D for IPv4) encourages the use of user-to-user keying (by specifying that implementations MUST support user-to-user keying, but only MAY provide for host-to-host keying), rather than host-to-host keying. The implication is that everytime a new *user* communicates to a specific machine, the key management software will be required to establish a new security association. If out-of-band keying is used, this is going to mean, on average, very poor performance, since the key management protocol must use a separate communications stream to establish the keys for use before communications on the stream originating the key management activity can proceed. It is for these reasons, among others, that in-band signalling should be supported by both final IPSEC Proposed Standards and by the IPv6 Proposed Standards for security. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 09:03:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06854; Fri, 24 Feb 95 09:03:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06848; Fri, 24 Feb 95 09:03:21 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21423; Fri, 24 Feb 1995 08:56:14 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA19546; Fri, 24 Feb 95 08:56:14 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA19515; Fri, 24 Feb 95 08:51:49 -0800 Received: by xirtlu.zk3.dec.com; id AA02029; Fri, 24 Feb 1995 11:50:48 -0500 Message-Id: <9502241650.AA02029@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) ICMP name query messages In-Reply-To: Your message of "Fri, 24 Feb 95 00:04:32 EST." <9502240505.AA26265@Sun.COM> Date: Fri, 24 Feb 95 11:50:42 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve B., >If we're going to rely on the host to announce its own name, maybe >it could live in an IP option. This option would always be sent with >a TCP SYN packet (or at least by default), and could be with UDP if the >application desired to. If it didn't arrive, the recipient could always >send the ICMP message. If you want something (more) trustworthy, you >do the forward lookup on either answer. > >I do feel compelled to point out that I'm not joking. If folks have a >decent handle on which services are *likely* to want the caller's name -- >and I think we do, though there are certainly no guarantees -- this >should result in less network traffic. And it's no less reliable than >the ICMP suggestion. It could also answer one of the objections: an >application that wanted to claim one of a set of host names could easily >do so; the kernel need only validate that the chosen name was in fact >one of the legal names for that host, based on boot-time configuration. I like this idea a lot. Good thinking. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 09:23:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06866; Fri, 24 Feb 95 09:23:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06860; Fri, 24 Feb 95 09:23:00 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23603; Fri, 24 Feb 1995 09:15:53 -0800 Received: from wintermute.imsi.com ([192.103.3.10]) by Sun.COM (sun-barr.Sun.COM) id AA23443; Fri, 24 Feb 95 09:15:25 PST Received: from relay.imsi.com by wintermute.imsi.com id MAA01556; Fri, 24 Feb 1995 12:13:54 -0500 Received: from snark.imsi.com by relay.imsi.com id MAA09599; Fri, 24 Feb 1995 12:13:53 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA03871; Fri, 24 Feb 95 12:13:49 EST Message-Id: <9502241713.AA03871@snark.imsi.com> To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 1995 08:39:28 PST." <199502241639.IAA24123@elrond.Eng.Sun.COM> X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 12:13:49 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan Nessett says: > Out-of-band management assumes either that > a synchronized security assocation already exists between the source and > destination hosts or that when an IP packet is processed, the key management > software is called to establish this context. Those familiar with X.25 will > recognize this as a virtual circuit model of operation. In fact I think it > is a fair characterization that out-of-band key management imposes a > "security virtual circuit" model on IP security (both IPv4 and IPv6). > > In-band key management, on the other hand, is philosophically similar to > dynamic connection management, which is the technique employed by TCP. Are you attempting to make an emotional argument here based on on the assumption that people will have a knee jerk reaction against things you label as being "X.25"ish? Unless that is your point, I cannot see why mentioning "X.25" vs. "TCP" would be important. You know, TCP connections require out of band mechanisms for determining mappings between host names and addresses. They also require out of band negotiation of IP routing and fixed preselection of communications ports. Somehow, we survive with all of this. > An important point that some may have overlooked is that the current > draft of the IPv6 security Architecture I-D (I couldn't find an > security architecture I-D for IPv4) encourages the use of > user-to-user keying (by specifying that implementations MUST support > user-to-user keying, but only MAY provide for host-to-host keying), > rather than host-to-host keying. The implication is that everytime a > new *user* communicates to a specific machine, the key management > software will be required to establish a new security > association. If out-of-band keying is used, this is going to mean, > on average, very poor performance, since the key management protocol > must use a separate communications stream to establish the keys for > use before communications on the stream originating the key > management activity can proceed. Is this based on your implementation experience? Could you please post some numbers describing how bad the performance is in practice? I was, in fact, unaware of your implementation. You know, horrors, virtually every time a TCP connection gets built on our network a DNS query has to be made. Performance is obviously impossibly low as a result of this. I say we get rid of DNS and put the queries in band somehow to increase performance. (The existing implementation work indicates that that crypto algorithms so dominate the costs of what we are doing that an extra packet exchange at the start of a connection is almost an invisible cost by comparison.) I don't think that even Ashar, who wants the in-band stuff to support SKIP, would argue that the out-of-bandness is per se a performance problem, especially given that his stuff is still going to require external communciation to look up keys and the like in databases. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 09:35:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06882; Fri, 24 Feb 95 09:35:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06876; Fri, 24 Feb 95 09:35:24 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24971; Fri, 24 Feb 1995 09:28:16 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA26675; Fri, 24 Feb 95 09:28:14 PST From: Ran Atkinson Message-Id: <9502241226.ZM8320@bodhi> Date: Fri, 24 Feb 1995 12:26:29 -0500 In-Reply-To: Danny.Nessett@eng.sun.com (Dan Nessett) "out-of-band key management is like virtual circuits" (Feb 24, 8:39) References: <199502241639.IAA24123@elrond.Eng.Sun.COM> X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett Subject: (IPng) Re: out-of-band key management is like virtual circuits Cc: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, I find your analogy to be highly misleading. I strongly disagree with your assertion that in-band key mgmt is better for a datagram network. All of the capability that you assert is unique to in-band can be done by simply sending key mgmt packets at the same time one sends the datagrams. Since SAIDs are receiver-oriented, a sender can't force a key upon the receiver without the receiver's involvement in any case. If we remove that receiver-orientation, then IP multicasting will not work well with security (and multicasting is a 1st order service of IPv6). Out of band keying does NOT mean "on average, very poor performance". Your assertion just is not true. We should continue to avoid coupling key mgmt and the security mechanisms and hence should continue to avoid in-band key mgmt in standards-track specifications within the IETF. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 09:56:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07019; Fri, 24 Feb 95 09:56:54 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07013; Fri, 24 Feb 95 09:56:47 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA10594; Fri, 24 Feb 1995 09:49:27 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA24180; Fri, 24 Feb 1995 09:49:18 -0800 Date: Fri, 24 Feb 1995 09:49:18 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199502241749.JAA24180@elrond.Eng.Sun.COM> To: atkinson@itd.nrl.navy.mil Subject: (IPng) Re: out-of-band key management is like virtual circuits Cc: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, Your point : > All of the capability that you assert is unique to in-band > can be done by simply sending key mgmt packets at the same time one > sends the datagrams. is somewhat misleading. The key management protocol will require an exchange between the source and destination in order for the source to obtain the SAID that it will use in the IP packet, which processing started the whole process. This induces a considerable delay in delivering the original IP packet. In-band signalling allows the key management activity to be "piggy-backed" on the original IP packet, thus saving not only the cost of processing one or more additional key mgmt IP packets, but also the delay of at least a two packet exchange (which is actually four packets for Photuris, i.e., COOKIE_REQUEST, COOKIE_RESPONSE, DH_REQUEST, DH_RESPONSE), to obtain the SAID. > Since SAIDs are receiver-oriented, a sender can't > force a key upon the receiver without the receiver's involvement in > any case. If we remove that receiver-orientation, then IP multicasting > will not work well with security (and multicasting is a 1st order > service of IPv6). In-band signalling doesn't "force a key upon the receiver without the receiver's involvement," it just piggy-backs the key management information in the original IP packet. The receiver has the option of dropping the packet with the piggy-backed information, just as it can drop an out-of-band key mgmt packet. > We should continue to avoid coupling key mgmt and the security > mechanisms and hence should continue to avoid in-band key mgmt in > standards-track specifications within the IETF. I agree that key mgmt protocols should not be forced to use in-band techniques. I think all of us (and there have been at least 5 messages from different people on this list asking for in-band signalling) would like the *option* of using in-band signalling. Then we can let the market decide which is the best approach. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 10:12:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07060; Fri, 24 Feb 95 10:12:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07054; Fri, 24 Feb 95 10:11:59 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29378; Fri, 24 Feb 1995 10:04:51 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA05867; Fri, 24 Feb 95 10:04:50 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-07.dialip.mich.net [141.211.7.143]) by merit.edu (8.6.10/merit-2.0) with SMTP id NAA23048 for ; Fri, 24 Feb 1995 13:04:46 -0500 Date: Fri, 24 Feb 95 17:53:17 GMT From: "William Allen Simpson" Message-Id: <3987.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) dynamic addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: "Mike O'Dell" > from where can I ftp the document which discusses the details of your propsal? > Don't know about his, but mine's in internet-drafts. Here's some of the relevant text: Each IPv6 border router will be configured with a Routing Domain Identifier (RDI). This RDI is used as the non-zero IPv6 prefix indicating the Administrative Domain. This prefix also has an associated size. Each border router will also be assigned its own number for extending the RDI to make a routing prefix. This routing prefix uniquely identifies the external connection. In addition, any internal site-local prefixes MAY be configured. The site-local prefix is not advertised outside the Adminstrative Domain. These routing prefixes are propagated to adjacent IPv6 routers within the Administrative Domain. Each intra-domain router extends the routing prefix by allocating enough bits for the number of its interfaces, and propagates the extended prefix in turn to its adjacent IPv6 routers. The interface from which the new prefix was learned is always assigned a zero in the extended prefix. This is the Cluster Address. Some routers will learn more than one prefix. In order to prevent loops, the router propagates only those prefixes with the shortest matching prefix. For example, having heard prefixes 1234, 123456, 1256, 12567, and 12589, only 1234, 1256 and 12589 would be propagated. The prefixes propagated by the routers are learned by the hosts. The non-zero prefix is automatically used to generate one or more additional IPv6 addresses for each node. ... Having learned its IPv6 prefix from the IPv6 routers, the IPv6 node can register its qualified IPv6 addresses with an IPv6 configuration server. At this stage, the IPv6 prefix is not zero. However, the zero prefix address form continues to be registered whenever an IPv4 address is also registered. The DNS will now carry at least 3 records for each IPv6+IPv4 node -- the IPv4 address, the leading zero prefix IPv6 equivalent, and the RDI prefixed IPv6 equivalent. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 10:34:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07096; Fri, 24 Feb 95 10:34:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07090; Fri, 24 Feb 95 10:34:10 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02151; Fri, 24 Feb 1995 10:27:02 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA10773; Fri, 24 Feb 95 10:26:52 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA15197; Fri, 24 Feb 95 10:20:41 -0800 Received: by xirtlu.zk3.dec.com; id AA04737; Fri, 24 Feb 1995 13:20:38 -0500 Message-Id: <9502241820.AA04737@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 12:13:49 EST." <9502241713.AA03871@snark.imsi.com> Date: Fri, 24 Feb 95 13:20:31 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, Danny is right on the performance hit its obvious. How much I think is a a good question. But when you get IPv6 with the present security just doing a authentication with MD5 and no key management. Expect a 50% peformance loss. If Danny's suggestion saves 10% then I think we should take it. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 10:37:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07108; Fri, 24 Feb 95 10:37:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06099; Thu, 23 Feb 95 15:58:13 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23397; Thu, 23 Feb 1995 15:51:08 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA09262; Thu, 23 Feb 95 15:51:07 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA00528; Thu, 23 Feb 95 15:48:08 -0800 Received: by xirtlu.zk3.dec.com; id AA05709; Thu, 23 Feb 1995 18:48:06 -0500 Message-Id: <9502232348.AA05709@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net Subject: Re: (IPng) Re: ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 95 23:03:13 GMT." <3960.bsimpson@morningstar.com> Date: Thu, 23 Feb 95 18:48:00 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill OK with me on IPv4 I am just saying with IPv6 we get to start fresh. Could be bigtime hard for I4 to do this I think. But if we want to do it I will help. Sorry if it appeared otherwise. Just don't want to not do it in IPv6 because its difficult in IPv4. I mean if we are in DNS anyway and folks think we can do it I will help. Hey I am a team player. sorry, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 10:51:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07137; Fri, 24 Feb 95 10:51:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07131; Fri, 24 Feb 95 10:51:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04221; Fri, 24 Feb 1995 10:44:08 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA14611; Fri, 24 Feb 95 10:44:03 PST Received: from relay.imsi.com by wintermute.imsi.com id NAA02074; Fri, 24 Feb 1995 13:44:01 -0500 Received: from snark.imsi.com by relay.imsi.com id NAA10440; Fri, 24 Feb 1995 13:44:01 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA04035; Fri, 24 Feb 95 13:43:57 EST Message-Id: <9502241843.AA04035@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 1995 13:20:31 EST." <9502241820.AA04737@xirtlu.zk3.dec.com> X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 13:43:57 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM bound@zk3.dec.com says: > Danny is right on the performance hit its obvious. No it isn't, Jim. A round trip might be required in *some* key management techniques in the *worst case*, and in any case the time in question is swamped by other times required. As I noted, virtually every transport session on the net these days begins with a DNS round trip. No one complains about that. And no, we aren't going to do user level keying for random ICMP messages -- what would it mean? User level keying is going to end up being employed for long lived sessions where the setup time is invisible over the length of the connection. So far as I can tell, he has no figures to back up his claims. Had he phrased this as a question or a suggestion for something to try to measure I would prehaps not be disturbed by his comments -- saying we should be considering this sort of thing is perfectly reasonable -- but I really don't like pronouncements from on high from people who have no implementation experience. One would think that he'd built a complete system, deployed it, and had been conducting measurements from the way that he wrote. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 10:56:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07149; Fri, 24 Feb 95 10:56:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07143; Fri, 24 Feb 95 10:56:25 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04906; Fri, 24 Feb 1995 10:49:17 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA15792; Fri, 24 Feb 95 10:49:11 PST From: Ran Atkinson Message-Id: <9502241343.ZM8407@bodhi> Date: Fri, 24 Feb 1995 13:43:33 -0500 In-Reply-To: bound@zk3.dec.com "Re: (IPng) out-of-band key management is like virtual circuits" (Feb 24, 13:20) References: <9502241820.AA04737@xirtlu.zk3.dec.com> X-Mailer: Z-Mail (3.0.0 15dec93) To: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) out-of-band key management is like virtual circuits Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, Dan's approach does not have the claimed performacen win. Hence is not sensible in our circumstance. Ran ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 10:58:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07162; Fri, 24 Feb 95 10:58:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07156; Fri, 24 Feb 95 10:58:22 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05107; Fri, 24 Feb 1995 10:51:15 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA16380; Fri, 24 Feb 95 10:51:14 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-29.dialip.mich.net [141.211.7.165]) by merit.edu (8.6.10/merit-2.0) with SMTP id NAA25181; Fri, 24 Feb 1995 13:51:02 -0500 Date: Fri, 24 Feb 95 18:07:16 GMT From: "William Allen Simpson" Message-Id: <3988.bsimpson@morningstar.com> To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net Subject: (IPng) Re: out-of-band key management is like virtual circuits Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Please reply on the IPSEC list, as those IPv6 members involved in security are already on that list. We have separate lists for separate IPng features, such as addrconf. > From: Danny.Nessett@eng.sun.com (Dan Nessett) > I think it might be useful to approach the in-band/out-of-band key management > issue from another perspective. Out-of-band management assumes either that > a synchronized security assocation already exists between the source and > destination hosts or that when an IP packet is processed, the key management > software is called to establish this context. I've already noted (previous messages to the IPSEC list) that the term "in-band" is inappropriate. All proposed messages are using IP, not some other signalling channel. (It appears that we have an influx of CCITT telco folks, or maybe that's what they are teaching in grad schools nowadays.) > Those familiar with X.25 will > recognize this as a virtual circuit model of operation. In fact I think it > is a fair characterization that out-of-band key management imposes a > "security virtual circuit" model on IP security (both IPv4 and IPv6). > I'm familiar with X.25, and I see no resemblence. TCP provides an end-to-end connection. I know of nobody who would characterize it as being at all like X.25 or virtual-circuit. The proposed Photuris IP Security only uses UDP datagrams, not even TCP, in order to create less state. The only proposal which suggests a reliable virtual signalling channel embedded in and on every datagram is, well, the one from Sun, which we have rejected. > In-band key management, on the other hand, is philosophically similar to > dynamic connection management, which is the technique employed by TCP. > When a connection is required, information is included within the TCP > header (e.g., syn flag, isn) to allow the construction of a connection > record at the destination. Similarly, the destination returns information > (syn ack, its isn), to allow the source to complete the construction of > its connection record. > Yes, this is the model used by Photuris. It should be no surprise that the exchange bears a strong resemblence to a TCP handshake, as Phil Karn has been a long-time TCP implementor. > An important point that some may have overlooked is that the current draft of > the IPv6 security Architecture I-D (I couldn't find an security architecture I-D > for IPv4) encourages the use of user-to-user keying (by specifying that > implementations MUST support user-to-user keying, but only MAY provide > for host-to-host keying), rather than host-to-host keying. The implication > is that everytime a new *user* communicates to a specific machine, the > key management software will be required to establish a new security > association. Indeed, this is a very important feature! For the reasons which have been stated to this list on several occasions. I refer you to the archives. > If out-of-band keying is used, this is going to mean, on > average, very poor performance, since the key management protocol must > use a separate communications stream to establish the keys for use before > communications on the stream originating the key management activity > can proceed. > Since we do not have "streams", this makes no sense. Of course user UDP datagrams do not "flow" during IP Security datagrams, as datagrams use bandwidth. This will make no difference to the user, which does not see datagrams. Do you have a technique which involves no bandwidth or computation? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 11:11:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07189; Fri, 24 Feb 95 11:11:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07171; Fri, 24 Feb 95 11:11:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06916; Fri, 24 Feb 1995 11:04:20 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA20065; Fri, 24 Feb 95 11:04:20 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA16655; Fri, 24 Feb 95 10:38:32 -0800 Received: by xirtlu.zk3.dec.com; id AA05353; Fri, 24 Feb 1995 13:38:27 -0500 Message-Id: <9502241838.AA05353@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 09:49:18 PST." <199502241749.JAA24180@elrond.Eng.Sun.COM> Date: Fri, 24 Feb 95 13:38:20 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I agree that key mgmt protocols should not be forced to use in-band techniques. >I think all of us (and there have been at least 5 messages from different >people on this list asking for in-band signalling) would like the *option* >of using in-band signalling. Then we can let the market decide which is >the best approach. 100% support on this. Let the option exist and let us who will build IPv6 security see if the market wants it. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 11:11:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07190; Fri, 24 Feb 95 11:11:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07177; Fri, 24 Feb 95 11:11:31 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06929; Fri, 24 Feb 1995 11:04:24 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA20090; Fri, 24 Feb 95 11:04:24 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA16265; Fri, 24 Feb 95 10:33:43 -0800 Received: by xirtlu.zk3.dec.com; id AA05181; Fri, 24 Feb 1995 13:33:39 -0500 Message-Id: <9502241833.AA05181@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: Dan Nessett , ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 12:26:29 EST." <9502241226.ZM8320@bodhi> Date: Fri, 24 Feb 95 13:33:33 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, I still await your response to my concerns in general the way the spec is written I sent out Monday Feb 20th. > I find your analogy to be highly misleading. I strongly disagree >with your assertion that in-band key mgmt is better for a datagram >network. All of the capability that you assert is unique to in-band >can be done by simply sending key mgmt packets at the same time one >sends the datagrams. Since SAIDs are receiver-oriented, a sender can't >force a key upon the receiver without the receiver's involvement in And where are these key mgmt packets in relation to the IPv6 packet? I can't parse what your thinking here? So far Danny has not been misleading and its obvious to me? You have not convinced me it is misleading, but I am sure Danny will reply too. >any case. If we remove that receiver-orientation, then IP multicasting >will not work well with security (and multicasting is a 1st order >service of IPv6). I don't agree with this is at all. Multicast for system discovery or autoconfiguration absolutely. Not for applications. The bulk of applications will still use unicast addresses for datagrams at least for the next 5 years. > Out of band keying does NOT mean "on average, very poor performance". >Your assertion just is not true. The assertion is intuitively true. > We should continue to avoid coupling key mgmt and the security >mechanisms and hence should continue to avoid in-band key mgmt in >standards-track specifications within the IETF. Better yet we need more people finally like Danny to come to IPNG and send us a wake up call before we make something a proposed standard that will cost so much in performance no one will use no matter how much security they need. Danny please continue your input on this we needed this kind of drilling of the security specs. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 11:11:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07191; Fri, 24 Feb 95 11:11:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07183; Fri, 24 Feb 95 11:11:35 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06937; Fri, 24 Feb 1995 11:04:28 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA20121; Fri, 24 Feb 95 11:04:29 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA16265; Fri, 24 Feb 95 10:33:43 -0800 Received: by xirtlu.zk3.dec.com; id AA05181; Fri, 24 Feb 1995 13:33:39 -0500 Message-Id: <9502241833.AA05181@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: Dan Nessett , ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 12:26:29 EST." <9502241226.ZM8320@bodhi> Date: Fri, 24 Feb 95 13:33:33 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, I still await your response to my concerns in general the way the spec is written I sent out Monday Feb 20th. > I find your analogy to be highly misleading. I strongly disagree >with your assertion that in-band key mgmt is better for a datagram >network. All of the capability that you assert is unique to in-band >can be done by simply sending key mgmt packets at the same time one >sends the datagrams. Since SAIDs are receiver-oriented, a sender can't >force a key upon the receiver without the receiver's involvement in And where are these key mgmt packets in relation to the IPv6 packet? I can't parse what your thinking here? So far Danny has not been misleading and its obvious to me? You have not convinced me it is misleading, but I am sure Danny will reply too. >any case. If we remove that receiver-orientation, then IP multicasting >will not work well with security (and multicasting is a 1st order >service of IPv6). I don't agree with this is at all. Multicast for system discovery or autoconfiguration absolutely. Not for applications. The bulk of applications will still use unicast addresses for datagrams at least for the next 5 years. > Out of band keying does NOT mean "on average, very poor performance". >Your assertion just is not true. The assertion is intuitively true. > We should continue to avoid coupling key mgmt and the security >mechanisms and hence should continue to avoid in-band key mgmt in >standards-track specifications within the IETF. Better yet we need more people finally like Danny to come to IPNG and send us a wake up call before we make something a proposed standard that will cost so much in performance no one will use no matter how much security they need. Danny please continue your input on this we needed this kind of drilling of the security specs. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 11:15:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07213; Fri, 24 Feb 95 11:15:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07207; Fri, 24 Feb 95 11:15:16 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07343; Fri, 24 Feb 1995 11:08:09 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA20915; Fri, 24 Feb 95 11:08:09 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA18620; Fri, 24 Feb 95 11:03:42 -0800 Received: by xirtlu.zk3.dec.com; id AA06454; Fri, 24 Feb 1995 14:03:35 -0500 Message-Id: <9502241903.AA06454@xirtlu.zk3.dec.com> To: atkinson@itd.nrl.navy.mil Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 13:43:33 EST." <9502241343.ZM8407@bodhi> Date: Fri, 24 Feb 95 14:03:28 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Well you say this dan says the other. But my knowledge strictly of how the packet gets to a user interface and when your MD5 happens in my kernel and how the key mgmt will work it appears to me Dan is right. Piggybacking is always faster. I have seen this in other areas besides security. Please explain technically why this is not true for the key mgmt protocol that could be used with your security architecture. And even if you can do this why not leave it as an option. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 11:33:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07236; Fri, 24 Feb 95 11:33:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07230; Fri, 24 Feb 95 11:33:28 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09347; Fri, 24 Feb 1995 11:26:19 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA25293; Fri, 24 Feb 95 11:26:20 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA19998; Fri, 24 Feb 95 11:20:06 -0800 Received: by xirtlu.zk3.dec.com; id AA06929; Fri, 24 Feb 1995 14:19:54 -0500 Message-Id: <9502241919.AA06929@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 13:43:57 EST." <9502241843.AA04035@snark.imsi.com> Date: Fri, 24 Feb 95 14:19:48 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Look folks lets slow down here and go back to basic protocol of 1993 #101. You can gain performance in networks in various manners. Like reducing memory copies, avoiding fine granular timers, and piggybacking data and even packets. The in-band approach can possibly increase performance becuase of the latter strictly from a pure packet throughput and avoidance of signing the key out-of-band data which is going to cost extra. The cost is the extra communications to establish the user to user key. It appears to me in-band data with the users key can avoid that extra communications. The other basic is why cannot we have it as an option. How many of you have tested Rans architecture in your code? The Digital team has. And it will be very costly to your end systems. If Danny's idea can or may give us a performance gain then why not permit it as an option. I can't commit but maybe we will build it and test it in our implementation of IPv6. How can a group who could not even come to a bake-off to test what is to be a proposed standard be so all fired up to say that this will not improve security performance when they themselves it appears are also dealing completely in theory, abstractions, and some historical evidence. I am also reading Dannys mail as I write this and I honestly did not get the same impressions from Dannys mail as Perry did. What I got was an engineer who knows a hell of a lot about security giving us another technical perspective. One that raises questions about our present Security draft. I will not be "railroaded" into not listening to his suggestion and data. In addition its completely in line with my input to Ran on the issue of Key Mgmt and the Security architecture and how a particular MUST is worded. In fact this is a good LAST CALL I don't like this argument to the IESG if necessary. Look this whole area of key mgmt has lots of people outside of the IETF worried that we have not figured this out. Also I still await response from Ran on my issue of this being widely deployed but the specs say theY want to make MUST that which will not be widely deployed. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 11:40:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07251; Fri, 24 Feb 95 11:40:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07245; Fri, 24 Feb 95 11:40:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10149; Fri, 24 Feb 1995 11:32:53 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA26917; Fri, 24 Feb 95 11:32:49 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA20656; Fri, 24 Feb 95 11:29:09 -0800 Received: by xirtlu.zk3.dec.com; id AA07195; Fri, 24 Feb 1995 14:29:07 -0500 Message-Id: <9502241929.AA07195@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 18:07:16 GMT." <3988.bsimpson@morningstar.com> Date: Fri, 24 Feb 95 14:29:01 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, NO I AM NOT ON IPSEC AND I DO NOT WANT TO BE. THIS MUST BE ON IPNG AND STOP BEING POLITICAL. IF THIS IS NOT DISCUSSED HERE I OBJECT TO YOUR STANDARD BEING SUGGESTED AS PROPOSED AT DANVERS. THIS MUST STAY ON THIS LIST OR YOU IMHO ARE JEOPARDIZING GETTING TO PROPOSED STANDARD. You build the standard in this group and then when there is a tough issue you take it to another groups mailing list. This is a foul and I will object to the IESG formally if this is what is to happen. I highly suggest to the chairs to get with Ran offline and fix this if he continues to pursue this course. He should have to justify why Dannys claims will not benefit a draft under this groups charter as of right now just like the rest of the drafts must do this. This is just the wrong thing to do. Also you consistently ask everyone else to prove their point in depth technically now its your turn. Do it or just give in. The principles of the IETF apply to all of us not just some of us. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 11:42:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07263; Fri, 24 Feb 95 11:42:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07257; Fri, 24 Feb 95 11:41:53 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10316; Fri, 24 Feb 1995 11:34:45 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA26681; Fri, 24 Feb 95 11:32:07 PST Received: from relay.imsi.com by wintermute.imsi.com id NAA02016; Fri, 24 Feb 1995 13:31:30 -0500 Received: from snark.imsi.com by relay.imsi.com id NAA10342; Fri, 24 Feb 1995 13:31:29 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA04008; Fri, 24 Feb 95 13:31:26 EST Message-Id: <9502241831.AA04008@snark.imsi.com> To: Danny.Nessett@Eng (Dan Nessett) Cc: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net Subject: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 1995 09:49:18 PST." <199502241749.JAA24180@elrond.Eng.Sun.COM> X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 13:31:26 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan Nessett says: > Ran, > > Your point : > > > All of the capability that you assert is unique to in-band > > can be done by simply sending key mgmt packets at the same time one > > sends the datagrams. > > is somewhat misleading. So is yours. > The key management protocol will require an exchange > between the source and destination in order for the source to obtain the > SAID that it will use in the IP packet, which processing started the whole > process. This induces a considerable delay in delivering the original > IP packet. Any key management protocol will require one or more exchanges to key servers. This will induce delay. Any connection these days on the net requires an exchange with DNS servers. This induces delay. Any key management protocol based on public key techniques will require significant computation time -- probably more than several packet round trips on the current internet. This will induce delay. None of these delays can be avoided. .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 12:11:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07317; Fri, 24 Feb 95 12:11:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05627; Thu, 23 Feb 95 09:59:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09981; Thu, 23 Feb 1995 09:52:32 -0800 Received: from rip.psg.com by Sun.COM (sun-barr.Sun.COM) id AA20604; Thu, 23 Feb 95 09:52:33 PST Received: by rip.psg.com (Smail3.1.29.1 #3) id m0rhhiC-00030oC; Thu, 23 Feb 95 09:52 PST Message-Id: Date: Thu, 23 Feb 95 09:52 PST From: randy@psg.com (Randy Bush) To: Steve Deering Cc: ipng@sunroof.Eng.Sun.COM, namedroppers@rs.internic.net Subject: (IPng) ICMP name query messages References: <95Feb22.192359pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, After sleeping on this a bit, I have begun to fear that we are, with the best of intent, entering a discussion on the implementation details of something for which we do not have the overall requirements agreed, or even the consensus that it is a good thing. For those of us who were at DNSIND and not IPng (or were at neither) could someone please describe how and what consensus was reached at the IPng meeting, what the requirement assumptions are, and what the lower-level goals are? I am obliged to declare that I am one who has qualms. Luckily others are expressing them far better than I could. randy PS: the discussion is quite welcome on namedroppers, and many would feel disenfranchised were it not. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 12:21:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07349; Fri, 24 Feb 95 12:21:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07343; Fri, 24 Feb 95 12:20:56 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14500; Fri, 24 Feb 1995 12:13:48 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA05693; Fri, 24 Feb 95 12:13:49 PST From: Ran Atkinson Message-Id: <9502241511.ZM8545@bodhi> Date: Fri, 24 Feb 1995 15:11:42 -0500 In-Reply-To: bound@zk3.dec.com "Re: (IPng) out-of-band key management is like virtual circuits" (Feb 24, 14:19) References: <9502241919.AA06929@xirtlu.zk3.dec.com> X-Mailer: Z-Mail (3.0.0 15dec93) To: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) out-of-band key management is like virtual circuits Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, Your statement that "Digital has test and found it to be costly" is directly refuted by other folks who are employed by Digital and have been in regular contact with me for over a year now. I do not believe you. I do believe Perry and other who have been implementing. Perry has code. I have code. Phil Karn has code for a similar security mechanism (different bit formats, but similar) in KA9Q. There is NO "MUST use security" there is a "MUST implement and support security". This is consistent with direction to me from the IESG. That issue must be resolved with them directly as I am following their specific direction on this point. Manual key distribution is necessary to have even in the presence of a key management protocol, making it mandatory regardless. We can't mandate a key mgmt protocol that isn't yet a Proposed Standard so we say "implementations SHOULD" implement it when it becomes Proposed Standard. More comments will come when I have more time. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 12:29:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07362; Fri, 24 Feb 95 12:29:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07356; Fri, 24 Feb 95 12:29:38 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15328; Fri, 24 Feb 1995 12:22:29 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA07596; Fri, 24 Feb 95 12:22:29 PST From: Ran Atkinson Message-Id: <9502241513.ZM8550@bodhi> Date: Fri, 24 Feb 1995 15:13:45 -0500 In-Reply-To: bound@zk3.dec.com "Re: (IPng) Re: out-of-band key management is like virtual circuits" (Feb 24, 14:29) References: <9502241929.AA07195@xirtlu.zk3.dec.com> X-Mailer: Z-Mail (3.0.0 15dec93) To: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, You addressed this last note to me and you should not have. You are responding to a note from someone else, not me. I have never suggested moving IPv6 Security away from the IPng mailing list. Please pay more attention to the FROM line in email that you read. I will not be replying to any more flames from you. If/when you calm down, I will reply to normal email notes as my time permits. Thanks, Ran ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 12:59:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07375; Fri, 24 Feb 95 12:59:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07369; Fri, 24 Feb 95 12:58:52 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18100; Fri, 24 Feb 1995 12:51:46 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA13230; Fri, 24 Feb 95 12:51:45 PST From: Ran Atkinson Message-Id: <9502241546.ZM8601@bodhi> Date: Fri, 24 Feb 1995 15:46:37 -0500 In-Reply-To: markson@osmosys.incog.com (Tom Markson) "Re: (IPng) out-of-band key management is like virtual circuits" (Feb 24, 12:01) References: <9502242001.AA02003@monster.incog.com> X-Mailer: Z-Mail (3.0.0 15dec93) To: Tom Markson Subject: Re: (IPng) out-of-band key management is like virtual circuits Cc: ipng@sunroof2.Eng.Sun.COM Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Feb 24, 12:01, Tom Markson wrote in response to Perry Metzger: } Subject: Re: (IPng) out-of-band key management is like virtual circuits > Any key management protocol will require one or more exchanges to key > servers. This will induce delay. % On the in-band model, if the long term key is local or cached, % no exchange with the key server is necessary. With out of band, % this exchange and it's delay will always incurred. One could send the same information to a well-known UDP port rather than as part of the ESP header and similarly avoid the key server exchanges. As the term "out of band" is being used here, UDP port use would be considered "out of band". > Any connection these days on the net requires an exchange with DNS > servers. This induces delay. % You can still use the IP address in which case is no DNS lookup. % Furthermore, your DNS server may cache the names/addresses in which % case there is no delay, as well. Again, a UDP port destination for the same keying data would do nicely and have exactly the same latency property as the scheme you describe. Right ?? > Any key > management protocol based on public key techniques will require > significant computation time -- probably more than several packet > round trips on the current internet. This will induce delay. None of > these delays can be avoided. % Some of them certainly can be avoided. With in-band keying, caching % of long term keys eliminates exchanges with the key servers for every % connection. In-band keying also eliminates the exchange required for % every connection. Computing a reasonably large amount of key material as part of one's D-H exchange would permit one to extract several session keys from the one computation and reduce the amount of recomputation needed. A single D-H exchange between hosts A and B could provide enough key material for several different session keys and different keys could be assigned to different connections, again achieving similar effects with what is being called "out of band" key mgmt in this WG. % By eliminating the structured SAID bit, you are also eliminating a % particular flavor of key management. As I recall, IPSP is supposed % to be independent of key management. >From the descriptions so far, it appears that the techniques used in-band can be adapted to have their own UDP port and thus work as well but be termed by this WG "out of band". Please clarify why you believe this is not true. This might be the crux of our non- agreement on this. ASIDE: I'm not happy with these "in-band" and "out-of-band" usages because when I think of "out-of-band" I think of human couriers carrying key material around and not sending that key material over the network where the keys will be used. Regards, Ran ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 13:01:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07394; Fri, 24 Feb 95 13:01:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07388; Fri, 24 Feb 95 13:01:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18269; Fri, 24 Feb 1995 12:53:56 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA13516; Fri, 24 Feb 95 12:53:14 PST Received: from relay.imsi.com by wintermute.imsi.com id PAA03232; Fri, 24 Feb 1995 15:49:15 -0500 Received: from snark.imsi.com by relay.imsi.com id PAA12059; Fri, 24 Feb 1995 15:49:15 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA04270; Fri, 24 Feb 95 15:49:12 EST Message-Id: <9502242049.AA04270@snark.imsi.com> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 1995 14:19:48 EST." <9502241919.AA06929@xirtlu.zk3.dec.com> X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 15:49:11 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM bound@zk3.dec.com says: > Look folks lets slow down here and go back to basic protocol of 1993 > #101. You can gain performance in networks in various manners. Like > reducing memory copies, avoiding fine granular timers, and piggybacking > data and even packets. The in-band approach can possibly increase > performance becuase of the latter strictly from a pure packet throughput > and avoidance of signing the key out-of-band data which is going to cost > extra. Jim; 1) Over the life of a typical Telnet session or AFS file sharing session or whatever, the few extra milliseconds involved in a user level packet exchange won't be noticed. Note that needing a packet exchange is worst case. I don't think it will occur normally. 2) Typical ICMP and other "system" applications will not be using user level keying and average case will have their security associations in place at the time of a packet transmission -- in other words, they will almost always be "in cache" as it were. > The other basic is why cannot we have it as an option. How many of you > have tested Rans architecture in your code? The Digital team has. And > it will be very costly to your end systems. Are we talking about encrypting every packet? We know thats expensive. I don't think that has anything to do with Ran's architecture -- if you are encrypting all your data, it costs a huge amount. And yes, I've got code that does that sort of thing right now, and it is bloody expensive. Its unavoidable, however. The solution is to use fast ciphers or hardware cipher implementations. Just switching from DES to RC4 gives you a huge boost. However, this has nothing to do with performance hits from key management. To my knowledge, as it stands you are probably using manual keying. > If Danny's idea can or may give us a performance gain then why not > permit it as an option. If someone thinkgs rubbing chicken entrails on our chests will give us a performance gain, shall we specify that in an RFC as well? I fail to understand what sort of performance gain we are to expect here. We aren't even being given a model of the sort of traffic we are discussing. If we are talking about a Telnet session Danny's notion can't give us any observable performance gain. If we are talking about a random hit at a DNS server it might give us a gain -- but DNS is not being protected with this mechanism. Were we talking about some sort of file service arrangement it certainly wouldn't give us a gain. Could someone PLEASE tell me how gaining a few milliseconds in startup of relationships between hosts that last hours is going to be worthwhile? Remember, of course, that we are talking of "worst case" situations -- average case you aren't going to gain anything. > In addition its completely in line with my input to Ran on the issue of > Key Mgmt and the Security architecture and how a particular MUST is > worded. In fact this is a good LAST CALL I don't like this argument to > the IESG if necessary. I don't believe a last call has been issued. Could you explain what it is that you are speaking of? Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 13:01:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07406; Fri, 24 Feb 95 13:01:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07400; Fri, 24 Feb 95 13:01:44 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18326; Fri, 24 Feb 1995 12:54:37 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA13715; Fri, 24 Feb 95 12:54:35 PST Received: from Bill.Simpson.DialUp.Mich.Net ([141.211.7.166]) by merit.edu (8.6.10/merit-2.0) with SMTP id PAA00163; Fri, 24 Feb 1995 15:50:00 -0500 Date: Fri, 24 Feb 95 20:18:26 GMT From: "William Allen Simpson" Message-Id: <3994.bsimpson@morningstar.com> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bound@zk3.dec.com > > Ran, > > NO I AM NOT ON IPSEC AND I DO NOT WANT TO BE. > > THIS MUST BE ON IPNG AND STOP BEING POLITICAL. IF THIS IS NOT DISCUSSED > HERE I OBJECT TO YOUR STANDARD BEING SUGGESTED AS PROPOSED AT DANVERS. > > THIS MUST STAY ON THIS LIST OR YOU IMHO ARE JEOPARDIZING GETTING TO > PROPOSED STANDARD. > > You build the standard in this group and then when there is a tough > issue you take it to another groups mailing list. This is a foul and I > will object to the IESG formally if this is what is to happen. > Jim, you are way out of line here. Ran did not take anything from IPv6 to IPv4. I did. Many months ago. One of the IPv4 folks came complaining back to IPv6. There just wasn't enough support for SKIP in IPv4. He can see that IPv6 is where the action is. And _I_ was the one asking us to stay on one mailing list. Particularly, not the IPng list, where people reply, but it won't show up on the other list because of the reply-to field. If you are not interested in IP Security enough to at least join the mailing list, let alone read the archives, then I don't see where you think you have standing to criticize. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 13:08:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07422; Fri, 24 Feb 95 13:08:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07416; Fri, 24 Feb 95 13:07:59 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19079; Fri, 24 Feb 1995 13:00:53 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA15200; Fri, 24 Feb 95 13:00:50 PST Received: from relay.imsi.com by wintermute.imsi.com id PAA03272; Fri, 24 Feb 1995 15:56:59 -0500 Received: from snark.imsi.com by relay.imsi.com id PAA12129; Fri, 24 Feb 1995 15:56:59 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA04287; Fri, 24 Feb 95 15:56:55 EST Message-Id: <9502242056.AA04287@snark.imsi.com> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 1995 14:29:01 EST." <9502241929.AA07195@xirtlu.zk3.dec.com> X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 15:56:55 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM bound@zk3.dec.com says: > I highly suggest to the chairs to get with Ran offline and fix this if > he continues to pursue this course. He should have to justify why > Dannys claims will not benefit a draft under this groups charter as of > right now just like the rest of the drafts must do this. This is just > the wrong thing to do. "Danny's" suggestion is in fact Ashar Aziz's suggestion, as you would know if you were on the ipsec list which you feel you don't have to be on. However, Ashar isn't claiming it has anything to do with performance per se -- he wants it to make his life easier in promoting a particular key management system called SKIP, which was designed with in-band in mind. I don't know how Danny got into this. He wasn't involved in any of the discussions before we heard from him from on high -- and I must say that I rather resent someone making an absolutistic demand presented without evidence as their initial posting on a topic. Some of the rest of us have been building prototypes and testing them, you know. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 13:09:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07434; Fri, 24 Feb 95 13:09:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07428; Fri, 24 Feb 95 13:08:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19171; Fri, 24 Feb 1995 13:01:51 -0800 Received: from bodhi.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA15400; Fri, 24 Feb 95 13:01:49 PST From: Ran Atkinson Message-Id: <9502241601.ZM8618@bodhi> Date: Fri, 24 Feb 1995 16:01:19 -0500 X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) apology and comment on performance impacts Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM All, I apologise publically to Jim Bound. He is correct that DEC and others (particularly including Peter Grehan at DEC/Australia, Hilarie Orman at U. Arizona, and Joe Touch at ISI) have done performance measurements indicating that MD5 keying for use with the Authentication Header is slow due to MD5 slowness. I completely agree with that performance assessment of MD5 and it is consistent with local work here at NRL (my hardware is not as fast as an Alpha so my numbers are slower than the Alpha numbers). I believe that the base Authentication Header is not a bad performance hit outside of the delays due to MD5. Joe Touch has proposed a faster alternative that merits close review by algorithm experts in the security community. The Authentication Header is designed to be algorithm- independent so a faster algorithm can be substituted for MD5 if/when a faster algorithm is found that after public review is believed to have sufficient cryptologic strength. I will modify the Auth Header drafts to substitute a different algorithm in place of MD5 if/when the community reaches consensus on some alternative algorithm. This could easily happen between Proposed Standard and Draft Standard, for example. Similarly, DES is not fast. I don't believe that ESP itself is a performance hit, but DES certainly will be. Again, because ESP is designed to be algorithm-independent, substituting some other algorithm is straight-forward should there be community consensus that such a substitution would be appropriate. I do not believe that "customer use of security" is mandated in any document. I do believe that "implementation and support of security" is mandated. This position seems entirely appropriate to me given the recurring and quite serious security problems reported widely, for example the recent CERT advisory on active attacks on terminal connections. Further, non-governmental customers such as Boeing and Chrysler have indicated that they would like to have security be implemented and available for their use in IPv6. The requirement for real IP security is being driven largely by non-government customers. Again, my apologies to Jim. I was out of line and I deeply regret it. Have a nicer rest of the day, Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 13:13:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07446; Fri, 24 Feb 95 13:13:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07440; Fri, 24 Feb 95 13:13:17 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19601; Fri, 24 Feb 1995 13:06:10 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA16234; Fri, 24 Feb 95 13:06:03 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-15.dialip.mich.net [141.211.7.151]) by merit.edu (8.6.10/merit-2.0) with SMTP id QAA00987 for ; Fri, 24 Feb 1995 16:05:59 -0500 Date: Fri, 24 Feb 95 20:50:13 GMT From: "William Allen Simpson" Message-Id: <3995.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) SKIPping out Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bound@zk3.dec.com > I highly suggest to the chairs to get with Ran offline and fix this if > he continues to pursue this course. He should have to justify why > Dannys claims will not benefit a draft under this groups charter as of > right now just like the rest of the drafts must do this. This is just > the wrong thing to do. > > Also you consistently ask everyone else to prove their point in depth > technically now its your turn. Do it or just give in. > I will save Ran the trouble. Danny's claim (of speed) will not benefit anyone because it is bullshit. SKIP speed is in computing ephemeral keys. It does this by carrying the current key in every packet, encrypted in another "long-lived" key. Because it carries the keys in every header, the headers are MUCH bigger, eating bandwidth. OK, understand now? Less CPU, more bandwidth. Bandwidth is the problem in most networks, so everything gets slower, not faster! Because it uses these "long-lived" keys, it doesn't have a property called "perfect forward secrecy". This is very important. What it means is that if ever somebody figures out your key, all of your data you have ever sent before is suddenly not secret. Perfect forward secrecy is one of our requirements, so SKIP loses bigtime. To protect these long-lived keys, they expect that you have a special hardware device. Another problem. Worse, they propose creating another parallel X.500 certificate tree. It doesn't use any of the deployed key databases that exist. Not X.509, not Kerberos, not DNS. N-o-t-h-i-n-g! SKIP -- which claims to be a key management proposal, but has only described a replacement for Ran's headers -- had some good ideas. However, they could not demonstrate the key management part. Their proposal is not interoperable (even on paper) with other proposals. It can't use the same IPv4 or IPv6 headers. Separation of header from key management is another requirement, so SKIP loses again. The proposal that can do _all_ of these things (plus others) is called Photuris. Most of the recent talk in IPSEC is about Photuris, not SKIP. Technical enough? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 13:32:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07486; Fri, 24 Feb 95 13:32:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07480; Fri, 24 Feb 95 13:32:07 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21735; Fri, 24 Feb 1995 13:25:00 -0800 Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA20098; Fri, 24 Feb 95 13:24:58 PST Message-Id: <9502242124.AA20098@Sun.COM> From: smb@research.att.com Received: by gryphon; Fri Feb 24 16:18:05 EST 1995 To: ipng@sunroof.Eng.Sun.COM Cc: Tom Markson , ipng@sunroof2.Eng.Sun.COM Subject: Re: (IPng) out-of-band key management is like virtual circuits Date: Fri, 24 Feb 95 16:18:04 EST Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM One could send the same information to a well-known UDP port rather than as part of the ESP header and similarly avoid the key server exchanges. As the term "out of band" is being used here, UDP port use would be considered "out of band". This has an important benefit: it's amenable to packet-filtering. It's bad enough that packet filters have to look at port numbers -- and they do. I don't want them having to peer at magic bits in the ESP header, the AH header, etc., to decide if the packet is kosher. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 13:32:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07498; Fri, 24 Feb 95 13:32:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07487; Fri, 24 Feb 95 13:32:34 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21816; Fri, 24 Feb 1995 13:25:27 -0800 Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA20202; Fri, 24 Feb 95 13:25:24 PST Message-Id: <9502242125.AA20202@Sun.COM> From: smb@research.att.com Received: by gryphon; Fri Feb 24 16:18:05 EST 1995 To: ipng@sunroof.Eng.Sun.COM Cc: Tom Markson , ipng@sunroof2.Eng.Sun.COM Subject: Re: (IPng) out-of-band key management is like virtual circuits Date: Fri, 24 Feb 95 16:18:04 EST Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM One could send the same information to a well-known UDP port rather than as part of the ESP header and similarly avoid the key server exchanges. As the term "out of band" is being used here, UDP port use would be considered "out of band". This has an important benefit: it's amenable to packet-filtering. It's bad enough that packet filters have to look at port numbers -- and they do. I don't want them having to peer at magic bits in the ESP header, the AH header, etc., to decide if the packet is kosher. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 13:56:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07590; Fri, 24 Feb 95 13:56:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06117; Thu, 23 Feb 95 16:06:02 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24320; Thu, 23 Feb 1995 15:58:56 -0800 Received: from BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA10720; Thu, 23 Feb 95 15:58:55 PST Received: from GAAK.BBN.COM by BBN.COM id aa08974; 23 Feb 95 18:51 EST Date: Thu, 23 Feb 1995 18:51:39 EST Message-Id: To: ipng@sunroof.Eng.Sun.COM, namedroppers@rs.internic.net In-Reply-To: <95Feb22.192359pst.12174@skylark.parc.xerox.com> (message from Steve Deering on Wed, 22 Feb 1995 19:23:54 PST) Subject: (IPng) Re: ICMP name query messages From: "Michael A. Patton" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Putting on my network operator's hat for a minute, I have some REALLY BIG PROBLEMS with using the host as the ONLY means of translating a number into a name. I frequently need to do this translation hours, days, or even months :-) after the fact. I realize that the longer it's been since a log was written, the less accurate the answer will be, but I can STILL GET AN ANSWER. If the only way to get an answer is from the users PC, I will usually be unable to get any answer at a random later time. Also, it has been my experience that even networking organizations can't get all the nodes to properly know their own names (that information is [sometimes] available in IPv4 via SNMP, I find it wrong as often as right), and would place very little expectation that end users could do it. Now having said that, I think that having this facility is sorely needed and fills an important gap. I therefore strongly applaud its addition to the IPv6 repertoire. But I think it also important that there be a persistent repository to answer queries when the subject host is not available (either because it's been shut off for the evening [which is when I usually get around to noticing logs that I want to research] or administratively firewalled as others have mentioned). I'm not certain that the DNS is the right place for this, but it _is_ the most widely deployed persistent distributed database around. As I've said in other fora, I think the solution is not to change the low level detail, but to offer much better tools to automatically manage the database so that it's easier to keep it populated and correct. When I worked at LCS we had an automatted procedure (with allowance for manual exceptions) for generating all zone master files. I believe we had well over 99% correct data in our IN-ADDR tree (with virtually all the errors being in the manually maintained fraction, a large part of which I was in the process of automating when I left, which I believed would have made the accuracy better than 99.9%). If most DNS administrators used tools like this, the data could be much better. In conclusion, I don't think it's the design of the database representation that's at fault in the bad rep of the IN-ADDR tree, but the lack of tools to maintain it. If the forward tree wasn't as necessary as it is, it would be as bad, since there aren't tools to maintain it, either. This is based on knowledge of parts of the Internet where name to address mapping is not considered important, and knowing that some of these domains are less than 1% correct... -MAP ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 14:02:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07623; Fri, 24 Feb 95 14:02:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06283; Thu, 23 Feb 95 21:06:42 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18124; Thu, 23 Feb 1995 20:59:36 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA25533; Thu, 23 Feb 95 20:59:37 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-09.dialip.mich.net [141.211.7.145]) by merit.edu (8.6.10/merit-2.0) with SMTP id XAA24040 for ; Thu, 23 Feb 1995 23:59:32 -0500 Date: Fri, 24 Feb 95 03:23:13 GMT From: "William Allen Simpson" Message-Id: <3962.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net Subject: Re: (IPng) A NEW thought on addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM You've sent this to 3 lists, and not gotten much of an answer. I've just read the message. Sorry I'm so slow. > From: rgm3@is.chrysler.com (Robert Moskowitz) > I am making a GROSS assumption that any of the config options will help > create all of these addresses, and that all of the necessary AAAA records > will be created. > Well, that's what my Deployment draft said should happen, but I couldn't get the political support. They won't guarantee that DNS will be available, or that the prefixes will be advertised so that the addresses will be generated. Several very vocal people are against it. > When PRESS.MFG.FOO.COM needs to connect to CAD.ENG.FOO.COM, the > gethostbyname() will return 3 AAAA records. PRESS will select the only > common address, the Private one, for the connection and off they go. In > fact, somehow there will need to be a weighting factor so that all FOO.COM > internal connections will perfer the private addresses. But I do not see > anything like this in the DNS spec. Remember that a commection between > CAD.ENG.FOO.COM to WWW.MKTG.FOO.COM has 2 valid addresses to choose from. > It's in Neighbor Discovery Processing. (c) The Destination is compared against the routing-prefixes | configured for each interface, or learned from Prefix- | Information and Known-Identifier extensions. If the Destination exactly matches one of the routing-prefixes, | then the Source is chosen from the indicated interface. When more than one IPv6 Unicast Address meets the criteria, the | Source chosen SHOULD have the longest bit-wise prefix match with the Destination. > The external connection for WWW.MKTG.FOO.COM will be interesting. How can a > decision be made which address to use? I might think that in response to an > external connection request, it will use the address that the was the > destination of the incoming package. Yes. In fact, it _has_ to reverse the destination to the source. > But if this is a caching server that > is going out to the greater world, WWW should first use one of the provider > addresses and if no connection is established, to then try the other > provider address. How to do this? Again it looks like a DNS address > weighting problem. Perhaps something like route weights in OSPF? > No, the choice was made by the requestor. But, if we are using Nimrod or Mobility, we can use a Routing Header to choose a different outgoing provider in the reply. But that won't be using the DNS. An external policy mapping database (Nimrod) or a Remote Redirect from the peer (Mobility) sets up the routing header. > So it seems like multihomed networks COULD WORK!!!!! We need to use the > speced ability to have multiple addresses per host interface. > > Now on to the joy of configuring the routers for such usage...... > > The router folks will need to configure 3 topologies in the router network > of FOO.COM. The private topology, the part of the network accessable via > A.NET and the part accessable via B.NET. A challenge for sure, unless there > is someway to identify a local topology (upper part of the lower half of the > address) and valid provider prefixes for the routers? > Well, if you had read my Deployment draft, you would note that the Boundary routers which connect to the providers are configured with RDI information. These prefixes are then propagated to all the routers in the site. In this case, each could be configured 2 RDIs: the internal, and the provider specific. The internal would not be reflected in the IDRP policy database, and thus would only be visible on site. I will add this to the Deployment draft. > Anyway, some NEW thoughts on this addressing chulent. > The internal RDI concept is new, and thanks for the feedback. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 14:06:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07635; Fri, 24 Feb 95 14:06:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06492; Fri, 24 Feb 95 00:35:46 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25160; Fri, 24 Feb 1995 00:28:41 -0800 Received: from sunrise.gv.ssi1.com by Sun.COM (sun-barr.Sun.COM) id AA15512; Fri, 24 Feb 95 00:28:36 PST Received: (from gdonl@localhost) by sunrise.gv.ssi1.com (8.6.10/8.6.10) id AAA14582; Fri, 24 Feb 1995 00:28:28 -0800 Message-Id: <199502240828.AAA14582@sunrise.gv.ssi1.com> From: gdonl@gv.ssi1.com (Don Lewis) Date: Fri, 24 Feb 1995 00:28:26 -0800 In-Reply-To: "William Allen Simpson" "Re: ICMP name query messages" (Feb 23, 1:01pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "William Allen Simpson" , ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: ICMP name query messages Cc: namedroppers@rs.internic.net Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Feb 23, 1:01pm, "William Allen Simpson" wrote: } Subject: Re: ICMP name query messages } > From: Steve Deering } > - Well-known multicast addresses can have names. Cluster/pack } > addresses can have names in IPv6. How is the address->name mapping } > done for those types of addresses? Is every member of a well-known } > multicast group or a pack expected to know the name of that } > group/pack. } > } If they are well-known, you won't need to query for them, because they } are already "known". } } Moreover, it is illegal for a multicast/cluster to be the Source of IP. } Since this is a technique which learns the name of an unknown sender, } it will never be used for multicast/cluster. } } You cannot receive a multicast for an address you have not explicitly } joined. If you have already joined the group (learned its address from } its name), why would you ask the name of the group? What about network diagnostic tools that are listening promiscuously? Something else occurred to me as well. What about the IPv6 equivalent of RFC1101 network number encoding? This isn't widely implemented, but it's handy to have. --- Truck ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 14:25:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07682; Fri, 24 Feb 95 14:25:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07676; Fri, 24 Feb 95 14:25:43 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28226; Fri, 24 Feb 1995 14:18:37 -0800 Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA01050; Fri, 24 Feb 95 14:18:33 PST Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.6.10/8.6.10) with ESMTP id RAA21038; Fri, 24 Feb 1995 17:18:24 -0500 Message-Id: <199502242218.RAA21038@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Cc: namedroppers@rs.internic.net Subject: Re: (IPng) Re: ICMP name query messages In-Reply-To: Your message of "Thu, 23 Feb 1995 18:51:39 EST." From: Valdis.Kletnieks@vt.edu Date: Fri, 24 Feb 1995 17:18:24 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Thu, 23 Feb 1995 18:51:39 EST, you said: > In conclusion, I don't think it's the design of the database > representation that's at fault in the bad rep of the IN-ADDR tree, but > the lack of tools to maintain it. If the forward tree wasn't as Umm.. somebody feel free to point me at an I-D or RFC to prove me wrong ;) One problem with the IN-ADDR tree right now is that it's impossible to delegate a subnet of a class C network's IN-ADDR - for instance, I have at home 198.82.251.1 through 251.15, and I have to cooperate with the person who runs the nameserver for 251.16 through 251.254 as well. In addition, the machines on that wire will (in the semi-near future) be resident in at least 2 different domains - meaning that you have an administrative turf war as the IN-ADDR zone can only be delegated to one place... But yes, modulo these 2 problems, the design is basically Ok... Valdis Kletnieks Computer Systems Engineer Virginia Tech ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 14:38:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07719; Fri, 24 Feb 95 14:38:44 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07713; Fri, 24 Feb 95 14:38:37 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id OAA25278; Fri, 24 Feb 1995 14:31:19 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id OAA24279; Fri, 24 Feb 1995 14:31:05 -0800 Date: Fri, 24 Feb 1995 14:31:05 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199502242231.OAA24279@elrond.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: (IPng) Proposed Standard or no? X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, I originally sent my email on in-band signalling of keying material to both the IPSEC and IPv6 mailing lists, since the issues are identical to each. Right now we have the following people who think in-band signalling should be allowed : IPSEC WG -------- hugo@watson.ibm.com rgm3@is.chrysler.com nessett@eng.sun.com markson@osmosys.incog.com ashar@osmosys.incog.com IPv6 WG ------- bound@zk3.dec.com markson@osmosys.incog.com ashar@osmosys.incog.com nessett@eng.sun.com The people opposed to in-band signalling are : IPSEC WG -------- atkinson@itd.nrl.navy.mil bsimpson@morningstar.com perry@imsi.com IPv6 WG ------- atkinson@itd.nrl.navy.mil bsimpson@morningstar.com perry@imsi.com Admittedly, neither group enjoys a clear majority (in fact most people probably aren't reading the email, due to the vituperation in many of the messages from certain of the participants). However, I think there are enough people who believe that in-band signalling should at least be *allowed* that the I-Ds as they currently stand should not be advanced to Proposed Draft status. Personally, I would like to hear from some of the others on these lists to find out what they think. [The views of those listed above have been thoroughly ventilated, I think]. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 14:39:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07731; Fri, 24 Feb 95 14:39:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07720; Fri, 24 Feb 95 14:38:56 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29648; Fri, 24 Feb 1995 14:31:49 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03947; Fri, 24 Feb 95 14:31:47 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA21322; Fri, 24 Feb 95 14:28:48 -0800 Received: by xirtlu.zk3.dec.com; id AA13297; Fri, 24 Feb 1995 17:27:47 -0500 Message-Id: <9502242227.AA13297@xirtlu.zk3.dec.com> To: atkinson@itd.nrl.navy.mil Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 15:13:45 EST." <9502241513.ZM8550@bodhi> Date: Fri, 24 Feb 95 17:27:41 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I addressed to you as author of the spec in the hope that you would support it staying on IPng, and it was not a flame. Bill already knows how I feel about moving discussions around. None of my mail has been a flame this is just more defensiveness on your part cause you have been asked some valid questions your not sure how to answer at this time, regarding the draft. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 14:39:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07743; Fri, 24 Feb 95 14:39:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07732; Fri, 24 Feb 95 14:39:18 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29686; Fri, 24 Feb 1995 14:32:12 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03980; Fri, 24 Feb 95 14:31:52 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA21039; Fri, 24 Feb 95 14:25:11 -0800 Received: by xirtlu.zk3.dec.com; id AA13226; Fri, 24 Feb 1995 17:24:10 -0500 Message-Id: <9502242224.AA13226@xirtlu.zk3.dec.com> To: atkinson@itd.nrl.navy.mil Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 15:11:42 EST." <9502241511.ZM8545@bodhi> Date: Fri, 24 Feb 95 17:24:04 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, > Your statement that "Digital has test and found it to be >costly" is directly refuted by other folks who are employed >by Digital and have been in regular contact with me for >over a year now. I do not believe you. We gave you the figures for MD5 authentication at the Seattle IETF implementors meeting. Your wrong and whoever in Digital told you this does not have a clue or would know better. I will search this person out so I suggest you let them know that I am looking for them to clear this up. You have now resigned yourself to character assasination because you cannot defend yourself technically and or have a clue what your own specification would cost to implement. Cost is relative. If it cost 500K then most normal return on investment should be 5 million as one example. There is also maintenance and having experts in an area et al. By this mail I hope you know that I will read and study your mail more than anyother and you should also realize if that Digital person did not know what we have done you have opened yourself up to slander of my credibility. Fortuneately for you I don't care about that kind of stuff. But I never forget a public attack such as the one you have just made. Pretty dumb Ran. > I do believe Perry and other who have been implementing. >Perry has code. I have code. Phil Karn has code for a similar >security mechanism (different bit formats, but similar) in KA9Q. Well then why did you not want to do interoperability testing when we asked at the last IETF meeting? Or respond to the mail that went out. We could have done some testing of IPv6 security with you. Which should have also tested other parts of the protocol? > There is NO "MUST use security" there is a "MUST implement and support >security". This is consistent with direction to me from the IESG. >That issue must be resolved with them directly as I am following >their specific direction on this point. No one is arguing this anymore. > Manual key distribution is necessary to have even in the presence >of a key management protocol, making it mandatory regardless. We >can't mandate a key mgmt protocol that isn't yet a Proposed Standard >so we say "implementations SHOULD" implement it when it becomes >Proposed Standard. > More comments will come when I have more time. Just respond to my formal response to your drafts. You will get more input trust me. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 14:43:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07755; Fri, 24 Feb 95 14:43:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07749; Fri, 24 Feb 95 14:42:48 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00138; Fri, 24 Feb 1995 14:35:41 -0800 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA04901; Fri, 24 Feb 95 14:35:40 PST Subject: (IPng) Comments on Palo Alto meeting notes To: IPng Mailing list Date: Fri, 24 Feb 1995 17:36:18 -0500 (EST) From: Dan McDonald Cc: Dan McDonald , atkinson@sundance.itd.nrl.navy.mil X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9502242236.aa00714@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM These comments correspond roughly to the order of the notes taken. If there is no comment about a piece of cited text, we pretty much agree with it. =====================(Cut up to and including here.)====================== > Core Documents > -------------- > The 'last call' on all of them should be issued before the Danvers > IETF in April. > The following documents are considered to be part of the 'core' set > as well but will be submitted as Informational or Experimental > RFCs rather than Proposed Standards. > Security API ? Okay, I will have revisions out on this RSN. See later for what kind of revisions I'll be doing. > IPng Address Architecture > ------------------------- > IANA will be asked to either obtain a new 24-bit IEEE address prefix > or request the donation of a multicast block currently associated > with some company's unicast block for the use of 'well known' IPv6 > multicast addresses. The mapping between the IPv6 multicast address > and the ethernet address will be based on the low-order 24 bits rather > than the current practice of 23 bits. IWBNI it could be 32-bits, because of the obvious load-store win on 32-bit machines, if IEEE thinks it's okay. > IPv6 Base Specification > ----------------------- > Minimum MTU/Reassembly sizes: > > Prior to this meeting, both the minimum MTU and reassembly sizes were > 1500 (or 1492) bytes. Several compelling points came up during this > part of the meeting that lead the group to lower both back values > down to 576 bytes: We EMPHATICALLY agree with this decision. > ICMPv6: > ------- > - codes 0 and 1 need modification > - use of the code 7 is to be resolved between the authors. How are these to be changed or resolved? > Some feel that the transmission of an 'administratively prohibited' > error message back to the originating host presents a compromise > in security. If there is some other document either prohibits this > or makes it a configurable option, this document should reiterate > that recommendation. There is a possibility that such messages might be used as a covert channel by a bad guy. (I'm no expert on covert channels, but the thought occured to me.) With that in mind, some additional words might be nice. Such words might include: If necessary to conform to the local system security policy, systems receiving an ICMP "Administratively Prohibited" message MAY ignor that message. > DNS (AAAA records): > ------------------- The only comment I have about this is that I'd probably implement this sort of feature outside my kernel. > Security API: > ------------- I'm glad to see people want this. > References to BSD-specific features (ie: SIGURG) should be removed > from the document. Will do. I always had that marked as controversial, so I have no qualms about removing it. I'll probably take the suggestions of many that using the exception file descriptor bit vectore in select() is a better way of indicating security problems! > A general question came up about ICMP and security: if there is a goal > to make all ICMP messages secure, it becomes problematic to take a > node "out of the box" and have it interoperate right away -- generally, > some manual configuration needs to occur in order for the node to be > capable of decrypting the ICMP messages it receives. I was always under the impression that the very first time a machine is plugged into the net, two things should be typed: 1. A name (although this only works with dynamic DNS updating...) 2. A security key I can't remember who said those two things originally (Bill S. comes to mind, but I don't want to misquote him, or anyone else), but I agree with those two things. > The mailing list last call on this document should be issued before > the Danvers IETF. Will do. > Address Configuration: > ---------------------- > The host behavior in the passive case is as follows: > - when the entry times out (the router is down and stops advertising; > the prefix is no longer advertised but not explicitly dropped > either), the host accepts packets addressed to the old address. > The old address gets lower priority than the link-local for source > addresses. Existing open connections (ie: TCP) would continue to > use the old address; new incoming connections get the link-local > address instead. I'd like to see some concrete rules for address lifetimes. It is not easy for me to cruft in support for such a concept, therefore I'd like a clear understanding of what they entail before I re-write my in6_ifaddr structures. > Neighbor Discovery Format: > Neighbor Discovery Processing: > ------------------------------ Ran has already mentioned our concerns about why discovery should be retained. I'm doing my damndest to implement discovery in such a way that I don't have to hack every device driver with a 'case AF_INET6:' fragment of code. That's the beauty of a properly designed and implemented system discovery mechanism, which I think we can still achieve with Bill's stuff. =====================(Cut up to and including here.)====================== Well, I guess that's it. Dan & Ran {danmcd,atkinson}@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 14:48:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07776; Fri, 24 Feb 95 14:48:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07770; Fri, 24 Feb 95 14:48:52 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00855; Fri, 24 Feb 1995 14:41:45 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA06429; Fri, 24 Feb 95 14:41:28 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA21997; Fri, 24 Feb 95 14:36:55 -0800 Received: by xirtlu.zk3.dec.com; id AA13525; Fri, 24 Feb 1995 17:35:53 -0500 Message-Id: <9502242235.AA13525@xirtlu.zk3.dec.com> To: perry@imsi.com Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 15:49:11 EST." <9502242049.AA04270@snark.imsi.com> Date: Fri, 24 Feb 95 17:35:48 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, A core set of IPv6 drafts are going to be suggested for proposed standard. Ran has 3 of them, What I mean't on Last Call is that my issue with the sec (general architecture) draft were questions and logic regarding the statements concerning widely deployed. I would rather not issue the comments at an IESG last call when it goes out for proposed if Ran can satisfy my concerns or eliminate them on the mailing list. I need to think on your questions of performance and examples. But I am concerned about end to end commercial applications not the Internet ones right now (not that I am not concerned about the Internet ones). TCP/IP does not exist because of TELNET and DNS these are enablers and not robust applications that people bet their business on. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 14:54:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07789; Fri, 24 Feb 95 14:54:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07783; Fri, 24 Feb 95 14:54:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01377; Fri, 24 Feb 1995 14:46:58 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA07561; Fri, 24 Feb 95 14:46:52 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA22543; Fri, 24 Feb 95 14:43:14 -0800 Received: by xirtlu.zk3.dec.com; id AA13735; Fri, 24 Feb 1995 17:42:13 -0500 Message-Id: <9502242242.AA13735@xirtlu.zk3.dec.com> To: "William Allen Simpson" Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 20:18:26 GMT." <3994.bsimpson@morningstar.com> Date: Fri, 24 Feb 95 17:42:07 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Jim, you are way out of line here. Ran did not take anything from IPv6 >to IPv4. I did. Many months ago. I don't agree and just responded why I sent the mail to Ran because I know you had made up your mind. >One of the IPv4 folks came complaining back to IPv6. There just wasn't >enough support for SKIP in IPv4. He can see that IPv6 is where the >action is. Fine. This has nothing to do with the issue at hand. >And _I_ was the one asking us to stay on one mailing list. Particularly, >not the IPng list, where people reply, but it won't show up on the other >list because of the reply-to field. I knew that and saw no point in debating this with you like I alluded to in my last mail. >If you are not interested in IP Security enough to at least join the >mailing list, let alone read the archives, then I don't see where you >think you have standing to criticize. Its the IPng group that is taking this to proposed standard. Its this group where the discussion should be. Once its in proposed standard then I will have to read ipsec if I still track it. I am focusing on IPv6 not IPv4 thats all. And Ran's draft is one of the drafts. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 15:02:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07818; Fri, 24 Feb 95 15:02:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07812; Fri, 24 Feb 95 15:01:58 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02212; Fri, 24 Feb 1995 14:54:51 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA09313; Fri, 24 Feb 95 14:54:51 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA23291; Fri, 24 Feb 95 14:52:46 -0800 Received: by xirtlu.zk3.dec.com; id AA13924; Fri, 24 Feb 1995 17:51:46 -0500 Message-Id: <9502242251.AA13924@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) SKIPping out In-Reply-To: Your message of "Fri, 24 Feb 95 20:50:13 GMT." <3995.bsimpson@morningstar.com> Date: Fri, 24 Feb 95 17:51:40 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yes Bill that was. Now you have my interest. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 15:07:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07878; Fri, 24 Feb 95 15:07:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07872; Fri, 24 Feb 95 15:07:43 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03006; Fri, 24 Feb 1995 15:00:35 -0800 Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA10735; Fri, 24 Feb 95 15:00:25 PST Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id SAA23298; Fri, 24 Feb 1995 18:00:24 -0500 Date: Fri, 24 Feb 1995 18:00:24 -0500 From: Vadim Antonov Message-Id: <199502242300.SAA23298@titan.sprintlink.net> To: avg@sprint.net, mo@uunet.uu.net Subject: (IPng) Re: dynamic addressing Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Mike O'Dell wrote: >you've certainly whetted my appetite. I'd be delighted with "tastes >great, less filling". Really. I guess that's because you like the insane papers i use to write time to time? :) >from where can I ftp the document which discusses the details of your propsal? No details for now -- only the overview paper, in ftp.sprintlink.net:/engineer/avg/draft-trap.txt or ftp.sprintlink.net:/engineer/avg/draft-trap.ps --vadim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 15:14:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07893; Fri, 24 Feb 95 15:14:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07887; Fri, 24 Feb 95 15:13:48 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03751; Fri, 24 Feb 1995 15:06:42 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA12144; Fri, 24 Feb 95 15:06:32 PST Received: from relay.imsi.com by wintermute.imsi.com id SAA04208; Fri, 24 Feb 1995 18:06:31 -0500 Received: from snark.imsi.com by relay.imsi.com id SAA13543; Fri, 24 Feb 1995 18:06:30 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA04539; Fri, 24 Feb 95 18:06:28 EST Message-Id: <9502242306.AA04539@snark.imsi.com> To: Danny.Nessett@Eng (Dan Nessett) Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: (IPng) Re: Proposed Standard or no? In-Reply-To: Your message of "Fri, 24 Feb 1995 14:31:05 PST." <199502242231.OAA24279@elrond.Eng.Sun.COM> X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 18:06:28 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan Nessett says: > I originally sent my email on in-band signalling of keying material to both > the IPSEC and IPv6 mailing lists, since the issues are identical to each. > > Right now we have the following people who think in-band signalling should be > allowed : This is the IETF. We don't vote. If we did vote, baseing it on who bothered to speak up on a mailing list wouldn't be appropriate. We certainly should not be voting on whether a particular technique causes a performance problem -- thats like voting on whether the gravitational constant has a particular value. If you have figures on this based on test implementation that support your contention, lets see them. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 15:22:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07932; Fri, 24 Feb 95 15:22:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07926; Fri, 24 Feb 95 15:22:41 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04922; Fri, 24 Feb 1995 15:15:33 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA14641; Fri, 24 Feb 95 15:15:22 PST Received: from relay.imsi.com by wintermute.imsi.com id SAA04247; Fri, 24 Feb 1995 18:14:05 -0500 Received: from snark.imsi.com by relay.imsi.com id SAA13624; Fri, 24 Feb 1995 18:14:04 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA04554; Fri, 24 Feb 95 18:14:02 EST Message-Id: <9502242314.AA04554@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 1995 14:15:39 PST." <9502242215.AA01000@miraj.> X-Reposting-Policy: redistribute only with permission Date: Fri, 24 Feb 1995 18:14:02 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ashar Aziz says: > We have serious concerns about being limited to a cached-VC-like model > with IPSP/IPv6. We anticipate this approach to be problematic on secure > servers with a large number of clients, and firewalls with a large number > of remote IP clients. Under those circumstances, SKIP would display absolutely identical properties if it was to perform well. You would end up having to cache lots of keys in the kernel -- unless you were going to do server lookups on each, with several packet exchanges, which would obviate all claims of performance advantages. Now, as for firewalls with large numbers of clients, I have actually built and operated such firewalls. They all operate with application level relays which are far heavier weight, statewise, than security associations could ever be. These firewalls function just fine. > The cached-security-session approach is even more problematic than > your typical cached VC situation because of the problem of "half-open- > connections". This is when one side crashes and loses the shared session > state. Normally, one can simply blow away half-open connections when > the side that has crashed detects them. This is not so trivial for a > security session because this has to be done securely, otherwise > denial-of-service attacks would be trivial. (Not to say that this can't > be solved, but this at least presents another complication). I don't see why its a problem at all. The TCP connections to the dead machine will vanish on their own. The security associations will eventually time out and go away. New connections from the rebooted machine will form new security associations. > Finally, as they say, the proof is in the pudding. Let's build > and deploy some of these approaches to gain operational experience. Thats an excellent suggestion, and one that I heartily approve of. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 15:33:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07994; Fri, 24 Feb 95 15:33:11 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07667; Fri, 24 Feb 95 14:25:27 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA14106; Fri, 24 Feb 1995 14:18:22 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA14088; Fri, 24 Feb 1995 14:18:18 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA15483; Fri, 24 Feb 95 14:18:17 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA01004; Fri, 24 Feb 95 14:18:14 PST Received: by ns.incog.com (8.6.10/94082501) id OAA20960; Fri, 24 Feb 1995 14:18:37 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id OAA20945; Fri, 24 Feb 1995 14:18:35 -0800 Received: from miraj. (miraj.incog.com) by osmosys.incog.com (5.x/SMI-SVR4) id AA08541; Fri, 24 Feb 1995 14:17:49 -0800 Received: by miraj. (5.x/SMI-SVR4) id AA01000; Fri, 24 Feb 1995 14:15:39 -0800 Date: Fri, 24 Feb 1995 14:15:39 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9502242215.AA01000@miraj.> To: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >I agree that key mgmt protocols should not be forced to use in-band techniques. > >I think all of us (and there have been at least 5 messages from different > >people on this list asking for in-band signalling) would like the *option* > >of using in-band signalling. Then we can let the market decide which is > >the best approach. > > 100% support on this. Let the option exist and let us who will build > IPv6 security see if the market wants it. Jim and Danny are absolutely right. Let's leave the option in. Let's not close our options on in-band key-mgmt (or any kind of key-mgmt for that matter) when the operational experience of Internet-wide key-mgmt is very limited at best. Danny is absolutely correct about the IP-over-X.25 analogy. The TCP-is-also- connection-oriented isn't an appropriate analogy because TCP runs over IP, whereas IPSP is supposed to run underneath IP, at least in what will be one of the prevalent modes (IP encapsulation in IPSP). We have serious concerns about being limited to a cached-VC-like model with IPSP/IPv6. We anticipate this approach to be problematic on secure servers with a large number of clients, and firewalls with a large number of remote IP clients. The cached-security-session approach is even more problematic than your typical cached VC situation because of the problem of "half-open- connections". This is when one side crashes and loses the shared session state. Normally, one can simply blow away half-open connections when the side that has crashed detects them. This is not so trivial for a security session because this has to be done securely, otherwise denial-of-service attacks would be trivial. (Not to say that this can't be solved, but this at least presents another complication). With the approach that we have proposed, there are no half-open connections because there are no connections to begin with. Leaving in the option to do in-band key-mgmt let's people experiment with the connection-less approach. Finally, as they say, the proof is in the pudding. Let's build and deploy some of these approaches to gain operational experience. Towards this end, we will soon be making our key-mgmt/IPSP software freely available (subject to US export regulations, of course). Stay tuned. Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 15:35:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08058; Fri, 24 Feb 95 15:35:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07796; Fri, 24 Feb 95 14:58:19 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01829; Fri, 24 Feb 1995 14:51:12 -0800 Received: from columbia.sparta.com (bugs_bunny.columbia.SPARTA.COM) by Sun.COM (sun-barr.Sun.COM) id AA08483; Fri, 24 Feb 95 14:51:09 PST Received: from marvin_martian.columbia.SPARTA.COM by columbia.sparta.com (4.1/SMI-4.1) id AA26617; Fri, 24 Feb 95 17:46:13 EST Message-Id: <9502242246.AA26617@columbia.sparta.com> To: perry@imsi.com Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, cfm@columbia.sparta.com Subject: Re: (IPng) out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 15:49:11 EST." <9502242049.AA04270@snark.imsi.com> Date: Fri, 24 Feb 95 17:47:38 -0500 From: Carl Muckenhirn Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message <9502242049.AA04270@snark.imsi.com> you wrote: Good points about context for measuring "overhead" elided > > Are we talking about encrypting every packet? We know thats > expensive. I don't think that has anything to do with Ran's > architecture -- if you are encrypting all your data, it costs a huge > amount. And yes, I've got code that does that sort of thing right now, > and it is bloody expensive. Its unavoidable, however. The solution is > to use fast ciphers or hardware cipher implementations. Just switching > from DES to RC4 gives you a huge boost. > I'd like to stop us from beating ourselves too hard about the "costs of encryption." While in the context of communications protocol execution "costs" encryption is expensive, but in the context of applications using these services we're (crypto) not really a problem. At the September ARPA Principal Investigators meeting, Van Jacobson pretty eloquently put this when he compared the "costs" of encryption with the "costs" of running a multi-media multicasting system. If encryption consumes 10% (real high) of the available processor, that's minor when compared to the 60, 70, or even 80% of the processor needed to support VAT at 30 fps. Yes, security should be "cheap", but there is value provided by the use of security so lets not worry too much about it. > However, this has nothing to do with performance hits from key > management. To my knowledge, as it stands you are probably using > manual keying. > > > If Danny's idea can or may give us a performance gain then why not > > permit it as an option. > > If someone thinkgs rubbing chicken entrails on our chests will give us > a performance gain, shall we specify that in an RFC as well? > I think that we should, and since Danvers is real close to the 91st day of 1995, I think that an ID or RFC on poultry enchanced security protocols would be quite appropriate. > I fail to understand what sort of performance gain we are to expect > here. We aren't even being given a model of the sort of traffic we are > discussing. If we are talking about a Telnet session Danny's notion > can't give us any observable performance gain. If we are talking about > a random hit at a DNS server it might give us a gain -- but DNS is not > being protected with this mechanism. Were we talking about some sort > of file service arrangement it certainly wouldn't give us a gain. > > Could someone PLEASE tell me how gaining a few milliseconds in startup > of relationships between hosts that last hours is going to be > worthwhile? Remember, of course, that we are talking of "worst case" > situations -- average case you aren't going to gain anything. > Well we wouldn't want to get the relationship off on the wrong foot, we all know how costly that can be in the long run. And we wouldn't wan to waste those precious milliseconds when we can replace them with "IVs" which have bloated to 2, or 3 times their normal length. (And need to be handled as exceptions in the code, I expect). > Perry carl. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 15:35:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08065; Fri, 24 Feb 95 15:35:39 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07761; Fri, 24 Feb 95 14:48:22 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA14720; Fri, 24 Feb 1995 14:41:19 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA14702; Fri, 24 Feb 1995 14:41:16 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA16829; Fri, 24 Feb 95 14:41:15 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA06360; Fri, 24 Feb 95 14:41:10 PST Received: by ns.incog.com (8.6.10/94082501) id OAA21648; Fri, 24 Feb 1995 14:41:33 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id OAA21339; Fri, 24 Feb 1995 14:31:20 -0800 Received: from miraj. (miraj.incog.com) by osmosys.incog.com (5.x/SMI-SVR4) id AA08784; Fri, 24 Feb 1995 14:30:40 -0800 Received: by miraj. (5.x/SMI-SVR4) id AA01003; Fri, 24 Feb 1995 14:28:29 -0800 Date: Fri, 24 Feb 1995 14:28:29 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9502242228.AA01003@miraj.> To: bound@zk3.dec.com, perry@imsi.com Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From ipsec-request@ans.net Fri Feb 24 14:12 PST 1995 > bound@zk3.dec.com says: > > I highly suggest to the chairs to get with Ran offline and fix this if > > he continues to pursue this course. He should have to justify why > > Dannys claims will not benefit a draft under this groups charter as of > > right now just like the rest of the drafts must do this. This is just > > the wrong thing to do. > > "Danny's" suggestion is in fact Ashar Aziz's suggestion, as you would > know if you were on the ipsec list which you feel you don't have to be > on. However, Ashar isn't claiming it has anything to do with > performance per se -- he wants it to make his life easier in promoting > a particular key management system called SKIP, which was designed > with in-band in mind. Perry, I have raised performance issues in the past (in fact you and I had that exchange). There are situations where you dont want to have to go through the overhead of establishing a session when all you want to do is send a few IP packets (e.g net mgmt, ICMP etc.). You suggested one could do this with cached security-connections, whereas I responded that this doesn't work well for servers, net managers or routers that may need to reach a very large destination set, because all of these connections would have to be re-established in case of crash/reboot scenarios. Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 15:35:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08077; Fri, 24 Feb 95 15:35:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07824; Fri, 24 Feb 95 15:02:52 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02325; Fri, 24 Feb 1995 14:55:44 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA09492; Fri, 24 Feb 95 14:55:41 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA23104; Fri, 24 Feb 95 14:50:16 -0800 Received: by xirtlu.zk3.dec.com; id AA13872; Fri, 24 Feb 1995 17:49:15 -0500 Message-Id: <9502242249.AA13872@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof2.Eng.Sun.COM Subject: Re: (IPng) apology and comment on performance impacts In-Reply-To: Your message of "Fri, 24 Feb 95 16:01:19 EST." <9502241601.ZM8618@bodhi> Date: Fri, 24 Feb 95 17:49:08 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, OK and I could have been a lot clearer and nicer asking you to help prevent the discussion going off the ipng list. I apologize for that it was too intense. This security is real important. Its a MUST and I agree it should be now. I am trying to just force a serious drilling of what I thought to be an issue of in vs out band because I am uncomfortable with no key mgmt to use other than manual, and have this appear in the market some day. The drilling is something that is not fun and I don't like when it is done to me either and it can often not be done nicely in heated exchanges such as ours. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 15:40:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08105; Fri, 24 Feb 95 15:40:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07118; Fri, 24 Feb 95 10:47:09 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03643; Fri, 24 Feb 1995 10:40:01 -0800 Received: from rip.psg.com by Sun.COM (sun-barr.Sun.COM) id AA13595; Fri, 24 Feb 95 10:39:58 PST Received: by rip.psg.com (Smail3.1.29.1 #3) id m0ri4vZ-00030RC; Fri, 24 Feb 95 10:39 PST Message-Id: Date: Fri, 24 Feb 95 10:39 PST From: randy@psg.com (Randy Bush) To: "William Allen Simpson" Cc: ipng@sunroof.Eng.Sun.COM, namedroppers@rs.internic.net Subject: (IPng) Re: ICMP name query messages References: <3948.bsimpson@morningstar.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The terminology in every other RFC is a "Domain Name", which is the > title I used. No sense of adventure. :-) > When other names are known at the same host or router, from a > different interface or address, these names MAY be listed, too. Yikes! I asked for the canonic name of the interface 0.1.2.3[.4..F]. To give me names which are not of that interface would seem almost malicious. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 15:49:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08135; Fri, 24 Feb 95 15:49:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08129; Fri, 24 Feb 95 15:49:08 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07942; Fri, 24 Feb 1995 15:42:02 -0800 Received: from columbia.sparta.com (bugs_bunny.columbia.SPARTA.COM) by Sun.COM (sun-barr.Sun.COM) id AA21196; Fri, 24 Feb 95 15:41:57 PST Received: from marvin_martian.columbia.SPARTA.COM by columbia.sparta.com (4.1/SMI-4.1) id AA26772; Fri, 24 Feb 95 18:35:54 EST Message-Id: <9502242335.AA26772@columbia.sparta.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: bound@zk3.dec.com, perry@imsi.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, cfm@columbia.sparta.com Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Fri, 24 Feb 95 14:28:29 PST." <9502242228.AA01003@miraj.> Date: Fri, 24 Feb 95 18:37:19 -0500 From: Carl Muckenhirn Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message <9502242228.AA01003@miraj.> you wrote: > > > From ipsec-request@ans.net Fri Feb 24 14:12 PST 1995 > > bound@zk3.dec.com says: > > > I highly suggest to the chairs to get with Ran offline and fix this if > > > he continues to pursue this course. He should have to justify why > > > Dannys claims will not benefit a draft under this groups charter as of > > > right now just like the rest of the drafts must do this. This is just > > > the wrong thing to do. > > > > "Danny's" suggestion is in fact Ashar Aziz's suggestion, as you would > > know if you were on the ipsec list which you feel you don't have to be > > on. However, Ashar isn't claiming it has anything to do with > > performance per se -- he wants it to make his life easier in promoting > > a particular key management system called SKIP, which was designed > > with in-band in mind. > > Perry, > > I have raised performance issues in the past (in fact you and I had that > exchange). There are situations where you dont want to have to go through > the overhead of establishing a session when all you want to do is send a > few IP packets (e.g net mgmt, ICMP etc.). You suggested one could do this > with cached security-connections, whereas I responded that this doesn't > work well for servers, net managers or routers that may need to reach a > very large destination set, because all of these connections would have > to be re-established in case of crash/reboot scenarios. > > Regards, > Ashar. Even with SKIP, there is some state kept around somewhere, maybe in the DNS (more messages), but it has to exist. In the case of crashes/reboot, you have to "re-establish" the context of all of those connections eventually anyways (not TCP connections per-se, but connections nevertheless). No one has said that the re-establishment was a synchronous event, just bring them back when you need them, you'll need them again in most cases. carl. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 24 20:27:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08380; Fri, 24 Feb 95 20:27:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08374; Fri, 24 Feb 95 20:27:00 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20214; Fri, 24 Feb 1995 20:19:52 -0800 Received: from cheops.anu.edu.au by Sun.COM (sun-barr.Sun.COM) id AA24039; Fri, 24 Feb 95 20:19:27 PST Message-Id: <9502250419.AA24039@Sun.COM> Received: by cheops.anu.edu.au (1.37.109.15/16.2) id AA208015960; Sat, 25 Feb 1995 15:19:20 +1100 From: Darren Reed Subject: Re: (IPng) ICMP name query messages To: ipng@sunroof.Eng.Sun.COM Date: Sat, 25 Feb 1995 15:19:20 +1100 (EDT) Cc: bound@zk3.dec.com In-Reply-To: <9502241650.AA02029@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Feb 24, 95 11:50:42 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Steve B., > > >If we're going to rely on the host to announce its own name, maybe > >it could live in an IP option. This option would always be sent with > >a TCP SYN packet (or at least by default), and could be with UDP if the > >application desired to. If it didn't arrive, the recipient could always > >send the ICMP message. If you want something (more) trustworthy, you > >do the forward lookup on either answer. > > > >I do feel compelled to point out that I'm not joking. If folks have a > >decent handle on which services are *likely* to want the caller's name -- > >and I think we do, though there are certainly no guarantees -- this > >should result in less network traffic. And it's no less reliable than > >the ICMP suggestion. It could also answer one of the objections: an > >application that wanted to claim one of a set of host names could easily > >do so; the kernel need only validate that the chosen name was in fact > >one of the legal names for that host, based on boot-time configuration. > > I like this idea a lot. Good thinking. Anyone for adding some sort of user identifier (such as returned by identd) in the SYN packet as well as `hostname' ? darren ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 25 03:57:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08499; Sat, 25 Feb 95 03:57:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08493; Sat, 25 Feb 95 03:56:51 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01596; Sat, 25 Feb 1995 03:49:45 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA23224; Sat, 25 Feb 95 03:49:44 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-07.dialip.mich.net [141.211.7.143]) by merit.edu (8.6.10/merit-2.0) with SMTP id GAA01946; Sat, 25 Feb 1995 06:49:35 -0500 Date: Sat, 25 Feb 95 11:04:07 GMT From: "William Allen Simpson" Message-Id: <3996.bsimpson@morningstar.com> To: "Michael A. Patton" Cc: ipng@sunroof.Eng.Sun.COM, namedroppers@rs.internic.net Subject: (IPng) ICMP name persistence (of vision) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: "Michael A. Patton" > Putting on my network operator's hat for a minute, ... > I frequently need to do this translation hours, > days, or even months :-) after the fact. I realize that the longer > it's been since a log was written, the less accurate the answer will > be, but I can STILL GET AN ANSWER. If the only way to get an answer > is from the users PC, I will usually be unable to get any answer at a > random later time. > This is a truly amazing feat! Look at my received line above, which contains my current address. Do a reverse lookup on it. So you still get Bill.Simpson? Will you in "days, or even months"? I access the net exclusively through a dialup connection, as do 100,000 others here at MichNet. How exactly do you "still get an answer", when my address has changed about 7 times in the past 24 hours? And doesn't exist at all when I am not dialed in? (I was actually connected about 90 minutes in the past 24 hours.) Have you actually read my draft? (This is not entirely aimed at you, as we have had several people with the same bogus "I control my site through good tools and everybody else should" response.) > Also, it has been my experience that even networking organizations > can't get all the nodes to properly know their own names (that > information is [sometimes] available in IPv4 via SNMP, I find it wrong > as often as right), and would place very little expectation that end > users could do it. > In IPv4, this is in conjunction with DNS Dynamic Update. The name->address has been deliberately changed by the host, which therefore knows its name. Networking organizations are not involved. In IPv6, there are no stable addresses. Everything is auto-configured. DNS is dynamically updated by the host, or by DHCPng. The name is assigned on the fly. > But I think it also important that there be a persistent repository to > answer queries when the subject host is not available (either because > it's been shut off for the evening [which is when I usually get around > to noticing logs that I want to research] or administratively > firewalled as others have mentioned). I'm not certain that the DNS is > the right place for this, but it _is_ the most widely deployed > persistent distributed database around. How do you propose to "manage" address->name? What kind of tools? A transaction database with rollback and history records? And how are you distributing the authority to the 100,000 users to simultaneously and cooperatively update the IN-ADDR tree? Remembering that they are mostly college students and itinerant hackers? And that the nature of the IN-ADDR tree is such that even _you_ might not have authority to update your own sub-tree, given CIDR. > Now having said that, I think that having this facility is sorely > needed and fills an important gap. I therefore strongly applaud its > addition to the IPv6 repertoire. > Thank you. Don't forget IPv4. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 25 06:07:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08535; Sat, 25 Feb 95 06:07:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08529; Sat, 25 Feb 95 06:07:03 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07806; Sat, 25 Feb 1995 05:59:56 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA29509; Sat, 25 Feb 95 05:59:56 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA11155; Sat, 25 Feb 95 05:59:13 -0800 Received: by xirtlu.zk3.dec.com; id AA22949; Sat, 25 Feb 1995 08:58:12 -0500 Message-Id: <9502251358.AA22949@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: Dan McDonald , atkinson@sundance.itd.nrl.navy.mil Subject: Re: (IPng) Comments on Palo Alto meeting notes In-Reply-To: Your message of "Fri, 24 Feb 95 17:36:18 EST." <9502242236.aa00714@sundance.itd.nrl.navy.mil> Date: Sat, 25 Feb 95 08:58:06 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan/Ran, >> Address Configuration: >> ---------------------- >> The host behavior in the passive case is as follows: >> - when the entry times out (the router is down and stops advertising; >> the prefix is no longer advertised but not explicitly dropped >> either), the host accepts packets addressed to the old address. >> The old address gets lower priority than the link-local for source >> addresses. Existing open connections (ie: TCP) would continue to >> use the old address; new incoming connections get the link-local >> address instead. >I'd like to see some concrete rules for address lifetimes. It is not easy >for me to cruft in support for such a concept, therefore I'd like a clear >understanding of what they entail before I re-write my in6_ifaddr I agree completely with the need. I can't even begin either as the draft stands presently to comprehend the variations between time-out and deprecated and when I just stop connections either or let them continue. Also when the draft comes out I may object to the statements regarding what continues or does not continue unless its a SHOULD or MAY. But I think we need to see the next revision at this time. Also some input as I think your building a public domain version of IPv6 and I would like ours to be if we can do that too (being a vendor it is unknown to me at this time). I went down this path too as far as rewrite of IPv4 if_ifaddr too. But I think there are enough open slots in a BSD 4.4 type implementation base (which OSF is) to absorb addr conf in *ifnet so we don't have to do "re-write" any of the *ifnet structures. You can also provide function pointers in an IPv6 ifaddr structure which can be executed to process the IPv6 addr conf routines. Just sending this as its pretty well defined in BSD 4.4 and clean. And I think we can keep it this way. >> Neighbor Discovery Format: >> Neighbor Discovery Processing: >> ------------------------------ >Ran has already mentioned our concerns about why discovery should be >retained. I'm doing my damndest to implement discovery in such a way that I >don't have to hack every device driver with a 'case AF_INET6:' fragment of >code. That's the beauty of a properly designed and implemented system >discovery mechanism, which I think we can still achieve with Bill's stuff. So you think it should go near datalink (e.g. ether_output) and exist where ARP does today in the BSD 4.4 kernel? But point-point or ATM or others are different different points of entry into the datalink. These entry points have different processing requirements than a broadcast mechanism. At least in BSD 4.4. Performance I think should be the number 1 requirement. How system discovery would work with non-broadcast datalink is unclear to me anyway at this time. Which may be the issue for the WG? And an architetural issue for all implementors? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 25 06:34:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08547; Sat, 25 Feb 95 06:34:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08541; Sat, 25 Feb 95 06:34:20 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08496; Sat, 25 Feb 1995 06:27:12 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA01350; Sat, 25 Feb 95 06:27:10 PST Received: by rodan.UU.NET id QQyept27851; Sat, 25 Feb 1995 09:27:09 -0500 Message-Id: To: ipng@sunroof.Eng.Sun.COM Cc: jis@mit.edu Subject: (IPng) Key management Date: Sat, 25 Feb 1995 09:27:08 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM One of the things discussed at length in the IESG discussions of whether to mandate the security machinery was that key management was *explicitly* excluded from the BASE DOCUMENTS. This was because that's where all the legal grief lies (in a number of ways). Note that this doesn't say we don't need automated key management - clearly we do - but holding up the *transport* mechanism for the *policy* machinery was deemed a Bad Idea. Yes, this will probably raise the noise floor slightly, but we hoped it would avert more paralizing entanglements. Note - this is my strong recollection - other IESG folks, especially Jeff Schiller, PLEASE correct me if I remembered this all wrong. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 25 08:12:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08561; Sat, 25 Feb 95 08:12:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08555; Sat, 25 Feb 95 08:12:32 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10504; Sat, 25 Feb 1995 08:05:24 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA05748; Sat, 25 Feb 95 08:05:25 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA16056; Sat, 25 Feb 95 08:00:45 -0800 Received: by xirtlu.zk3.dec.com; id AA23827; Sat, 25 Feb 1995 10:59:40 -0500 Message-Id: <9502251559.AA23827@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: jis@mit.edu, bound@zk3.dec.com Subject: Re: (IPng) Key management In-Reply-To: Your message of "Sat, 25 Feb 95 09:27:08 EST." Date: Sat, 25 Feb 95 10:59:34 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Mike, >One of the things discussed at length in the IESG discussions of >whether to mandate the security machinery was that key management was >*explicitly* excluded from the BASE DOCUMENTS. This was because >that's where all the legal grief lies (in a number of ways). >Note that this doesn't say we don't need automated key management - >clearly we do - but holding up the *transport* mechanism for the >*policy* machinery was deemed a Bad Idea. Yes, this will probably >raise the noise floor slightly, but we hoped it would avert more >paralizing entanglements. I understand I "think" the motivation now. But I "think" to get wide deployment in the market the key management protocol (and maybe serveral) need to be implemented (according to IETF rules) and reach at least draft standard before I think it can really be turned on. We can clearly begin testing in a multivendor environment the IPv6 Security with manual key management, but I think customers will want a key management protocol. I will note that during the discussion and flame fest of yesterday I thought I heard folks say they had implementations of IPv6 Security but when I asked at IETF XEROX meeting for folks to do IPv6 interoperability testing at Danvers possibly, there were no takers. In industry if a group or person convinces the business that they need to put an enabler in a product that may not get used right away, because it requires additional future functionality (which is a very hard sell to any engineering entity I have worked in for the last 20 years) it has to be completely justified. I think the IETF may have done that with the logic of 'we need network layer security for the Internet' (not saying I am convinced yet the security drafts for IPv6 are ready for proposed standard). Now if that enabler is not used, and more important does not make a profit as an integral part of that product, funding is pulled for the work at some point in time and the work is canceled. Depending on the cost and time it took up in engineering and past history of those that proposed this strategy they may also get fired. I think without key management we have not solved the whole problem the IESG and the IAB Workshop was trying to solve, because we cannot widely deploy IPv6 security without a set of key management protocols, or at least one. So we are in the situation above where we want the enabler turned on at least for IPv6 implementations. Now I think the IESG needs to take a serious work task on to make sure that the IETF fast track and get done a key management protocol, which can pick up speed so that it can become a draft standard at the same time that IPv6 network layer Security does. This is a tall order but I hope the IESG thought of this when they decided to make implementing IPv6 security a MUST as an integral part the Internets next generation protocol (IPv6)? If we can't get one of our bright people to invent one for a standard that does have legal freedom, that should tell the IETF management/leaders something regarding the decisiion to require a MUST implement IPv6 network layer security. If this does not happen the implementor community and vendors have put time into putting this in our prototypes and eventually pre-product development with no hope of return on investment. Most of us only have so many resources to put into building code for IETF pre-standards work. This means we may not do something else in the work such as SNMP or other parts of IPv6. Now if we put it in the work and no key management protocol emerges as a draft standard with IPv6 security, then I think the IESG and whoever else was a key decision maker for this has failed. Then I think its fair for them to be fired from the IESG via the community. I hope what the new POISE WG (I asssume POISE will make the IETF ranks more open to selection and recall in the IETF community) will develop is a process to get rid of any good ole boy/girl network that MAY (I don't know if there is or not) exist presently in the IETF, so they can be fired. Also if one is proposing something of this magnitude and they have made a mistake I personally don't want them any where near the IETF leadership again for a long time. This will be too big a mistake to have made. So lets have some accountability for this decision is the bottom line at the IESG level. Instead of putting ones career on the line in Industry they are putting their credibility on the line to continue to be a person we can trust the judgement of in the IETF mangement/leadership ranks. I also think this applies to any architects in the IETF we trust when supporting specific technical strategies etc... Everyone should have something to loose here not just the implementors and vendors. And if no one has figured it out yet, I am going to watch this one very carefully to see what happens and keep a very accurate history log. Plus as one of the IPv6 implementors we will do everything possible to implement security in IPv6 as it progresses, to support the IETF leadership and community. Though at this point the key management looks like an engineering unknown to implement, so we need to look at that more closely as to what it takes for a prototype, regarding it as time sink in IPv6 code base. p.s. Implementors of IPv4 security please don't send me pointers to implementation design thoughts for IPv6 security key management unless you have ported your implementation to IPv6 and using the IPv6 BSD API draft for accessing network connections and AAAA records via IPv6 API suggested changes per DNS. We need to be clear on IPv6 vs IPv4 IMHO. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 25 08:46:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08573; Sat, 25 Feb 95 08:46:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08567; Sat, 25 Feb 95 08:46:23 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11136; Sat, 25 Feb 1995 08:39:16 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA07199; Sat, 25 Feb 95 08:35:26 PST Received: by rodan.UU.NET id QQyeqc07832; Sat, 25 Feb 1995 11:35:25 -0500 Message-Id: To: ipng@sunroof.Eng.Sun.COM Cc: jis@mit.edu, bound@zk3.dec.com, mo@uunet.uu.net Subject: Re: (IPng) Key management In-Reply-To: Your message of "Sat, 25 Feb 1995 10:59:34 EST." <9502251559.AA23827@xirtlu.zk3.dec.com> Date: Sat, 25 Feb 1995 11:35:25 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, I don't think I disagree with your overall assessment of the strategic situation for large values of T (although I do reserve the right to change my mind after I cogitate a bit). But to cut to the chase, exogenous key management (EKM) is a perfectly adquate mechanism to have in place for initial deployment and to make initial use of the facilities FOR SOME (NOT ALL) PURPOSES. As a vendor of IP crypto hardware, it continually amazes us the number of people who INSIST upon EKM, even when you show them all the cleverness you have mustered about doing it otherwise. N.B.: I do not assert that EKM is adequate to solve all the world's security problems - I'm not *that* dumb (although you can find those who might argue that point!) but it *can* solve a number of very real and urgently pressing problems right now. I believe EKM is perfectly adequate to ensure and demonstrate the interoperability of the basic protocol mechanism and implementations, even in the presence of some inconvenience (although inconvenience is in the eye of the beholder). Again, I do not for an instant dispute the importance of getting rapid closure on other, more automated key-management mechanisms and getting them implemented and widely depolyed. But I strongly refute the notion that the IPv6SEC machinery is of no value without it - quite the contrary - it can be of IMMENSE value almost immediately, but admittedly, maybe not to everyone. Making *everyone* happy probably requires more than just automated key management (big grin). Cheers, -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 25 09:02:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08594; Sat, 25 Feb 95 09:02:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08588; Sat, 25 Feb 95 09:02:09 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11498; Sat, 25 Feb 1995 08:55:02 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA08228; Sat, 25 Feb 95 08:55:02 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA18361; Sat, 25 Feb 95 08:52:01 -0800 Received: by xirtlu.zk3.dec.com; id AA24130; Sat, 25 Feb 1995 11:50:59 -0500 Message-Id: <9502251650.AA24130@xirtlu.zk3.dec.com> To: "Mike O'Dell" Cc: ipng@sunroof.Eng.Sun.COM, jis@mit.edu Subject: Re: (IPng) Key management In-Reply-To: Your message of "Sat, 25 Feb 95 11:35:25 EST." Date: Sat, 25 Feb 95 11:50:53 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Mike, Can you say more about EKM. And define it for those of us who do not know or are not familiar with that term. Should EKM be stated in the IPv6 sec specs? Right now manual key is described only. p.s. I realize that this work needs to go to IPsec and we will have someone who is there and an implementor of IPv6. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 25 09:13:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08610; Sat, 25 Feb 95 09:13:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08604; Sat, 25 Feb 95 09:13:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11902; Sat, 25 Feb 1995 09:06:18 -0800 Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA08710; Sat, 25 Feb 95 09:06:19 PST Message-Id: <9502251706.AA08710@Sun.COM> From: smb@research.att.com Received: by gryphon; Sat Feb 25 12:05:14 EST 1995 To: ipng@sunroof.Eng.Sun.COM Cc: "Mike O'Dell" Subject: Re: (IPng) Key management Date: Sat, 25 Feb 95 12:05:12 EST Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Mike, Can you say more about EKM. And define it for those of us who do not know or are not familiar with that term. Should EKM be stated in the IPv6 sec specs? Right now manual key is described only. p.s. I realize that this work needs to go to IPsec and we will have someone who is there and an implementor of IPv6. I'm pretty sure EKM messages are transmitted by Sneakernet... At least, that's the way UUNET's crypto gear worked at first. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 25 09:33:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08622; Sat, 25 Feb 95 09:33:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08616; Sat, 25 Feb 95 09:33:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12452; Sat, 25 Feb 1995 09:26:31 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA09849; Sat, 25 Feb 95 09:26:32 PST Received: by rodan.UU.NET id QQyeqf11134; Sat, 25 Feb 1995 12:22:42 -0500 Message-Id: To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, jis@mit.edu, mo@uunet.uu.net Subject: Re: (IPng) Key management In-Reply-To: Your message of "Sat, 25 Feb 1995 11:50:53 EST." <9502251650.AA24130@xirtlu.zk3.dec.com> Date: Sat, 25 Feb 1995 12:22:42 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM EKM - exogenous key management the two endpoints exploit exogenous knowledge to "know" the keys corresonding to the security associations exogenous knowledge comes from "outside the system" as opposed to endogenous knowledge which is generated "inside the system" this hinges on the current definition of "the system", and here, I mean the IPv6 protocol encapusulation machinery. this is a matter of drawing very judicious circles, carefully isolating what we are defining from what we are not defing but still assuming the existance of. For the purpose of the base documents, I'm talking about drawing the circle very carefully so it slices between the actual protocol encapuslation machinery and the stuff that populates the security association lookups for the corresponding keying material, etc. How the translations are made from security association to key, and how the information gets exchanged to make that translation possible is deemed to be out-of-scope for the purposes of the base documents. manual key distribution would be one example of exogenous knowledge (ie, the system knows because someone carried the information "by hand") another example would be using a private software-based Key Distribution Center (like Kerberos, for example). the simplcity of EKM, at least for the purposes of dealing with IPv6SEC in the BASE DOCUMENTS, is that we postulate the existance of a mechanism which transfers the knowledge of key material for the security associations WITHOUT specifying how that mechanism works. clearly this means that in the implementation, some form of interface must exist between key management machinery and the IPv6SEC protocol machinery, but that isn't a surprising result and nothing new. what is clear from talking with lots of people about their security policies and such is that there must be great flexibility, allowing possibly multiple mechanisms to operate in real implementations. For example, one might require use of a Kerberos KDC to provide keying within a corporate network environment, but also be required to use a public key system for going to some commercial goods seller outside the firewalls. It is very important we keep these from becoming too intertwined. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 25 12:06:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08657; Sat, 25 Feb 95 12:06:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08651; Sat, 25 Feb 95 12:06:06 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16528; Sat, 25 Feb 1995 11:58:57 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA17353; Sat, 25 Feb 95 11:58:58 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24808; Sun, 26 Feb 1995 06:58:48 +1100 (from kre@munnari.OZ.AU) To: "William Allen Simpson" Cc: ipng@sunroof.Eng.Sun.COM, namedroppers@rs.internic.net Subject: (IPng) Re: ICMP name persistence (of vision) In-Reply-To: Your message of "Sat, 25 Feb 1995 11:04:07 GMT." <3996.bsimpson@morningstar.com> Date: Sun, 26 Feb 1995 06:58:34 +1100 Message-Id: <5598.793742314@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Sat, 25 Feb 95 11:04:07 GMT From: "William Allen Simpson" Message-ID: <3996.bsimpson@morningstar.com> This is a truly amazing feat! Look at my received line above, which contains my current address. Do a reverse lookup on it. So you still get Bill.Simpson? Will you in "days, or even months"? No, but nor did merit when their mailer looked it up when you connected to them, they obtained (from the headers) .. pm002-07.dialip.mich.net When I do a lookup now, I get the same thing. If I do a lookup tomorrow, and probably next week, I'll still get the same thing. That is the name associated with that address (141.211.7.143) as established by the owner of the address. The Bill.Simpson.DialUp.Mich.Net version is just what your host decided to call itself, and what's more, has no A record (or doesn't at the minute, I'd guess it probably didn't when you were connected either). Getting that string back in response to a name lookup is an example of how useless it is - all those people (basically everyone these days for most purposes) who verify the name by a name->A lookup will trash the name as invalid, and the request/reply (plus subsequent DNS queries) will be wasted. Note that if we're going to be receiving user configured useless nonsense like this back, then absolutely everyone will do the verification trick, even if they're not planning on pretending the answer has any uses at all for any kind of authentication purposes. One might hope that with dynamic DNS updates and IPv6 the name->A record might in fact be there when queried, it might. For dialup connections it also probably might not - DNS propogation delays are likely to mean that not all servers have been updated by the time that your (brief) connection to send mail is done. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 04:02:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09026; Sun, 26 Feb 95 04:02:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09020; Sun, 26 Feb 95 04:02:18 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11889; Sun, 26 Feb 1995 03:55:09 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA02379; Sun, 26 Feb 95 03:55:09 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-07.dialip.mich.net [141.211.7.143]) by merit.edu (8.6.10/merit-2.0) with SMTP id GAA18156 for ; Sun, 26 Feb 1995 06:55:06 -0500 Date: Sun, 26 Feb 95 11:12:28 GMT From: "William Allen Simpson" Message-Id: <4013.bsimpson@morningstar.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) SKIPping out Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I've learned that I made a practical error in my analysis. > SKIP speed is in computing ephemeral keys. It does this by carrying > the current key in every packet, encrypted in another "long-lived" key. > > Because it carries the keys in every header, the headers are MUCH > bigger, eating bandwidth. > > OK, understand now? Less CPU, more bandwidth. Bandwidth is the problem > in most networks, so everything gets slower, not faster! > The PD DES has a big initialization time, to calculate some big tables for each key. So, if you change the ephemeral key a lot, the SKIP reason for being, you have to re-initialize DES a lot. So, for SKIP with DES, _more_ CPU, _more_ bandwidth. Feel better? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 06:04:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09044; Sun, 26 Feb 95 06:04:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09038; Sun, 26 Feb 95 06:03:54 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13564; Sun, 26 Feb 1995 05:56:43 -0800 Received: from access1.digex.net by Sun.COM (sun-barr.Sun.COM) id AA04644; Sun, 26 Feb 95 05:56:43 PST Received: from houston_cc_smtp.hai-net.com by access1.digex.net with SMTP id AA06997 (5.67b8/IDA-1.5 for ); Sun, 26 Feb 1995 08:23:45 -0500 Received: from cc:Mail by houston_cc_smtp.hai-net.com id AA793815959; Sun, 26 Feb 95 08:20:26 EST Date: Sun, 26 Feb 95 08:20:26 EST From: sharborth@hai-net.com Message-Id: <9501267938.AA793815959@houston_cc_smtp.hai-net.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Allow both. Don't mandate the use of one over the other. In systems which are in use today we use both methods, I would suspect each equally (at least from my experience over the past 12 years in secure communications system design & implementation.) Admittedly each has it's good and bad points, but we are all in the process of trying to design a NEW protocol and this protocol, if it is to be widely accepted, must be able to be implemented by everyone. Some customers really are not concerned with the overhead, they just want a secure channel. It really depends on the application. Bottom line: Security has always had some overhead and it always will. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-= W.S. "Skip" Harborth Manager & Senior Engineer Information Systems Security Engineering Houston Associates, Incorporated 4601 North Fairfax Dr, Suite 1001 Arlington, Virginia 22203 USA (703) 284-8732 812-5099 (fax) INTERNET> sharborth@hai-net.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-= _______________________________________________________________________________ Subject: (IPng) Proposed Standard or no? From: ipng@sunroof.Eng.Sun.COM at internet Date: 24-02-95 19:43 Folks, I originally sent my email on in-band signalling of keying material to both the IPSEC and IPv6 mailing lists, since the issues are identical to each. Right now we have the following people who think in-band signalling should be allowed : IPSEC WG -------- hugo@watson.ibm.com rgm3@is.chrysler.com nessett@eng.sun.com markson@osmosys.incog.com ashar@osmosys.incog.com IPv6 WG ------- bound@zk3.dec.com markson@osmosys.incog.com ashar@osmosys.incog.com nessett@eng.sun.com The people opposed to in-band signalling are : IPSEC WG -------- atkinson@itd.nrl.navy.mil bsimpson@morningstar.com perry@imsi.com IPv6 WG ------- atkinson@itd.nrl.navy.mil bsimpson@morningstar.com perry@imsi.com Admittedly, neither group enjoys a clear majority (in fact most people probably aren't reading the email, due to the vituperation in many of the messages from certain of the participants). However, I think there are enough people who believe that in-band signalling should at least be *allowed* that the I-Ds as they currently stand should not be advanced to Proposed Draft status. Personally, I would like to hear from some of the others on these lists to find out what they think. [The views of those listed above have been thoroughly ventilated, I think]. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 08:04:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09096; Sun, 26 Feb 95 08:04:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09090; Sun, 26 Feb 95 08:04:24 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15454; Sun, 26 Feb 1995 07:55:45 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA09437; Sun, 26 Feb 95 07:55:47 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA04779; Sun, 26 Feb 95 07:52:31 -0800 Received: by xirtlu.zk3.dec.com; id AA04985; Sun, 26 Feb 1995 10:52:29 -0500 Message-Id: <9502261552.AA04985@xirtlu.zk3.dec.com> To: "Mike O'Dell" Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, jis@mit.edu Subject: Re: (IPng) Key management In-Reply-To: Your message of "Sat, 25 Feb 95 12:22:42 EST." Date: Sun, 26 Feb 95 10:52:23 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Mike, Thanks you have made this clearer to me re: EKM. Now in Ran's drafts (Ran this is to you to OK) can the explanation you just provided about EKM with a discussion of how a KDC like Kerberos could be used as interim solution (good if we had public one to reference too) as a form of manual key distribution pending key mgmt protocols. Then the circles you suggested we judiciously slice in the IPv6SEC protocol machinery for the above would also be useful in the specs too. And very important clarity that we clearly articulate that this/these mechanisms cannot be intertwined with the use of auto key mgmt. I think this would add great value to the specs. New Question: Do we want to leave it to be implementation defined how we provide different accept/reject of IPv6SEC packets based on when users MAY or MAY not USE IPv6SEC. The issue is if a user is not using IPv6SEC it may want to respond not right now or if you insist OK. I sent this to Ran as other input to define config granularity to process security requests. This will be discussed in Dan M's. API work but APIs in the IETF won't get to any standards track. I realize this is policy. But how IPv6SEC is used per users MAY or MAY NOT using it could I think cause an interoperability problem if we don't have some options. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 08:47:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09112; Sun, 26 Feb 95 08:47:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09106; Sun, 26 Feb 95 08:47:18 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16432; Sun, 26 Feb 1995 08:39:59 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA11214; Sun, 26 Feb 95 08:40:00 PST Received: by rodan.UU.NET id QQyetu23911; Sun, 26 Feb 1995 11:36:06 -0500 Message-Id: To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, jis@mit.edu, mo@uunet.uu.net Subject: (IPng) Re: accept/reject keys... In-Reply-To: Your message of "Sun, 26 Feb 1995 10:52:23 EST." <9502261552.AA04985@xirtlu.zk3.dec.com> Date: Sun, 26 Feb 1995 11:36:06 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Wait a minute - I thought this was long dead, but keeps rising from the dead. THERE IS NO NEED FOR AN ACCEPT/REJECT MECHANISM. Think carefully about this: If I start sending you encrypted packets and you don't know how to decrypt them, then I'll never get a session established. You might want to send an ICMP "What the hell are you trying to say to me?" packet just so it is easier to understand why we cannot communicate, but there is NO NEED for anything else. Note that this applies whether it's because we don't share an encryption algorithm in our implementations, or that we haven't yet negotiated key knowledge for the SA (whether exogenous or endogenous doesn't matter for this issue), or whether it's becase your end doesn't implement encryption AT ALL. We must be *very* careful not to think of this as a "negotiation" in the usual IETF sense of the word. My use of encryption starting a connection and your insistence on demanding authenticated packets are UNILATERAL decisions and not subject to discussion. If I start and encrypted stream and you have the information to process it, then you should do so (obviously), and if you don't, the bits just fall on the floor. We don't dance around trying random things. This is *precisely* why how to get keying knowledge is not part of the encapsulation machinery. Secure sessions must be arranged-for by exchanging Security Association information up front, somehow, and then used by connections or flows or however they get used by the SOURCE of the packets - you always do what the source says. If you, the recipient, don't have enough info to make sense of it, just drop it (and maybe ICMP, as was said above). But even that might be a security risk (you might be able to probe for SAs that way) (Jeff??). i hope this is helping.... -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 10:08:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09130; Sun, 26 Feb 95 10:08:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09124; Sun, 26 Feb 95 10:07:59 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17973; Sun, 26 Feb 1995 10:00:06 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA14227; Sun, 26 Feb 95 10:00:08 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA26626; Sun, 26 Feb 95 09:55:46 -0800 Received: by xirtlu.zk3.dec.com; id AA09370; Sun, 26 Feb 1995 12:54:43 -0500 Message-Id: <9502261754.AA09370@xirtlu.zk3.dec.com> To: "Mike O'Dell" Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, jis@mit.edu Subject: (IPng) Re: accept/reject keys... In-Reply-To: Your message of "Sun, 26 Feb 95 11:36:06 EST." Date: Sun, 26 Feb 95 12:54:37 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Mike, It is helping. The issue I was concerned about then is this: If a user of an IPv6 implementation sets IPv6SEC to IP6SEC_NOT_USE at configuration time then if a node sends an IPv6SEC header in an IPv6 packet the implementation will either drop the packet or send "I don't know what your talking about". But what if we want to permit applications to determine if IPv6SEC is enabled in an implementation even if IP6SEC_NOT_USE is set at configuration time. This means the default setting of the configuration is changed for a particular application. This means that IPv6SEC can be used by some applications and not by others. I think this is a feature we will want to offer the market. Now we could say that this should not be in the IPv6 standards? But I think it needs to be somewhere? Or can we just let everyone roll their own on this one? We are really getting at the API issue and where the MAY or MAY NOT USE is controlled maybe? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 10:33:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09142; Sun, 26 Feb 95 10:33:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09136; Sun, 26 Feb 95 10:33:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18498; Sun, 26 Feb 1995 10:23:30 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA15117; Sun, 26 Feb 95 10:19:37 PST Received: from relay.imsi.com by wintermute.imsi.com id NAA09337; Sun, 26 Feb 1995 13:19:35 -0500 Received: from snark.imsi.com by relay.imsi.com id NAA00292; Sun, 26 Feb 1995 13:19:35 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA06104; Sun, 26 Feb 95 13:19:08 EST Message-Id: <9502261819.AA06104@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com, jis@mit.edu, mo@uunet.uu.net Subject: Re: (IPng) Re: accept/reject keys... In-Reply-To: Your message of "Sun, 26 Feb 1995 11:36:06 EST." X-Reposting-Policy: redistribute only with permission Date: Sun, 26 Feb 1995 13:19:07 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "Mike O'Dell" says: > THERE IS NO NEED FOR AN ACCEPT/REJECT MECHANISM. > > Think carefully about this: > > If I start sending you encrypted packets and you don't know > how to decrypt them, then I'll never get a session established. > You might want to send an ICMP "What the hell are you trying to > say to me?" packet just so it is easier to understand why we > cannot communicate, but there is NO NEED for anything else. Quite right. This is reflected in the (v4) ICMP messages for IPSP draft that I'm working on. > We must be *very* careful not to think of this as a "negotiation" in > the usual IETF sense of the word. My use of encryption starting a > connection and your insistence on demanding authenticated packets > are UNILATERAL decisions and not subject to discussion. If I start > and encrypted stream and you have the information to process it, then > you should do so (obviously), and if you don't, the bits just fall > on the floor. We don't dance around trying random things. I'll point out, though, that if you get an ICMP "sorry, you weren't encrypted" message, you logically should then try to set up a security association and try again. This is not a negotiation in the usual sense (as you point out) but it isn't quite "drop the whole thing on the floor" either. .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 10:40:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09154; Sun, 26 Feb 95 10:40:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09148; Sun, 26 Feb 95 10:39:51 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18608; Sun, 26 Feb 1995 10:31:58 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA15577; Sun, 26 Feb 95 10:31:59 PST Received: from relay.imsi.com by wintermute.imsi.com id NAA09318; Sun, 26 Feb 1995 13:11:21 -0500 Received: from snark.imsi.com by relay.imsi.com id NAA00242; Sun, 26 Feb 1995 13:11:20 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA06080; Sun, 26 Feb 95 13:10:53 EST Message-Id: <9502261810.AA06080@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? In-Reply-To: Your message of "Sun, 26 Feb 1995 08:20:26 EST." <9501267938.AA793815959@houston_cc_smtp.hai-net.com> X-Reposting-Policy: redistribute only with permission Date: Sun, 26 Feb 1995 13:10:53 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM sharborth@hai-net.com says: > Allow both. Don't mandate the use of one over the other. In > systems which are in use today we use both methods, I would suspect > each equally (at least from my experience over the past 12 years in > secure communications system design & implementation.) I suspect that you don't understand what is being discussed -- I'm not trying to insult you here, its just that the conversation is being couched in very deceptive terms. You probably are not using either method today, and very likely not both. The terminology is very odd -- I suggest that you read all the drafts in question in order to really get a feel for what is being discussed. The topic boils down to this: do we want to permit for conveying key management information in IPSP packets instead of in, say, separate UDP packets. The argument being made on our side is "it won't give you any performance and messes up a very clean design, making it far harder to implement for negligible gain". The argument on their side boils down to "we get to save a whole packet at the beginning of each of your TCP sessions, and it means you get to rekey on every packet!" Neither of these particularly seem to be important to me. In the end, this comes down to whether you feel SKIP should be the key management protocol we use -- the changes are being requested purely to support SKIP, because Ashar seems to have painted himself into a corner in which he assured us all along that he could adapt SKIP to the proposed IPSP design and then realized only in the last week (it seems) that he needed functionality at the IPSP layer that wasn't available. One of the reasons a number of us have argued this discussion should be on the IPSEC list is because people on IPng lack the context of the discussion. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 12:08:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09228; Sun, 26 Feb 95 12:08:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09208; Sun, 26 Feb 95 12:07:48 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20497; Sun, 26 Feb 1995 12:00:37 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA19118; Sun, 26 Feb 95 12:00:39 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA17368; Sun, 26 Feb 95 11:56:27 -0800 Received: by xirtlu.zk3.dec.com; id AA10183; Sun, 26 Feb 1995 14:56:24 -0500 Message-Id: <9502261956.AA10183@xirtlu.zk3.dec.com> To: jis@mit.edu (Jeffrey I. Schiller) Cc: bound@zk3.dec.com, perry@imsi.com, ipng@sunroof.Eng.Sun.COM, mo@uunet.uu.net Subject: Re: (IPng) Re: accept/reject keys... In-Reply-To: Your message of "Sun, 26 Feb 95 14:17:33 EST." Date: Sun, 26 Feb 95 14:56:18 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jeff, >Phil Karn spent some serious time simply considering the problem of two >security speaking nodes where one of them reboots, loosing keying state, >and the other node doesn't know that happened. Getting things up and >running in a secure fashion is requires some subtle thinking about protocol >design. I agree and see the problem with ICMP too. We are talking about making the IPv6 security docs proposed standard. Do we need more time for subtle thinking about protocol design and how this is going to work, come up with some answers, and then go to proposed standard? If I convince my engineering manager that I MUST change ifnet for IPv6 protocol they will not say go change it. They will say whats the affect to the rest of the networking routines that must use the ifnet structure elements, how will it affect the IPv4 stack, and how will ifconfig and routed work with the changes to the ifnet. If I can't answer all those questions I don't get the nod to change ifnet. Or as an engineer I could have thought about all this before I went to my engineering manager. Either way someone has to look at the total affect to the architecture. I don't want us to get bogged down in strategic issues for IPv6 at this point, but I can't help but feel we are trying to to state a MUST for all IPv6 implementations without having a complete solution or knowing the affect to the overall implementation and interoperability of IPv6 because of the IPv6SEC specifications. Did not anyone answer these architecture questions and implementation details in the IESG prior to giving Ran the impression (and many of us) that security should be a MUST in IPv6 to implement was well thought out. I just assumed that this discussion had already been thought about in a subtle manner and someone had answers. If not then I still think its premature for the IESG or anyone to mandate security for implementations in IPv6. Yes we do need security on the Internet. But I think we have some more design work to do. Until that design work is done mandating to vendors they MUST implement IPv6SEC is premature from both a technical and business perspective. I see no choice but to make it a SHOULD because in a Last Call response I am sure several of us who are concerned can put together quite a case why this should not be a MUST. I see no point of eating to many more cycles on this mail list as we have so much other IPv6 work to do. I have presented the concerns to the WG, watched an extensive discussion, and now I think its time I get ready for the last call and will search for colleagues in the IETF that agree with me and try and prevent what I think is a very premature decision to be made regarding IPv6. Which will negatively impact the market when its objective was a positive effort to solve a real problem. Is the IETF now going to start always mandating parts of technology because they don't trust the implementors to do the right thing? Is that the motivation for all this. What vendor would not implement security if it was available and better yet what customer would bother buying their products who use the Internet if they did notplement Rans protocol specifications for IPv6. But it does not have to be a must implement like a checksum routine or payload type field in the IPv6 header. We can keep moving with IPv6 and work on security, but we don't need a MUST implement. The IESG could end this entire discussion and a lot of work to get ready for a proposed standard last call by changing MUST to SHOULD. The IESG would also then be making a less intense decision regarding their accountability per a previous memo to Mike. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 12:15:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09290; Sun, 26 Feb 95 12:15:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09284; Sun, 26 Feb 95 12:15:08 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20602; Sun, 26 Feb 1995 12:06:29 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA19149; Sun, 26 Feb 95 12:01:30 PST Received: by rodan.UU.NET id QQyeuf08078; Sun, 26 Feb 1995 14:21:20 -0500 Message-Id: To: bound@zk3.dec.com Cc: "Mike O'Dell" , ipng@sunroof.Eng.Sun.COM, jis@mit.edu Subject: (IPng) Re: accept/reject keys... In-Reply-To: Your message of "Sun, 26 Feb 1995 12:54:37 EST." <9502261754.AA09370@xirtlu.zk3.dec.com> Date: Sun, 26 Feb 1995 14:21:19 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM clearly what you propose should work and it should be said somewhere. but the thing that makes it work, and the indicator which says whether it will or not (before simply timing out when attempted) is the attempt to establish a Security Association which will then be used. Maybe a few examples will make this clearer (to me at least!).... If my workstation is configured with "Don't do security stuff at all" the situation is simple. Any attempt by your workstation to establish security associations with my workstation will fail. This means that you know you cannot talk to me securely. It would be silly for you to send encrypted traffic as I will drop it. Whether it is pointless for you to include an authentication header is less clear - if my workstation forwards traffic to someone else...... If my workstation is configured for "Do security if requested by local apps or remote solicitations", then your attempt to establish a security association will succeed, assuming that we can agree upon an encryption protocol and exchange key material in a mutually satisfactory manner (subject to whatever key management machinery we agree to use, however we make such an agreement). If we successfully establish a security association, then you can send encrypted traffic, subject to the use constraints on the security association, and I can decrypt it successfully. Note that I will still process unencrypted traffic initiated from elsewhere and originate connections in the clear unless the application requests encryption. In that case, I become the other end of this discussion. If my workstation is configured for "Always initiate secure communications and demand secure communications", the I will always try to establish secure paths and will return failure if that cannot be done. likewise, the box will not process traffic which does not have some form of security processing....... Hmmmm - now I think I understand the root cause of the problem. We have been seriously overloading the "configuration switches" There are two switches: One for "remotely initiated contacts" - call it RICS (S for security) and One for "locally initiated contacts" - call it LICS RICS has several settings: (1) Ignore security requests (2) Honor security requests (subject to key management, etc) (3) Demand security requests (don't let it in without it) LICS also has several settings: (1) Don't allow outgoing security (return error on requests for it) (2) Allow discressionary security (apps can request it) (3) Non-discressionary security (demand it even it the app doesn't) I've been thinking through this in the transport (TCP) frame of reference. there are problably some implications for UDP, etc. Also, there may be other switches which are used to force traffic through crypto-tunnels - demand all traffic between two destinations (granularity of a destination is probably a general prefix down to single host) must go wholesale encrypted ON TOP of whatever application encryption might be in effect as negotiated by the application protocols. While this is a start on the config issue, I think there's been waaay too much overloading. I don't claim this model is perfect, but I see how to use it much easier than I have previously. I wait your ruminations. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 12:18:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09302; Sun, 26 Feb 95 12:18:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09296; Sun, 26 Feb 95 12:17:48 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20707; Sun, 26 Feb 1995 12:10:37 -0800 Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA19422; Sun, 26 Feb 95 12:10:39 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA18057; Sun, 26 Feb 95 12:09:32 -0800 Received: by xirtlu.zk3.dec.com; id AA10258; Sun, 26 Feb 1995 15:09:30 -0500 Message-Id: <9502262009.AA10258@xirtlu.zk3.dec.com> To: "Mike O'Dell" Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, jis@mit.edu Subject: (IPng) Re: accept/reject keys... In-Reply-To: Your message of "Sun, 26 Feb 95 14:21:19 EST." Date: Sun, 26 Feb 95 15:09:24 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Mike, I am with you. Yes its really overloaded I think your idea of remote vs local is a good one. Here is something Greg Minshall stated to me and then sent out to a few of us. What started it was Greg and I were talking how is the API going to look for IPv6 security. I think this is close to part of your thoughts too. Greg is on IPng list too. I have deleted text where products were talked about as this was private mail. This way just in case a flame fest starts again product names are not even involved (sorry I am paranoid now). What do you think? --------------------------------------------------------- Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com, mcdonald@itd.nrl.navy.mil, atkinson@itd.nrl.navy.mil From: greg_minshall@Novell.COM Subject: Re: Security API Spec Cc: grehan@flotsm.ozy.dec.com, Bob.Gilligan@eng.sun.com, set@thumper.bellcore.com, deering@parc.xerox.com Jim, et al, ************text deleted******************************** Packet signing is controlled by a 4-position switch on clients and servers. During connection set up time, the positions of the switches at the two ends are used to decide whether to use packet signing on the connection (and, in fact, whether a connection is possible). If packet signing is used, it is used in both directions. The four positions are: 1. I refuse to participate in packet signing. 2. I won't request packet signing, but will agree to it if my peer so requests. 3. I will request packet signing, but i'm willing to communicate even if my peer won't agree to do packet signing. 4. I insist on packet signing; i won't communicate unless my peer is willing to do packet signing. (As you can see, if one side is set to position 1 and the other is set to position 4, no communications will occur; all other combinations are compatible.) ****************************************************** We haven't implemented this in an API, but if we *were* to do that, i would argue that the API option compose well with the per-node option. At the minimum, this means a fifth position (labelled "0"), the default, which says "whatever the per node switch is set to". Probably, you would also want some indicator that says "MAX(per-node, API parameter)", or some such, but i haven't really thought much about that. Greg ------------------------------------------------------ thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 15:39:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09462; Sun, 26 Feb 95 15:39:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09456; Sun, 26 Feb 95 15:39:34 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25548; Sun, 26 Feb 1995 15:31:41 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA27254; Sun, 26 Feb 95 15:31:42 PST Received: from relay.imsi.com by wintermute.imsi.com id SAA10093; Sun, 26 Feb 1995 18:18:39 -0500 Received: from snark.imsi.com by relay.imsi.com id SAA02302; Sun, 26 Feb 1995 18:18:38 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA06459; Sun, 26 Feb 95 18:18:09 EST Message-Id: <9502262318.AA06459@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Sun, 26 Feb 1995 14:58:29 PST." <9502262258.AA01913@miraj.> X-Reposting-Policy: redistribute only with permission Date: Sun, 26 Feb 1995 18:18:08 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ashar Aziz says: > > From perry@imsi.com Fri Feb 24 15:15 PST 1995 > > Under those circumstances, SKIP would display absolutely identical > > properties if it was to perform well. You would end up having to cache > > lots of keys in the kernel -- unless you were going to do server > > lookups on each, with several packet exchanges, which would obviate > > all claims of performance advantages. > > As I just explained in an earlier message to Carl, SKIP caching is quite > different from caching stateful connections. It is very session-less, Ashar; A session is a lump of data sitting in memory. It isn't a bunch of phone linemen with trucks. Our connections are "virtual"; they are just state. From what I can tell, SKIP forces you to cache a bunch of data, and other proposals do, too. As soon as you start having to keep track of data, you aren't stateless and thats all that counts. "Sessions" are a red herring. The question is state, and you have it just like all the other proposals. You can't avoid it. One reason people have to want to be stateless is that things like DNS get huge amounts of traffic from lots of sources -- but you would have just as bad a problem securing DNS traffic as anyone else, because you'd have to do lots of database lookups for your keys just like everyone else. IPSP isn't suitable for such applications -- only things like the Eastlake-Kaufman DNS proposal, which produce very low server overhead by pre-signing lots of data, will work for such applications. > and with the right implementation, one can almost completely hide the > overhead of expensive public-key operations; this cannot be achieved > by caching traditional secure sessions. Why not? So far as I can tell you are just labeling your data differently -- you are also involving state, you are just calling it something else. > > Now, as for firewalls with large numbers of clients, I have actually > > built and operated such firewalls. They all operate with application > > level relays which are far heavier weight, statewise, than security > > associations could ever be. These firewalls function just fine. > > We have several firewalls in-house as well. However, these firewalls > with application-layer relays have never been used to establish > entire virtual enterprises over a public net like the Internet. What is a "virtual enterprise", and why should we expect it to be any harder to establish than anything else? Anyway, the point was simply that existing systems that employ state are capable of handling fairly heavy loads -- loads similar, if not higher than, the ones we would expect to have to hit in machines dealing with the sort of state that SKIP or other protocols would induce in them. And yes, Ashar, you are not proposing a stateless protocol no matter what you would say. > > > Normally, one can simply blow away half-open connections when > > > the side that has crashed detects them. This is not so trivial for a > > > security session because this has to be done securely, otherwise > > > denial-of-service attacks would be trivial. (Not to say that this can't > > > be solved, but this at least presents another complication). > > > > I don't see why its a problem at all. The TCP connections to the dead > > machine will vanish on their own. The security associations will > > eventually time out and go away. New connections from the rebooted > > machine will form new security associations. > > Yes, but we are not talking about a security protocol just for TCP. Thats completely irrelevant. You just put an inactivity timer on your SA structures and they clean themselves up. Bit deal. > We are talking about a security protocol for IP, and TCP is not the > only thing that runs over IP. In particular, secure sessions running > underneath session-less protocols (e.g. UDP based apps) will not time out > and vanish. Yes they will. If you have no traffic for long enough a period, you can time out your state, and if new traffic arises, you can re-establish it. > (As it so happens, the encrypted video demo using Sun's ShowMe > application that I gave at the San Jose IETF is one such application.) ShowMe is a very heavyweight application -- you get data packets from it on a constant basis. I would expect, then, that the half-open state problem would not be a problem -- a two minute inactivity timer on your state would easily handle the problem. That was your original point, remember? In any case, I assume that you have to build such stuff into the cache of state that you have to have built into your SKIP implementation, because unless you are caching keys that you expect to be using soon, you will hit insanely bad performance problems -- like having to do an X.500 query to the X.500 database you are depending on to store your X.509 certificates on every packet for which you haven't already cached the keys. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 16:40:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09618; Sun, 26 Feb 95 16:40:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09161; Sun, 26 Feb 95 11:24:57 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19536; Sun, 26 Feb 1995 11:17:46 -0800 Received: from big-screw (BIG-SCREW.MIT.EDU) by Sun.COM (sun-barr.Sun.COM) id AA17526; Sun, 26 Feb 95 11:17:39 PST Received: by big-screw id AA14234; Sun, 26 Feb 95 14:16:49 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 26 Feb 1995 14:17:33 -0500 To: bound@zk3.dec.com From: jis@mit.edu (Jeffrey I. Schiller) Subject: Re: (IPng) Re: accept/reject keys... Cc: perry@imsi.com, ipng@sunroof.Eng.Sun.COM, jis@mit.edu, mo@uunet.uu.net Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 13:58 2/26/95, bound@zk3.dec.com wrote: >If the reason an ICMP packet was sent to the node trying to attempt to >send security payload was that the node being attempted had MAY NOT USE >security on then should that not tell the node to just give up? This could >mean the two nodes cannot communicate. Which leads me to the question I >was inherently asking, which is that if a node uses IPv6SEC then is it >TRUE that they can only communicate with other nodes that have IPv6SEC MAY >USE per the user configuration. The affect of this should be intuitive >to all. One problem is that an attacker should not be able to fool a IPv6SEC speaking node from using it by sending bogus ICMP packets stating that security is not available. When designing negotiation mechanims that involve the use (or non-use) of security services you need to determine what affect an intruder can do by introducing bogus data into your negotiation stream, particularly when your negotiation is not protected by a security service. Phil Karn spent some serious time simply considering the problem of two security speaking nodes where one of them reboots, loosing keying state, and the other node doesn't know that happened. Getting things up and running in a secure fashion is requires some subtle thinking about protocol design. -Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 16:42:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09630; Sun, 26 Feb 95 16:42:55 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09446; Sun, 26 Feb 95 15:18:57 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA02293; Sun, 26 Feb 1995 15:11:50 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA02275; Sun, 26 Feb 1995 15:11:45 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA26836; Sun, 26 Feb 95 15:11:44 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA26448; Sun, 26 Feb 95 15:11:42 PST Received: by ns.incog.com (8.6.10/94082501) id PAA05800; Sun, 26 Feb 1995 15:11:46 -0800 Received: from miraj. by ns.incog.com (8.6.10/94082501) id PAA05785; Sun, 26 Feb 1995 15:11:44 -0800 Received: by miraj. (5.x/SMI-SVR4) id AA01906; Sun, 26 Feb 1995 14:27:35 -0800 Date: Sun, 26 Feb 1995 14:27:35 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9502262227.AA01906@miraj.> To: cfm@columbia.sparta.com Cc: bound@zk3.dec.com, perry@imsi.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Carl Muckenhirn > Even with SKIP, there is some state kept around somewhere, maybe in the DNS > (more messages), but it has to exist. In the case of crashes/reboot, you have > to "re-establish" the context of all of those connections eventually anyways > (not TCP connections per-se, but connections nevertheless). No one has said > that the re-establishment was a synchronous event, just bring them back when > you need them, you'll need them again in most cases. Carl, There may be state but is not connections and it is not shared-state (a la session keys). SKIP caching is completely session-less (because the SKIP master key is what needs to be cached) and does not need to be re-established on both sides in case of a reboot. Only the side that loses it may need to re-establish it. Even this can be eliminated, if one can cache the master keys in non-volatile secure memory (and we are examining several solutions that will permit this in a very inexpensive way). This will permit either side to crash/reboot and perform no public-key operations in order to go back into secure mode. The point here is that the SKIP master keys are good across "sessions", unlike session keys which when session state is lost are no good. A simple analogy is as follows; when I have locally cached the result of a DNS lookup of your hostname-to-IP-addr mapping, if you crash then I don't have to do another look-up. The information that is cached is good across sessions. This is analagous to SKIP master key caching. By contrast, if I have a stateful connection to you (e.g. TCP or X.25 etc), then if you crash, we both have to re-establish that. This is analagous to traditional session key re-establishment. Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 16:44:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09659; Sun, 26 Feb 95 16:44:16 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09446; Sun, 26 Feb 95 15:18:57 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA02293; Sun, 26 Feb 1995 15:11:50 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA02275; Sun, 26 Feb 1995 15:11:45 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA26836; Sun, 26 Feb 95 15:11:44 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA26448; Sun, 26 Feb 95 15:11:42 PST Received: by ns.incog.com (8.6.10/94082501) id PAA05800; Sun, 26 Feb 1995 15:11:46 -0800 Received: from miraj. by ns.incog.com (8.6.10/94082501) id PAA05785; Sun, 26 Feb 1995 15:11:44 -0800 Received: by miraj. (5.x/SMI-SVR4) id AA01906; Sun, 26 Feb 1995 14:27:35 -0800 Date: Sun, 26 Feb 1995 14:27:35 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9502262227.AA01906@miraj.> To: cfm@columbia.sparta.com Cc: bound@zk3.dec.com, perry@imsi.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Carl Muckenhirn > Even with SKIP, there is some state kept around somewhere, maybe in the DNS > (more messages), but it has to exist. In the case of crashes/reboot, you have > to "re-establish" the context of all of those connections eventually anyways > (not TCP connections per-se, but connections nevertheless). No one has said > that the re-establishment was a synchronous event, just bring them back when > you need them, you'll need them again in most cases. Carl, There may be state but is not connections and it is not shared-state (a la session keys). SKIP caching is completely session-less (because the SKIP master key is what needs to be cached) and does not need to be re-established on both sides in case of a reboot. Only the side that loses it may need to re-establish it. Even this can be eliminated, if one can cache the master keys in non-volatile secure memory (and we are examining several solutions that will permit this in a very inexpensive way). This will permit either side to crash/reboot and perform no public-key operations in order to go back into secure mode. The point here is that the SKIP master keys are good across "sessions", unlike session keys which when session state is lost are no good. A simple analogy is as follows; when I have locally cached the result of a DNS lookup of your hostname-to-IP-addr mapping, if you crash then I don't have to do another look-up. The information that is cached is good across sessions. This is analagous to SKIP master key caching. By contrast, if I have a stateful connection to you (e.g. TCP or X.25 etc), then if you crash, we both have to re-establish that. This is analagous to traditional session key re-establishment. Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 17:13:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09703; Sun, 26 Feb 95 17:13:02 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09498; Sun, 26 Feb 95 15:53:53 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA03450; Sun, 26 Feb 1995 15:46:46 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA03427; Sun, 26 Feb 1995 15:46:40 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA27396; Sun, 26 Feb 95 15:46:39 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB27873; Sun, 26 Feb 95 15:46:37 PST Received: by ns.incog.com (8.6.10/94082501) id PAA02129; Sun, 26 Feb 1995 15:01:31 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id PAA02080; Sun, 26 Feb 1995 15:01:23 -0800 Received: from miraj. (miraj.incog.com) by osmosys.incog.com (5.x/SMI-SVR4) id AA01484; Sun, 26 Feb 1995 15:00:41 -0800 Received: by miraj. (5.x/SMI-SVR4) id AA01913; Sun, 26 Feb 1995 14:58:29 -0800 Date: Sun, 26 Feb 1995 14:58:29 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9502262258.AA01913@miraj.> To: perry@imsi.com Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From perry@imsi.com Fri Feb 24 15:15 PST 1995 > Under those circumstances, SKIP would display absolutely identical > properties if it was to perform well. You would end up having to cache > lots of keys in the kernel -- unless you were going to do server > lookups on each, with several packet exchanges, which would obviate > all claims of performance advantages. Perry, As I just explained in an earlier message to Carl, SKIP caching is quite different from caching stateful connections. It is very session-less, and with the right implementation, one can almost completely hide the overhead of expensive public-key operations; this cannot be achieved by caching traditional secure sessions. > Now, as for firewalls with large numbers of clients, I have actually > built and operated such firewalls. They all operate with application > level relays which are far heavier weight, statewise, than security > associations could ever be. These firewalls function just fine. We have several firewalls in-house as well. However, these firewalls with application-layer relays have never been used to establish entire virtual enterprises over a public net like the Internet. They typically give you a handful of Internet services, and connectivity through them is not as seamless as on a private net. I don't believe that to date, very large scale virtual enterprises have been built using the kind of firewall you are referring to (though I am open to correction). > > Normally, one can simply blow away half-open connections when > > the side that has crashed detects them. This is not so trivial for a > > security session because this has to be done securely, otherwise > > denial-of-service attacks would be trivial. (Not to say that this can't > > be solved, but this at least presents another complication). > > I don't see why its a problem at all. The TCP connections to the dead > machine will vanish on their own. The security associations will > eventually time out and go away. New connections from the rebooted > machine will form new security associations. Yes, but we are not talking about a security protocol just for TCP. We are talking about a security protocol for IP, and TCP is not the only thing that runs over IP. In particular, secure sessions running underneath session-less protocols (e.g. UDP based apps) will not time out and vanish. (As it so happens, the encrypted video demo using Sun's ShowMe application that I gave at the San Jose IETF is one such application.) Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 19:08:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09794; Sun, 26 Feb 95 19:08:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09788; Sun, 26 Feb 95 19:08:47 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19252; Sun, 26 Feb 1995 11:05:02 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA16912; Sun, 26 Feb 95 11:05:04 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA00224; Sun, 26 Feb 95 11:00:05 -0800 Received: by xirtlu.zk3.dec.com; id AA09863; Sun, 26 Feb 1995 13:59:02 -0500 Message-Id: <9502261859.AA09863@xirtlu.zk3.dec.com> To: perry@imsi.com Cc: ipng@sunroof.Eng.Sun.COM, jis@mit.edu, mo@uunet.uu.net Subject: Re: (IPng) Re: accept/reject keys... In-Reply-To: Your message of "Sun, 26 Feb 95 13:19:07 EST." <9502261819.AA06104@snark.imsi.com> Date: Sun, 26 Feb 95 13:58:56 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, >I'll point out, though, that if you get an ICMP "sorry, you weren't >encrypted" message, you logically should then try to set up a security >association and try again. This is not a negotiation in the usual >sense (as you point out) but it isn't quite "drop the whole thing on >the floor" either. If the reason an ICMP packet was sent to the node trying to attempt to send security payload was that the node being attempted had MAY NOT USE security on then should that not tell the node to just give up? This could mean the two nodes cannot communicate. Which leads me to the question I was inherently asking, which is that if a node uses IPv6SEC then is it TRUE that they can only communicate with other nodes that have IPv6SEC MAY USE per the user configuration. The affect of this should be intuitive to all. Bottomline is because one node wants to USE security it cannot force the other node to USE security too they just don't communicate. Unless we define some other negotiation somewhere this is the only choice. I am not saying what should be but trying to understand the affect of IPv6 security on the ability for communications between two IPv6 nodes. If we want them to communicate either one of the nodes stops sending security or the other one turns it on. Neither operation is required. Do we need to say how this may be done in an IPv6 networking environment? Or as I said to Mike let everyone roll their own? [this discussion must be on this mailing list for now its an IPv6 architecture issue too] /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 26 19:39:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09820; Sun, 26 Feb 95 19:39:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09814; Sun, 26 Feb 95 19:38:59 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02744; Sun, 26 Feb 1995 19:31:47 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA15624; Sun, 26 Feb 95 19:31:49 PST Received: from relay.imsi.com by wintermute.imsi.com id SAA10120; Sun, 26 Feb 1995 18:30:52 -0500 Received: from snark.imsi.com by relay.imsi.com id SAA02397; Sun, 26 Feb 1995 18:30:51 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA06477; Sun, 26 Feb 95 18:30:21 EST Message-Id: <9502262330.AA06477@snark.imsi.com> To: ashar@miraj.incog.com (Ashar Aziz) Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Sun, 26 Feb 1995 14:27:35 PST." <9502262227.AA01906@miraj.> X-Reposting-Policy: redistribute only with permission Date: Sun, 26 Feb 1995 18:30:20 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ashar Aziz says: > >From: Carl Muckenhirn > > Even with SKIP, there is some state kept around somewhere, maybe > > in the DNS (more messages), but it has to exist. In the case of > > crashes/reboot, you have to "re-establish" the context of all of > > those connections eventually anyways (not TCP connections per-se, > > but connections nevertheless). No one has said that the > > re-establishment was a synchronous event, just bring them back > > when you need them, you'll need them again in most cases. > > There may be state but is not connections and it is not shared-state > (a la session keys). A connection is not established in a modern network with wire, and solder, Ashar. Its, too, is just a bit of state sitting in memory. As soon as you have state, all you've done is renamed what we are talking about. Now, Photuris and other alternatives to your SKIP proposal aren't "connection oriented", either. They cache a security association. You cache data and call it something different. Big deal. You are also being extraordinarily deceptive in claiming not to have shared state. Of course you have shared state. If both sides didn't know what key to expect the data to be encrypted with, no communication could take place. The fact that you are being unusual in the way you deal with that data in no way changes the fact that you have state involved and shared information -- you've just renamed it. > SKIP caching is completely session-less > (because the SKIP master key is what needs to be cached) and does not > need to be re-established on both sides in case of a reboot. Of course it has to be re-established. If you don't have the data present again, you can't communicate again. You are being deceptive by renaming things. None of the other proposals claimed to have "sessions" by the way -- you just claim that you are "sessionless", but thats meaningless -- you are caching as much data as they are, and the key database lookups you do are just as expensive as the ones everyone else has to do. > Even this can be eliminated, if one can cache the master keys in > non-volatile secure memory (and we are examining several solutions > that will permit this in a very inexpensive way). This will permit > either side to crash/reboot and perform no public-key operations in > order to go back into secure mode. In what way is this different from anyone else? All the proposals I know of would recover from crashes transparently if you had some NV-RAM available. Big deal. In what way is this a contrast to anyone else? Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 01:53:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09976; Mon, 27 Feb 95 01:53:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09970; Mon, 27 Feb 95 01:53:49 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13826; Mon, 27 Feb 1995 01:46:39 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA14035; Mon, 27 Feb 95 01:46:26 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 27 Feb 95 18:44:56 +0859 From: Masataka Ohta Message-Id: <9502270945.AA02331@necom830.cc.titech.ac.jp> Subject: Re: (IPng) A NEW thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Mon, 27 Feb 95 18:44:54 JST In-Reply-To: <9502211329.AA17913@clncrdv1.is.chrysler.com>; from "Robert Moskowitz" at Feb 21, 95 8:14 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Friends, > > I have been a lurker here for the past 2 months, as I have been swamped > launching a number of key systems and designing some new ones for this year... > > But I have been giving this addressing issue a lot of thought. > > At Toronto, I felt that a provider prefix for some of us 'big guys' was the > answer. After all, we are providers for many of our subsidiaries and some > suppliers and customers. > > But more recently I have thought about the multi-addressing nature of IPv6 > and how it might work. Consider the following (BTW I think it implies some > holes in our auto address config work): It might work for multihoming with less convenient way than *ID. For some other provider independence such as abrupt provider change, it is powerless. > Corp FOO has 2 INTERNET providers, A.NET and B.NET. MFG.FOO.COM is > restricted to using A.NET, ENG.FOO.COM is restricted to using B.NET, and all > others (like FIN.FOO.COM and HR.FOO.COM can use either). > > It would seem to me that when PRESS.MFG.FOO.COM boots up, it will have 3 > addresses: The INTRA-LINK address, a Private address for FOO.COM, and a > provider address from A.NET's space. Likewise when CAD.ENG.FOO.COM starts > up, it will also have 3 addresses: The Intra-Link, a Private and a provider > address from B.NET's space. Purely statically, it works. The problem is that the scheme takes a lot of work for address reassignement at the transition. When I say multihoming, it is like IPv4 multihoming. That is, if a organization connecting to provider A want to receive service also from B, IPv4 needs NO reassignment of host IP addresses. With Yakov's proposal, the length of subscriber-specific components is variable length. So, if a subscriber to provider A is using 9 byte and want to connect to provider B, reassignment of subscriber-specific part is mandately. For gradual multihoming, it might be OK. But, if a subscriber want to abruptly cut the link to provider A and switch to provider B, all the work of address reassignment is the obstacle. Considering the inconvenience of reassignment, I don't think your scheme promote provider independence. > I am making a GROSS assumption that any of the config options will help > create all of these addresses, and that all of the necessary AAAA records > will be created. As the length of subscriber-specific part is variable, that is, unspecified, your config options will depend on the first provider, which makes provider change painful. > The router folks will need to configure 3 topologies in the router network > of FOO.COM. The private topology, the part of the network accessable via > A.NET and the part accessable via B.NET. A challenge for sure, unless there > is someway to identify a local topology (upper part of the lower half of the > address) and valid provider prefixes for the routers? You are proposing to have lower half common to all the providers, that is, provider independent part, which *ID proposals already implies and is not so NEW. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 05:13:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10080; Mon, 27 Feb 95 05:13:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10074; Mon, 27 Feb 95 05:13:41 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23568; Mon, 27 Feb 1995 05:06:30 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA04373; Mon, 27 Feb 95 05:06:29 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 27 Feb 95 22:05:13 +0900 From: Masataka Ohta Message-Id: <9502271305.AA03559@necom830.cc.titech.ac.jp> Subject: re: Re: (IPng) National Registry of Routing is Har To: ipng@sunroof.Eng.Sun.COM Date: Mon, 27 Feb 95 22:05:11 JST In-Reply-To: ; from "Alan.Lloyd@datacraft.com.au" at Feb 23, 95 8:58 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > jeffs comment re pabxs and switching providers. > > YES it all relies on consistent numbering plans and carriers understanding > each others DNICs, etc. plus a few bilateral agreements to say the least. > ditto multi homed X.400 PRMDs. What's DNICs? > Once one has assumed that, then one must set up formal arrangements for > registering providers and some degree of common terms of reference for > bilateral aggreements and provider responsibility. (otherwise chaos) I love the current moderate chaos of the Internet. :-) > Registration points at the national level and guidelines such as X.660 > provide the mechanisms for this for other technologies. Though we might want proper registry, it does not mean that the bits for routing may be wasted to represent registries in unroutable way. To know how a provider is, we can lookup a database: DNS or whois, with a key of provider ID. As future globally unique MAC address for 10^15 hosts needs a lot more than 50 bits (MAC address collision is the broadcast storm bringer, the total chaos everyone shuns.), we must reserve the lower 64bit of IP address for unroutable part. So, we shouldn't waste bits for the routable part. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 09:51:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10205; Mon, 27 Feb 95 09:51:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10199; Mon, 27 Feb 95 09:51:19 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10812; Mon, 27 Feb 1995 09:44:08 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA12952; Mon, 27 Feb 95 09:44:04 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14540(1)>; Mon, 27 Feb 1995 09:39:52 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Mon, 27 Feb 1995 09:39:42 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng) Re: implementor's meeting in Danvers? In-Reply-To: deering's message of Fri, 17 Feb 95 10:12:50 -0800. <95Feb17.101302pst.12174@skylark.parc.xerox.com> Date: Mon, 27 Feb 1995 09:39:36 PST From: Steve Deering Message-Id: <95Feb27.093942pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I got several private messages suggesting that we *not* hold an implementors' meeting in Danvers because: (a) the time would be better spent actually doing some implementation, so maybe *next* time we'll have some implementation issues to talk about. (b) there is an impression that protocol decisions are being made in the "back room" implementors' meeting, decisions that are properly made in a Working Group meeting or over the mailing list. Certainly the previous meetings have been spent more on discussing protocol issues than implementation issues, due to the lack of much real implementation experience and the incompleteness of the specs. I expect both of those factors to be much improved after Danvers, but not before. (c) most of the people doing the actual coding on the few implementations that have been publically reported will not be able to make it on either the Sunday before or the Friday at the end of the IETF week. These arguments sound reasonable to Ross and me, so we have decided not to schedule an implementors' meeting this time. You can all spend the pre-IETF Saturday working on your code, rather than flying to Boston. :-) We have asked for 3 IPng WG slots during the week (not including ngtrans or addrconf meetings). Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 10:05:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10219; Mon, 27 Feb 95 10:05:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10213; Mon, 27 Feb 95 10:05:01 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12213; Mon, 27 Feb 1995 09:57:48 -0800 Received: from access1.digex.net by Sun.COM (sun-barr.Sun.COM) id AA15055; Mon, 27 Feb 95 09:57:38 PST Received: from houston_cc_smtp.hai-net.com by access1.digex.net with SMTP id AA15695 (5.67b8/IDA-1.5 for ); Mon, 27 Feb 1995 12:19:15 -0500 Received: from cc:Mail by houston_cc_smtp.hai-net.com id AA793916526; Mon, 27 Feb 95 12:15:58 EST Date: Mon, 27 Feb 95 12:15:58 EST From: sharborth@hai-net.com Message-Id: <9501277939.AA793916526@houston_cc_smtp.hai-net.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re[2]: (IPng) Proposed Standard or no? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM You are right I did not look at the all of the references before speaking. I was thinking along the lines of "out-of-band" negotiations being done via courier as Ran noted in his 2:03 pm message of 25 February. Also, I do currently use systems which use "out-of-band" couriers for distribution of keymat and the equipment also does in-band key management for distribution of key. Skip _______________________________________________________________________________ Subject: Re: (IPng) Proposed Standard or no? From: ipng@sunroof.Eng.Sun.COM at internet Date: 26-02-95 13:40 sharborth@hai-net.com says: > Allow both. Don't mandate the use of one over the other. In > systems which are in use today we use both methods, I would suspect > each equally (at least from my experience over the past 12 years in > secure communications system design & implementation.) I suspect that you don't understand what is being discussed -- I'm not trying to insult you here, its just that the conversation is being couched in very deceptive terms. You probably are not using either method today, and very likely not both. The terminology is very odd -- I suggest that you read all the drafts in question in order to really get a feel for what is being discussed. The topic boils down to this: do we want to permit for conveying key management information in IPSP packets instead of in, say, separate UDP packets. The argument being made on our side is "it won't give you any performance and messes up a very clean design, making it far harder to implement for negligible gain". The argument on their side boils down to "we get to save a whole packet at the beginning of each of your TCP sessions, and it means you get to rekey on every packet!" Neither of these particularly seem to be important to me. In the end, this comes down to whether you feel SKIP should be the key management protocol we use -- the changes are being requested purely to support SKIP, because Ashar seems to have painted himself into a corner in which he assured us all along that he could adapt SKIP to the proposed IPSP design and then realized only in the last week (it seems) that he needed functionality at the IPSP layer that wasn't available. One of the reasons a number of us have argued this discussion should be on the IPSEC list is because people on IPng lack the context of the discussion. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 11:38:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10349; Mon, 27 Feb 95 11:38:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10343; Mon, 27 Feb 95 11:38:33 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23649; Mon, 27 Feb 1995 11:31:21 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA02044; Mon, 27 Feb 95 11:30:33 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14543(2)>; Mon, 27 Feb 1995 11:30:00 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Mon, 27 Feb 1995 11:29:49 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng) IPng Working Group Last Calls Date: Mon, 27 Feb 1995 11:29:38 PST From: Steve Deering Message-Id: <95Feb27.112949pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As reported in the minutes of the IPng meeting at PARC, we identified a set of documents that we intend to submit to the IESG as Proposed Standards before the Danvers IETF. Most of the documents require some small changes, which were discussed and agreed to in the meeting, and the authors were given one to three weeks to make those changes and file updated drafts. Then for each of the documents, we are going to do a "Working Group Last Call", in which we ask the working group to review the documents for clarity, correctness, and completeness before we formally submit them to the IESG for consideration as Proposed Standards. The IESG will then do an IETF-wide Last Call. We'd like to start the WG Last Call process now (i.e., the "T" in Allison's timetable equals Feb 27). The following two documents are ready for WG final review; please post any comments or corrections to the ipng mailing list within ONE WEEK, i.e., by March 6: An Architecture for IPv6 Unicast Address Allocation draft-ietf-ipngwg-arch-addr-01.txt An IPv6 Global Unicast Address Format draft-ietf-ipngwg-address-format-01.txt (NOTE: this is *not* an invitation to engage in the "provider-based addressing is evil" discussion. Note the word "An" at the beginning of the titles of the above documents -- these documents specify *one* IPng unicast addressing architecture and format (the only one that happens to be fully specified at the moment, and the only one with which there is any related operational experience [CIDR]); alternative addressing architectures and formats may and, we hope, will be specified in the future, at which point they will go through the same process of WG review.) Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 12:04:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10377; Mon, 27 Feb 95 12:04:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10249; Mon, 27 Feb 95 10:50:31 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17732; Mon, 27 Feb 1995 10:43:18 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB22061; Mon, 27 Feb 95 10:37:12 PST Received: by netcomsv.netcom.com with UUCP (8.6.9/SMI-4.1) id JAA13626; Mon, 27 Feb 1995 09:27:36 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA793905458 Mon, 27 Feb 95 09:17:38 Date: Mon, 27 Feb 95 09:17:38 From: "Housley, Russ" Encoding: 1420 Text Message-Id: <9501277939.AA793905458@spysouth.spyrus.com> To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net, Danny.Nessett@Eng (Dan Nessett) Subject: (IPng) Re: out-of-band key management is like virtual circuits Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi Dan. In IEEE 802.10, when we were developing the Secure Data Exchange (SDE) Protocol, this same "in-line" key issue surfaced. It was resolved in a manner that has not been considered by the IETF. The solution has pros and cons, but I think that it should be considered before a decision is made. SDE has a 32-bit SAID that is followed by an optional field, called the Management Defined Field (MDF). DEC pushed very hard for this field because they wanted the SAID to identifiy a Master Key that would be used to decrypt the contents of the MDF. The MDF carried the key or keys to decrypt and/or check the integrity of the payload. SKIP is the same idea. SKIP sderives the Master Key using D-H key agreement instead of out-of-band master key distribution. This alternative would permit the approach advocated by DEC, and it would accompdate the SKIP approach. Using a bit in the SAID to indicate the presence/absence of the MDF (or whatever we call it for IPSP) would avoid the need for a key management protocol to negotiate the attributes for the security association. Perhaps a reserved SAID would indicate that the key management technique used by SKIP should be used to generate the key to decrypt the MDF. I just do not see why we cannot architect an IP layer security protocol that permits both types of key management. More food for thought.... Russ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 12:55:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10411; Mon, 27 Feb 95 12:55:32 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10405; Mon, 27 Feb 95 12:55:20 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA29224; Mon, 27 Feb 1995 12:48:12 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA29206; Mon, 27 Feb 1995 12:48:09 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA12299; Mon, 27 Feb 95 12:48:06 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA12834; Mon, 27 Feb 95 12:47:58 PST Received: by ns.incog.com (8.6.10/94082501) id MAA02083; Mon, 27 Feb 1995 12:47:51 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id MAA02068; Mon, 27 Feb 1995 12:47:47 -0800 Received: from miraj. (miraj.incog.com) by osmosys.incog.com (5.x/SMI-SVR4) id AA11529; Mon, 27 Feb 1995 12:47:00 -0800 Received: by miraj. (5.x/SMI-SVR4) id AA02314; Mon, 27 Feb 1995 12:44:48 -0800 Date: Mon, 27 Feb 1995 12:44:48 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9502272044.AA02314@miraj.> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net, perry@imsi.com X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Content-Length: 5742 Subject: Re: (IPng) Proposed Standard or no? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: "Perry E. Metzger" > The topic boils down to this: do we want to permit for conveying key > management information in IPSP packets instead of in, say, separate > UDP packets. The argument being made on our side is "it won't give you > any performance and messes up a very clean design, making it far > harder to implement for negligible gain". The argument on their side > boils down to "we get to save a whole packet at the beginning of each > of your TCP sessions, and it means you get to rekey on every packet!" > Neither of these particularly seem to be important to me. > > In the end, this comes down to whether you feel SKIP should be the key > management protocol we use -- the changes are being requested purely > to support SKIP, because Ashar seems to have painted himself into a > corner in which he assured us all along that he could adapt SKIP to > the proposed IPSP design and then realized only in the last week (it > seems) that he needed functionality at the IPSP layer that wasn't > available. Perry, As I have mentioned repeatedly (and as others have also mentioned), SKIP is not the only approach that uses in-band communication of keys. The reason I asked if IPSP could support SKIP is because there was some ambiguity of what can and cannot be in IPSP. Ran and you believe that the current IPSP doesn't support it, whereas Bill Simpson though that it wasn't precluded. No, it doesn't in the end come down to whether you feel SKIP should be the key-management protocol we use. The changes accommodate key-management techniques that have nothing to do with SKIP. It comes down to whether SKIP (or, e.g. DEC style key-management) can be an *option* to consider later on. Precluding particular styles of key-mgmt when we haven't yet decided on which key-mgmt technique to use is not a good idea. I have since the Toronto meeting asked for in-band key-mgmt. It was in both my presentations (independent of SKIP) and this was on a slide that was put up on the projector in both talks (despite claims to the contrary). Check out the "Precursor to SKIP" slide that gives a picture of in-band key-mgmt, and states that IPSP should support this mode of operation. The Toronto slides should still be ftp available from ftp.network.com, and if you have hard copies from the San Jose talks it should be in there. This is not something that I came up with in the last few weeks, and it shouldn't be presented as such. This doesn't lock us into any one kind of key-mgmt and it shouldn't be presented as such. And please don't trivialize the argument to saving one packet in the beginning of a TCP connection. The DEC folks had sound engineering reasons for doing in-band key-mgmt and we had some real engineering concerns that led us to do something similar. These issues/concerns have been presented before, are in the slides, in the mail archives, and don't need be rehashed over and over. I agree with Russ, Dan, Jim, Tom, Piper, Bob Moskowitz and others who believe that we shouldn't be precluding any viable kind of key-mgmt option. Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 14:10:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10457; Mon, 27 Feb 95 14:10:50 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10451; Mon, 27 Feb 95 14:10:39 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA00614; Mon, 27 Feb 1995 14:03:30 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA00580; Mon, 27 Feb 1995 14:03:24 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA17091; Mon, 27 Feb 95 14:03:22 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB23502; Mon, 27 Feb 95 14:03:20 PST Received: by ns.incog.com (8.6.10/94082501) id NAA03267; Mon, 27 Feb 1995 13:48:51 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id NAA03252; Mon, 27 Feb 1995 13:48:49 -0800 Received: from miraj. (miraj.incog.com) by osmosys.incog.com (5.x/SMI-SVR4) id AA12360; Mon, 27 Feb 1995 13:48:05 -0800 Received: by miraj. (5.x/SMI-SVR4) id AA02352; Mon, 27 Feb 1995 13:45:53 -0800 Date: Mon, 27 Feb 1995 13:45:53 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9502272145.AA02352@miraj.> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Content-Length: 4584 Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: "Perry E. Metzger" > A session is a lump of data sitting in memory. It isn't a bunch of > phone linemen with trucks. Our connections are "virtual"; they are > just state. From what I can tell, SKIP forces you to cache a bunch of > data, and other proposals do, too. As soon as you start having to keep > track of data, you aren't stateless and thats all that > counts. "Sessions" are a red herring. The question is state, and you > have it just like all the other proposals. You can't avoid it. Perry, I disagree (which by now shouldn't be a surprise). E-mail and IP are session-less. I can send you IP packets or e-mail regardless of whether your node is up or down (you may not receive them but that's a different story). I cannot establish a TCP or X.25 connection with you if your node is unavailable. Now, with SKIP I can establish and change keys, even if your node is down. With other session oriented key-mgmt schemes this cannot be done. It is in this sense that SKIP is stateless and session less and operates essentially like IP. The cache of information that SKIP maintains is similarly session less (as e.g. information about what the remote node's IP address is session-less, but per VCI X.25 information is not). SKIP cached information is good across reboots. The information that some of the other key-mgmt protocols maintain (e.g. session keys) is not good across reboots. This means public-key operations always have to be done after reboots, but with SKIP they only have to be done once. These are important distinctions. > > Yes, but we are not talking about a security protocol just for TCP. > > Thats completely irrelevant. You just put an inactivity timer on your > SA structures and they clean themselves up. Bit deal. > > ShowMe is a very heavyweight application -- you get data packets from > it on a constant basis. I would expect, then, that the half-open state > problem would not be a problem -- a two minute inactivity timer on > your state would easily handle the problem. No, it wouldn't. ShowMe will send video regardless of whether the remote node is up or down. There will be no inactivity, and so the inactivity timer will never go off. Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 15:04:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10489; Mon, 27 Feb 95 15:04:40 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10483; Mon, 27 Feb 95 15:04:28 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA02050; Mon, 27 Feb 1995 14:57:20 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA02032; Mon, 27 Feb 1995 14:57:16 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA19806; Mon, 27 Feb 95 14:57:15 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA04273; Mon, 27 Feb 95 14:57:05 PST Received: by ns.incog.com (8.6.10/94082501) id OAA04753; Mon, 27 Feb 1995 14:57:26 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id OAA04735; Mon, 27 Feb 1995 14:57:24 -0800 Received: from miraj. (miraj.incog.com) by osmosys.incog.com (5.x/SMI-SVR4) id AA13039; Mon, 27 Feb 1995 14:56:41 -0800 Received: by miraj. (5.x/SMI-SVR4) id AA02374; Mon, 27 Feb 1995 14:54:30 -0800 Date: Mon, 27 Feb 1995 14:54:30 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9502272254.AA02374@miraj.> To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Content-Length: 3349 Subject: Re: (IPng) out-of-band key management is like virtual circuits Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: "Perry E. Metzger" > You have to have upcalls from your kernel to deal with structured > SAIDs, and you have to deal with different types of these structured > SAIDs -- of course, you've only implemented the ones for SKIP, but > what happens when someone else wants to use these structured SAIDs for > some purpose? At which point, of course, the kernel has to distinguish > between them and start building a switch table to decide where to do > the upcall to. Of course it all can be done -- but its more > complex. Its also less modular. Without this stuff, you can replace > key management without any kernel manipulation at all. Perry, I don't understand this argument at all. Allowing the *possibility* for someone else to implement a particular kind of key-mgmt technique doesn't force you to do any kernel manipulations at all. The way the DEC scheme works, the key-manipulations happen in hardware, not even in the kernel. If someone implements that, then they have the hardware to do that. If not, then they don't do anything. Nobody is forcing you do implement any particular scheme in the kernel. Those of us who want to implement a particular scheme will have the right combination of software and hardware to do that. And it's really not as complex as you are making it out to be. Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 15:22:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10507; Mon, 27 Feb 95 15:22:23 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10501; Mon, 27 Feb 95 15:22:16 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA02635; Mon, 27 Feb 1995 15:15:07 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA02605; Mon, 27 Feb 1995 15:15:03 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA21331; Mon, 27 Feb 95 15:15:02 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA06445; Mon, 27 Feb 95 15:14:59 PST Received: by ns.incog.com (8.6.10/94082501) id PAA05158; Mon, 27 Feb 1995 15:14:39 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id PAA05143; Mon, 27 Feb 1995 15:14:35 -0800 Received: from monster.incog.com by osmosys.incog.com (5.x/SMI-SVR4) id AA13202; Mon, 27 Feb 1995 15:13:52 -0800 Received: by monster.incog.com (5.x/SMI-SVR4) id AA04067; Mon, 27 Feb 1995 15:14:13 -0800 From: markson@icgmail.Eng.Sun.COM (Tom Markson) Message-Id: <9502272314.AA04067@monster.incog.com> To: perry@imsi.com Date: Mon, 27 Feb 1995 15:14:13 -0800 (PST) Cc: ashar@icgmail.Eng.Sun.COM, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net In-Reply-To: <9502272104.AA07901@snark.imsi.com> from "Perry E. Metzger" at Feb 27, 95 04:04:14 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text X-Icg-Mailfrom: markson@icgmail.eng.sun.com Content-Length: 2114 Subject: Re: (IPng) Proposed Standard or no? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >[Perry Metzger writes:] > I'm not aware that we are precluding any viable option -- including a > slightly modified SKIP. What we are precluding is pre-assigned SAIDs > and all the kernel muck that would be associated with processing them. I don't understand this argument. If the host implements in-band key management, then it will use the "structured" bit in the SAID. If it doesn't, it can safely ignore it. I don't understand how this will create muck in the kernel. --tom ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 15:39:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10541; Mon, 27 Feb 95 15:39:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10535; Mon, 27 Feb 95 15:39:26 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17387; Mon, 27 Feb 1995 15:32:10 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA10016; Mon, 27 Feb 95 15:31:55 PST Received: from relay.imsi.com by wintermute.imsi.com id RAA14385; Mon, 27 Feb 1995 17:33:52 -0500 Received: from snark.imsi.com by relay.imsi.com id RAA12293; Mon, 27 Feb 1995 17:33:51 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA08013; Mon, 27 Feb 95 17:33:08 EST Message-Id: <9502272233.AA08013@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Mon, 27 Feb 1995 13:45:53 PST." <9502272145.AA02352@miraj.> X-Reposting-Policy: redistribute only with permission Date: Mon, 27 Feb 1995 17:33:07 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ashar Aziz says: > Now, with SKIP I can establish and change keys, even if your > node is down. With other session oriented key-mgmt schemes > this cannot be done. One wonders of the utility of establishing a key for use with a host that isn't up. > It is in this sense that SKIP is stateless SKIP is emphatically NOT stateless -- at least not if it performs remotely well. As I've noted, unless you are going to do a key lookup in a key database for every packet that comes in, you are going to have to cache just as much state as everyone else. > SKIP cached information is good across reboots. > > The information that some of the other key-mgmt protocols maintain > (e.g. session keys) is not good across reboots. Why wouldn't it be? You say that if you have NVRAM you can do this miraculous preservation of SKIP cached information across reboots, but as I've noted, if you actually had nonvolitile ram to cache security association information in across reboots, there would be no reason any other key management protocol couldn't maintain state, too. Furthermore, reboots are an extremely unusual circumstance, and I don't think that maintaining associations across reboots is going to impact reboot times as much as, say, file system consistancy checks. (By the way, my routers typically are rebooted on the order of once a year or less.) > > > Yes, but we are not talking about a security protocol just for TCP. > > > > Thats completely irrelevant. You just put an inactivity timer on your > > SA structures and they clean themselves up. Bit deal. > > > > ShowMe is a very heavyweight application -- you get data packets from > > it on a constant basis. I would expect, then, that the half-open state > > problem would not be a problem -- a two minute inactivity timer on > > your state would easily handle the problem. > No, it wouldn't. ShowMe will send video regardless of whether > the remote node is up or down. There will be no inactivity, and so > the inactivity timer will never go off. The inactivity timer is at the RECEIVER, not at the SOURCE. Security associations are different in each direction. .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 15:40:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10553; Mon, 27 Feb 95 15:40:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10542; Mon, 27 Feb 95 15:39:44 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17467; Mon, 27 Feb 1995 15:32:31 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB10016; Mon, 27 Feb 95 15:32:19 PST Received: from relay.imsi.com by wintermute.imsi.com id QAA13952; Mon, 27 Feb 1995 16:04:58 -0500 Received: from snark.imsi.com by relay.imsi.com id QAA11609; Mon, 27 Feb 1995 16:04:58 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA07901; Mon, 27 Feb 95 16:04:15 EST Message-Id: <9502272104.AA07901@snark.imsi.com> To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? In-Reply-To: Your message of "Mon, 27 Feb 1995 12:44:48 PST." <9502272044.AA02314@miraj.> X-Reposting-Policy: redistribute only with permission Date: Mon, 27 Feb 1995 16:04:14 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ashar Aziz says: > > As I have mentioned repeatedly (and as others have also mentioned), > SKIP is not the only approach that uses in-band communication > of keys. The reason I asked if IPSP could support SKIP is because > there was some ambiguity of what can and cannot be in IPSP. Ran > and you believe that the current IPSP doesn't support it, whereas > Bill Simpson though that it wasn't precluded. > Actually, I have no opinion on whether IPSP can or cannot support SKIP. At Toronto, you said that there was no problem in changing your packet format to match IPSP. At San Jose, you didn't indicate that you had a problem with the packet format. After Bill Simpson made it clear that the amount of time left for comments was limited a couple of weeks ago, you first mentioned this need to convey key management information inside IPSP packets and you asked if we could structure SAIDs. You never said you wanted that before. If you did say so, it isn't in the archives of the mailing list I just searched, and it isn't in any of my notes from the meetings. > I have since the Toronto meeting asked for in-band key-mgmt. "In Band" is an ambiguous term. What we are talking about is sending key management data in IPSP packets with special reserved SAIDs instead of in their own packets -- nothing more. My recollection is that you said that you had no problem with IPSP on several occassions. > And please don't trivialize the argument to saving one packet in > the beginning of a TCP connection. The DEC folks had sound engineering > reasons for doing in-band key-mgmt Yeah; they had a patented high speed hardware DES chip that took the key at the head of the data to be decrypted, so it gave them a nice market advantage. > and we had some real engineering concerns that led us to do > something similar. > I agree with Russ, Dan, Jim, Tom, Piper, Bob Moskowitz and > others who believe that we shouldn't be precluding any viable > kind of key-mgmt option. I'm not aware that we are precluding any viable option -- including a slightly modified SKIP. What we are precluding is pre-assigned SAIDs and all the kernel muck that would be associated with processing them. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 15:59:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10717; Mon, 27 Feb 95 15:59:02 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10711; Mon, 27 Feb 95 15:58:50 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA04081; Mon, 27 Feb 1995 15:51:42 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA04062; Mon, 27 Feb 1995 15:51:35 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AB24836; Mon, 27 Feb 95 15:51:32 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AB14281; Mon, 27 Feb 95 15:47:36 PST Received: by ns.incog.com (8.6.10/94082501) id PAA06244; Mon, 27 Feb 1995 15:42:18 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id PAA06229; Mon, 27 Feb 1995 15:42:16 -0800 Received: from miraj. (miraj.incog.com) by osmosys.incog.com (5.x/SMI-SVR4) id AA13580; Mon, 27 Feb 1995 15:41:33 -0800 Received: by miraj. (5.x/SMI-SVR4) id AA02389; Mon, 27 Feb 1995 15:39:21 -0800 Date: Mon, 27 Feb 1995 15:39:21 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9502272339.AA02389@miraj.> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Content-Length: 2874 Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: "Perry E. Metzger" > > No, it wouldn't. ShowMe will send video regardless of whether > > the remote node is up or down. There will be no inactivity, and so > > the inactivity timer will never go off. > > The inactivity timer is at the RECEIVER, not at the SOURCE. Security > associations are different in each direction. But the session key that needs to be blown away is at the source. The receiver has no state left of that association when it reboots, so how will inactivity timeouts on the receiver help? The receiver will simply be seeing encrypted traffic coming in over a SAID that it has no information on, and it will need to somehow tell the sender (securely) to blow that association away. The receiver will not have an inactivity timer for an association that it knows nothing about. Responding to the other parts of your message would entail rehashing arguments that have already been made, and I will spare the lists this rehash. Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 16:43:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10813; Mon, 27 Feb 95 16:43:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10807; Mon, 27 Feb 95 16:43:24 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28770; Mon, 27 Feb 1995 16:36:14 -0800 Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA27070; Mon, 27 Feb 95 16:36:09 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA21390; Mon, 27 Feb 95 10:07:04 -0800 Received: by xirtlu.zk3.dec.com; id AA03556; Mon, 27 Feb 1995 13:05:01 -0500 Message-Id: <9502271805.AA03556@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM, ipspec@ans.net Subject: (IPng) Joining the IPSEC mail list Date: Mon, 27 Feb 95 13:04:55 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi anyone, Can someone post how we join ipsec mail list so IPv6ers who now need to do that can (like me). I am sure the IPv6 security work will end up in this WG in the seucurity area after Danvers. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 17:11:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10852; Mon, 27 Feb 95 17:11:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10846; Mon, 27 Feb 95 17:11:04 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02835; Mon, 27 Feb 1995 17:03:53 -0800 Received: from alink-gw.apple.com by Sun.COM (sun-barr.Sun.COM) id AA04889; Mon, 27 Feb 95 17:03:29 PST Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA01978; Mon, 27 Feb 95 11:17:39 -0800 for ipng@sunroof.eng.sun.com Received: from lilith.lansys.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef) id AA20379; Mon, 27 Feb 1995 11:16:15 +0800 for ipng@sunroof.eng.sun.com Received: (justin@localhost) by lilith.lansys.apple.com (8.6.9/A/UX 3.1) id LAA08543; Mon, 27 Feb 1995 11:17:40 -0800 Date: Mon, 27 Feb 1995 11:17:40 -0800 From: "Justin C. Walker" Message-Id: <199502271917.LAA08543@lilith.lansys.apple.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM, danmcd@sundance.itd.nrl.navy.mil, atkinson@sundance.itd.nrl.navy.mil In-Reply-To: bound@zk3.dec.com's message of Sat, 25 Feb 95 08:58:06 -0500 <9502251358.AA22949@xirtlu.zk3.dec.com> Subject: (IPng) Comments on Palo Alto meeting notes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> Performance I think should be the number 1 requirement. How system >> discovery would work with non-broadcast datalink is unclear to me anyway >> at this time. Which may be the issue for the WG? And an architetural >> issue for all implementors? I'm a little uneasy with putting such a high premium on performance, especially when we are working on only one piece of the system". For example, we've gone to great lengths to get the IPv6 packet definition to wind up on 64-bit boundaries, but my ethernet adapter (probably with the same kind of "performance first" mentality of its designers) is forcing my receive buffers to align on 32-bit boundaries. Given that the datalink headers are 14 (or, in the case of those benighted IEEE types :-}, 22 bytes), it looks to me like the IPv6 packets wind up on 16-bit boundaries. Performance is important, but what affects performance (from the engineering perspective) changes so rapidly, and involves so many other pieces, that protocol design should not be slaved to it. a note of caution from the fringes... Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple Business Systems | of boredom Apple Computer, Inc. | For trying to change the system 10500 North De Anza Blvd | from within Cupertino, CA 95014 | LC *---------------------------------------*------------------------------------* ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 17:45:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10901; Mon, 27 Feb 95 17:45:49 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10895; Mon, 27 Feb 95 17:45:42 PST Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id RAA07566; Mon, 27 Feb 1995 17:38:30 -0800 Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id RAA25744; Mon, 27 Feb 1995 17:38:20 -0800 Date: Mon, 27 Feb 1995 17:38:20 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199502280138.RAA25744@elrond.Eng.Sun.COM> To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Russ, Thanks for the information on SDE. It sounds like these issues have been thoroughly discused in other forums. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 17:53:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10913; Mon, 27 Feb 95 17:53:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10907; Mon, 27 Feb 95 17:53:15 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08426; Mon, 27 Feb 1995 17:46:04 -0800 Received: from columbia.sparta.com (bugs_bunny.columbia.SPARTA.COM) by Sun.COM (sun-barr.Sun.COM) id AA17120; Mon, 27 Feb 95 17:46:00 PST Received: from [157.185.80.232] (muckintosh.columbia.SPARTA.COM) by columbia.sparta.com (4.1/SMI-4.1) id AA04812; Mon, 27 Feb 95 20:44:19 EST X-Sender: cfm@bugs.columbia.sparta.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Feb 1995 20:44:27 -0500 To: ashar@osmosys.incog.com (Ashar Aziz), ipng@sunroof.Eng.Sun.COM, ipsec@ans.net From: cfm@columbia.sparta.com (Carl F. Muckenhirn) Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 1:45 PM 2/27/95, Ashar Aziz wrote: >> From: "Perry E. Metzger" >> A session is a lump of data sitting in memory. It isn't a bunch of >> phone linemen with trucks. Our connections are "virtual"; they are >> just state. From what I can tell, SKIP forces you to cache a bunch of >> data, and other proposals do, too. As soon as you start having to keep >> track of data, you aren't stateless and thats all that >> counts. "Sessions" are a red herring. The question is state, and you >> have it just like all the other proposals. You can't avoid it. > >Perry, > >I disagree (which by now shouldn't be a surprise). E-mail and >IP are session-less. I can send you IP packets or e-mail regardless >of whether your node is up or down (you may not receive them >but that's a different story). I cannot establish a TCP or >X.25 connection with you if your node is unavailable. This is an interesting approach, session(connection)less e-mail (I assume not SMTP, POP, MMDF, X.400). Ignoring that, of what use it it sending IP datagrams to me if I can't recieve them. Who is sending them and why? A DNS query, well I believe that it will timeout (at the UDP level but it will still time-out), how about NTP, well same thing. In both of these cases there is no harm (that's how they're designed to work) but I can't see how this helps SKIP. > >Now, with SKIP I can establish and change keys, even if your >node is down. With other session oriented key-mgmt schemes >this cannot be done. It is in this sense that SKIP is stateless >and session less and operates essentially like IP. The cache of >information that SKIP maintains is similarly session less >(as e.g. information about what the remote node's IP address is >session-less, but per VCI X.25 information is not). SKIP >cached information is good across reboots. What good was it to change keys if I can't receive the packet? How do the "out-of-band" key management protocols suffer from not being able to change keys when their peer is unavailable? (other than that they will know with higher assurance that they peer is unavailable). And why is the SKIP information session-less? I believe that the master key needs to be rekeyed periodically (at least I hope it is), will this change at the same (spritely) pace as IP addresses? How frequent are the cases where one of the parties will be down when the other needs to send this (obviously) time critical information (we can't wait for the key to be set up), and if it is so critical that the information not be delayed, don't we want to know that the peer is down? > >The information that some of the other key-mgmt protocols maintain >(e.g. session keys) is not good across reboots. This means public-key >operations always have to be done after reboots, but with SKIP they >only have to be done once. These are important distinctions. > Why is it that SKIP can cache "security information" and other approaches can't? I don't believe that any of the other key mgmt protocols proposed to date actually specify volatile storage of keys, and if this is really such a problem we can always add that to the approach. >> > Yes, but we are not talking about a security protocol just for TCP. >> >> Thats completely irrelevant. You just put an inactivity timer on your >> SA structures and they clean themselves up. Bit deal. >> >> ShowMe is a very heavyweight application -- you get data packets from >> it on a constant basis. I would expect, then, that the half-open state >> problem would not be a problem -- a two minute inactivity timer on >> your state would easily handle the problem. > >No, it wouldn't. ShowMe will send video regardless of whether >the remote node is up or down. There will be no inactivity, and so >the inactivity timer will never go off. > This is good? I thought that bandwidth was a fairly precious resource. And it doesn't really apply in the case we are talking about. If ShowMe is running using Photuris (for example) as its key management protocol, and the distant end dies, it just dies. Phouris only comes to play when someone (daemon?) decides it is time to rekey, if that's 8 hours from now, well then we discover that foobar.mars.com is fubar and we stop clogging the Internet with videograms. With SKIP we go on until god knows when. >Regards, >Ashar. The more I think about SKIP, the more my initial impression is reinforced. Specifically, that SKIP addresses the easy part, I know something about the distant end and want to "securely" exchange a key with him. But it glosses over the hard part, how to get that "something" in place securely at both ends. If there is any real difference between "out-of-band" and "in-band" methods it is of degree and not kind. One thing that has somewhat troubled me about SKIP (and I'll admit I haven't implemented it yet) is with "in-band" traffic, I need to change the way IP works (it appears as a new option, functionally) which will incur some (admittedly small) overhead on each packet processed. How does this overhead compare with the "out-of-band" overhead of a separate "connection"? carl. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 19:53:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11013; Mon, 27 Feb 95 19:53:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11007; Mon, 27 Feb 95 19:53:37 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18681; Mon, 27 Feb 1995 19:46:25 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA14766; Mon, 27 Feb 95 19:46:14 PST Received: from relay.imsi.com by wintermute.imsi.com id WAA16181; Mon, 27 Feb 1995 22:44:53 -0500 Received: from snark.imsi.com by relay.imsi.com id WAA15164; Mon, 27 Feb 1995 22:44:52 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA08316; Mon, 27 Feb 95 22:44:07 EST Message-Id: <9502280344.AA08316@snark.imsi.com> To: markson@osmosys.incog.com (Tom Markson) Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? In-Reply-To: Your message of "Mon, 27 Feb 1995 15:14:13 PST." <9502272314.AA04067@monster.incog.com> X-Reposting-Policy: redistribute only with permission Date: Mon, 27 Feb 1995 22:44:06 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tom Markson says: > >[Perry Metzger writes:] > > I'm not aware that we are precluding any viable option -- including a > > slightly modified SKIP. What we are precluding is pre-assigned SAIDs > > and all the kernel muck that would be associated with processing them. > > I don't understand this argument. If the host implements in-band > key management, then it will use the "structured" bit in the SAID. If it > doesn't, it can safely ignore it. I don't understand how this will create > muck in the kernel. If you want to have the implementation of the bit be optional, that implies that SKIP is being proposed as an optional protocol. Does that imply that you guys are withdrawing from consideration as a SKIP as a proposed internet standard? Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 19:59:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11025; Mon, 27 Feb 95 19:59:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11019; Mon, 27 Feb 95 19:58:59 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18979; Mon, 27 Feb 1995 19:51:48 -0800 Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA15638; Mon, 27 Feb 95 19:51:45 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 28 Feb 95 12:49:43 +0900 From: Masataka Ohta Message-Id: <9502280349.AA06711@necom830.cc.titech.ac.jp> Subject: Re: (IPng) IPng Working Group Last Calls To: ipng@sunroof.Eng.Sun.COM Date: Tue, 28 Feb 95 12:49:42 JST Cc: deering@parc.xerox.com In-Reply-To: <95Feb27.112949pst.12174@skylark.parc.xerox.com>; from "Steve Deering" at Feb 27, 95 11:29 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > An Architecture for IPv6 Unicast Address Allocation > draft-ietf-ipngwg-arch-addr-01.txt > > An IPv6 Global Unicast Address Format > draft-ietf-ipngwg-address-format-01.txt > > (NOTE: this is *not* an invitation to engage in the "provider-based > addressing is evil" discussion. Note the word "An" at the beginning > of the titles of the above documents -- Could you refrain from playing with wordings in the face of a lot of non-native English users? > these documents specify *one* > IPng unicast addressing architecture and format Such a statement is applicable to every document which is expected to be "A" proposed standard. Note the word "A". Is anything special with the two documents? > (the only one that > happens to be fully specified at the moment, and the only one with > which there is any related operational experience [CIDR]); Proposed standard should be considered to be defect free, shouldn't it? Now, we are discussing that the proposal is defective. Isn't it a sufficient reason to stop the standardization? You can continue to use the proposal even if it is not given a status of a proposed standard. > alternative > addressing architectures and formats may and, we hope, will be specified > in the future, at which point they will go through the same process of > WG review.) I don't think it takes a lot of time to have a defect free ones. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 20:03:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11042; Mon, 27 Feb 95 20:03:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11036; Mon, 27 Feb 95 20:03:36 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19205; Mon, 27 Feb 1995 19:56:24 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA16187; Mon, 27 Feb 95 19:56:17 PST Received: from relay.imsi.com by wintermute.imsi.com id WAA16231; Mon, 27 Feb 1995 22:56:16 -0500 Received: from snark.imsi.com by relay.imsi.com id WAA15270; Mon, 27 Feb 1995 22:56:16 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA08338; Mon, 27 Feb 95 22:55:29 EST Message-Id: <9502280355.AA08338@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of "Mon, 27 Feb 1995 15:39:21 PST." <9502272339.AA02389@miraj.> X-Reposting-Policy: redistribute only with permission Date: Mon, 27 Feb 1995 22:55:29 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ashar Aziz says: > > From: "Perry E. Metzger" > > > No, it wouldn't. ShowMe will send video regardless of whether > > > the remote node is up or down. There will be no inactivity, and so > > > the inactivity timer will never go off. > > > > The inactivity timer is at the RECEIVER, not at the SOURCE. Security > > associations are different in each direction. > > But the session key that needs to be blown away is at the source. > > The receiver has no state left of that association when it reboots, > so how will inactivity timeouts on the receiver help? It will help if the source goes away. If the receiver goes away, the source will get an ICMP message the next time it tries to send on an invalid SAID and the SAID will go away. (I'm contemplating a handshaking design to make denial of service attacks hard to mount by sending random ICMPs.) You have inactivity timers on both sides, by the way -- I was just addressing the ShowMe example. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 21:42:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11271; Mon, 27 Feb 95 21:42:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10183; Mon, 27 Feb 95 09:32:57 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09052; Mon, 27 Feb 1995 09:25:45 -0800 Received: from carmen.logica.co.uk by Sun.COM (sun-barr.Sun.COM) id AA10451; Mon, 27 Feb 95 09:25:26 PST Received: from smtpmail.logica.com (mssmtp.logica.com) by carmen.logica.co.uk (4.1/SMI-4.1) id AA16486; Mon, 27 Feb 95 17:26:32 GMT Received: by smtpmail.logica.com with Microsoft Mail id <2F52195F@smtpmail.logica.com>; Mon, 27 Feb 95 17:26:39 gmt From: Fieldhouse Dirk To: 'IPng mailing list' Subject: Re: (IPng) Re: ICMP name query messages Date: Mon, 27 Feb 95 17:19:00 gmt Message-Id: <2F52195F@smtpmail.logica.com> Encoding: 26 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM writes: > To: ipng > Cc: namedroppers > Subject: Re: (IPng) Re: ICMP name query messages > Date: 23 February 1995 09:56 > > "William Allen Simpson" writes: > > You cannot receive a multicast for an address you have not explicitly > > joined. If you have already joined the group (learned its address from > > its name), why would you ask the name of the group? > > How about if you inherted a socket accross a fork/exec and you want > to figure out the name associated with an address? Surely this is a local issue? The necessary information ought to be stored with the socket and accessible via a structure access or an ioctl-ish API. Fix the API before quoting this as a reason for inventing protocols. Dirk Fieldhouse Logica UK Limited fieldhouse@logica.com 68 Newman St c=gb;a=tmailuk;p=logica; London W1A 4SE o=lg;ou1=lgwct;s=fieldhouse UK +44 (171) 637 9111 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 27 23:20:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11326; Mon, 27 Feb 95 23:20:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11320; Mon, 27 Feb 95 23:20:39 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27609; Mon, 27 Feb 1995 23:13:26 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AB10773; Mon, 27 Feb 95 23:13:28 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18014; Tue, 28 Feb 1995 08:13:26 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA02762; Tue, 28 Feb 1995 08:13:24 +0100 Message-Id: <9502280713.AA02762@dxcoms.cern.ch> Subject: Re: (IPng) IPng Working Group Last Calls To: ipng@sunroof.Eng.Sun.COM Date: Tue, 28 Feb 1995 08:13:24 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <95Feb27.112949pst.12174@skylark.parc.xerox.com> from "Steve Deering" at Feb 27, 95 11:29:38 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > An Architecture for IPv6 Unicast Address Allocation > draft-ietf-ipngwg-arch-addr-01.txt > > An IPv6 Global Unicast Address Format > draft-ietf-ipngwg-address-format-01.txt > I support an immediate move to PS for these two documents. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 28 05:03:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11646; Tue, 28 Feb 95 05:03:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11640; Tue, 28 Feb 95 05:03:35 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08495; Tue, 28 Feb 1995 04:56:24 -0800 Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA14802; Tue, 28 Feb 95 04:56:22 PST Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.9/8.6.9) with ESMTP id HAA02029 for ; Tue, 28 Feb 1995 07:56:17 -0500 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.9/8.6.9) with SMTP id HAA20460 for ; Tue, 28 Feb 1995 07:56:16 -0500 Received: from bobsgrid.is.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA16600; Tue, 28 Feb 95 08:11:38 EST Message-Id: <9502281311.AA16600@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Feb 1995 07:56:01 -0500 To: "William Allen Simpson" , "Michael A. Patton" From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: (IPng) Re: ICMP name persistence (of vision) Cc: ipng@sunroof.Eng.Sun.COM, namedroppers@rs.internic.net Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 11:04 AM 2/25/95 GMT, William Allen Simpson wrote: >> From: "Michael A. Patton" >> Putting on my network operator's hat for a minute, ... >> I frequently need to do this translation hours, >> days, or even months :-) after the fact. I realize that the longer >> it's been since a log was written, the less accurate the answer will >> be, but I can STILL GET AN ANSWER. If the only way to get an answer >> is from the users PC, I will usually be unable to get any answer at a >> random later time. >> >This is a truly amazing feat! Look at my received line above, which >contains my current address. Do a reverse lookup on it. So you still >get Bill.Simpson? Will you in "days, or even months"? > >I access the net exclusively through a dialup connection, as do 100,000 >others here at MichNet. How exactly do you "still get an answer", when >my address has changed about 7 times in the past 24 hours? And doesn't >exist at all when I am not dialed in? (I was actually connected about >90 minutes in the past 24 hours.) > >Have you actually read my draft? > >(This is not entirely aimed at you, as we have had several people with >the same bogus "I control my site through good tools and everybody else >should" response.) I apologize if my note made it appear all is rosy here. Building our in-addr helps some but not in all cases. For us DNS breaks around the edges. We have systems that need different names for different collections of interfaces. This would mean an A record occurs more than once and should result in multiple PTR records in IN-ADDR. Some of our BIG systems can have 6 or more interfaces. Some are for batch use only, some for interactive only some for either... We have 'Mobile Processes'. Major applications move to a different address, normally at noon or midnight. DYN-UPD with NOTIFY should help here. Yes we have two major systems in different states that trade off which applications they run. Load balancing is part of the reason, disaster recovery practise is another (How can you know you ca recover if you don't try REGULARLY), and some of think that operator whimsy is another (no that is really not fair. Those people really work hard). Of course we have dial up IP users. 1800 already and growing. Right now there is no registration for these users. Again DYN-UPD with NOTIFY should help. Or we may not secondary the dialup domain at all, thus eliminating the need of Notify. We also need load balancing on our multihomed hosts. VM is a particular problem right now. We are rapidly approaching the 2000 user limit for the address space. We could start up a second address space to gain another 2000 users, but then need to distribute the load. ROUND-ROBIN will help here. Ah the joys. We got a good team here, now if we just had some good code. We are further constrained in some cases to only using the UNIX vendor supplied BIND... Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 28 05:14:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11660; Tue, 28 Feb 95 05:14:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11652; Tue, 28 Feb 95 05:14:34 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09042; Tue, 28 Feb 1995 05:07:23 -0800 Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA15983; Tue, 28 Feb 95 05:07:22 PST Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.9/8.6.9) with ESMTP id IAA03766 for ; Tue, 28 Feb 1995 08:07:19 -0500 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.9/8.6.9) with SMTP id IAA20481 for ; Tue, 28 Feb 1995 08:07:18 -0500 Received: from bobsgrid.is.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA16671; Tue, 28 Feb 95 08:22:49 EST Message-Id: <9502281322.AA16671@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Feb 1995 08:07:12 -0500 To: ipng@sunroof.Eng.Sun.COM From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: (IPng) Gratuitous ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 10:30 AM 2/23/95 -0500, "Perry E. Metzger" wrote: > >"William Allen Simpson" says: >> The question for us: do we want to add Self Solicitation for discovery >> of duplicate addresses? >[...] >> I am of the opinion that it is not worth the bother. KRE has expressed >> the opposite view in the Apple Networking Forum. > >Less than three days ago, "self solicitation" saved my >buttocks. Someone brought up a second machine on an etherthernet with >the same IP address and had this feature not been in place a >production network would have been brought to its knees. I'm in favor >of any feature that has shown great operational utility, and this is >certainly one of them. Sorry I fell behind on this list again. Not quite a weeks worth... This has been a requirement here. Dup IPs occur dayly somewhere in our network. Fortunely our DOS stack now aborts with a message of the offending MAC address and our OPs people have ways of finding that address in the hub and turning that hub port off. Then the offender calls in that they lost their connection and things get straighten out (yes this fails sometimes, one user once misconfigured and the 'offender' was a NOVELL server...). But I HOPE that this all goes away with v6. The only risk that I have seen Identified is with Stateless address assignment and a duplicate MAC address within a topology. But then these devices should be having bigger problems, even in a bridged network!!! Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 28 12:19:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11916; Tue, 28 Feb 95 12:19:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11910; Tue, 28 Feb 95 12:19:11 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18226; Tue, 28 Feb 1995 12:11:57 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA27992; Tue, 28 Feb 95 12:08:31 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14633(2)>; Tue, 28 Feb 1995 12:07:47 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Tue, 28 Feb 1995 12:07:39 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, deering@parc.xerox.com Subject: (IPng) new Next Header values Date: Tue, 28 Feb 1995 12:07:33 PST From: Steve Deering Message-Id: <95Feb28.120739pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------- Forwarded Message Date: Tue, 28 Feb 1995 11:43:12 -0800 From: jkrey@isi.edu To: deering@parc.xerox.com Subject: Re: request for two new IP Protocol numbers Cc: iana@isi.edu Steve, Per your request, we have assigned the following IP Protocol numbers, with you as the point of contact: - "IPv6 ICMP" - 58 - "No Next Header" - 59 Joyce ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 28 12:30:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11928; Tue, 28 Feb 95 12:30:55 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11922; Tue, 28 Feb 95 12:30:47 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA17979; Tue, 28 Feb 1995 12:23:37 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA17961; Tue, 28 Feb 1995 12:23:34 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA18276; Tue, 28 Feb 95 12:23:32 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA00510; Tue, 28 Feb 95 12:22:25 PST Received: by ns.incog.com (8.6.10/94082501) id MAA27429; Tue, 28 Feb 1995 12:21:45 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id MAA27414; Tue, 28 Feb 1995 12:21:42 -0800 Received: from monster.incog.com by osmosys.incog.com (5.x/SMI-SVR4) id AA20660; Tue, 28 Feb 1995 12:20:58 -0800 Received: by monster.incog.com (5.x/SMI-SVR4) id AA04573; Tue, 28 Feb 1995 12:21:20 -0800 From: markson@icgmail.Eng.Sun.COM (Tom Markson) Message-Id: <9502282021.AA04573@monster.incog.com> To: perry@imsi.com Date: Tue, 28 Feb 1995 12:21:20 -0800 (PST) Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net In-Reply-To: <9502280344.AA08316@snark.imsi.com> from "Perry E. Metzger" at Feb 27, 95 10:44:06 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text X-Icg-Mailfrom: markson@icgmail.eng.sun.com Content-Length: 2419 Subject: Re: (IPng) Proposed Standard or no? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > If you want to have the implementation of the bit be optional, that > implies that SKIP is being proposed as an optional protocol. Does that > imply that you guys are withdrawing from consideration as a SKIP as a > proposed internet standard? > > Perry Obviously not. What I am saying (and have been saying) is that key management needs to be independent from IPSP. If the Structured SAID bit is not in IPSP, you are eliminating possible key management schemes. But you still haven't answered my original question. How does the structured SAID bit create muck in the kernel? If you are using a key management scheme that uses it, great. If you are not, you can ignore it. --tom ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 28 14:24:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12031; Tue, 28 Feb 95 14:24:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12025; Tue, 28 Feb 95 14:24:05 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00925; Tue, 28 Feb 1995 14:16:53 -0800 Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA22333; Tue, 28 Feb 95 14:16:39 PST Received: from imokay.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA15433; Tue, 28 Feb 1995 13:11:42 -0500 Received: by imokay.zk3.dec.com (5.57/MS-040293); id AA07460; Tue, 28 Feb 95 13:11:40 -0500 Received: by maniac.zk3.dec.com; id AA25940; Tue, 28 Feb 1995 13:11:48 -0500 Received: from localhost by capecod.zk3.dec.com; (5.65/1.1.2.4/28Feb95-1029AM) id AA01064; Tue, 28 Feb 1995 13:13:39 -0500 Message-Id: <9502281813.AA01064@capecod.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Joining the IPSEC mail list In-Reply-To: Your message of "Mon, 27 Feb 95 13:04:55 EST." <9502271805.AA03556@xirtlu.zk3.dec.com> Date: Tue, 28 Feb 95 13:13:38 -0500 From: Andy Bayerl X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, if you figure this out, could you let me know. I suspect that the ipsec list might be more focused towards what we in MLSland are doing. The ongoing IPv6 discussions are interesting but the volume quickly gets pretty overwhelming. /andy ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 28 14:30:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12046; Tue, 28 Feb 95 14:30:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12040; Tue, 28 Feb 95 14:30:42 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01637; Tue, 28 Feb 1995 14:23:30 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA23295; Tue, 28 Feb 95 14:21:36 PST Received: from relay.imsi.com by wintermute.imsi.com id RAA19569; Tue, 28 Feb 1995 17:19:00 -0500 Received: from snark.imsi.com by relay.imsi.com id RAA23908; Tue, 28 Feb 1995 17:19:00 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA09757; Tue, 28 Feb 95 17:18:54 EST Message-Id: <9502282218.AA09757@snark.imsi.com> To: markson@osmosys.incog.com (Tom Markson) Cc: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? In-Reply-To: Your message of "Tue, 28 Feb 1995 12:21:20 PST." <9502282021.AA04573@monster.incog.com> X-Reposting-Policy: redistribute only with permission Date: Tue, 28 Feb 1995 17:18:54 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tom Markson says: > But you still haven't answered my original question. How does the > structured SAID bit create muck in the kernel? You have to detect it and switch on it. Given that you guys are claiming that several schemes could use it, we presumably start having to keep kernel tables of what the various structured SAIDs mean so we can process them, and we start needing either kernel level key management or upcalls of some sort to user code to handle them. > If you are using a key management scheme that uses it, great. If > you are not, you can ignore it. You can't ignore it. If the machine owner can say "gee, I'd like to use SKIP" then the kernel has to have the hooks, doesn't it? .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 28 15:37:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12065; Tue, 28 Feb 95 15:37:07 PST Received: from eunuchs.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12059; Tue, 28 Feb 95 15:36:56 PST Received: by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA20679; Tue, 28 Feb 1995 15:29:47 +0800 Received: from snail.Sun.COM by eunuchs.Eng.Sun.COM (eunuchs.Eng.Sun.COM) id AA20661; Tue, 28 Feb 1995 15:29:42 +0800 Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA29199; Tue, 28 Feb 95 15:29:40 PST Received: from ns.incog.com by Sun.COM (sun-barr.Sun.COM) id AA06739; Tue, 28 Feb 95 15:28:58 PST Received: by ns.incog.com (8.6.10/94082501) id PAA00700; Tue, 28 Feb 1995 15:29:19 -0800 Received: from osmosys.incog.com by ns.incog.com (8.6.10/94082501) id PAA00685; Tue, 28 Feb 1995 15:29:16 -0800 Received: from miraj. (miraj.incog.com) by osmosys.incog.com (5.x/SMI-SVR4) id AA22152; Tue, 28 Feb 1995 15:28:32 -0800 Received: by miraj. (5.x/SMI-SVR4) id AA02831; Tue, 28 Feb 1995 15:26:18 -0800 Date: Tue, 28 Feb 1995 15:26:18 -0800 From: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) Message-Id: <9502282326.AA02831@miraj.> To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net X-Sun-Charset: US-ASCII X-Icg-Mailfrom: ashar@icgmail.eng.sun.com Content-Length: 2094 Subject: Re: (IPng) Proposed Standard or no? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: "Perry E. Metzger" > You can't ignore it. If the machine owner can say "gee, I'd like to > use SKIP" then the kernel has to have the hooks, doesn't it? No, it doesn't. If the machine owner wants to use the DEC scheme, and the protocol supports it (e.g. like IEEE 802.10b), this doesn't mean we all have to have a socket on our machines to plug in the DEC chip. In any case, I think this one's been beaten to death by now. Regards, Ashar. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 28 16:53:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12108; Tue, 28 Feb 95 16:53:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12102; Tue, 28 Feb 95 16:53:49 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18217; Tue, 28 Feb 1995 16:46:34 -0800 Received: from ftp.com (wd40.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA24644; Tue, 28 Feb 95 16:46:25 PST Received: from ftp.com by ftp.com ; Tue, 28 Feb 1995 19:30:54 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 28 Feb 1995 19:30:54 -0500 Received: from solensky.beehive.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA00909; Tue, 28 Feb 95 19:29:14 EST Date: Tue, 28 Feb 95 19:29:14 EST Message-Id: <9503010029.AA00909@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Joining the IPSEC mail list From: solensky@ftp.com (Frank T Solensky) Repository: mailserv-D.ftp.com, [message accepted at Tue Feb 28 19:29:06 1995] Originating-Client: beehive.ftp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bound@zk3.dec.com > > Can someone post how we join ipsec mail list so IPv6ers who now need to > do that can (like me). ipsec-request@ans.net ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 28 20:47:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12180; Tue, 28 Feb 95 20:47:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12174; Tue, 28 Feb 95 20:47:35 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB06997; Tue, 28 Feb 1995 20:40:21 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA13525; Tue, 28 Feb 95 20:40:22 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA09424; Tue, 28 Feb 95 20:36:06 -0800 Received: by xirtlu.zk3.dec.com; id AA22379; Tue, 28 Feb 1995 23:35:51 -0500 Message-Id: <9503010435.AA22379@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) IPng Working Group Last Calls In-Reply-To: Your message of "Mon, 27 Feb 95 11:29:38 PST." <95Feb27.112949pst.12174@skylark.parc.xerox.com> Date: Tue, 28 Feb 95 23:35:45 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > An Architecture for IPv6 Unicast Address Allocation > draft-ietf-ipngwg-arch-addr-01.txt > > An IPv6 Global Unicast Address Format > draft-ietf-ipngwg-address-format-01.txt I support the above moving to proposed standard. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 28 21:03:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12202; Tue, 28 Feb 95 21:03:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12196; Tue, 28 Feb 95 21:03:08 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07742; Tue, 28 Feb 1995 20:55:54 -0800 Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA15387; Tue, 28 Feb 95 20:55:56 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA10363; Tue, 28 Feb 95 20:50:40 -0800 Received: by xirtlu.zk3.dec.com; id AA22626; Tue, 28 Feb 1995 23:50:32 -0500 Message-Id: <9503010450.AA22626@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? In-Reply-To: Your message of "Tue, 28 Feb 95 17:18:54 EST." <9502282218.AA09757@snark.imsi.com> Date: Tue, 28 Feb 95 23:50:26 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I would now like to support Bill Simpsons suggestion this be moved to IPv6 because this is now a key mgmt issue and not just IPv6 SEC. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 28 21:19:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12217; Tue, 28 Feb 95 21:19:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12211; Tue, 28 Feb 95 21:19:10 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08415; Tue, 28 Feb 1995 21:11:56 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA17456; Tue, 28 Feb 95 21:11:52 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14598(3)>; Tue, 28 Feb 1995 21:09:21 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Tue, 28 Feb 1995 21:09:14 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng) WG last call: v6 ICMP draft Date: Tue, 28 Feb 1995 21:09:02 PST From: Steve Deering Message-Id: <95Feb28.210914pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This is a Working Group last call for the following document, before requesting the IESG to make it a Proposed Standard: ICMP for the Internet Protocol Version 6 (IPv6) draft-ietf-ipngwg-icmp-01.txt Please post comments/corrections/clarifications to the ipng mailing list BEFORE March 8. When you read it, you may notice that we omitted the Node Name Request/Response messages that I referred to last week. We decided to leave those out for now, so as not to hold up progress on this document while the debate rages on this list and on namedroppers about whether or not the ICMP name querying messages are a good idea. If we do decide to go with the ICMP name querying messages, they can follow in a separate document, like the ICMP neighbor discovery messages. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 28 23:12:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12265; Tue, 28 Feb 95 23:12:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12257; Tue, 28 Feb 95 23:12:33 PST Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12620; Tue, 28 Feb 1995 23:05:20 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA29551; Tue, 28 Feb 95 23:05:20 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA15841; Wed, 1 Mar 1995 08:05:17 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05194; Wed, 1 Mar 1995 08:05:12 +0100 X-Delivered: at request of brian on dxcoms.cern.ch Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09180; 28 Feb 95 14:31 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09175; 28 Feb 95 14:30 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@IETF.CNRI.Reston.VA.US;;;;;;; From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-carpenter-ipv6-osi-00.txt Date: Tue, 28 Feb 95 14:30:56 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-Id: <9502281430.aa09175@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mechanisms for OSI NSAPs, CLNP and TP over IPv6 Author(s) : B. Carpenter Filename : draft-carpenter-ipv6-osi-00.txt Pages : 18 Date : 02/27/1995 This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. However, it also defines a set of mechanisms for the support of OSI NSAP addressing, CLNP, and Transport Protocols over an IPv6 network. These mechanisms are the ones that MUST be used if such support is required. This document also defines a mapping of IPv6 addresses within the OSI address format, should this be required. 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-carpenter-ipv6-osi-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-carpenter-ipv6-osi-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-carpenter-ipv6-osi-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19950227120815.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-carpenter-ipv6-osi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-carpenter-ipv6-osi-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950227120815.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com