From owner-ip-ng Wed Aug 3 02:43:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00562; Wed, 3 Aug 94 02:43:09 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00556; Wed, 3 Aug 94 02:43:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA21763; Wed, 3 Aug 94 02:40:37 PDT Received: from relay2.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA22726; Wed, 3 Aug 94 02:40:25 PDT Received: from jalfrezi.ndl.co.uk by relay2.pipex.net with SMTP (PP) id <16348-0@relay2.pipex.net>; Wed, 3 Aug 1994 10:40:17 +0100 Received: from rollsroyce (rollsroyce.ndl.co.uk) by ndl.co.uk (4.1/SMI-4.1) id AA16306; Wed, 3 Aug 94 10:38:44 BST Message-Id: <9408030938.AA16306@ndl.co.uk> X-Sender: tony@mailhost.ndl.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 03 Aug 1994 10:38:10 +0100 To: ip-ng@sunroof.Eng.Sun.COM From: tony@ndl.co.uk (Tony Legge) Subject: (IPng) ip-ng addressing X-Mailer: Sender: owner-ip-ng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ip-ng@sunroof.Eng.Sun.COM Jack Houldsworth of ICL has asked me to forward these observations on IPng addressing. He is on vacation and has no mail access. I have transcribed this as accurately as I can from a fax he has sent me. His usual address is J.Houldsworth@ste0906.wins.icl.co.uk. Basic proposal: -NSAP addresses identified by 111100xx in octet 1 of 16 bit SIPP address space. -AFI is first 4 bits of octet 2, remaining 4 bits of octet 2 form first digit of 3 digit IFI. -All 1's AFI - signals DCC address. -Originally anything else in AFI signalled ICD address but: -This excluded X.121, E.164, E.163 and F69, all allocated by ITU-T. Brian Carpenter proposed: -All 1's AFI signals DCC. -ICD uses encodings 0 thru 9. -This leaves codes A thru E open (5 code points) for X.121, E.164, E163, and F69. But this fails because: -X.121 requires 4 AFI values for preferred decimal/binary and leading digit 0 or 1. -E.164, E.163 and F69 each require 2 AFI values for binary or decimal. This proposal has been thrown together very quickly and we need to return to the encoding drawing board. I need more time to get ideas from the SC6 experts but here are some suggestions: -First digit of 16 octet address should be AFI value with Internet having one or more AFI values. -This creates a uniform format which allows any system to identify address type and who allocated it. -Allows any existing Network Termination Point (X.25, ISDN, CLNP) to belong to the new IPng without having to allocate new addresses. -More potential new internet users without painful transition. -Frees up first 4 bits of octet 2 because DCC, ICD, X.121 etc would be identified in octet 1. In any case there are lots of better ways of catering for NSAP by more sympathetic allocation of code points in octet 1 even if existing SIPP addressing style is preferred: -Could allocate all encodings 1110 xxxx to NSAP addresses - move IPX to another reserved combination or give it an AFI value. -xxxx in octet 1 (above) then becomes AFI first digit and first 4 bits of octet 2 become second digit of AFI requiring no reallocation of ISO and ITU-T codes. PLEASE REMEMBER: -NSAP addresses are used by all current global services provided by ITU-T including X.25 and ISDN. -All known global protocols including X.25 provide space for 20 bytes maximum NSAP address. -X121, E.164, E.163, F69 addressing schemes as well as DCC and ICD have been expanded for local domain addressing by major users and many use 20 byte max. -UK GOSIP and European EPHOS has a standard for allocatong 20 bytes max. This subject needs to be carefully handled so that IPng is launched with no unknowns. We must be careful not to exclude users who have already commissioned working systems using the NSAP scheme. JACK HOULDSWORTH ------------------------------------------------------------------------------ IETF IP-ng Mailing List Unsubscribe: unsubscribe ip-ng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ip-ng Wed Aug 3 09:52:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00977; Wed, 3 Aug 94 09:52:15 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00971; Wed, 3 Aug 94 09:52:11 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA26944; Wed, 3 Aug 1994 09:49:32 -0700 Date: Wed, 3 Aug 1994 09:49:32 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <9408031649.AA26944@jurassic.Eng.Sun.COM> To: sipp@sunroof.Eng.Sun.COM Cc: ip-ng@sunroof.Eng.Sun.COM In-Reply-To: <9408031631.AA01815@xirtlu.zk3.dec.com> Subject: (IPng) (sipp) Mail List Explanation Sender: owner-ip-ng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ip-ng@sunroof.Eng.Sun.COM > Are we going to combine the old sipp list with the ipng list made up? > > I assume the ipng addr above is tne new names to the list? There will be an announcement later today. Bob ------------------------------------------------------------------------------ IETF IP-ng Mailing List Unsubscribe: unsubscribe ip-ng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 3 11:50:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01249; Wed, 3 Aug 94 11:50:32 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00596; Wed, 3 Aug 94 04:20:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA23422; Wed, 3 Aug 94 04:17:47 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA01132; Wed, 3 Aug 94 04:17:38 PDT To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) NSAP addressing Date: Wed, 3 Aug 94 12:13:54 GMT From: Ran Atkinson Message-Id: <9408031213.aa16386@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I would like to see Brian Carpenter's good work on mappings continue. [rant on] I do not see ANY value whatsoever in wasting IPng address space on X.121 or E.164 or E.163 or F69 address plans to the extent they can't be accomodated by Brian's work. For those not in the know, we're talking about the X.25 SUBnetwork technology and plain-old telephone numbers here. Just because ISO has politically designed network specifications does NOT mean that those of us solving real technical problems should have to suffer from their mistakes. There is often good VALUE in having different addressing schemes for different protocols, particularly with protocols at different levels in the protocol stack (e.g. the phone system is below IP and X.25 is also below IP). Some ATM users are already finding routing problems arising from their ATM addresses having the same syntax as their ISO CLNP addresses. Let's not repeat that particular mistake, which was politically forced within the ATM Forum, in IPng. As to ISO, I have to agree with Stef that its about time to see them bend a little and try to work WITH us rather than always pushing us to accomodate them. Cooperation is a two-way street, not the IETF always giving in to people who have a much smaller installed base and lower quality technology. [rant off] We now return you to your usual technical discussions. Sorry for the interruption. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ 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 Wed Aug 3 11:50:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01261; Wed, 3 Aug 94 11:50:38 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00607; Wed, 3 Aug 94 04:37:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA23735; Wed, 3 Aug 94 04:34:54 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA02160; Wed, 3 Aug 94 04:34:45 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA27609; Wed, 3 Aug 1994 13:34:41 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA15392; Wed, 3 Aug 1994 13:34:39 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408031134.AA15392@dxcoms.cern.ch> Subject: Re: (IPng) ip-ng addressing To: ipng@sunroof.Eng.Sun.COM Date: Wed, 3 Aug 1994 13:34:39 +0200 (MET DST) In-Reply-To: <9408030938.AA16306@ndl.co.uk> from "Tony Legge" at Aug 3, 94 10:38:10 am X-Mailer: ELM [version 2.4 PL22] 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 Tony, I was actioned with Jim Bound to work on this after Toronto, and the current proposal is in Jack's mailbox. I accidentally also sent it to the old SIPP list (thank you Majordomo :-) so I will not repeat it on this list. However, it is certain that you will not get consensus on sacrificing the most significant byte of an IP6 address for this. The current proposal sacrifices 1/32 of the IP6 address space and covers ICD, DCC, X.121 and E.164 (binary encoding only). I would take a lot of convincing that anything more is needed. In fact I regard the X.121 and E.164 cases as very marginal, but they don't consume any more bits. I will post a revised version on this list in about 3 weeks when I have returned from vacation and processed any comments received from various experts. I will look at Jack's proposal as part of that process. Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ 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 Wed Aug 3 13:15:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01350; Wed, 3 Aug 94 13:15:32 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01344; Wed, 3 Aug 94 13:15:26 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14782; Wed, 3 Aug 94 13:12:58 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA03867; Wed, 3 Aug 94 13:12:46 PDT Subject: (IPng) ICMP Destination unreachable and options To: ip-ng@sunroof2.Eng.Sun.COM Date: Wed, 3 Aug 1994 16:13:16 -0500 (EST) From: "Daniel L. McDonald" Cc: "Daniel L. McDonald" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2718 Message-Id: <9408032113.aa17338@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Under IP, or at least IP inside BSD Net/2 (Reno), when a Destination Unreachable is generated by UDP, the IP options are stripped. My subsequent question is two-fold: 1. Should a higher level protocol (like UDP) strip IPng options from a packet before sending Dest. Unreachable so that the source of the offending packet can send the incoming Dest. Unreachable to its appropriate higher-level protocol? 2. If not, what if the options (like a monstrously large source route) take all of the 576 bytes allowed for ICMP messages? How does my IPng module deal with this? Let me illustrate with an example. Let's say I send a UDP message with a source route to a machine. The header chain will look like: 0 40 n +------------+----------------+------------------------ | SIPP hdr | Routing header | UDP header + data | | | | Next Hdr = | Next Header = | | Routing | UDP | +------------+----------------+------------------------ Now let's say the UDP header specifies a port that has no listeners. The receiving UDP module will send an ICMP Dest. Unreachable with code Port Unreachable. What will the ICMP message look like? Will it look like this? <----- Offending packet, up to 576 bytes ---> (Potentially might not include UDP header. Think of n > 526. ) 0 40 48 88 n+48 +------------+-----++-----------+----------------+------------------ | SIPP hdr |I D U||(Bad) SIPP | Routing header | UDP header + data | |C e n||Header | | | Next Hdr = |M s r||Next Hdr = | Next Header = | | ICMP |P t c|| Routing | UDP | +------------+-----++-----------+----------------+------------------ Or will it look like.... 0 40 48 88 +------------+-----++-----------+------------------ | SIPP hdr |I D U||(Bad) SIPP | UDP header + data | |C e n||Header | | Next Hdr = |M s r||Next Hdr = | | ICMP |P t c|| UDP | +------------+-----++-----------+------------------ If it is the former, my IPng module will have to potentially parse through the headers of the included offending packet to know to deliver the ICMP message to UDP. If the latter, my UDP module will have to strip options, much like UDP modules do in current IP on BSD Net/2. Also, if this is true, my IPng module may have to strip options in the case of destination unreachable codes and packet too big code. IWBNI anybody who's done SIPP-8s and ICMPs already would speak up on this. Thanks a ton! Dan McD. ------------------------------------------------------------------------------ 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 Sat Aug 6 15:52:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07422; Sat, 6 Aug 94 15:52:07 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07416; Sat, 6 Aug 94 15:52:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22560; Sat, 6 Aug 94 15:49:29 PDT Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA16110; Sat, 6 Aug 94 15:49:04 PDT Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA28587 for ip-ng@sunroof.eng.sun.com; Sat, 6 Aug 94 18:48:51 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id PAA06013; Sat, 6 Aug 1994 15:48:17 -0700 Message-Id: <199408062248.PAA06013@aland.bbn.com> To: ip-ng@sunroof.Eng.Sun.COM Subject: (IPng) re: A Generic Socket Interface for QoS From: Craig Partridge Date: Sat, 06 Aug 94 15:48:12 -0700 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM It was suggested I should forward this note here too. Craig E-mail: craig@aland.bbn.com or craig@bbn.com ------- Forwarded Message Received: from venera.isi.edu by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA18875 for popbbn; Sat, 6 Aug 94 17:43:17 -0400 Received: from uu2.psi.com by venera.isi.edu (5.65c/5.61+local-14) id ; Sat, 6 Aug 1994 13:44:05 -0700 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA06757 for int-serv@isi.edu; Sat, 6 Aug 94 16:42:36 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id NAA05857; Sat, 6 Aug 1994 13:41:59 -0700 Message-Id: <199408062041.NAA05857@aland.bbn.com> To: int-serv@ISI.EDU To: rsvp@ISI.EDU To: af-saa@atmforum.com To: end2end-interest@ISI.EDU To: posix-net-ptp@nemo.ncsl.nist.gov Cc: tmendez@bbn.com, scsmith@bbn.com Subject: A Generic Socket Interface for QoS Reply-To: Craig Partridge From: Craig Partridge Date: Sat, 06 Aug 94 13:41:58 -0700 Sender: craig@aland.bbn.com Hi folks: Several folks have asked me to put my views on how to enhance the BSD socket (and presumably WINSOCK) interfaces to support quality of service. Here's an attempt to present my ideas in about three pages of text (short enough that one can easily read it). I'm giving this wide circulation to solicit opinions as I'm about to start implementing this as part of a larger project to integrate ATM and QoS into a BSD socket interface. The Basic Premise The ideas here stem from a basic premise. If at all possible, we want a single, generic interface for QoS support. Just as sockets are a generic interface for networking protocols so far, any extensions for QoS should also be generic possibly with bells and whistles for various protocol families. [This work also motivates the ATM socket work I'm doing with Trevor Mendez and Shawn Smith -- we've got code using a PF_ATM protocol entry table and mapped calls like bind() and connect() into ATM actions] The point is that regardless of whether one is using IPv4, IP6, or ATM, the interface should be the same. The job of operating systems is to provide such generic interfaces in a way that makes programming them easy and comfortable for applications programmers. The Interface If one looks carefully at the BSD socket interface, its logic is similar to that of UNIX process creation. First, you create a socket using socket(). Then you customize it, using bind(), setsockopt(), fcntl() and ioctl(). Finally you make the socket operational (i.e. ready to send data or to accept connections) using connect(), or listen()/accept(). [The similarity to process creation is that one calls fork() to create the process, then customize the new process's privileges, open files, etc, and then call exec() to get the new image loaded]. From the perspective of QoS, we obviously want the QoS in place once the socket becomes operational. I.e., after connect() or listen()/ accept() returns, we expect our QoS requirements to be in place and thus to be able to start sending or receiving data. Note, parenthetically, that we'd obviously like to be able to check on the QoS at any time during the life of the active socket. My view is that, if one agrees with this analysis, the right thing is to find some way to set the QoS between the time socket() is called and the time connect() or listen() is called. And there already exists a very generic system call for customizing sockets -- setsockopt(). So my proposal is that we standardize one or more options for setsockopt to set a QoS. (And use getsockopt() to get any information about QoS, such as after doing an accept()). Here's a brief outline. Let's suppose that there's one UNIX QoS structure for all protocol families (a topic discussed further later). We can define an option SO_QOS. An video application that wanted to set a QoS could do the following: if ((s = socket(AF_FAMILY, SOCK_STREAM, 0)) < 0) { perror("socket"); exit(1); } if ((qos = getqosbyname("mpeg-2")) == (struct qos *)0) { fprintf(stderr,"unknown service\n"); exit(1); } if (setsockopt(s,SOL_SOCKET,SO_QOS,(char *)qos,sizeof(*qos)) != 0) { perror("setsockopt"); exit(1); } if (connect(s,(struct sockaddr *)dst,sizeof(*dst)) != 0) { perror("connect"); exit(1); } to get a socket opened with an established QoS. If no QoS is set, the socket QoS defaults to best effort (i.e. what it is today). Internally in socket implementations there's some logic to this approach too. A call to connect() is the first time that any packets are sent. So one can enhance the internal kernel code to pass the QoS structure down with the first packet (e.g., the TCP syn) through the transport layer to IP (for IP QoS) and the link level driver (e.g., ATM, Fast Ethernet, FDDI) so that lower layers can do what they have to (e.g., IP call RSVP, ATM do a setup, FDDI request for bandwidth) to implement the QoS. I envision that we'd implement routines like getqosbyname() so application writers would not have to know the innards of the QoS structure unless they needed to. They'd just need to know what type of application they were running. A Few Open Questions I'm aware of two open issues with this interface. First, is the QoS structure generic (e.g., SOL SOCKET) or per-protocol family specific? This isn't a big deal. A generic structure would be nice but if we have protocol specific formats it just means that getqosbyname has two args (protocol family and name of service), and setsockopt has QOS option values for each protocol family, and we have to define a new QoS structure for each protocol family. A bit of a nuisance for application writers but that's it. Second, how to integrate scheduling? Remember that in most cases where we're asking for a QoS guarantee, we also need to make sure that the BSD scheduler knows to give the real-time application some guarantees about CPU time. Unfortunately, there is no defined way for BSD to provide guarantees about CPU time yet. One option is to integrate this into the QoS request, but I think that's overloading the setsockopt() call. An alternative is to assume the application is smart enough to request the CPU resources it needs at the same time it sets up the socket. E.g., there's some bit of code like: sp = getschedulebyname("mpeg-2"); scheduler(sp); in the code that gets the right scheduling parameters and calls the scheduler (via a new system call) to get that scheduling. I welcome any comments folks have. However, I do ask that if you believe I've got this design all wrong, you provide an alternative theory of BSD works now and show how your proposal fits your model. I think we're much more likely to have a successful approach if it fits with what has gone before. Thanks! Craig ------- End of Forwarded Message ------------------------------------------------------------------------------ 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 Sun Aug 7 08:38:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00294; Sun, 7 Aug 94 08:38:10 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00288; Sun, 7 Aug 94 08:38:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA06049; Sun, 7 Aug 94 08:35:31 PDT Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA17429; Sun, 7 Aug 94 08:35:21 PDT Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA15007 for ipng@sunroof.eng.sun.com; Sun, 7 Aug 94 11:18:38 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id IAA06313; Sun, 7 Aug 1994 08:18:03 -0700 Message-Id: <199408071518.IAA06313@aland.bbn.com> To: Jon Crowcroft Cc: Craig Partridge , int-serv@ISI.EDU, rsvp@ISI.EDU, af-saa@atmforum.com, end2end-interest@ISI.EDU, posix-net-ptp@nemo.ncsl.nist.gov, tmendez@bbn.com, scsmith@bbn.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: A Generic Socket Interface for QoS In-Reply-To: Your message of Sun, 07 Aug 94 14:08:19 +0100. <1565.776264899@cs.ucl.ac.uk> From: Craig Partridge Date: Sun, 07 Aug 94 08:18:02 -0700 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Second, how to integrate scheduling? Remember that in most cases wh ere >we're asking for a QoS guarantee, we also need to make sure that the BSD >scheduler knows to give the real-time application some guarantees about >CPU time. > sp = getschedulebyname("mpeg-2"); > scheduler(sp); why do you need to tell the scheduler anything new - the QoS guarantee for packets is done by sceduling packets in routers - surely the scheduler in the end system can make the same calcuation (or derived one) insterad of burdening the application with an extra system call...? Hi Jon: You have to talk to the scheduler because the workload on the end systems is not simply the cost of moving packets through queues. You also have to allocate time for the application to process the data. And different applications will have different processing requirements (there's a big difference between, say, deciding where to place some bits on a screen and doing some compression or decompression of video). In other words, the amount of time required per packet varies widely on a per application basis and only the application knows how much time it needs per packet if it is to keep up with the data stream. Craig ------------------------------------------------------------------------------ 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 Sun Aug 7 08:51:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00311; Sun, 7 Aug 94 08:51:13 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00305; Sun, 7 Aug 94 08:51:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA06345; Sun, 7 Aug 94 08:48:34 PDT Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA17918; Sun, 7 Aug 94 08:48:23 PDT Message-Id: <9408071548.AA17918@Sun.COM> Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk via Local Delivery channel id ; Sun, 7 Aug 1994 16:48:07 +0100 Date: Sun, 7 Aug 1994 16:48:04 +0100 From: J.Crowcroft@cs.ucl.ac.uk To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: A Generic Socket Interface for QoS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This is an automatic reply. Feel free to send additional mail, as only this one notice will be generated. The following is a prerecorded message, sent for J.Crowcroft@cs.ucl.ac.uk I'm away from aug 9 til aug 23 inclusive, NOT reading e-mail SIGCOMM Registration: Soren Sorensen (soren@cs.ucl.ac.uk, +44 71 380 7285) Local: Angela Sasse (angela@cs.ucl.ac.uk, +44 71 380 7212) Departmental: Natalie May (natalie@cs.ucl.ac.uk, +44 71 380 7214) WWW: http://www.cs.ucl.ac.uk/sigcomm94/index.html DCNDS MSc, Tracy Cogger (t.cogger@cs.ucl.ac.uk) DARPA project, p.kirstein@cs.ucl.ac.uk, i.wakeman@cs.ucl.ac.uk RACE Prepare, Dave, d.lewis@cs.ucl.ac.uk EMMA project, Roy, r.bennett@cs.ucl.ack BT MMN things, James, j.cowan@cs.ucl.ac.uk FUME stuff, Zheng, z.wang@cs.ucl.ac.uk HIPPARCH stuff: Atanu, a.ghosh@cs.ucl.ac.uk ME: http://www.cs.ucl.ac.uk/people/jon.html ------------------------------------------------------------------------------ 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 Sun Aug 7 18:20:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00477; Sun, 7 Aug 94 18:20:12 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07380; Sat, 6 Aug 94 14:35:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA21312; Sat, 6 Aug 94 14:32:46 PDT Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA13634; Sat, 6 Aug 94 14:32:37 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id OAA13564; Sat, 6 Aug 1994 14:32:28 -0700 Date: Sat, 6 Aug 1994 14:32:28 -0700 From: Dave Katz Message-Id: <199408062132.OAA13564@feta.cisco.com> To: ietf@cnri.reston.va.us Cc: sipp@sunroof.Eng.Sun.COM, ipng@sunroof.Eng.Sun.COM, tuba@lanl.gov, catnip@world.std.com Subject: (IPng) IPng Address Autoconfiguration Mailing List Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Apologies in advance for the cross-posting. Following the Address Autoconfiguration BOF at the recent IETF meeting in Toronto, a mailing list has been established in anticipation of the formation of an IETF working group. The anticipated scope of this group will be to specify a dynamic network address administration architecture and protocol for IPv6. The mailing list is: addrconf@cisco.com The request list is: addrconf-request@cisco.com Those of you who attended the BOF in Toronto and *did not* receive a "welcome" message on the mailing list, please send a message to the request list above. I was unable to read all of the email addresses on the attendance list (and deleted several addresses that I thought I could read, but that generated mail bounces). -- Dave Katz (dkatz@cisco.com) Sue Thomson (set@thumper.bellcore.com) co-chairs ------------------------------------------------------------------------------ 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 Sun Aug 7 18:48:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00507; Sun, 7 Aug 94 18:48:00 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00453; Sun, 7 Aug 94 17:07:47 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14184; Sun, 7 Aug 94 17:05:14 PDT Received: from odin.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA05697; Sun, 7 Aug 94 17:05:04 PDT Received: by odin.UU.NET (maildrop) id QQxbzk04372; Sun, 7 Aug 1994 20:05:02 -0400 Date: Sun, 7 Aug 1994 20:05:02 -0400 Message-Id: From: Joseph Malcolm To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: A Generic Socket Interface for QoS In-Reply-To: <9408071548.AA17918@Sun.COM> References: <9408071548.AA17918@Sun.COM> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM You probably want to fix your vacation autoreplier, if it's not too late. J.Crowcroft@cs.ucl.ac.uk writes: > This is an automatic reply. Feel free to send additional >mail, as only this one notice will be generated. The following >is a prerecorded message, sent for J.Crowcroft@cs.ucl.ac.uk > > > >I'm away from aug 9 til aug 23 inclusive, NOT reading e-mail > >SIGCOMM Registration: Soren Sorensen (soren@cs.ucl.ac.uk, +44 71 380 7285) > Local: Angela Sasse (angela@cs.ucl.ac.uk, +44 71 380 7212) > Departmental: Natalie May (natalie@cs.ucl.ac.uk, +44 71 380 7214) > WWW: http://www.cs.ucl.ac.uk/sigcomm94/index.html > >DCNDS MSc, Tracy Cogger (t.cogger@cs.ucl.ac.uk) > >DARPA project, p.kirstein@cs.ucl.ac.uk, i.wakeman@cs.ucl.ac.uk > >RACE Prepare, Dave, d.lewis@cs.ucl.ac.uk > >EMMA project, Roy, r.bennett@cs.ucl.ack > >BT MMN things, James, j.cowan@cs.ucl.ac.uk > >FUME stuff, Zheng, z.wang@cs.ucl.ac.uk > >HIPPARCH stuff: Atanu, a.ghosh@cs.ucl.ac.uk > >ME: http://www.cs.ucl.ac.uk/people/jon.html >------------------------------------------------------------------------------ >IETF IPng Mailing List >Unsubscribe: unsubscribe ipng (as message body, not subject) >Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ 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 Mon Aug 8 09:38:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00935; Mon, 8 Aug 94 09:38:56 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00531; Sun, 7 Aug 94 19:33:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA16515; Sun, 7 Aug 94 19:31:21 PDT Received: from odin.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA12761; Sun, 7 Aug 94 19:31:12 PDT Received: by odin.UU.NET (maildrop) id QQxbzu06718; Sun, 7 Aug 1994 22:31:11 -0400 Date: Sun, 7 Aug 1994 22:31:11 -0400 Message-Id: From: Joseph Malcolm To: Joseph Malcolm Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: A Generic Socket Interface for QoS In-Reply-To: References: <9408071548.AA17918@Sun.COM> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joseph Malcolm writes: >You probably want to fix your vacation autoreplier, if it's not too >late. Sorry for the unintentionally wide distribution on that message - I meant to send it only to Jon, but that "Reply-To: ipng@sunroof.Eng.Sun.COM" and not quite enough attention on my part combined to bother you all. ------------------------------------------------------------------------------ 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 Wed Aug 10 06:17:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02909; Wed, 10 Aug 94 06:17:19 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02903; Wed, 10 Aug 94 06:17:12 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03329; Wed, 10 Aug 94 06:14:37 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA03028; Wed, 10 Aug 94 06:14:20 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Wed, 10 Aug 1994 14:13:49 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Wed, 10 Aug 1994 14:09:14 +0100 Date: Wed, 10 Aug 1994 14:09:14 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003387] Original-Encoded-Information-Types: ia5 text (2),undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3387 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3387*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) NSAPs in IPng Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 ------------------------------ Start of body part 2 >To: majordomo@sunroof.eng.sun.com >Subject: IPng addressing observations > >Basic Proposal > > -NSAP addresses identified by 111100xx in octet 1 of 16 bit >SIPP address space. > > -AFI is first 4 bits of octet 2, remaining 4 bits of octet 2 >form first digit of 3 digit IFI. > > -All 1's AFI - signals DCC address. > > -Originally anything else in AFI signalled ICD address but: > > -This excluded X.121, E.164, E.163 and F69, all allocated by ITU-T. > >Brian Carpenter proposed: > > -All 1's AFI signals DCC. > > -ICD uses encodings 0 thru 9. > > -This leaves codes A thru E open (5 code points) for X.121, E.164, >E163, and F69. But this fails because: > -X.121 requires 4 AFI values for preferred decimal/binary and leading >digit 0 or 1. > -E.164, E.163 and F69 each require 2 AFI values for binary or decimal. > >This proposal has been thrown together very quickly and we need to >return to the encoding drawing board. I need more time to get ideas >from the SC6 experts but here are some suggestions: > > -First digit of 16 octet address should be AFI value with Internet >having one or more AFI values. > > -This creates a uniform format which allows any system to identify >address type and who allocated it. > > -Allows any existing Network Termination Point (X.25, ISDN, CLNP) to >belong to the new IPng without having to allocate new addresses. > > -More potential new internet users without painful transition. > > -Frees up first 4 bits of octet 2 because DCC, ICD, X.121 etc would >be identified in octet 1. > >In any case there are lots of better ways of catering for NSAP by >more sympathetic allocation of code points in octet 1 even if >existing SIPP addressing style is preferred: > > -Could allocate all encodings 1110 xxxx to NSAP addresses - move IPX >to another reserved combination or give it an AFI value. > > -xxxx in octet 1 (above) then becomes AFI first digit and first 4 >bits of octet 2 become second digit of AFI requiring no reallocation >of ISO and ITU-T codes. > >PLEASE REMEMBER: > > -NSAP addresses are used by all current global services provided by >ITU-T including X.25 and ISDN. > > -All known global protocols including X.25 provide space for20 bytes >maximum NSAP address. > > -X121, E.164, E.163, F69 addressing schemes as well as DCC and ICD >have been expanded for local domain addressing by major users and >many use 20 byte max. > > -UK GOSIP and European EPHOS have a standard for allocating 20 bytes >max. > >This subject needs to be carefully handled so that IPng is launched >with no unknowns. > >We must be careful not to exclude users who have already commissioned >working systems using the NSAP scheme. > > JACK HOULDSWORTH ------------------------------ End of body part 2 ------------------------------------------------------------------------------ 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 Wed Aug 10 13:09:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03301; Wed, 10 Aug 94 13:09:52 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03295; Wed, 10 Aug 94 13:09:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20047; Wed, 10 Aug 94 13:07:09 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA10164; Wed, 10 Aug 94 13:06:52 PDT Message-Id: <9408102006.AA10164@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6959; Wed, 10 Aug 94 16:03:32 EDT Date: Wed, 10 Aug 94 16:02:51 EDT From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM FYI. Tony & Yakov. P.S. There was some confusion on our part whether the official title for IPng is "IP6" or "IPv6". We found that the correct title is "IP6", but we found it after we sent the document as an Internet Draft. We'll fix this in the next iteration. ****** The following is a COPY ***************************** Received: from IETF.nri.reston.VA.US by watson.ibm.com (IBM VM SMTP V2R3) with TCP; Wed, 10 Aug 94 15:05:08 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08918; 10 Aug 94 14:12 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08883; 10 Aug 94 14:09 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-rekhter-ipng-arch-IPv6-addr-00.txt Date: Wed, 10 Aug 94 14:09:17 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9408101409.aa08883@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Architecture for IPv6 Unicast Address Allocation Author(s) : Y. Rekhter, T. Li Filename : draft-rekhter-ipng-arch-IPv6-addr-00.txt Pages : 24 Date : 08/09/1994 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 password "guest". After logging in, Type "cd internet-drafts". "get draft-rekhter-ipng-arch-IPv6-addr-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rekhter-ipng-arch-IPv6-addr-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: <19940809174936.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-rekhter-ipng-arch-IPv6-addr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rekhter-ipng-arch-IPv6-addr-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940809174936.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ 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 Wed Aug 10 17:13:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03531; Wed, 10 Aug 94 17:13:35 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03491; Wed, 10 Aug 94 16:31:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00664; Wed, 10 Aug 94 16:29:14 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA23843; Wed, 10 Aug 94 16:29:04 PDT To: ip-ng@sunroof.Eng.Sun.COM Subject: (IPng) naming conventions & political correctness in the IETF Date: Thu, 11 Aug 94 0:27:34 GMT From: Ran Atkinson Message-Id: <9408110027.aa03609@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yakov & Tony, I happen to think that the currently popular "political correctness" on naming is fairly silly. The important thing is that the words we use be accurate. The term "IPv6" is clear and accurate and nicely parallels the term "IPv4". Certainly at the IPv6 Implementer's meeting in Toronto, most folks thought that "IPv6" was clearer given the publicity given the term "IPv4" over the past painful while. Moreover, "IP6" implies IP with 6 byte addresses, while we're trying to work on IP _version_ 6. I don't think you all should worry about which name you used in the draft and I don't think it matters what name is used as long as its clear to the reader. We aren't yet ISO where one has to use the politically correct nomenclature or get in trouble, or so I hope. For what its worth, my drafts also use IPv6 and I do NOT plan to change because it ain't worth my time to make such changes. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ 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 Thu Aug 11 09:06:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03976; Thu, 11 Aug 94 09:06:39 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03970; Thu, 11 Aug 94 09:06:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA28144; Thu, 11 Aug 94 09:03:55 PDT Received: from gatekeeper.mcimail.com by Sun.COM (sun-barr.Sun.COM) id AA02642; Thu, 11 Aug 94 09:03:45 PDT Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA25996; Thu, 11 Aug 94 11:05:56 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ay15607; 11 Aug 94 15:59 GMT Date: Thu, 11 Aug 94 10:50 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: ipng Subject: Re: (IPng) naming conventions & political correctness in the IETF Message-Id: <83940811155038/0003858921NA2EM@mcimail.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran said: > I happen to think that the currently popular "political correctness" >on naming is fairly silly. The important thing is that the words we >use be accurate. The term "IPv6" is clear and accurate and nicely >parallels the term "IPv4". Certainly at the IPv6 Implementer's >meeting in Toronto, most folks thought that "IPv6" was clearer given >the publicity given the term "IPv4" over the past painful while. >Moreover, "IP6" implies IP with 6 byte addresses, while we're trying >to work on IP _version_ 6. As a person that has to deal with 'political correctness' in the corporate world, I told Scott and a few others that I recommend IPv6, not IP6. Bob ------------------------------------------------------------------------------ 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 Thu Aug 11 09:15:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03988; Thu, 11 Aug 94 09:15:45 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03982; Thu, 11 Aug 94 09:15:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA28614; Thu, 11 Aug 94 09:13:02 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA04855; Thu, 11 Aug 94 09:12:52 PDT Received: from pm002-22.dialip.mich.net (pm002-22.dialip.mich.net [35.1.48.103]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA00634 for ; Thu, 11 Aug 1994 12:12:49 -0400 Date: Thu, 11 Aug 94 15:07:39 GMT From: "William Allen Simpson" Message-Id: <3012.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) naming conventions & political correctness in the IETF Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I don't think you all should worry about which name you used in the > draft and I don't think it matters what name is used as long as its > clear to the reader. We aren't yet ISO where one has to use the > politically correct nomenclature or get in trouble, or so I hope. For > what its worth, my drafts also use IPv6 and I do NOT plan to change > because it ain't worth my time to make such changes. > I will agree with the first sentiment, and with the last. But, it does help to have a consistent nomenclature. That's why we have an Editor. A big part of his job is simply making the final versions of the document fit together. Let _him_ do it. 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 From owner-ipng Thu Aug 11 09:51:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04040; Thu, 11 Aug 94 09:51:58 PDT Received: from jurassic (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04034; Thu, 11 Aug 94 09:51:51 PDT Received: (hinden@localhost) by jurassic (8.6.9/8.5) id JAA10947; Thu, 11 Aug 1994 09:49:03 -0700 Date: Thu, 11 Aug 1994 09:49:03 -0700 From: Bob Hinden Message-Id: <199408111649.JAA10947@jurassic> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <83940811155038/0003858921NA2EM@mcimail.com> Subject: Re: (IPng) naming conventions & political correctness in the IETF Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >parallels the term "IPv4". Certainly at the IPv6 Implementer's > >meeting in Toronto, most folks thought that "IPv6" was clearer given > >the publicity given the term "IPv4" over the past painful while. > >Moreover, "IP6" implies IP with 6 byte addresses, while we're trying > >to work on IP _version_ 6. > > As a person that has to deal with 'political correctness' in the corporate > world, I told Scott and a few others that I recommend IPv6, not IP6. I think I also prefer IPv6 instead of IP6. I am working on updating some of the documents, so this would be a good time to decide. Any objections to IPv6? Also, the strategy I have been taking is to call the activity "IP Next Generation (IPng)" and the protocol itself IPv6 (or IP6 (or...)). My reason for this is that IPng has a lot of name recognition now. I wouldn't want people to think that IP6 was another proposal :-) Bob ------------------------------------------------------------------------------ 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 Thu Aug 11 10:54:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04068; Thu, 11 Aug 94 10:54:15 PDT Received: from future.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04062; Thu, 11 Aug 94 10:54:08 PDT Received: from localhost by future.Eng.Sun.COM (5.x/SMI-SVR4) id AA05422; Thu, 11 Aug 1994 10:50:39 -0700 Message-Id: <9408111750.AA05422@future.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) naming conventions & political correctness in the IETF In-Reply-To: Your message of "Thu, 11 Aug 94 09:49:03 PDT." <199408111649.JAA10947@jurassic> Date: Thu, 11 Aug 94 10:50:39 PDT From: Geoff Mulligan Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I agree with Bob. I like the idea of calling the effort IPng (including transition) with the actual protocol being implemented IPv6. IP6 doesn't parallel IPv4. geoff ------------------------------------------------------------------------------ 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 Thu Aug 11 11:07:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04083; Thu, 11 Aug 94 11:07:15 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04077; Thu, 11 Aug 94 11:07:07 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05373; Thu, 11 Aug 94 11:04:31 PDT Received: from clark.net by Sun.COM (sun-barr.Sun.COM) id AA03728; Thu, 11 Aug 94 11:04:11 PDT Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id OAA02170 for ipng@sunroof.Eng.Sun.COM; Thu, 11 Aug 1994 14:04:07 -0400 From: Howard Berkowitz Message-Id: <199408111804.OAA02170@clark.net> Subject: Re: (IPng) naming conventions & political correctness in the IETF To: ipng@sunroof.Eng.Sun.COM Date: Thu, 11 Aug 1994 14:04:06 -0400 (EDT) In-Reply-To: <199408111649.JAA10947@jurassic> from "Bob Hinden" at Aug 11, 94 09:49: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 Content-Length: 22 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM But what about IPds9? ------------------------------------------------------------------------------ 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 Thu Aug 11 12:01:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04173; Thu, 11 Aug 94 12:01:51 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04167; Thu, 11 Aug 94 12:01:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA08161; Thu, 11 Aug 94 11:59:07 PDT Received: from ftp.com (wd40.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA16782; Thu, 11 Aug 94 11:58:56 PDT Received: from ftp.com by ftp.com ; Thu, 11 Aug 1994 14:58:25 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 11 Aug 1994 14:58:25 -0400 Received: from solensky.fenway.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA23679; Thu, 11 Aug 94 14:55:54 EDT Date: Thu, 11 Aug 94 14:55:54 EDT Message-Id: <9408111855.AA23679@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) naming conventions & political correctness in the IETF From: solensky@ftp.com (Frank T Solensky) Repository: mailserv-D.ftp.com, [message accepted at Thu Aug 11 14:55:52 1994] Originating-Client: fenway.ftp.com Content-Length: 196 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > But what about IPds9? That's for when we start running into problems with IPv6. By that time, Paramount should have at least a few more spin-off series in production... ;-) -- Frank ------------------------------------------------------------------------------ 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 Thu Aug 11 16:01:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04546; Thu, 11 Aug 94 16:01:41 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04540; Thu, 11 Aug 94 16:01:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19922; Thu, 11 Aug 94 15:58:57 PDT Received: from FNAL.FNAL.GOV by Sun.COM (sun-barr.Sun.COM) id AA09328; Thu, 11 Aug 94 15:57:51 PDT Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HFSIJY8FAO005WS0@FNAL.FNAL.GOV>; Thu, 11 Aug 1994 17:52:41 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA00559; Thu, 11 Aug 94 17:51:59 CDT Date: Thu, 11 Aug 1994 17:51:58 -0500 From: Matt Crawford Subject: Re: (IPng) naming conventions & political correctness in the IETF In-Reply-To: Your message of Thu, 11 Aug 94 10:50:39 PDT. <9408111750.AA05422@future.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Message-Id: <9408112251.AA00559@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM While creating the To-Do list at the Thursday morning SIPP session, the sense of the room was for the name "IP6". My own reason for favoring that name was that it sounded less "me-too-ish" alongside Appletalk Phase 2, Decnet Phase V, System V Release 4, and so on. You may call that political [in]correctness, I call it aesthetics. Or maybe non-conformity. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab ------------------------------------------------------------------------------ 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 Thu Aug 11 16:07:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04564; Thu, 11 Aug 94 16:07:32 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04552; Thu, 11 Aug 94 16:07:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20190; Thu, 11 Aug 94 16:04:46 PDT Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA10390; Thu, 11 Aug 94 16:01:52 PDT Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id QAA12375; Thu, 11 Aug 1994 16:01:25 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Aug 1994 16:01:34 -0700 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: (IPng) naming conventions & political correctness in the IETF Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Spin-off. You said sping-off?? ARGGGGG. I thought I was the only turkey that did puns like that. Yeah, yeah. Go ahead and claim that having a space station spin wasn't the idea... >> But what about IPds9? > >That's for when we start running into problems with IPv6. By that >time, Paramount should have at least a few more spin-off series >in production... ;-) d/ ----- Dave Crocker 675 Spruce Dr. +1 408 246 8253; fax: +1 408 249 6205 Sunnyvale, CA 94086 (USA) ------------------------------------------------------------------------------ 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 Thu Aug 11 16:07:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04565; Thu, 11 Aug 94 16:07:36 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04558; Thu, 11 Aug 94 16:07:26 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20194; Thu, 11 Aug 94 16:04:49 PDT Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA10302; Thu, 11 Aug 94 16:02:24 PDT Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id QAA12371; Thu, 11 Aug 1994 16:01:07 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Aug 1994 16:01:18 -0700 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: (IPng) naming conventions & political correctness in the IETF Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Since there's such intense debate about this question, I'll also cast my vote for IPv6, since we already established the pattern with IPv4. This all harkens back some years ago to extended debates about the name of this protocol stack. Was it TCP/IP, IP/TCP, The Internet Protocol Suite, or what?... We've come along way. This debate looks like it will be shorter and will result in a shorter term. (Well, we DO specialize in short-term solutions...) d/ ----- Dave Crocker 675 Spruce Dr. +1 408 246 8253; fax: +1 408 249 6205 Sunnyvale, CA 94086 (USA) ------------------------------------------------------------------------------ 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 Thu Aug 11 17:38:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04675; Thu, 11 Aug 94 17:38:00 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04669; Thu, 11 Aug 94 17:37:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24156; Thu, 11 Aug 94 17:35:18 PDT Received: from clark.net by Sun.COM (sun-barr.Sun.COM) id AA27930; Thu, 11 Aug 94 17:34:06 PDT Received: (from hcb@localhost) by clark.net (8.6.9/8.6.9) id UAA27385 for ipng@sunroof.Eng.Sun.COM; Thu, 11 Aug 1994 20:33:40 -0400 From: Howard Berkowitz Message-Id: <199408120033.UAA27385@clark.net> Subject: Re: (IPng) naming conventions & political correctness in the IETF To: ipng@sunroof.Eng.Sun.COM Date: Thu, 11 Aug 1994 20:33:39 -0400 (EDT) In-Reply-To: from "Dave Crocker" at Aug 11, 94 04:01:18 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 504 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Since there's such intense debate about this question, I'll also cast my > vote for IPv6, since we already established the pattern with IPv4. > > This all harkens back some years ago to extended debates about the name of > this protocol stack. Was it TCP/IP, IP/TCP, The Internet Protocol Suite, > or what?... > I believe Justice Stewart stated that he could not define it but knew it when he saw it. True, he was referring to hard-core pornography, but we all know mixed stacks like that... ------------------------------------------------------------------------------ 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 Fri Aug 12 07:13:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05078; Fri, 12 Aug 94 07:13:53 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05072; Fri, 12 Aug 94 07:13:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12957; Fri, 12 Aug 94 07:11:07 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AB17235; Fri, 12 Aug 94 07:10:58 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA12848; Fri, 12 Aug 94 06:46:40 -0700 Received: by xirtlu.zk3.dec.com; id AA26815; Fri, 12 Aug 1994 09:46:12 -0400 Message-Id: <9408121346.AA26815@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: Jon Crowcroft , Craig Partridge , int-serv@ISI.EDU, rsvp@ISI.EDU, af-saa@atmforum.com, end2end-interest@ISI.EDU, posix-net-ptp@nemo.ncsl.nist.gov, tmendez@bbn.com, scsmith@bbn.com Subject: Re: (IPng) Re: A Generic Socket Interface for QoS In-Reply-To: Your message of "Sun, 07 Aug 94 08:18:02 PDT." <199408071518.IAA06313@aland.bbn.com> Date: Fri, 12 Aug 94 09:46:06 -0400 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, ---------------------------------------------- FROM Jon Crowcroft > Second, how to integrate scheduling? Remember that in most cases wh ere >we're asking for a QoS guarantee, we also need to make sure that the BSD >scheduler knows to give the real-time application some guarantees about >CPU time. > sp = getschedulebyname("mpeg-2"); > scheduler(sp); why do you need to tell the scheduler anything new - the QoS guarantee for packets is done by sceduling packets in routers - surely the scheduler in the end system can make the same calcuation (or derived one) insterad of burdening the application with an extra system call...? --------------------------------------------- >Hi Jon: > You have to talk to the scheduler because the workload on the end >systems is not simply the cost of moving packets through queues. You also >have to allocate time for the application to process the data. And different >applications will have different processing requirements (there's a big >difference between, say, deciding where to place some bits on a screen and >doing some compression or decompression of video). In other words, the >amount of time required per packet varies widely on a per application basis >and only the application knows how much time it needs per packet if it is >to keep up with the data stream. I have to agree with Jon. The 1003.4 Realtime spec will set realtime switches per implementations. I do not believe IP6 should add scheduling to the API for networking. These should be distinct. What we don't want to do with sockets is overload them to solve the world hunger problem on end systems. At the IP6 implementors meeting in Toronto we also heard a request to add management interfaces to sockets. I also believe this leaving the paradigm for sockets. I think right now its more important to define and efficient and expedient sockets interface that will: 1. Be backwards compatible (and binary) with IPv4. 2. Possibly let the connect() determine the IP6 or IPv4 stack. 3. Update gethostbyxxx() calls that need to understand IP6 | IPv4. Lets solve 80% of the engineering problem and get an API out for folks to work with on IP6. I am working with Bob Gilligan to write the new IP6 API spec and input is needed and I am not hard lined on the above but I would like to see good justifications to alter the present paradigm of the BSD sockets model. I do agree QOS should be a set sockopt. ???? /jim ------------------------------------------------------------------------------ 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 Fri Aug 12 07:37:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05098; Fri, 12 Aug 94 07:37:07 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05092; Fri, 12 Aug 94 07:37:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA13634; Fri, 12 Aug 94 07:34:23 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA20488; Fri, 12 Aug 94 07:34:13 PDT Received: by rodan.UU.NET id QQxcqk01146; Fri, 12 Aug 1994 10:34:11 -0400 Date: Fri, 12 Aug 1994 10:34:11 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Scheduling and QoS.... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, IPv6 should do NOTHING w.r.t. "scheduling", especially in any API. There should be a way to assert that you wish to request a certain QoS, but beyong that, it is pure implementation. There may not even BE a scheduler in the traditional sense, much less anything as, uh, "entertaining" as the POSIX real-time shenanagans. But in any case, it is up to the implementation to provide the requested QoS, or reject the request. Period. Full-Stop. Next Contestant. Anything beyond that is gonna draw heavy flak, I promise you. And be *very* careful with this API stuff - the first-order rule is "The IETF does NOT do APIs, it does PROTOCOLS." That having been said...... There are probably good reasons for some slight deviation from this, but don't expect an API, per se, to go as a real Standard. An Informational as to "How We Hacked Sockets To Do IPv6" is very cool and a much needed part of the work to be done and documented, but PLEASE, don't get this all twisted together with other things. It will only produce grief down the road. Now I'll cede the soapbox back to real work at hand. -Mike ------------------------------------------------------------------------------ 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 Fri Aug 12 21:44:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05461; Fri, 12 Aug 94 21:44:59 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05455; Fri, 12 Aug 94 21:44:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18039; Fri, 12 Aug 94 21:42:14 PDT Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA15478; Fri, 12 Aug 94 21:42:01 PDT Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA04002 for ipng@sunroof.eng.sun.com; Sat, 13 Aug 94 00:41:45 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id VAA00450; Fri, 12 Aug 1994 21:41:10 -0700 Message-Id: <199408130441.VAA00450@aland.bbn.com> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, Jon Crowcroft , Craig Partridge , int-serv@ISI.EDU, rsvp@ISI.EDU, af-saa@atmforum.com, end2end-interest@ISI.EDU, posix-net-ptp@nemo.ncsl.nist.gov, tmendez@bbn.com, scsmith@bbn.com Subject: Re: (IPng) Re: A Generic Socket Interface for QoS In-Reply-To: Your message of Fri, 12 Aug 94 09:46:06 -0400. <9408121346.AA26815@xirtlu.zk3.dec.com> From: Craig Partridge Date: Fri, 12 Aug 94 21:41:09 -0700 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi Jim: I think we're having an agreement of sorts. All my note was trying to say is that a setsockopt() won't solve all the problems related to doing real-time. This isn't to say that I want us to put the scheduling stuff into the API -- that's not our problem -- the socket part is. But if we standardize the socket part and don't point out that scheduling is also needed, we're likely to surprise somebody. Craig ------------------------------------------------------------------------------ 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 Fri Aug 12 22:52:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05525; Fri, 12 Aug 94 22:52:01 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05519; Fri, 12 Aug 94 22:51:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19180; Fri, 12 Aug 94 22:49:15 PDT Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA18124; Fri, 12 Aug 94 22:49:02 PDT Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA06777 for ipng@sunroof.eng.sun.com; Sat, 13 Aug 94 01:00:31 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id VAA00525; Fri, 12 Aug 1994 21:59:51 -0700 Message-Id: <199408130459.VAA00525@aland.bbn.com> To: int-serv@isi.edu, rsvp@isi.edu, af-saa@atmforum.com, end2end-interest@isi.edu, posix-net-ptp@nemo.ncsl.nist.gov, tmendez@bbn.com, scsmith@bbn.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng) Generic Socket QoS stuff and ATM FORUM SAA From: Craig Partridge Date: Fri, 12 Aug 94 21:59:49 -0700 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi folks: I have learned this week that ATM Forum has this bizarre rule that you can't participate in discussions on their mailing lists unless you are an ATM Forum member. While this is obviously busted from the perspective of getting useful technical input into the Forum, I gather they got legal advice they have to do this. So, henceforth, kindly remove the af-saa mailing list from discussions of socket interfaces, QoS standards, et al. I'll try to find some method for communicating with the Forum (smoke signals? :-)) when we decide what the right thing is. Craig ------------------------------------------------------------------------------ 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 Sat Aug 13 03:45:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05587; Sat, 13 Aug 94 03:45:19 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05581; Sat, 13 Aug 94 03:45:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA23738; Sat, 13 Aug 94 03:42:32 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA03716; Sat, 13 Aug 94 03:42:12 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 13 Aug 94 19:32:02 +0900 From: Masataka Ohta Message-Id: <9408131032.AA00908@necom830.cc.titech.ac.jp> Subject: Re: (IPng) Generic Socket QoS stuff and ATM FORUM SAA To: ipng@sunroof.Eng.Sun.COM Date: Sat, 13 Aug 94 19:32:01 JST Cc: int-serv@isi.edu, rsvp@isi.edu, af-saa@atmforum.com, end2end-interest@isi.edu, posix-net-ptp@nemo.ncsl.nist.gov, tmendez@bbn.com, scsmith@bbn.com In-Reply-To: <199408130459.VAA00525@aland.bbn.com>; from "Craig Partridge" at Aug 12, 94 9:59 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 folks: > > I have learned this week that ATM Forum has this bizarre rule that > you can't participate in discussions on their mailing lists unless you > are an ATM Forum member. While this is obviously busted from the perspective > of getting useful technical input into the Forum, I gather they got legal > advice they have to do this. No problem to me. A research group I belong is a member of ATM Forum. > So, henceforth, kindly remove the af-saa mailing list from discussions > of socket interfaces, QoS standards, et al. I'll try to find some method > for communicating with the Forum (smoke signals? :-)) when we decide what the > right thing is. Well, theoretically, we have IP over ATM WG of IETF. But when I mentioned the WG this obvious solution to use setsockopt() for QoS last March, there seems to have been no understanding on the issue. Of course, you may try to reopen it. Masataka Ohta ------------------------------------------------------------------------------ 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 Mon Aug 15 02:27:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06082; Mon, 15 Aug 94 02:27:43 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06076; Mon, 15 Aug 94 02:27:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07499; Mon, 15 Aug 94 02:24:56 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA09354; Mon, 15 Aug 94 02:24:46 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 15 Aug 1994 10:24:08 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; Relayed; Mon, 15 Aug 1994 10:03:05 +0100 Date: Mon, 15 Aug 1994 10:03:05 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003424] X400-Content-Type: P2-1984 (2) Content-Identifier: 3424 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3424*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IP6, IPv6 etc. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As I suggested in Toronto, the new name should differentiate the new effort and a snappier title would inspire the punters. I suggested Global Internet Protocol (GLIP) and a counter suggestion was Connectionless Internet Protocol (CLIP). Prize for the best? Not a Tee shirt though!! Jack ------------------------------------------------------------------------------ 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 Mon Aug 15 06:50:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06177; Mon, 15 Aug 94 06:50:31 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06171; Mon, 15 Aug 94 06:50:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12656; Mon, 15 Aug 94 06:47:45 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA01205; Mon, 15 Aug 94 06:46:52 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA04770; Mon, 15 Aug 94 05:40:30 -0700 Received: by xirtlu.zk3.dec.com; id AA08315; Mon, 15 Aug 1994 08:40:23 -0400 Message-Id: <9408151240.AA08315@xirtlu.zk3.dec.com> To: Craig Partridge Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, Jon Crowcroft , int-serv@ISI.EDU, rsvp@ISI.EDU, af-saa@atmforum.com, end2end-interest@ISI.EDU, posix-net-ptp@nemo.ncsl.nist.gov, tmendez@bbn.com, scsmith@bbn.com Subject: Re: (IPng) Re: A Generic Socket Interface for QoS In-Reply-To: Your message of "Fri, 12 Aug 94 21:41:09 PDT." <199408130441.VAA00450@aland.bbn.com> Date: Mon, 15 Aug 94 08:40:17 -0400 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, ACK OK. /jim ------------------------------------------------------------------------------ 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 Mon Aug 15 10:08:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06397; Mon, 15 Aug 94 10:08:26 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06391; Mon, 15 Aug 94 10:08:19 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20254; Mon, 15 Aug 94 10:05:39 PDT Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA10893; Mon, 15 Aug 94 10:05:25 PDT Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA23809 for ipng@sunroof.eng.sun.com; Mon, 15 Aug 94 13:05:02 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA01779; Mon, 15 Aug 1994 10:04:23 -0700 Message-Id: <199408151704.KAA01779@aland.bbn.com> To: end2end-interest@isi.edu, int-serv@isi.edu To: ipng@sunroof.Eng.Sun.COM, posix-net-ptp@nemo.ncsl.nist.gov Subject: (IPng) various questions about Generic QoS Socket Interface From: Craig Partridge Date: Mon, 15 Aug 94 10:04:21 -0700 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi folks: Thanks for all the notes and comments so far on the socket interface for QoS. I've been hoarding up the various questions and now that e-mail is tapering off, I think I can hazard trying to reply to some of them, in one note. First, Bob Durst asked how QoS gets handled by sockets at the server side (i.e., listen/accept path). My working plan is that the receiver checks that the QoS is OK by doing a getsockopt after accepting the connection. The logic is that in some cases the receiver won't care about QoS, so we shouldn't force a new call into the series. (For instance, a sending FTP may request a QoS but the receiving FTP need never know about the QoS to work properly). If the receiver doesn't like the QoS, it closes the connection. An open question for me is whether we could allow the listening socket to establish a minimum (or max) QoS, against which the kernel could do a sanity check on the connection request before creating the new socket to accept. I think this depends heavily on how complex the QoS structure is, and I don't think the problem is worth fussing over very much. A touchier question is how to handle cases where one wants to examine the QoS before actually establishing the connection. The problem in BSD is that an application needs a socket handle (i.e. a file descriptor) to be able to reject a connection -- which means one has to do an accept first. My recollection is that 4.4BSD hacks the semantics of accept to permit examining the socket before the kernel sends back an OK (for TP4), though I can't find details of the change in the BSD code. If possible, I'd use this hack. If not, there are other ways to skin this cat (like a blocking getsockopt() option to read the QoS of the socket on the front of the listen queue). Second, the note from Geoff at Lancaster raised several issues some of which I've revised here to present as questions: 1. is the QoS idea geared to stream data? Not intentionally. My thought had been that for connectionless data, the call to sendto() would implicitly force the creation of a QoS to the destination of the sendto() call. 2. can this work for pipelines of processes? I would hope so. It seems to me that establishing a QoS on a socket over a loopback interface makes perfect sense. 3. can the socket API support direction connections to kernel managed devices like video cards? I think this is a matter of memory management. Certainly if an application can map the video card memory into its memory space, then an application can do a send() or receive() from or to the video memory and cause direct transfer of memory without going through kernel buffers. I like this approach because it leaves the application in the control path to deal with oddities like control instructions from the user. Third, Gopal at Wash University suggested using QoS structures based on application classes (isochoronous, etc). I confess that personally I really dislike this approach. It tends to create a multiplicity of QoS structures based on (what I consider to be arbitrary) taxonomies of applications. Part of my dislike comes from the fact that token-bucket schemes (what ATM and FR use) can express the range of applications from isochronous to bursty using a single QoS structure. So I'd prefer a generic structure if we can do it. (The major impediment I see is if some new real-time protocol comes up with a QoS system which is richer than token bucket and thus we cannot easily map from our generic token bucket into the richer QoS space). Overall, comments were generally positive so I'm going to try to take some time to put the ideas into a more detailed paper that can be circulated around. Craig ------------------------------------------------------------------------------ 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 Wed Aug 17 10:09:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08271; Wed, 17 Aug 94 10:09:36 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07957; Tue, 16 Aug 94 20:47:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14930; Tue, 16 Aug 94 20:45:07 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA07571; Tue, 16 Aug 94 20:44:54 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 17 Aug 1994 13:40:26 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 17 Aug 1994 13:41:00 +1000 X400-Received: by /PRMD=/ADMD=otc/C=au/; Relayed; Wed, 17 Aug 1994 13:42:13 +1000 X400-Received: by /PRMD=SA/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 17 Aug 1994 13:41:00 +1000 Date: Wed, 17 Aug 1994 13:41:00 +1000 X400-Originator: DAVID.BRUCE-STEER@saa.sa.telememo.au X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=SA/ADMD=TELEMEMO/C=AU/;G30021167C0200000101000129B80001] X400-Content-Type: P2-1984 (2) From: BRUCE-STEER DAVID (Tel \(02\)746 4829) Message-Id: To: ipng@sunroof.Eng.Sun.COM (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: (IPng) FWD:COMMENTS ON IPNG Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM LLOYD ALAN: >Forwarded to: x400@mis@dcpmel[c=au;a=telememo;p=sa;o=saa;s=bruce-steer;] > cc: >Comments by: Alan Lloyd@Marketing@DCTHQ >Comments: > > > -------------------------- [Original Message] ------------------------- > >gentlemen... > >I am somewhat associated with the development of OSI and large scale carrier, >defence and govt networks and have just seen the documents from brian@ SUN >released on IPNG and its new address forms and inclusion of NSAPs.. Oh dear! > >From an overall perspective I am concerned why 16 byte addressing has been >chosen >What is the rationale for this knowing that OSI uses 20 bytes? > > >The comments in the document associated with applying NSAPAs to the 16 byte >form is certainly US and Internet centric (as one would expect). However, >perhaps the following should be observed. > >Networks have been for some time and still ARE being designed with full >length NSAPs and therefore need the full 20 byte form. > > > >NSAP Structure -- It is more than just "20 bytes". > >The NSAP format provides an ISO agreed routing hierarchy which is also >related to the administration hierarchy of countries, authorities, sub >registration authorities (SRAs) and Sub RAS (SSRAs).. These have been >formally established within countries and large organisations. > > >With ISO NSAPS we can design globally ready networks for national >infrastructure (ie. global infrastructure).. eg. for aviation, defence, >transport systems because we can logically address aircraft, tactical units, >ships - emergency vehicles, etc. AND this design, allocation and >implementation process has started.. > > >NSAPs are also configured into millions of OSI products such as routers, >switches, X.400, X.500 and X.700 systems - in fact these last application >level products have to be configured to evaluate the data syntax (not just >bitstring compare) of NSAPs to do searches and check for equivalence... etc. > > >There are many ITU documents contain definitions of NSAPs.. eg X.300 >(Network Interworking), Q.2931 (ISDN and B-ISDN signalling) and X.25 >facilities as well as all the X.500 and X.700, CLNP/ES-IS and IS-IS code and >documents that reside on this planet.. > > >So with all this in place.. why is IPNG is now planning to have ANOTHER NSAP >format. > >It is not just a question that US GOSIP does not use NSAPs widely.. >Or that one can truncate 20 bytes into 16 because of perceived unused fields. > >IT is a question of the extra cost in implementing code and configuration >tools in every piece of internetworking equipment.. and X.400 messaging, >X.500 directory systems and X.700 management systems right across the planet >to deal with two formats of the same information. >Plus many people will have to deal with two network design methodologies and >possibly address registration facilities. > > > >Given the assumption that the Internet and every TCP/IP product will have to >be upgraded to adopt IPNG.. ($BBBB) Is the IETF also requesting that all the >OSI products and documents in existance etc are also upgraded to cater for >two forms of NSAPs. AS there will be no single network out there which >will escape OSI NSAPs or interworking with IPNG. > > > >Is it not more logical to adopt 20 byte addressing in IPNG NOW and then >utilise an ICD for the Internet (as do other global and national >organisations) and permit sub division of the Internet space within this ie.. >an RD for 4 byte addressing and RDs for logical components of the bigger >Internet. > > >Where broadcast and other "internetwork" features are required other fields >can be used .. eg.. NSEL at the low end if that is appropriate or >identification in the routing domain .. if the higher level broadcasting is >used. > > > >On a small point.. the comment that NSEL is not required because TCP/UDP do >not use it.. Is it not possible that voice, video and image could be >transferred over IPNG in the future and this could have "network service" >selection requirements.. > > > >In closing .. and not being party to the initial decision.. >Please can you inform me why the 16 byte addressing scheme has been chosen >when the Internet has to be reconfigured anyway.. > >Is there any reason why the Internet addressing cannot just be structured as >an independent ICD with a field set aside for indicating backwards >compatibility or broadcast features? > >What are the issues with NSAPs and IPNG.. eg is an option that the 16 bytes >could be used and another 4 as address extensions... as per X.25 facilities? >and then the whole NSAP (as defined by ISO and the ITU) will fit correctly >and be compatible. > > > >Regards Alan Lloyd > >alan@datacraft.oz.au >X.400 G=alan;s=lloyd;o=dcthq;p=datacraft;a=telememo;c=au ------------------------------------------------------------------------------ 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 Wed Aug 17 10:11:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08290; Wed, 17 Aug 94 10:11:32 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07927; Tue, 16 Aug 94 18:25:35 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA11153; Tue, 16 Aug 94 18:22:53 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA23744; Tue, 16 Aug 94 18:22:35 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 17 Aug 1994 11:18:48 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 17 Aug 1994 11:20:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 17 Aug 1994 10:29:16 +1000 Date: Wed, 17 Aug 1994 10:29:16 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: bruce-steer@saa.sa.telememo.au, kim.fenley@cm-dimp.aditcs.hqadf.defencenet.gov.au, ipng@sunroof.eng.sun.com, tli@cisco.com, yakov@watson.ibm.com X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 940817 09:24:03 024] X400-Content-Type: P2-1984 (2) Content-Identifier: 940817 09:24:03 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"940817 09:24:03*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: bruce-steer@saa.sa.telememo.au (Non Receipt Notification Requested), kim.fenley@cm-dimp.aditcs.hqadf.defencenet.gov.au (Non Receipt Notification Requested), ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested), tli@cisco.com (Non Receipt Notification Requested), yakov@watson.ibm.com (Non Receipt Notification Requested) Subject: (IPng) RE RECOMMENDATIONS FOR IPV6 ADDRESSING. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM tony, yakov - re the document on IPv6 addressing and its recommendations.. Please do not see me as a religious OSI person (even though I probably am!!) Many of the points raised and described are dealt with in the Network layer defintions and routing standards as used by OSI.. ie NSAPs provide both dependent routing schemes eg.. E.164,X.121,etc and the ICD and DCC forms provide network independent schemes. These schemes permit the Internetworking to be performed on fixed geographic - technology dependent networks or logicical internetworking using independednt schemes (ICD and DCC) which can traverse geographic boundaries (over dependent networks).. The difference with ICD and DCC forms is that one is "Administered" at the global level and the other (DCC) at the national level.. (DCC is sometimes considered as working only WITHIN a country! wrong!) Both ICD and DCC interwork and permit allocation and subdivision of RDs in a logical, functional or geographic way.. it depends on the organisations requirements .. in terms of demographics and geographical distribution of their operations.. So the NSAPs and the OSI network layer organisation, routing architectures and relay functions should be included I feel in the evaluation of the way in which IPng addressing is developed.. certainly if they are referenced in your recommendations it would indicate some level of applicability and harmonisation. Certainly I would still like to see if the IETF have identified any problems with OSIs addressing and routing architectures which are "show stoppers".. that way we can fix them. Finally, I am doing a bit of work on Intelligent Network Architectures (Q.12xx) and B-ISDN signalling (Q.293B) and because NSAPs and E.164 are specified in the called/calling address structures it is important that carrier based signalling is compatible with IPng addressing. Particularly as we move to Universal Personallised Telecommunications (UPT) and the emerging mobile services (FPLMTS) which requires international roaming, identification, billing, security, etc and the ability to access data and video networks.. It is for this reason that I see the longer term that the use of NSAPs and the OSI routing designs are critical to IPngs evolution.. Regards Alan my email preference is X.400.. c=au;a=telememo;p=datacraft;o=dcthq;g=alan;s=lloyd; ------------------------------------------------------------------------------ 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 Wed Aug 17 13:37:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08421; Wed, 17 Aug 94 13:37:28 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08415; Wed, 17 Aug 94 13:37:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA16878; Wed, 17 Aug 94 13:34:38 PDT Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA07584; Wed, 17 Aug 94 13:34:26 PDT Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.4/8.6.4) with ESMTP id QAA29366 for ; Wed, 17 Aug 1994 16:34:20 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.4/8.6.4) with SMTP id QAA13112 for ; Wed, 17 Aug 1994 16:34:20 -0400 Received: from grid (bobsgrid.clis.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA26077; Wed, 17 Aug 94 16:40:34 EDT Message-Id: <9408172040.AA26077@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Aug 1994 16:34:22 -0500 To: ipng@sunroof.Eng.Sun.COM From: "Robert G. Moskowitz" <0003858921@mcimail.com> (by way of RGMoskowitz-3@is.chrysler.com (Robert Moskowitz)) Subject: (IPng) Re: local address token... X-Mailer: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This is from a discussion that was going on on addrconf. The issue is the MAC address option. ----------------- Forwarded Message Date: Tue Aug 16, 1994 8:03 AM EST To: Scott Bradner EMS: INTERNET / MCI ID: 376-5414 MBX: sob@hsdndev.harvard.edu TO: GeertJan.deGroot EMS: INTERNET / MCI ID: 376-5414 MBX: GeertJan.deGroot@ripe.net TO: mo EMS: INTERNET / MCI ID: 376-5414 MBX: mo@uunet.uu.net CC: addrconf EMS: INTERNET / MCI ID: 376-5414 MBX: addrconf@cisco.com Subject: Re: local address token... Message-Id: 52940816121325/0003858921NA3EM >> An alternative (but more complex, sorry Mike!) would be to hash >> the MAC address to something like, say, 16 bits, and ARP for >> the result. If no answer was found, take the suffix. >Since I think the address must be verified anyway (unless one is using >a 100% guaranteed unique cookie ) this sounds like a good idea to me. The use of MAC addresses in the IP6 format has bothered me a lot. Thus I really should post this also to IPng list, but lets first work out somethings here.... As I understand it, the call for MAC addresses was for the serverless model: Just tell the router our MAC address (or some other token!) and it would combine it with the topology info to make your full address for you. Much like IPX does now. But those 6 bytes are VERY expensive. That is 3/4 of the subscriber portion of the address. Not much left for topology. Now consider that there are very few different brands of cards within a topology, given a 99 percentile max of 1,000 devices within a topological level (I kind of think that even 30 years from now the worst case won't be much more). Thus it seems to me that some of the mathematicians here (hey Ohta San!) could work out a reasonable one-way hash of a MAC address to get it down to 16 bits for sure, maybe even 12 bits. If it is a one-way hash, even I won't be concerned about using this in my addressing scheme! Can we PLEASE investigate this before MAC addresses get too set into the address format? If we get a good working model for the serverless networks without them, we can forward it to the IPng list for a spec change there.... Bob Moskowitz Chrysler ------------------------------------------------------------------------------ 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 Wed Aug 17 14:00:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08442; Wed, 17 Aug 94 14:00:19 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08436; Wed, 17 Aug 94 14:00:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18089; Wed, 17 Aug 94 13:57:27 PDT Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA12366; Wed, 17 Aug 94 13:57:03 PDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13103; 17 Aug 94 16:55 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-mcdonald-readable-keys-00.txt Date: Wed, 17 Aug 94 16:55:01 -0400 Message-Id: <9408171655.aa13103@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart Note: This is a re-send announcement with a correction made on the ipng address. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Convention for Human-Readable 128-bit Keys Author(s) : D. McDonald Filename : draft-mcdonald-readable-keys-00.txt Pages : 15 Date : 08/16/1994 With the emergence of keyed MD5 as a common Internet authentication mechanism, 128-bit keys are becoming common. This draft proposes a convention for representing 128-bit keys in a string of 12 small English words. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-mcdonald-readable-keys-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-mcdonald-readable-keys-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: <19940816151252.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-mcdonald-readable-keys-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-readable-keys-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940816151252.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ 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 Wed Aug 17 14:28:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08485; Wed, 17 Aug 94 14:28:41 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08395; Wed, 17 Aug 94 13:36:12 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA16819; Wed, 17 Aug 94 13:33:23 PDT Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA07232; Wed, 17 Aug 94 13:33:12 PDT Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.4/8.6.4) with ESMTP id QAA29363 for ; Wed, 17 Aug 1994 16:33:08 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.4/8.6.4) with SMTP id QAA13109 for ; Wed, 17 Aug 1994 16:33:08 -0400 Received: from grid (bobsgrid.clis.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA26064; Wed, 17 Aug 94 16:39:22 EDT Message-Id: <9408172039.AA26064@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Aug 1994 16:33:10 -0500 To: ipng@sunroof.Eng.Sun.COM From: RGMoskowitz-3@is.chrysler.com (Robert Moskowitz) Subject: (IPng) Mail problems X-Mailer: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This time I REALLY did have a mail problem. I've been switching, slowly, from my MCI account to my firewall account. And I fat fingered the special alias I set up for IPNG. The result is the last message I received was: Date: Mon Aug 15, 1994 10:14 pm EST Source-Date: Mon, 15 Aug 94 18:44:10 PDT From: greg minshall EMS: INTERNET / MCI ID: 376-5414 MBX: greg_minshall@novell.com TO: * Robert G. Moskowitz / MCI ID: 385-8921 TO: addrconf EMS: INTERNET / MCI ID: 376-5414 MBX: addrconf@cisco.com Subject: Re: (sipp) E.164 mapping into IPv6 Message-Id: 44940816031444/0003765414DC2EM Source-Msg-Id: <9408160144.AA01127@WC.Novell.COM> Then just a little while ago (after fixing the alias problem) I got: Return-Path: X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 17 Aug 1994 13:40:26 +1000 So I assume I missed a lot. Can someone EMail me privately that can send me those messages. Just what I need more back reading.... Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ 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 Wed Aug 17 14:30:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08498; Wed, 17 Aug 94 14:30:37 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08448; Wed, 17 Aug 94 14:08:35 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18372; Wed, 17 Aug 94 14:05:52 PDT Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA13769; Wed, 17 Aug 94 14:05:35 PDT Message-Id: <9408172105.AA13769@Sun.COM> From: smb@research.att.com Received: by gryphon; Wed Aug 17 16:45:41 EDT 1994 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: local address token... Date: Wed, 17 Aug 94 16:45:40 EDT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Thus it seems to me that some of the mathematicians here (hey Ohta San!) could work out a reasonable one-way hash of a MAC address to get it down to 16 bits for sure, maybe even 12 bits. If it is a one-way hash, even I won't be concerned about using this in my addressing scheme! The problem is that you run up against the birthday paradox. If there are 12 bits of addressing, the odds on a collision are about 50% when the population reaches about 2^6. That's why cryptographic hash functions have output sizes roughly twice the key length of an encryption algorithm of comparable strength (i.e., SHS vs. Skipjack). ------------------------------------------------------------------------------ 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 Wed Aug 17 14:34:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08514; Wed, 17 Aug 94 14:34:29 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08508; Wed, 17 Aug 94 14:34:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19525; Wed, 17 Aug 94 14:31:40 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA18647; Wed, 17 Aug 94 14:31:25 PDT Message-Id: <9408172131.AA18647@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2645; Wed, 17 Aug 94 17:31:23 EDT Date: Wed, 17 Aug 94 17:30:19 EDT From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) question about cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, >From Section 2.3.5 of draft-ietf-sipp-routing-addr-02.txt: To reach the nearest boundary router for subscriber S of provider D, a packet may be sent to the following cluster address: | 2 | m bits | n bits | 128-m-n bits | +----+--------------+----------------+----------------------------+ | 01 | provider = D | subscriber = S |0000000000000000000000000000| +----+--------------+----------------+----------------------------+ When a boundary router for subscriber S of provider D receives a packet destined to the following cluster address: | 2 | m bits | 128-m bits | +----+--------------+---------------------------------------------+ | 01 | provider = D |000000000000000000000000000000000000000000000| +----+--------------+---------------------------------------------+ should the router accept the packet as being addressed to itself or not ? 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 Wed Aug 17 16:03:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08567; Wed, 17 Aug 94 16:03:26 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08561; Wed, 17 Aug 94 16:03:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24466; Wed, 17 Aug 94 16:00:32 PDT Received: from CU.NIH.GOV by Sun.COM (sun-barr.Sun.COM) id AA09254; Wed, 17 Aug 94 16:00:21 PDT Message-Id: <9408172300.AA09254@Sun.COM> To: ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Wed, 17 Aug 1994 18:57:46 EDT Subject: Re: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > An Architecture for IPv6 Unicast Address Allocation > > > ... > > If a direct service provider is connected to another provider(s) > (either direct or indirect) via multiple attachment points, then in > certain cases it may be advantageous to the direct provider to exert > a certain degree of control over the coupling between the attachment > points and flow of the traffic destined to a particular subscriber. > Such control can be facilitated by first partitioning all the > subscribers into groups, such that traffic destined to all the > subscribers within a group should flow through a particular > attachment point. Once the partitioning is done, the address space of > the provider is subdivided along the group boundaries. A leaf routing > domain that is willing to accept prefixes derived from its direct > provider gets a prefix from the provider's address space subdivision > associated with the group the domain belongs to. Note that the > advertisement by the direct provider of the routing information > associated with each subdivision must be done with care to ensure > that such an advertisement would not result in a global distribution > of separate reachability information associated with each > subdivision, unless such distribution is warranted for some other > purposes (e.g. supporting certain aspects of policy-based routing). In order to be effective, these groupings of subscribers have to be made known outside the provider's network. Is it expected that this will be done in the same way by all providers? I don't recall any provision for a group field in the address formats draft. Will it be possible to have symmetrical routing between subscribers on different providers in this environment? It seems like that might be easier if providers used the same geographical groupings, but that may not be practical. ------------------------------------------------------------------------------ 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 Wed Aug 17 17:55:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08651; Wed, 17 Aug 94 17:55:47 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08590; Wed, 17 Aug 94 16:50:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA26624; Wed, 17 Aug 94 16:48:12 PDT Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA18946; Wed, 17 Aug 94 16:47:57 PDT Message-Id: <9408172347.AA18946@Sun.COM> From: keshav@research.att.com Date: Wed, 17 Aug 94 19:44 EDT To: end2end-interest@ISI.EDU, int-serv@ISI.EDU, ipng@sunroof.Eng.Sun.COM, posix-net-ptp@nemo.ncsl.nist.gov Subject: (IPng) Re: Generic QoS Socket Interface Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, Gopal, Geoff and others, Here are some thoughts on how application ought to specify a QoS to the network (and how this QoS should be provided by the network). Much of this arises from work that we have been doing at Bell Labs since June 92 in the Xunet testbed. What we have in place now is a 'native-mode' ATM stack that allows applications to specify per connection QoS, and signaling and OS hooks as well as the protocol stack to provide this QoS. Some of this work will appear in a paper in the coming Sigcomm. If I understand Craig correctly, he wants to work under the constraint that existing applications ought to be easily ported to the QoS enhanced sockets. This is achieved by keeping the socket interface the same, but putting hooks into the bind/connect calls to set up a QoS provisioned ATM VCI. The QoS would be specified by the setsockopt call. I believe that we should view the QoS in the following way. The client sends a specification via signalling to the server. The server has a chance to accept the connection, and _modify_ this QoS, depending on its current load. The modified string is then used to relax the network's reservation state, and passed back to the client. The client sees the modified QoS, and if it doesnt like it, tears down the call. This way, both the client and the server have a chance to negotiate the QoS before tha call completes. The first problem with setsockopt is that it is a one-way street - an application can specify what quality it wants, but cannot receive information back about what information the network can actually provide. One way out is to have a poll loop on getsockopt(), waiting for something to change. This is not elegant. Another, dirtier, solution is the one proposed earlier in this thread, where an application would pause awaiting a signal, which would be delivered on call completion. In our solution, the client makes a call to a library routine, which in turn makes an RPC to the signalling entity (running in user space - more on this later). The library routine also passes in what is effectively a handle into an RPC stub where the signaling entity can call back back when signaling completes. When this stub is called, the client can see what QoS value was returned, and if this is not satisfactory, the socket() call need not be made. The second problem with Craig's solution is that by using setsockopt to pass in QoS info, he is forcing the implementation of signaling to be in the kernel (unless the bind/connect calls make an upcall from the kernel to a signaling entity in user space). Having worked with two signaling implementations, it is very clear, at least to me, that putting signaling in the kernel is a bad idea. There are far too many things that can go wrong, and it is a big win to be able to restart signaling in user space, instead of rebooting the kernel each time. Now, if you accept that signaling is in user space, then separating call establishment (and QoS specification) from the socket abstraction is a small next step. This is what we have done. The signaling entity is a user level process, which is accessed by a call-estblishment library using RPC-like calls. This approach has three advantages: 1) signaling can run in user space 2) client see the modified QoS string. 3) if the qos string changes (because today's flavor is different from yesterday's), we recompile and run, instead of rebooting every system we have. Such libraries are easily provided in all operating systems, and it is trivial to add it to Unix. So, this solution satisfies Craig's constraints. A code fragment from our implementation: client: vci = open_connection(dest, service, portno, out_comment, out_res, in_commen t, &in_res); /* dest is the dest ATM address, service is like a /etc/services port, portno is the local RPC stub, out_res is the outgoing qos string, the comment strings are for experimanting with */ sd = socket(AF_XUNET, SOCK_DGRAM, 0); addr.family = AF_XUNET; addr.chan = vci; connect(sd, &addr, sizeof(addr) On the server side, the corresponding calls are export_service(service, portno); cookie = await_service_request(listen_sock, comment, &res); vci = accept_connection(cookie, comment, res); sd = socket(AF_XUNET, SOCK_DGRAM, 0); addr.family = AF_XUNET; addr.chan = vci; bind(sd, &(addr), sizeof(addr)) Note the use of a cookie (capability) which makes sure that no one can hijack an open connection. More details about this are in the Sigcomm paper. ------------------------ The Chorus work has carried out the QoS concept much farther, but without Craig's constraints. Their use of 'direct connections' is very nice (and something that one Xunet student wants to do in IRIX/Plan 9). But, the use of a dummy upcall to an application sounds pretty complicated as an API. One has to be fairly sure of the 'average' case, and further, the avarage and worst cases should be close to each other. Otherwise, the scheduler doesnt have much to go on. ------------------------- Gopal proposes that protocol stack code be linked into an app to allow per-process QoS from the scheduler. This seems to be a good idea. We are working on similar lines using Plan 9. In any case, since we have a non-multiplexing stack, we can easily associate a process with one or more tasks (each layer of the stack is an independently schedulable task). This would allow scheduling of the protocol tasks and the user process in a reasonable manner, even if the protocol lies inside the kernel. At the moment, we only have hooks for task scheduling, and are fishing around for policies. ----------------------------- Any comments on our design are welcome, either on this list, or in person during Sigcomm. keshav ------------------------------------------------------------------------------ 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 Wed Aug 17 18:42:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08667; Wed, 17 Aug 94 18:42:16 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08661; Wed, 17 Aug 94 18:42:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA01105; Wed, 17 Aug 94 18:39:25 PDT Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA05114; Wed, 17 Aug 94 18:39:11 PDT Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA16732 for ipng@sunroof.eng.sun.com; Wed, 17 Aug 94 20:42:17 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id RAA04237; Wed, 17 Aug 1994 17:41:33 -0700 Message-Id: <199408180041.RAA04237@aland.bbn.com> To: keshav@research.att.com Cc: end2end-interest@isi.edu, int-serv@isi.edu, ipng@sunroof.Eng.Sun.COM, posix-net-ptp@nemo.ncsl.nist.gov Subject: (IPng) Re: Generic QoS Socket Interface In-Reply-To: Your message of Wed, 17 Aug 94 19:44:00 -0400. <9408172349.AA12898@nemo.ncsl.nist.gov> From: Craig Partridge Date: Wed, 17 Aug 94 17:41:32 -0700 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi Keshav: Thanks very much for the comments. I want to think some of them over some more but I have a two immediate comments. If I understand Craig correctly, he wants to work under the constraint that existing applications ought to be easily ported to the QoS enhanced sockets. Not quite my goal. My goal is that all QoS needy applications use the same basic interface, regardless of protocol stack (IP with integrated services, ATM, IPX with integrated services, whatever). The first problem with setsockopt is that it is a one-way street - an application can specify what quality it wants, but cannot receive information back about what information the network can actually provide. One way out is to have a poll loop on getsockopt(), waiting for something to change. This is not elegant. Another, dirtier, solution is the one proposed earlier in this thread, where an application would paus e awaiting a signal, which would be delivered on call completion. I don't think so. When using connect() the semantics of connect() are that the call doesn't return until the connection is made. For UDP without QoS this is trivial and connect() returns immediately but for UDP w/QoS (and for TCP now) connect() would wait until the net OK came back and then could examine the QoS. And UDP already supports multiple calls to connect. I'll note that I think the interface *should not* enforce a given negotiation model. So one way (only get to say QoS and not dicker) should work as should two way. Craig PS: What are the error scenarios in the user interface? The code for the usual case looks OK but what cleanup has to be done (say if socket fails after a vci is created)? ------------------------------------------------------------------------------ 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 Wed Aug 17 23:07:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08856; Wed, 17 Aug 94 23:07:48 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08850; Wed, 17 Aug 94 23:07:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07806; Wed, 17 Aug 94 23:04:58 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AB26131; Wed, 17 Aug 94 23:04:41 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 18 Aug 94 14:57:48 +0859 From: Masataka Ohta Message-Id: <9408180558.AA17045@necom830.cc.titech.ac.jp> Subject: Re: (IPng) Re: Generic QoS Socket Interface To: ipng@sunroof.Eng.Sun.COM Date: Thu, 18 Aug 94 14:57:46 JST Cc: end2end-interest@ISI.EDU, int-serv@ISI.EDU, posix-net-ptp@nemo.ncsl.nist.gov In-Reply-To: <9408172347.AA18946@Sun.COM>; from "keshav@research.att.com" at Aug 17, 94 7:44 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I believe that we should view the QoS in the following way. The client > sends a specification via signalling to the server. The server has > a chance to accept the connection, and _modify_ this QoS, depending on > its current load. The modified string is then used to relax the > network's reservation state, and passed back to the client. There are a lot of people who thinks differently in a lot less connection oriented way. That is, a client periodically sends reservation packets to the destination. Intermediate relaying entities such as routers or bridges may or may not grant the reservation and may notify the denied grant to the client. > Having worked with two signaling implementations, > it is very clear, at least to me, that putting > signaling in the kernel is a bad idea. There are far too many things > that can go wrong, and it is a big win to be able to restart signaling > in user space, instead of rebooting the kernel each time. Then, what is wrong is the signaling specification, not rest of the world. Anyway, the current ATM QoS with Q.2931 packet is no effective beyond IP routers and can not be a basis of QoS specification for the Internet. Masataka Ohta ------------------------------------------------------------------------------ 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 Thu Aug 18 01:13:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08881; Thu, 18 Aug 94 01:13:17 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08875; Thu, 18 Aug 94 01:13:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10683; Thu, 18 Aug 94 01:10:26 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA10651; Thu, 18 Aug 94 01:10:15 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA08772; Thu, 18 Aug 1994 10:11:58 +0200 Message-Id: <199408180811.AA08772@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) question about cluster addresses In-Reply-To: Your message of "Wed, 17 Aug 1994 17:30:19 EDT." <9408172131.AA18647@Sun.COM> Date: Thu, 18 Aug 1994 10:11:57 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM => | 2 | m bits | 128-m bits | => +----+--------------+---------------------------------------------+ => | 01 | provider = D |000000000000000000000000000000000000000000000| => +----+--------------+---------------------------------------------+ => => should the router accept the packet as being addressed to itself or not ? Not. A cluster is a connected set of routers and hosts that share the same addressing prefix. Only the provider's router share the provider prefix. You can analyse that from a routing table point of view. At a customer site, there is a routing entry for the provider prefix, i.e. the aggregated route towards all the provider's customers. In the provider backbone, such an aggregation has little meaning. Christian Huitema ------------------------------------------------------------------------------ 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 Thu Aug 18 07:05:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09473; Thu, 18 Aug 94 07:05:15 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09467; Thu, 18 Aug 94 07:05:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18029; Thu, 18 Aug 94 07:02:25 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA18961; Thu, 18 Aug 94 07:02:15 PDT Message-Id: <9408181402.AA18961@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8805; Thu, 18 Aug 94 10:02:18 EDT Date: Thu, 18 Aug 94 10:00:47 EDT From: yakov@watson.ibm.com To: Christian.Huitema@sophia.inria.fr Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian, >A cluster is a connected set of routers and hosts that share the same >addressing prefix. Assume that you have a provider X and a set of subscribers, S1, S2, etc.. attached to X. The provider uses the block of addresses | 2 | m bits | n bits | +----+--------------+----------------+ | 01 | provider = D | K | +----+--------------+----------------+ for assignment of addresses inside the provider (e.g. for routers). The subscriber S1 uses the block of addresses | 2 | m bits | n bits | +----+--------------+----------------+ | 01 | provider = D | subscriber = S1| +----+--------------+----------------+ for assignment of addresses inside the subscriber. Now consider a segment of topology that includes the set of routers and hosts from both X and S1. The set is connected and shares the same addressing prefix, namely D. Is that a cluster (in your definition) ? And if yes, then what is the cluster address(es) of that 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 Thu Aug 18 07:30:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09554; Thu, 18 Aug 94 07:30:57 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09548; Thu, 18 Aug 94 07:30:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18923; Thu, 18 Aug 94 07:28:07 PDT Received: from FNAL.FNAL.GOV by Sun.COM (sun-barr.Sun.COM) id AA22313; Thu, 18 Aug 94 07:27:56 PDT Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HG1SYECSI80076P0@FNAL.FNAL.GOV>; Thu, 18 Aug 1994 09:27:48 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA28222; Thu, 18 Aug 94 09:27:02 CDT Date: Thu, 18 Aug 1994 09:27:01 -0500 From: Matt Crawford Subject: Re: (IPng) question about cluster addresses In-Reply-To: Your message of Thu, 18 Aug 94 10:11:57 +0100. <199408180811.AA08772@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Message-Id: <9408181427.AA28222@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > => | 2 | m bits | 128-m bits | > => +----+--------------+---------------------------------------------+ > => | 01 | provider = D |000000000000000000000000000000000000000000000| > => +----+--------------+---------------------------------------------+ > => should the router accept the packet as being addressed to itself or not ? > > Not. Ditto. Besides Christian's arguments based on the definition of a cluster, having a subscriber's router consume this packet would take away that subcriber's ability to anycast to the provider. That ability probably has non-zero value. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab ------------------------------------------------------------------------------ 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 Thu Aug 18 07:43:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09656; Thu, 18 Aug 94 07:43:12 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09650; Thu, 18 Aug 94 07:43:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19376; Thu, 18 Aug 94 07:40:23 PDT Received: from FNAL.FNAL.GOV by Sun.COM (sun-barr.Sun.COM) id AA24103; Thu, 18 Aug 94 07:40:12 PDT Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HG1TDQI15C0071AX@FNAL.FNAL.GOV>; Thu, 18 Aug 1994 09:40:10 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA28287; Thu, 18 Aug 94 09:39:24 CDT Date: Thu, 18 Aug 1994 09:39:23 -0500 From: Matt Crawford Subject: Re: (IPng) cluster addresses In-Reply-To: Your message of Thu, 18 Aug 94 10:00:47 EDT. <9408181402.AA18961@Sun.COM> To: ipng@sunroof.Eng.Sun.COM Message-Id: <9408181439.AA28287@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Now consider a segment of topology that includes the set > of routers and hosts from both X and S1. The set is connected > and shares the same addressing prefix, namely D. Is that a cluster > (in your definition) ? No, they have "a common prefix", but they don't have "the same prefix". Specifically, the routers in S1 are advertising the prefix [ 01 . D . S1 ], or even longer prefixes, on the local subnetworks. Are you leading us down the Socratic path to the question of whether their can be clusters within clusters? I think it would be a bad idea to have subscriber routers answer to the provider's cluster address, but I can imagine cases where it might be desirable for routers to be members of a cluster and a "supercluster". Hmmmm. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab ------------------------------------------------------------------------------ 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 Thu Aug 18 07:53:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09695; Thu, 18 Aug 94 07:53:01 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09689; Thu, 18 Aug 94 07:52:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19822; Thu, 18 Aug 94 07:50:09 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA25754; Thu, 18 Aug 94 07:49:46 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA13597; Thu, 18 Aug 94 07:41:38 -0700 Received: by xirtlu.zk3.dec.com; id AA14363; Thu, 18 Aug 1994 10:40:35 -0400 Message-Id: <9408181440.AA14363@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Oct 10-14 IPng Implementors and Base Group Meeting Date: Thu, 18 Aug 94 10:40:29 -0400 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 All, On Friday in Toronto at the implementors meeting we decided we would have an interim meeting for implementors and the base WG for IPng. It was decided to have this meeting in New England. This is a nice time of year here too. Ross Callon and I are going to work together to figure out the logistics. So we need to know how many of you folks would actually come to the meeting. We hope to have Mbone for parts of the meeting, but we need you folks present (especially the Chairs and document authors) to have a really good and effective meeting. Please respond if you can come to Boston we need an idea of headcount to determine location and other logistics. Also if you have any questions on things you may want to do the weekend before or while your here send me private mail. thanks /jim ------------------------------------------------------------------------------ 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 Thu Aug 18 07:55:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09729; Thu, 18 Aug 94 07:55:56 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09723; Thu, 18 Aug 94 07:55:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19905; Thu, 18 Aug 94 07:53:07 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA26255; Thu, 18 Aug 94 07:52:54 PDT Received: by rodan.UU.NET id QQxdmp18307; Thu, 18 Aug 1994 10:52:48 -0400 Date: Thu, 18 Aug 1994 10:52:48 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: yackov@watson.ibm.com Subject: (IPng) Cluster addresses and providers...... Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM my hunch is that the cluster addresses that I'd advertise would be for my customers, NOT my routers. the best-hop for the customer-cluster aggregate would be an external interface on one of my routers (probably at some mass interconnect point) but I think I'd explicitly saw-off a piece to use for my routers and NEVER advertise those internal interfaces outside my igp. does this help? =mo ------------------------------------------------------------------------------ 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 Thu Aug 18 08:29:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09863; Thu, 18 Aug 94 08:29:58 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09857; Thu, 18 Aug 94 08:29:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA21377; Thu, 18 Aug 94 08:27:09 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA02634; Thu, 18 Aug 94 08:26:59 PDT Message-Id: <9408181526.AA02634@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0317; Thu, 18 Aug 94 11:27:02 EDT Date: Thu, 18 Aug 94 11:25:40 EDT From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM, crawdad@fnal.gov Subject: (IPng) cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Thu, 18 Aug 1994 09:39:23 -0500 Matt, >No, they have a "common prefix", but they don't have "the same prefix". According to 2.3.5 of draft-ietf-sipp-routing-addr-02.txt ...set of boundary routers of a cluster of nodes identified by a common prefix in the SIPP unicast routing hierarchy. So, the document talks about a *common* prefix, but not about *the same* prefix. >Specifically, the routers in S1 are advertising the prefix >[ 01 . D . S1], or even longer prefixes, on the local subnetworks. Does that imply that there is a relation between a cluster address a router may have and a set of address prefixes that the router advertises ? If yes, then what is the exact nature of this relation ? 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 Thu Aug 18 08:40:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09884; Thu, 18 Aug 94 08:40:28 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09878; Thu, 18 Aug 94 08:40:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA21811; Thu, 18 Aug 94 08:37:37 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA04880; Thu, 18 Aug 94 08:37:26 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA22844; Thu, 18 Aug 94 11:33:25 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9408181533.AA22844@pluto.dss.com> Subject: Re: (IPng) Oct 10-14 IPng Implementors and Base Group Meeting To: ipng@sunroof.Eng.Sun.COM Date: Thu, 18 Aug 1994 11:33:24 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo) In-Reply-To: <9408181440.AA14363@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Aug 18, 94 10:40:29 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1397 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Hi All, > On Friday in Toronto at the implementors meeting we decided we would > have an interim meeting for implementors and the base WG for IPng. > It was decided to have this meeting in New England. This is a nice time > of year here too. > Ross Callon and I are going to work together to figure out the > logistics. > So we need to know how many of you folks would actually come to the > meeting. We hope to have Mbone for parts of the meeting, but we need you > folks present (especially the Chairs and document authors) to have a really > good and effective meeting. > Please respond if you can come to Boston we need an idea of headcount to > determine location and other logistics. Also if you have any questions > on things you may want to do the weekend before or while your here send > me private mail. > thanks > /jim Hi, I would like to bring the PDN development group. The members are: Tony Bono, Director of Bridge Router Development Joachim Martillo, Manager of Internetworking Research Mike Davis, Engineer Jeff Griglack, Engineer Rich Eichacker, Engineer Tony Ryan, Engineer L. Loisuet Lee, QA Manager (TTI) Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com ------------------------------------------------------------------------------ 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 Thu Aug 18 08:43:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09935; Thu, 18 Aug 94 08:43:03 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09928; Thu, 18 Aug 94 08:42:57 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA21953; Thu, 18 Aug 94 08:40:12 PDT Received: from cps201.cps.cmich.edu by Sun.COM (sun-barr.Sun.COM) id AA05493; Thu, 18 Aug 94 08:40:02 PDT Received: from cps213.cps.cmich.edu (cps213.cps.cmich.edu [141.209.20.213]) by cps201.cps.cmich.edu (8.6.8.1/8.6.6) with ESMTP id LAA02208 for ; Thu, 18 Aug 1994 11:39:58 -0400 From: Brad Wilson Received: (wilson@localhost) by cps213.cps.cmich.edu (8.6.8.1/8.6.6) id LAA02519 for ipng@sunroof.Eng.Sun.COM; Thu, 18 Aug 1994 11:37:23 -0400 Message-Id: <199408181537.LAA02519@cps213.cps.cmich.edu> Subject: Re: (IPng) Oct 10-14 IPng Implementors and Base Group Meeting To: ipng@sunroof.Eng.Sun.COM Date: Thu, 18 Aug 1994 11:37:23 -0400 (EDT) In-Reply-To: <9408181440.AA14363@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Aug 18, 94 10:40:29 am X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 954 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> So we need to know how many of you folks would actually come to the >> meeting. We hope to have Mbone for parts of the meeting, but we need you >> folks present (especially the Chairs and document authors) to have a really >> good and effective meeting. Unfortunately, I won't be able to make the meeting (nor was I able to make the IETF in Toronto). I'm very interested in hearing about those who are doing implementations, because I'm interested to know what time frames are going to be like for initial testing (as well as a million other questions), so I know how to write my schedule for implementation. Thanks for the information... Brad -- Brad Wilson Crucial Software Share and Enjoy! msg++; smiley++; Internet: wilson@cps201.cps.cmich.edu Speaking for myself and myself alone "Come to think of it, there are already a million monkeys on a million typewriters, and Usenet is NOTHING like Shakespeare." ------------------------------------------------------------------------------ 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 Thu Aug 18 09:35:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10102; Thu, 18 Aug 94 09:35:33 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08748; Wed, 17 Aug 94 19:36:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA02849; Wed, 17 Aug 94 19:33:28 PDT Received: from relay.fore.com by Sun.COM (sun-barr.Sun.COM) id AA10120; Wed, 17 Aug 94 19:33:13 PDT Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA12536; Wed, 17 Aug 94 21:07:32 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA09150; Wed, 17 Aug 94 21:07:19 EDT Received: by marlin (4.1/SMI-4.1) id AA10396; Wed, 17 Aug 94 21:07:19 EDT Date: Wed, 17 Aug 94 21:07:19 EDT From: ddp@fore.com (Drew Perkins) Message-Id: <9408180107.AA10396@marlin> To: int-serv@isi.edu, rsvp@isi.edu, af-saa@atmforum.com, end2end-interest@isi.edu, posix-net-ptp@nemo.ncsl.nist.gov, tmendez@bbn.com, scsmith@bbn.com, ipng@sunroof.Eng.Sun.COM, craig@aland.bbn.com Subject: (IPng) Re: Generic Socket QoS stuff and ATM FORUM SAA Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Hi folks: > > I have learned this week that ATM Forum has this bizarre rule that > you can't participate in discussions on their mailing lists unless you > are an ATM Forum member. While this is obviously busted from the perspective > of getting useful technical input into the Forum, I gather they got legal > advice they have to do this. > > So, henceforth, kindly remove the af-saa mailing list from discussions > of socket interfaces, QoS standards, et al. I'll try to find some method > for communicating with the Forum (smoke signals? :-)) when we decide what the > right thing is. > > Craig Craig, There are many ways to communicate with the ATM Forum. 1. There is a membership class in the ATM Forum for users. $1500 and buys you membership in an ATM Forum committee called the Enterprise Network Roundtable. The ENR has three working groups, one of which is the User Technical Requirements which is run by Dave Beering, Amoco, drbeering@amoco.com. The ENR feeds information into the Forum. 2. You can ask any Forum member to relay information to the Technical Committee. 3. As the ATM Forum's IETF Liason, I'd be very happy to relay information, questions, advice, comments, complaints, or just about anything else from the IETF to the ATM Forum. 4. There is a possibility that the ISOC could join the ATM Forum as a principle member. 5. The ATM Forum is investigating the possibility of allowing anyone to send mail to ATM Forum mailing lists. 6. Jim Harford, the chairman of the API working group, would also be happy to relay information. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com ------------------------------------------------------------------------------ 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 Thu Aug 18 09:49:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10209; Thu, 18 Aug 94 09:49:37 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10203; Thu, 18 Aug 94 09:49:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24664; Thu, 18 Aug 94 09:46:47 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA17896; Thu, 18 Aug 94 09:44:50 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA19228; Thu, 18 Aug 94 09:20:44 -0700 Received: by xirtlu.zk3.dec.com; id AA23770; Thu, 18 Aug 1994 12:19:36 -0400 Message-Id: <9408181619.AA23770@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Oct 10-14 IPng Implementors and Base Group Meeting In-Reply-To: Your message of "Thu, 18 Aug 94 10:40:29 EDT." <9408181440.AA14363@xirtlu.zk3.dec.com> Date: Thu, 18 Aug 94 12:19:30 -0400 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 broke the rules of effective communications. The date for the meeting were in the subject header instead of the message body )--> smile | sorry ^##$[...what?]. But the dates are October 10-14. /jim ------------------------------------------------------------------------------ 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 Thu Aug 18 11:18:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10359; Thu, 18 Aug 94 11:18:13 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10353; Thu, 18 Aug 94 11:18:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA28436; Thu, 18 Aug 94 11:15:21 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA04224; Thu, 18 Aug 94 11:15:07 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14595(4)>; Thu, 18 Aug 1994 11:10:01 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Thu, 18 Aug 1994 11:09:50 -0700 To: yakov@watson.ibm.com Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) question about cluster addresses In-Reply-To: yakov's message of Wed, 17 Aug 94 14:30:19 -0800. <9408172131.AA18647@Sun.COM> Date: Thu, 18 Aug 1994 11:09:47 PDT From: Steve Deering Message-Id: <94Aug18.110950pdt.12171@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > When a boundary router for subscriber S of provider D receives a packet > destined to the following cluster address: > > | 2 | m bits | 128-m bits | > +----+--------------+---------------------------------------------+ > | 01 | provider = D |000000000000000000000000000000000000000000000| > +----+--------------+---------------------------------------------+ > > should the router accept the packet as being addressed to itself or not ? Only if the router happens to be a boundary router of the topological cluster that is identified by the prefix: | 2 | m bits | +----+--------------+ | 01 | provider = D | +----+--------------+ , that is, the cluster consisting of the provider D's facilities and all of provider D's subscriber's facilities. A router is a boundary router for prefix P if it has a neighboring router whose address on their common link does not start with P. Steve ------------------------------------------------------------------------------ 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 Thu Aug 18 13:22:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10775; Thu, 18 Aug 94 13:22:47 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10769; Thu, 18 Aug 94 13:22:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05278; Thu, 18 Aug 94 13:19:55 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA05736; Thu, 18 Aug 94 13:19:38 PDT Message-Id: <9408182019.AA05736@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5523; Thu, 18 Aug 94 16:19:38 EDT Date: Thu, 18 Aug 94 16:18:02 EDT From: yakov@watson.ibm.com To: deering@parc.xerox.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, >> When a boundary router for subscriber S of provider D receives a packet >> destined to the following cluster address: >> >> | 2 | m bits | 128-m bits | >> +----+--------------+---------------------------------------------+ >> | 01 | provider = D |000000000000000000000000000000000000000000000| >> +----+--------------+---------------------------------------------+ >> >> should the router accept the packet as being addressed to itself or not ? > >Only if the router happens to be a boundary router of the topological >cluster that is identified by the prefix: > > | 2 | m bits | > +----+--------------+ > | 01 | provider = D | > +----+--------------+ > >, that is, the cluster consisting of the provider D's facilities and all >of provider D's subscriber's facilities. >A router is a boundary router for prefix P if it has a neighboring router >whose address on their common link does not start with P. Here is a slight modification of the question I asked before. Assume that you have a provider X and a set of subscribers S1, S2, etc... The provider uses the block of addresses | 2 | m bits | n bits | +----+--------------+----------------+ | 01 | provider = D | K | +----+--------------+----------------+ for assignment of addresses inside the provider (e.g. for routers). The subscriber S1 uses the block of addresses | 2 | m bits | n bits | +----+--------------+----------------+ | 01 | provider = D | subscriber = S1| +----+--------------+----------------+ for assignment of addresses inside the subscriber. Assume also that there is a router R in S1 that is connected to another provider (which has completely different address block). Now consider a segment of topology that includes the set of all the routers and hosts from both X and S1. This segment consists of the provider D's and subscriber S1's facilities. Is that a cluster (in your definition) ? If yes, then what is the cluster address(es) of R ? 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 Thu Aug 18 13:57:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10844; Thu, 18 Aug 94 13:57:56 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10838; Thu, 18 Aug 94 13:57:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA06635; Thu, 18 Aug 94 13:55:05 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA11671; Thu, 18 Aug 94 13:49:43 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14543(2)>; Thu, 18 Aug 1994 13:49:02 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Thu, 18 Aug 1994 13:48:50 -0700 To: yakov@watson.ibm.com Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng) Re: cluster addresses In-Reply-To: yakov's message of Thu, 18 Aug 94 13:18:02 -0800. <94Aug18.131940pdt.14500(4)@alpha.xerox.com> Date: Thu, 18 Aug 1994 13:48:43 PDT From: Steve Deering Message-Id: <94Aug18.134850pdt.12171@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yakov, > Here is a slight modification of the question I asked before. > > Assume that you have a provider X and a set of subscribers S1, S2, etc... > The provider uses the block of addresses > > | 2 | m bits | n bits | > +----+--------------+----------------+ > | 01 | provider = D | K | > +----+--------------+----------------+ > > for assignment of addresses inside the provider (e.g. for routers). > > The subscriber S1 uses the block of addresses > > | 2 | m bits | n bits | > +----+--------------+----------------+ > | 01 | provider = D | subscriber = S1| > +----+--------------+----------------+ > > for assignment of addresses inside the subscriber. > > Assume also that there is a router R in S1 that is connected to another > provider (which has completely different address block). > > Now consider a segment of topology that includes the set of all the > routers and hosts from both X and S1. This segment consists of the > provider D's and subscriber S1's facilities. > > Is that a cluster (in your definition) ? If you include all the other subscribers of X (i.e., all the subscribers using addresses with prefix D), then the answer is yes. It is the cluster identified by prefix D. > If yes, then what is the cluster address(es) of R ? R is a boundary router for both cluster and for (sub)cluster so it MAY recognize the following cluster addresses as identifying itself: | 2 | m bits | 126-m bits | +----+--------------+----------------+----------------------------------+ | 01 | provider = D |000.............................................000| +----+--------------+----------------+----------------------------------+ | 2 | m bits | n bits | 126-m-n bits | +----+--------------+----------------+----------------------------------+ | 01 | provider = D | subscriber = S1|000............................000| +----+--------------+----------------+----------------------------------+ I said "MAY recognize" because it depends on what the router actually knows about the structure of the addresses (i.e., what it has been configured to know and what it can derive automatically). For instance, the router may not know about the boundary between D and S1 (i.e., it may not know the bit count "m"), in which case, it would not recognize the first of those two cluster addresses. I don't know where you are leading with these questions, but if you were wondering how you direct a packet to the nearest router belonging to X, *excluding* the routers belonging to X's subscribers, the answer is to use the following cluster address: | 2 | m bits | n bits | 126-m-n bits | +----+--------------+----------------+----------------------------------+ | 01 | provider = D | K |000............................000| +----+--------------+----------------+----------------------------------+ Steve ------------------------------------------------------------------------------ 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 Thu Aug 18 14:17:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10894; Thu, 18 Aug 94 14:17:13 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10888; Thu, 18 Aug 94 14:17:07 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07401; Thu, 18 Aug 94 14:14:22 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA15663; Thu, 18 Aug 94 14:12:58 PDT Message-Id: <9408182112.AA15663@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6349; Thu, 18 Aug 94 17:12:51 EDT Date: Thu, 18 Aug 94 17:09:34 EDT From: yakov@watson.ibm.com To: deering@parc.xerox.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Thu, 18 Aug 1994 13:48:43 PDT Steve, >If you include all the other subscribers of X (i.e., all the >subscribers using addresses with prefix D), then the answer is yes. >It is the cluster identified by prefix D. It seems that you require that a cluster identified by prefix D *must* include *all* (and not just some of) the routers and hosts that form a connected topology and whose unicast addresses match D. If you agree with this, then perhaps there is a need to modify 2.3.5 of draft-ietf-sipp-routing-addr-02.txt to reflect this. >R is a boundary router for both cluster and for (sub) cluster , >so it MAY recognize the following cluster addresses as identifying itself: > >I said "MAY recognize" because it depends on what the router >actually knows about the structure of addresses (i.e., what it has >been configured to know and what it can derive automatically). Could you please be more specific on what a router can derive automatically (and how), so that we'll get a better understanding of what is assumed to require configuration. 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 Thu Aug 18 15:56:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11001; Thu, 18 Aug 94 15:56:00 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10791; Thu, 18 Aug 94 13:44:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA06211; Thu, 18 Aug 94 13:41:46 PDT Received: from overdrive.ccrl.nj.nec.com (overdrive3.ccrl.nj.nec.com) by Sun.COM (sun-barr.Sun.COM) id AB09702; Thu, 18 Aug 94 13:37:23 PDT Received: by overdrive.ccrl.nj.nec.com (4.1/YDL1.9-920708.13) id AA04443(overdrive.ccrl.nj.nec.com); Thu, 18 Aug 94 16:06:33 EDT Received: by europa.ccrl.nj.nec.com (4.1/YDL1.9-920708.13) id AA03316(europa.ccrl.nj.nec.com); Thu, 18 Aug 94 16:02:01 EDT From: bansal@ccrl.nj.nec.com (Vivek Bansal) Received: by depot (4.1/CNC-Client) id AA10093; Thu, 18 Aug 94 16:06:28 EDT Date: Thu, 18 Aug 94 16:06:28 EDT Message-Id: <9408182006.AA10093@depot> To: end2end-interest@ISI.EDU, int-serv@ISI.EDU, ipng@sunroof.Eng.Sun.COM, posix-net-ptp@nemo.ncsl.nist.gov, keshav@research.att.com Subject: (IPng) Re: Generic QoS Socket Interface Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I believe that we should view the QoS in the following way. The client > sends a specification via signalling to the server. The server has > a chance to accept the connection, and _modify_ this QoS, depending on > its current load. The modified string is then used to relax the > network's reservation state, and passed back to the client. The client > sees the modified QoS, and if it doesnt like it, tears down the call. In our work , we've also recognized the need for communication between the client and the server through signalling before the actual data connection is actually set. For example in case of typical (image, video)-on-demand application it would be the server which would not the characteristics of the data stream itself, although the connection request would be initiated by the client. But Keshav , I believe in your model of connection-setup the resources are allocated in the first round and in the second round if the server modifies te QoS then you change the allocation. We do not allocate any resources at all till the client and server have handshaked the requirements. We also provide options to the application to pass some data with the signallingmessages, which the server application can use in deciding the kind of data stream that the client needs (which only the server application understands). Well it can be said that, well thats a layer above the transport issue, but in order to set a data connection at the ATM level, we believe all layers (if they can) should contribute in deciding how fat the ATM pipe should be and what QoS is needed for it. All comments welcome... Vivek... ------------------------------------------------------------------------------ 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 Thu Aug 18 15:56:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11013; Thu, 18 Aug 94 15:56:23 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10791; Thu, 18 Aug 94 13:44:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA06211; Thu, 18 Aug 94 13:41:46 PDT Received: from overdrive.ccrl.nj.nec.com (overdrive3.ccrl.nj.nec.com) by Sun.COM (sun-barr.Sun.COM) id AB09702; Thu, 18 Aug 94 13:37:23 PDT Received: by overdrive.ccrl.nj.nec.com (4.1/YDL1.9-920708.13) id AA04443(overdrive.ccrl.nj.nec.com); Thu, 18 Aug 94 16:06:33 EDT Received: by europa.ccrl.nj.nec.com (4.1/YDL1.9-920708.13) id AA03316(europa.ccrl.nj.nec.com); Thu, 18 Aug 94 16:02:01 EDT From: bansal@ccrl.nj.nec.com (Vivek Bansal) Received: by depot (4.1/CNC-Client) id AA10093; Thu, 18 Aug 94 16:06:28 EDT Date: Thu, 18 Aug 94 16:06:28 EDT Message-Id: <9408182006.AA10093@depot> To: end2end-interest@ISI.EDU, int-serv@ISI.EDU, ipng@sunroof.Eng.Sun.COM, posix-net-ptp@nemo.ncsl.nist.gov, keshav@research.att.com Subject: (IPng) Re: Generic QoS Socket Interface Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I believe that we should view the QoS in the following way. The client > sends a specification via signalling to the server. The server has > a chance to accept the connection, and _modify_ this QoS, depending on > its current load. The modified string is then used to relax the > network's reservation state, and passed back to the client. The client > sees the modified QoS, and if it doesnt like it, tears down the call. In our work , we've also recognized the need for communication between the client and the server through signalling before the actual data connection is actually set. For example in case of typical (image, video)-on-demand application it would be the server which would not the characteristics of the data stream itself, although the connection request would be initiated by the client. But Keshav , I believe in your model of connection-setup the resources are allocated in the first round and in the second round if the server modifies te QoS then you change the allocation. We do not allocate any resources at all till the client and server have handshaked the requirements. We also provide options to the application to pass some data with the signallingmessages, which the server application can use in deciding the kind of data stream that the client needs (which only the server application understands). Well it can be said that, well thats a layer above the transport issue, but in order to set a data connection at the ATM level, we believe all layers (if they can) should contribute in deciding how fat the ATM pipe should be and what QoS is needed for it. All comments welcome... Vivek... ------------------------------------------------------------------------------ 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 Thu Aug 18 16:52:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11145; Thu, 18 Aug 94 16:52:24 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11031; Thu, 18 Aug 94 16:18:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14026; Thu, 18 Aug 94 16:15:29 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA12717; Thu, 18 Aug 94 16:15:11 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA29765; Thu, 18 Aug 1994 16:15:11 -0700 Date: Thu, 18 Aug 1994 16:15:11 -0700 From: Tony Li Message-Id: <199408182315.QAA29765@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: yakov@watson.ibm.com, ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Thu, 18 Aug 1994 13:48:43 PDT <94Aug18.134850pdt.12171@skylark.parc.xerox.com> Subject: (IPng) Re: cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I don't know where you are leading with these questions, but if you were wondering how you direct a packet to the nearest router belonging to X, *excluding* the routers belonging to X's subscribers, the answer is to use the following cluster address: | 2 | m bits | n bits | 126-m-n bits | +----+--------------+----------------+----------------------------------+ | 01 | provider = D | K |000............................000| +----+--------------+----------------+----------------------------------+ Steve, Where we leading with all of this, is that we're very interested in using cluster addresses for "SDRP in IPv6" (warning: imminent name change). In describing this mechanism, we need a very precise definition of a cluster address. Preferably one which makes it easy to include cluster addresses in routes. Tony ------------------------------------------------------------------------------ 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 Thu Aug 18 16:53:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11159; Thu, 18 Aug 94 16:53:26 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11042; Thu, 18 Aug 94 16:19:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14061; Thu, 18 Aug 94 16:16:27 PDT Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA12936; Thu, 18 Aug 94 16:16:14 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA23777; Thu, 18 Aug 1994 16:16:29 -0700 Date: Thu, 18 Aug 1994 16:16:29 -0700 From: Dave Katz Message-Id: <199408182316.QAA23777@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: bound@zk3.dec.com's message of Thu, 18 Aug 94 10:40:29 -0400 <9408181440.AA14363@xirtlu.zk3.dec.com> Subject: (IPng) Oct 10-14 IPng Implementors and Base Group Meeting Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Is five days really necessary? It's very unlikely that some of us will be able to get away that long (and seems excessive in any case). Date: Thu, 18 Aug 94 10:40:29 -0400 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 All, On Friday in Toronto at the implementors meeting we decided we would have an interim meeting for implementors and the base WG for IPng. It was decided to have this meeting in New England. This is a nice time of year here too. Ross Callon and I are going to work together to figure out the logistics. So we need to know how many of you folks would actually come to the meeting. We hope to have Mbone for parts of the meeting, but we need you folks present (especially the Chairs and document authors) to have a really good and effective meeting. Please respond if you can come to Boston we need an idea of headcount to determine location and other logistics. Also if you have any questions on things you may want to do the weekend before or while your here send me private mail. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ 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 Thu Aug 18 16:53:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11171; Thu, 18 Aug 94 16:53:46 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11053; Thu, 18 Aug 94 16:24:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14351; Thu, 18 Aug 94 16:21:48 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA13910; Thu, 18 Aug 94 16:21:21 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA00219; Thu, 18 Aug 1994 16:21:22 -0700 Date: Thu, 18 Aug 1994 16:21:22 -0700 From: Tony Li Message-Id: <199408182321.QAA00219@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM, martillo@pluto.dss.com In-Reply-To: Joachim Martillo's message of Thu, 18 Aug 1994 11:33:24 -0400 (EDT) <9408181533.AA22844@pluto.dss.com> Subject: (IPng) Oct 10-14 IPng Implementors and Base Group Meeting Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joachim, To keep the group making progress, please send only one or two implementors. Thanks, Tony I would like to bring the PDN development group. The members are: Tony Bono, Director of Bridge Router Development Joachim Martillo, Manager of Internetworking Research Mike Davis, Engineer Jeff Griglack, Engineer Rich Eichacker, Engineer Tony Ryan, Engineer L. Loisuet Lee, QA Manager (TTI) ------------------------------------------------------------------------------ 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 Thu Aug 18 16:56:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11183; Thu, 18 Aug 94 16:56:37 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11067; Thu, 18 Aug 94 16:37:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15085; Thu, 18 Aug 94 16:34:34 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA16583; Thu, 18 Aug 94 16:34:22 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA01218; Thu, 18 Aug 1994 16:34:21 -0700 Date: Thu, 18 Aug 1994 16:34:21 -0700 From: Tony Li Message-Id: <199408182334.QAA01218@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: yakov@watson.ibm.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: Mike O'Dell's message of Thu, 18 Aug 1994 10:52:48 -0400 Subject: (IPng) Cluster addresses and providers...... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM my hunch is that the cluster addresses that I'd advertise would be for my customers, NOT my routers. I don't understand this at all. As you are implicitly advertising the cluster addresses when you advertise address space, what does this mean? You will be advertising customer address space, but none of your internal address space? the best-hop for the customer-cluster aggregate would be an external interface on one of my routers (probably at some mass interconnect point) but I think I'd explicitly saw-off a piece to use for my routers and NEVER advertise those internal interfaces outside my igp. does this help? No, it only points out some of the problems. ;-) A customer cluster address on one of your interfaces is a bad thing whether or not you advertise it as that router will receive packets intended for a cluster which is nominally not part of your administrative region. Note that this is again a side effect of having addresses for interfaces. If we also had addresses for boxes and used that address for the definition of a cluster, it would help things considerably. It would make it clear which box belonged to which cluster. The current scheme forces one to do some strange things (DMZs) to insure that clusters correspond to reasonable administrative entities. Tony ------------------------------------------------------------------------------ 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 Thu Aug 18 17:01:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11195; Thu, 18 Aug 94 17:01:07 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11189; Thu, 18 Aug 94 17:01:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA16235; Thu, 18 Aug 94 16:58:17 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA21473; Thu, 18 Aug 94 16:57:49 PDT Received: from oils.ozy.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA10290; Thu, 18 Aug 94 16:50:03 -0700 Received: by oils.ozy.dec.com (5.65/ozy-211093); id AA05163; Fri, 19 Aug 1994 09:49:33 +1000 Message-Id: <9408182349.AA05163@oils.ozy.dec.com> To: deering@parc.xerox.com Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) question about cluster addresses Date: Fri, 19 Aug 94 09:49:33 +1000 From: grehan@ozy.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, >A router is a boundary router for prefix P if it has a neighboring router >whose address on their common link does not start with P. For the case where there is a neighboring router with the same prefix P, will it be up to some form of router election to determine who is the boundary router and hence who 'owns' the cluster address for P ? Peter. ------------------------------------------------------------------------------ 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 Thu Aug 18 17:10:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11227; Thu, 18 Aug 94 17:10:34 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11221; Thu, 18 Aug 94 17:10:26 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA16651; Thu, 18 Aug 94 17:07:42 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA23439; Thu, 18 Aug 94 17:07:31 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id RAA03007; Thu, 18 Aug 1994 17:07:31 -0700 Date: Thu, 18 Aug 1994 17:07:31 -0700 From: Tony Li Message-Id: <199408190007.RAA03007@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > An Architecture for IPv6 Unicast Address Allocation > > > ... [Text on subdividing prefixes and advertising them locally to optimize routing.] > Once the partitioning is done, the address space of > the provider is subdivided along the group boundaries. A leaf routing > domain that is willing to accept prefixes derived from its direct > provider gets a prefix from the provider's address space subdivision > associated with the group the domain belongs to. Note that the > advertisement by the direct provider of the routing information > associated with each subdivision must be done with care to ensure > that such an advertisement would not result in a global distribution > of separate reachability information associated with each > subdivision, unless such distribution is warranted for some other > purposes (e.g. supporting certain aspects of policy-based routing). In order to be effective, these groupings of subscribers have to be made known outside the provider's network. Is it expected that this will be done in the same way by all providers? I don't recall any provision for a group field in the address formats draft. Correct, the advertisements are done by simply propagating longer prefixes than the provider would otherwise generate. Note that since these prefixes should NOT be globally visible, it's not necessary to have any architectural statement on how this is to be done. It certainly does not require a special "group field" in the address. Note that in a truly degenerate case, the groups are individual sites. Will it be possible to have symmetrical routing between subscribers on different providers in this environment? It seems like that might be easier if providers used the same geographical groupings, but that may not be practical. There are no guarantees of symmetrical routing. I don't understand your point about geographical groupings. Tony ------------------------------------------------------------------------------ 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 Thu Aug 18 17:27:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11294; Thu, 18 Aug 94 17:27:08 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11280; Thu, 18 Aug 94 17:26:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA17322; Thu, 18 Aug 94 17:24:12 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA25927; Thu, 18 Aug 94 17:23:53 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id RAA03612; Thu, 18 Aug 1994 17:18:11 -0700 Date: Thu, 18 Aug 1994 17:18:11 -0700 From: Tony Li Message-Id: <199408190018.RAA03612@lager.cisco.com> To: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Cc: bruce-steer@saa.sa.telememo.au, kim.fenley@cm-dimp.aditcs.hqadf.defencenet.gov.au, ipng@sunroof.Eng.Sun.COM, tli@cisco.com, yakov@watson.ibm.com In-Reply-To: ALAN.LLOYD@DCTHQ.datacraft.telememo.au's message of Wed, 17 Aug 1994 10:29:16 +1000 <"940817 09:24:03*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> Subject: (IPng) RE RECOMMENDATIONS FOR IPV6 ADDRESSING. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, tony, yakov - re the document on IPv6 addressing and its recommendations.. It is for this reason that I see the longer term that the use of NSAPs and the OSI routing designs are critical to IPngs evolution.. What are the issues with NSAPs and IPNG.. eg is an option that the 16 bytes could be used and another 4 as address extensions... as per X.25 facilities? and then the whole NSAP (as defined by ISO and the ITU) will fit correctly and be compatible. While I appreciate your comments, the document that Yakov and I have written is not the one that mandates 16 byte addresses. That is part of the basic IPv6 design. Tony ------------------------------------------------------------------------------ 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 Thu Aug 18 19:02:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11388; Thu, 18 Aug 94 19:02:54 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11382; Thu, 18 Aug 94 19:02:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20818; Thu, 18 Aug 94 18:59:58 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA11477; Thu, 18 Aug 94 18:59:41 PDT Received: from pm002-11.dialip.mich.net (pm002-11.dialip.mich.net [35.1.48.92]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id VAA24735 for ; Thu, 18 Aug 1994 21:59:39 -0400 Date: Thu, 18 Aug 94 22:20:31 GMT From: "William Allen Simpson" Message-Id: <3063.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Cc: alan@datacraft.oz.au Cc: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Subject: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >Comments by: Alan Lloyd@Marketing@DCTHQ > >NSAPs are also configured into millions of OSI products We have been busy mapping the number and location of IP products, which number in the tens of millions. It would be of great assistance if you would send a detailed mapping of the number and location of these millions of OSI products, so that convergence planning could be coordinated. > ... such as routers, > >switches, X.400, X.500 and X.700 systems - in fact these last application > >level products have to be configured to evaluate the data syntax (not just > >bitstring compare) of NSAPs to do searches and check for equivalence... etc. > > > >It is not just a question that US GOSIP does not use NSAPs widely.. > >Or that one can truncate 20 bytes into 16 because of perceived unused fields. > > This is a very valid concern. Of course, we were planning on truncating into 12 or fewer bytes. This would destroy the ability to have the NSAP mapping into IPv6. Brian Carpenter, could you please provide a detailed description of the range and number of currently deployed NSAPs and their mapping into IPv6? Perhaps you could coordinate with Alan. 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 From owner-ipng Thu Aug 18 19:26:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11412; Thu, 18 Aug 94 19:26:00 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11406; Thu, 18 Aug 94 19:25:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA21413; Thu, 18 Aug 94 19:23:09 PDT Received: from CU.NIH.GOV by Sun.COM (sun-barr.Sun.COM) id AA14827; Thu, 18 Aug 94 19:22:58 PDT Message-Id: <9408190222.AA14827@Sun.COM> To: tli@cisco.com, ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Thu, 18 Aug 1994 22:21:17 EDT Subject: Re: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Will it be possible to have symmetrical routing between > subscribers on different providers in this environment? It seems > like that might be easier if providers used the same geographical > groupings, but that may not be practical. > > There are no guarantees of symmetrical routing. I don't understand > your point about geographical groupings. > > Tony Well, I'm trying to understand how the architecture deals with providers that are multiply connected. If Subscriber 1 on Provider A sends to Subscriber 2 on Provider B, it seems like the packet would likely move from Provider A's network to Provider B's network at the connection point that is nearest Subscriber 1 in terms of Provider A's routing metric. Now when Subscriber 2 on Provider B responds, the packet is likely to move from Provider B's network to Provider A's at the connection point that is nearest Subscriber 2 in terms of Provider B's routing metric. If the two providers are multiply connected, that may well be a different connection point than the packet from Subscriber 1 to Subscriber 2 took. So, not only is there no guarantee of symmetric routing, it is highly likely that you won't get it. It was my impression that symmetric routing was considered a very good thing in the past. One reason is so that traceroute would tell you something about the way packets come back to you, as well as the way they go. What's the IPv6 tool that will replace this? SNMP queries of routing tables? What I was trying to say about groups is that if the various providers have some sort of groupings of subscribers that indicate what inter-provider connection point they are nearest (by a group number in the address or by use of multiple provider numbers for each provider), and those groupings are advertised to other providers, then it would be easier to get symmetric routing, at the cost of larger routing tables. I think it would imply that the provider prefix for a subscriber could change when the provider changes the topology of their network. So it would be especially important to be able to do that sort of renumbering automatically. Anyway, if everyone has given up on symmetric routing as just too hard to do, it would be worthwhile to explicity say that, so that everyone understands. ------------------------------------------------------------------------------ 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 Thu Aug 18 21:17:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11547; Thu, 18 Aug 94 21:17:18 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11541; Thu, 18 Aug 94 21:17:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24339; Thu, 18 Aug 94 21:14:26 PDT Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA26126; Thu, 18 Aug 94 21:14:14 PDT Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA10255 for ipng@sunroof.eng.sun.com; Thu, 18 Aug 94 23:48:13 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id UAA05676; Thu, 18 Aug 1994 20:47:21 -0700 Message-Id: <199408190347.UAA05676@aland.bbn.com> To: ipng@sunroof.Eng.Sun.COM Cc: int-serv@isi.edu, rsvp@isi.edu, af-saa@atmforum.com, end2end-interest@isi.edu, posix-net-ptp@nemo.ncsl.nist.gov, tmendez@bbn.com, scsmith@bbn.com, craig@aland.bbn.com Subject: Re: (IPng) Re: Generic Socket QoS stuff and ATM FORUM SAA In-Reply-To: Your message of Wed, 17 Aug 94 21:07:19 -0400. <9408180107.AA10396@marlin> From: Craig Partridge Date: Thu, 18 Aug 94 20:47:19 -0700 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Drew: I'm actually apparently a member of the forum, since BBN is. However that's not the problem. I've been notified that I can't include ATM Forum mailing lists in general discussions that include other mailing lists -- in other words, that we can't have a free technical discussion that mixes Forum mailing lists and non-Forum lists. Since there are several non-Forum lists which have people on them who care about sockets, and the Forum is the only group that isn't able to conduct free and open technical exchanges, the obvious answer is to segregate the Forum and find some (less useful) way to convey information in. Craig ------------------------------------------------------------------------------ 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 Thu Aug 18 22:19:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11716; Thu, 18 Aug 94 22:19:19 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11710; Thu, 18 Aug 94 22:19:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25810; Thu, 18 Aug 94 22:16:26 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA02065; Thu, 18 Aug 94 22:15:57 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 19 Aug 94 14:08:38 +0900 From: Masataka Ohta Message-Id: <9408190508.AA03168@necom830.cc.titech.ac.jp> Subject: Re: (IPng) millions of OSI products To: ipng@sunroof.Eng.Sun.COM Date: Fri, 19 Aug 94 14:08:36 JST Cc: alan@datacraft.oz.au, brian@dxcoms.cern.ch In-Reply-To: <3063.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Aug 18, 94 10:20 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >NSAPs are also configured into millions of OSI products If there are only millions of OSI products, how about just giving OSI products a class A address which can contain 16 millions of OSI products? Address mapping could be handled at the gateway. Or, we may even give 6 or 8 bytes and let OSI products use that length of NSAP address, not full 20 byts (address reassignment is assumed). IMHO, it's irrational to talk seriously about 20 byte NSAP address only to support merely millions of products. Masataka Ohta ------------------------------------------------------------------------------ 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 Thu Aug 18 23:01:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11753; Thu, 18 Aug 94 23:01:52 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11747; Thu, 18 Aug 94 23:01:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA26673; Thu, 18 Aug 94 22:59:00 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA05149; Thu, 18 Aug 94 22:58:50 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id WAA16058; Thu, 18 Aug 1994 22:58:47 -0700 Date: Thu, 18 Aug 1994 22:58:47 -0700 From: Tony Li Message-Id: <199408190558.WAA16058@lager.cisco.com> To: RAF@CU.NIH.GOV Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Roger Fajman"'s message of Thu, 18 Aug 1994 22:21:17 EDT <199408190222.TAA02473@hubbub.cisco.com> Subject: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Roger, Well, I'm trying to understand how the architecture deals with providers that are multiply connected. If Subscriber 1 on Provider A sends to Subscriber 2 on Provider B, it seems like the packet would likely move from Provider A's network to Provider B's network at the connection point that is nearest Subscriber 1 in terms of Provider A's routing metric. Now when Subscriber 2 on Provider B responds, the packet is likely to move from Provider B's network to Provider A's at the connection point that is nearest Subscriber 2 in terms of Provider B's routing metric. If the two providers are multiply connected, that may well be a different connection point than the packet from Subscriber 1 to Subscriber 2 took. Yup. So, not only is there no guarantee of symmetric routing, it is highly likely that you won't get it. Well, that's not clear. You have to recall that most providers are sensitive to this issue and I've seen some providers go to EXTREME lengths to provide it. Doing this is, however, labor intensive. It was my impression that symmetric routing was considered a very good thing in the past. One reason is so that traceroute would tell you something about the way packets come back to you, as well as the way they go. What's the IPv6 tool that will replace this? SNMP queries of routing tables? Hopefully, IPv6 will provide a better tool than traceroute. [Don't get me wrong, I love it dearly, BUT....] Imagine how useful IPv4 record route could have been if it didn't have a 9 hop limitation. This would allow you to clearly see if the route is asymmetric. Symmetry is good for other reasons (SRTT calculations), but interdomain routing would get incredibly complcated if you tried to enforce this automatically. Of course, if someone has a good idea, please step forward... ;-) What I was trying to say about groups is that if the various providers have some sort of groupings of subscribers that indicate what inter-provider connection point they are nearest (by a group number in the address or by use of multiple provider numbers for each provider), and those groupings are advertised to other providers, then it would be easier to get symmetric routing, at the cost of larger routing tables. I think our suggestions is to do exactly that, but without the explicit group number.... I think it would imply that the provider prefix for a subscriber could change when the provider changes the topology of their network. So it would be especially important to be able to do that sort of renumbering automatically. ... and renumbering would not be required. Tho the number of routes advertised (locally) to achieve optimality might increase without renumbering. Anyway, if everyone has given up on symmetric routing as just too hard to do, it would be worthwhile to explicity say that, so that everyone understands. Agreed, but I don't think that this is the case. Tony ------------------------------------------------------------------------------ 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 Fri Aug 19 01:08:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11808; Fri, 19 Aug 94 01:08:05 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11802; Fri, 19 Aug 94 01:07:57 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA29131; Fri, 19 Aug 94 01:05:12 PDT Received: from bunyip.cc.uq.oz.au by Sun.COM (sun-barr.Sun.COM) id AA18416; Fri, 19 Aug 94 01:04:49 PDT Received: from clix.aarnet.edu.au by bunyip.cc.uq.oz.au with SMTP (PP); Fri, 19 Aug 1994 18:04:10 +1000 X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 19 Aug 1994 18:00:28 +1000 X400-Received: by /PRMD=AUSGOVDEFENCENET/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 18 Aug 1994 14:02:22 +1000 Date: Thu, 18 Aug 1994 14:02:22 +1000 X400-Originator: Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au X400-Recipients: IPNG@SUNROOF.ENG.SUN.COM X400-Mts-Identifier: [/PRMD=AUSGOVDEFENCENET/ADMD=TELEMEMO/C=AU/;40A 940818140219] X400-Content-Type: P2-1984 (2) Content-Identifier: 40A 940818140219 From: Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au Message-Id: <"40A 940818140219*"@MHS> To: IPNG@SUNROOF.Eng.Sun.COM (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: (IPng) Comments on IPv6 to NSAP recommendations Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 To all See attached ------------------------------ Start of body part 2 Gentleman I am interested in the use of good technology whether it is OSI or IPv6. However, what I have distilled from the NSAP to IPv6 recommendations causes me concern as an organisation trying to implement OSI first and IPS latterly. Most GOSIPs and implementors of OSI NSAPs have employed the 20 octets with a similar DSP structures. The IPv6 document states the mechanism of mapping 20 octets into 16 octets. The assumption on my behalf is that this is only possible by trashing 4 octets somehow. An assumption is also made by the IPv6 working group to use the US GOSIP NSAP structure as the bases for mapping an NSAP into IPv6 (although there are others). The first octet reduction is achieved through a compression of the IDP in the NSAP. I suspect that the other 3 octets are dropped to provide the collapsed structure of 16 octets in IPv6 and they comes from dropping the "RES"erve field in the DSP above the RD field. If this is the case, organisations such as ours has its perceived growth severely limited and possibly be put into the position that the Internet is currently in. Some organisation such as the Aviation industry have already allocated some of the "reserve" area for use, as we intend in the future. Thus, the compression of the 17 octets of the DSP in the NSAP as it currently stands, needs carefully consideration. Have you looked at all aspects of the DSP usage and the impacts of mapping them to IPv6? eg. broadcast, video, ATM and the newer carrier technologies. Finally, can I say that harmonisation is the key issue in the long term. No one wants the pain, let alone twice! Regards Kim Fenley A/Deputy Director Information Technology and Communication Standards X.400 address: G=KIM;S=FENLEY;OU=CM-DIMP;OU=ADITCS; O=HQADF;P=AUSGOVDEFENCENET;A=TELEMEMO;C=AU Internet address: Kim.Fenley@aditcs.cm-dimp.hqadf.defencenet.gov.au HeadQuarters Australian Defence Force Corporate Management (Forces Executive) Branch Russell Offices (B-3-25) Canberra ACT 2600 +61 6 265-3730 Ph +61 6 265-3601 FAX Standards Australia Committee member IT/1/21 IT/1/6 IT/1/3 ------------------------------ End of body part 2 ------------------------------------------------------------------------------ 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 Fri Aug 19 02:11:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11876; Fri, 19 Aug 94 02:11:52 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11870; Fri, 19 Aug 94 02:11:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00344; Fri, 19 Aug 94 02:09:00 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA24394; Fri, 19 Aug 94 02:08:49 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA01994; Fri, 19 Aug 1994 11:10:33 +0200 Message-Id: <199408190910.AA01994@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) question about cluster addresses In-Reply-To: Your message of "Fri, 19 Aug 1994 09:49:33 +1000." <9408182349.AA05163@oils.ozy.dec.com> Date: Fri, 19 Aug 1994 11:10:31 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Let's take a practical tack on this. Things that look like good candidates for clusters in my mind are: * Connected subnets. The cluster address equals the subnet prefix. * Autonomous systems, provided all subnets within the AS share a common prefix. That prefix equals the cluster address. * OSPF or IS-IS areas, where the prefix is probably smtg like the concatenation of an area ID to the AS prefix. Indeed, there will be variation of these in case of multiple addressing (e.g. multiple providers). I leave it to the intelligent reader. Note that there may be more "common prefixes" that "clusters", e.g. due to address allocation strategies. A "cluster" is a routing concept. Christian Huitema ------------------------------------------------------------------------------ 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 Fri Aug 19 02:21:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11898; Fri, 19 Aug 94 02:21:50 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11892; Fri, 19 Aug 94 02:21:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00503; Fri, 19 Aug 94 02:18:58 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA25179; Fri, 19 Aug 94 02:18:47 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id CAA22108; Fri, 19 Aug 1994 02:18:47 -0700 Date: Fri, 19 Aug 1994 02:18:47 -0700 From: Tony Li Message-Id: <199408190918.CAA22108@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Christian Huitema's message of Fri, 19 Aug 1994 11:10:31 +0200 <199408190910.AA01994@mitsou.inria.fr> Subject: (IPng) question about cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Let's take a practical tack on this. Things that look like good candidates for clusters in my mind are: * Connected subnets. The cluster address equals the subnet prefix. Yup. * Autonomous systems, provided all subnets within the AS share a common prefix. That prefix equals the cluster address. Actually, some of us have been discussing this and it actually makes more sense to identify routing domains using a separate domain identifier. We thought about the cluster approach, but decided to abandon it when we were confronted with IDRP confederations. * OSPF or IS-IS areas, where the prefix is probably smtg like the concatenation of an area ID to the AS prefix. Seems reasonable. And in general, we should be able to define a cluster address for each non-leaf hierarchical level within the address space. Indeed, there will be variation of these in case of multiple addressing (e.g. multiple providers). I leave it to the intelligent reader. Note that there may be more "common prefixes" that "clusters", e.g. due to address allocation strategies. A "cluster" is a routing concept. As such, we need a mathematically precise definition to work from. Or at least enough understanding of the intent of the designers so that we can follow through. Tony ------------------------------------------------------------------------------ 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 Fri Aug 19 05:37:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11985; Fri, 19 Aug 94 05:37:03 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11979; Fri, 19 Aug 94 05:36:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03695; Fri, 19 Aug 94 05:34:10 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA12812; Fri, 19 Aug 94 05:34:00 PDT Message-Id: <9408191234.AA12812@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1699; Fri, 19 Aug 94 08:34:03 EDT Date: Fri, 19 Aug 94 08:32:08 EDT From: yakov@watson.ibm.com To: Christian.Huitema@sophia.inria.fr Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) a question about cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian, >A "cluster" is a routing concept. If that is the case, then would you please define the relationship between one or more cluster addresses assigned to a router and the routing information that the router advertises to other routers ? 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 Fri Aug 19 06:39:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12014; Fri, 19 Aug 94 06:39:28 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12008; Fri, 19 Aug 94 06:39:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05028; Fri, 19 Aug 94 06:36:36 PDT Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA20843; Fri, 19 Aug 94 06:36:25 PDT Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.4/8.6.4) with ESMTP id JAA12856 for ; Fri, 19 Aug 1994 09:36:23 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.4/8.6.4) with SMTP id JAA14978 for ; Fri, 19 Aug 1994 09:36:21 -0400 Received: from grid (bobsgrid.clis.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA11493; Fri, 19 Aug 94 09:42:40 EDT Message-Id: <9408191342.AA11493@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Aug 1994 09:36:23 -0500 To: ipng@sunroof.Eng.Sun.COM From: RGMoskowitz-3@is.chrysler.com (Robert Moskowitz) Subject: Re: (IPng) Re: local address token... X-Mailer: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> Thus it seems to me that some of the mathematicians here (hey >> Ohta San!) could work out a reasonable one-way hash of a MAC >> address to get it down to 16 bits for sure, maybe even 12 >> bits. If it is a one-way hash, even I won't be concerned >> about using this in my addressing scheme! smb@research.att.com said: >The problem is that you run up against the birthday paradox. If >there are 12 bits of addressing, the odds on a collision are about >50% when the population reaches about 2^6. That's why cryptographic >hash functions have output sizes roughly twice the key length of >an encryption algorithm of comparable strength (i.e., SHS vs. Skipjack). crawdad@munin.fnal.gov said on the addrconf: >> Since you've got a database like that to test with, let me ask you >> a question. Suppose you simply took the low four bytes of the six >> byte MAC addresses. What then is the degeneracy histogram? >Ah-hm. Even fewer collisions, although there are some bigger ones. >simple 16-bit xor >number in number of >same bucket such buckets >1 7119 >2 452 >3 32 >4 6 >5 3 >6 1 >7 1 >Using lowest 32 bits >number in number of >same bucket such buckets >1 7853 >2 74 >3 19 >4 9 >5 3 >6 1 >7 2 >9 1 >12 1 >21 1 So the 16 xor had a 0.5% conflict for over 8,000 MAC addresses. Seems like something can be done with this to work out an algorithm to handle dups and thus only use 16bits for the workstation component instead of 48 bits. Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ 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 Fri Aug 19 11:37:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12340; Fri, 19 Aug 94 11:37:45 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12334; Fri, 19 Aug 94 11:37:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19163; Fri, 19 Aug 94 11:34:53 PDT Received: from inet-gw-3.pa.dec.com ([16.1.0.33]) by Sun.COM (sun-barr.Sun.COM) id AA16796; Fri, 19 Aug 94 11:31:44 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA04565; Fri, 19 Aug 94 11:25:58 -0700 Received: by xirtlu.zk3.dec.com; id AA09347; Fri, 19 Aug 1994 14:25:00 -0400 Message-Id: <9408191825.AA09347@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) CHANGE IPng Implementors Dates In-Reply-To: Your message of "Thu, 18 Aug 94 12:19:30 EDT." <9408181619.AA23770@xirtlu.zk3.dec.com> Date: Fri, 19 Aug 94 14:24:53 -0400 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 checked with our chairs. The meeting will only be from: October 10-12. The meeting will end at Noon on October 12 for those flying back. /jim ------------------------------------------------------------------------------ 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 Fri Aug 19 11:39:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12352; Fri, 19 Aug 94 11:39:26 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12346; Fri, 19 Aug 94 11:39:19 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19266; Fri, 19 Aug 94 11:36:33 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA17689; Fri, 19 Aug 94 11:36:07 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14648(1)>; Fri, 19 Aug 1994 11:31:34 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 19 Aug 1994 11:31:28 -0700 To: yakov@watson.ibm.com Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) cluster addresses In-Reply-To: yakov's message of Thu, 18 Aug 94 14:09:34 -0800. <9408182112.AA15663@Sun.COM> Date: Fri, 19 Aug 1994 11:31:14 PDT From: Steve Deering Message-Id: <94Aug19.113128pdt.12171@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > It seems that you require that a cluster identified by prefix D *must* > include *all* (and not just some of) the routers and hosts that form > a connected topology and whose unicast addresses match D. Yes, the cluster is *defined* as the topological region that is labelled with prefix D. > If you agree with this, then perhaps there is a need to modify 2.3.5 of > draft-ietf-sipp-routing-addr-02.txt to reflect this. I don't know which part of 2.3.5 is at odds with what I have been saying. If you are suggesting that that it needs to be enhanced with more explanatory text, please let me know what you found lacking. We *should* relax the following statement in that section: Cluster boundary routers are required to know that they are boundary routers and to accept packets addressed to the corresponding cluster address as being addressed to themselves. because I think it may be too burdensome for a router to know all of the clusters for which it is on the boundary. It really only needs to recognize those cluster addresses that will actually be *used* as destinations of packets. In your example of clusters , , and , if only and are useful (to reach the facilities of the subscriber and the facilities of the provider, respectively), then there is no need for any router to know it is on the boundary of . > Could you please be more specific on what a router can derive > automatically (and how), so that we'll get a better understanding > of what is assumed to require configuration. I'm not sure I can be more specific, and I could use your help in figuring it out. Certainly routers can be expected to know (either through manual configuration or through some as-yet-undefined router autoconfig mechanism) the subnet numbers of their directly-attached links, so from that they can "automatically" realize that the subnet prefixes of those links are cluster addresses they must recognize. I had hoped that entry routers into higher-level aggregates would analagously know the prefixes that identified those aggregates, and could thus automatically adopt those higher-level prefixes as cluster addresses that they must recognize. If the necessary knowledge is not already present, then it would have to be configured. Having cluster addresses that identify *subnets* has always seemed like a useful and basically "free" capability to me, as way to reach the nearest router on a particular subnet, e.g., for a mobile host sending registration messages "home" (under the assumption that all routers are able to serve a Home Agents for their attached subnets, which is the architecture I prefer). Then it seemed natural to extrapolate that concept to higher levels in the addressing hierarchy, and it seem to have potential for provider-selection (in a provider-based addressing hierarchy) and maybe other purposes. If that turns out not to be true, that's OK. If remains useful to have a separate AS numbering space, independent of the node address space (rather than being the high-order part of addresses), we certainly have enough address bits to allocate some to AS identifiers. Steve ------------------------------------------------------------------------------ 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 Fri Aug 19 11:53:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12396; Fri, 19 Aug 94 11:53:19 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12390; Fri, 19 Aug 94 11:53:12 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19743; Fri, 19 Aug 94 11:50:27 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA19872; Fri, 19 Aug 94 11:49:29 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14535(1)>; Fri, 19 Aug 1994 11:47:56 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 19 Aug 1994 11:47:46 -0700 To: grehan@ozy.dec.com Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) question about cluster addresses In-Reply-To: grehan's message of Thu, 18 Aug 94 16:49:33 -0800. <9408182349.AA05163@oils.ozy.dec.com> Date: Fri, 19 Aug 1994 11:47:42 PDT From: Steve Deering Message-Id: <94Aug19.114746pdt.12171@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >A router is a boundary router for prefix P if it has a neighboring router > >whose address on their common link does not start with P. > > For the case where there is a neighboring router with the same prefix P, > will it be up to some form of router election to determine who is > the boundary router and hence who 'owns' the cluster address for P ? Peter, The boundary routers for cluster P are all the routers with links that leave cluster P. There is no need for an election -- cluster addresses are a special form of "anycast" address, that is an address that can be owned by more than one node but which, when used as a destination of a packet, results in delivery to only one node. Let me know if you find this answer unhelpful. Steve ------------------------------------------------------------------------------ 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 Fri Aug 19 12:35:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12507; Fri, 19 Aug 94 12:35:14 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12375; Fri, 19 Aug 94 11:52:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19683; Fri, 19 Aug 94 11:49:19 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA19696; Fri, 19 Aug 94 11:48:28 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14617(1)>; Fri, 19 Aug 1994 11:41:25 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 19 Aug 1994 11:41:15 -0700 To: Tony Li Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) Cluster addresses and providers...... In-Reply-To: tli's message of Thu, 18 Aug 94 16:34:21 -0800. <199408182334.QAA01218@lager.cisco.com> Date: Fri, 19 Aug 1994 11:41:09 PDT From: Steve Deering Message-Id: <94Aug19.114115pdt.12171@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > If we also had addresses for boxes and used that address for the > definition of a cluster, it would help things considerably. It would > make it clear which box belonged to which cluster. The current scheme > forces one to do some strange things (DMZs) to insure that clusters > correspond to reasonable administrative entities. Tony, Can you help me to understand this? I don't understand what difference it makes whether cluster boundaries fall across links (e.g., DMZs) *or* across routers, with respect to making cluster addressing work. Steve ------------------------------------------------------------------------------ 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 Fri Aug 19 13:17:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12588; Fri, 19 Aug 94 13:17:24 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12582; Fri, 19 Aug 94 13:17:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24835; Fri, 19 Aug 94 13:14:31 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA04420; Fri, 19 Aug 94 13:14:13 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA18950; Fri, 19 Aug 1994 13:14:04 -0700 Date: Fri, 19 Aug 1994 13:14:04 -0700 From: Tony Li Message-Id: <199408192014.NAA18950@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: yakov@watson.ibm.com, ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Fri, 19 Aug 1994 11:31:14 PDT <94Aug19.113128pdt.12171@skylark.parc.xerox.com> Subject: (IPng) cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, We *should* relax the following statement in that section: Cluster boundary routers are required to know that they are boundary routers and to accept packets addressed to the corresponding cluster address as being addressed to themselves. because I think it may be too burdensome for a router to know all of the clusters for which it is on the boundary. It really only needs to recognize those cluster addresses that will actually be *used* as destinations of packets. In your example of clusters , , and , if only and are useful (to reach the facilities of the subscriber and the facilities of the provider, respectively), then there is no need for any router to know it is on the boundary of . Are you suggesting that the important cluster addresses be configured on the router? I was under the impression that the router was responsible (through FM ;-) for computing its cluster addresses. Note that computation is not simply finding the longest common bit strings amongst all subnet addresses yields incorrect results (bit strings terminating in the middle of hierarchical levels). Thus, the router is responsible for understanding all layers of hierarchy above it. This seems "challenging". Am I way off base? > Could you please be more specific on what a router can derive > automatically (and how), so that we'll get a better understanding > of what is assumed to require configuration. I'm not sure I can be more specific, and I could use your help in figuring it out. Certainly routers can be expected to know (either through manual configuration or through some as-yet-undefined router autoconfig mechanism) the subnet numbers of their directly-attached links, so from that they can "automatically" realize that the subnet prefixes of those links are cluster addresses they must recognize. I had hoped that entry routers into higher-level aggregates would analagously know the prefixes that identified those aggregates, and could thus automatically adopt those higher-level prefixes as cluster addresses that they must recognize. If the necessary knowledge is not already present, then it would have to be configured. I would consider requiring manual configuration of anything to be completely unacceptable. Tony ------------------------------------------------------------------------------ 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 Fri Aug 19 14:01:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12629; Fri, 19 Aug 94 14:01:33 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12623; Fri, 19 Aug 94 14:01:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA26686; Fri, 19 Aug 94 13:58:41 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA12783; Fri, 19 Aug 94 13:58:18 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14558(2)>; Fri, 19 Aug 1994 13:52:23 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 19 Aug 1994 13:52:13 -0700 To: Tony Li Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) Cluster addresses and providers...... In-Reply-To: tli's message of Fri, 19 Aug 94 12:58:05 -0800. <199408191958.MAA17991@lager.cisco.com> Date: Fri, 19 Aug 1994 13:52:01 PDT From: Steve Deering Message-Id: <94Aug19.135213pdt.12171@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony, > The point is that the cluster boundary needs to fall along > administrative lines, and with the current model, administrative lines > and addressing lines are blurred. Well, clearly if we want to use addressing lines to identify administrative boundaries, we have to un-blur them. But it seems to me that it ought to be possible to draw a clear administrative line either between routers or through the middle of routers. > A cleaner model would have a router belong to a set of nested clusters. I agree that that's cleaner, but doesn't that imply the need for DMZs, which I thought you didn't like? In the BARRnet/Xerox example you gave, the T1 line between the two organizations would be the DMZ. If Xerox and BARRnet happened to be physically adjacent, and the two organizations agreed to share the cost of a router connecting Xerox facilities to BARRnet facilities, your model would require them to buy two routers instead, connected by a DMZ wire. (I guess if you're in the business of selling routers, that sounds like a pretty good model! :-) ) Steve ------------------------------------------------------------------------------ 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 Fri Aug 19 14:14:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12641; Fri, 19 Aug 94 14:14:34 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12635; Fri, 19 Aug 94 14:14:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA27292; Fri, 19 Aug 94 14:11:36 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA15397; Fri, 19 Aug 94 14:11:19 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14598(3)>; Fri, 19 Aug 1994 14:10:35 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 19 Aug 1994 14:10:30 -0700 To: Tony Li Cc: yakov@watson.ibm.com, ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) cluster addresses In-Reply-To: tli's message of Fri, 19 Aug 94 13:14:04 -0800. <199408192014.NAA18950@lager.cisco.com> Date: Fri, 19 Aug 1994 14:10:25 PDT From: Steve Deering Message-Id: <94Aug19.141030pdt.12171@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony, > Are you suggesting that the important cluster addresses be configured > on the router? I was under the impression that the router was > responsible (through FM ;-) for computing its cluster addresses. I am suggesting that any important cluster addresses that cannot be derived automatically by the router should be configured into the router. I was hoping that all important cluster addresses could be automatically derived, but I recognized that that might require some Future Magic (is that what "FM" stands for?). > Note that computation is not simply finding the longest common bit > strings amongst all subnet addresses yields incorrect results (bit > strings terminating in the middle of hierarchical levels). Thus, the > router is responsible for understanding all layers of hierarchy above > it. This seems "challenging". > > Am I way off base? No, you are right on. It was to ameliorate that challenge that I suggested that a router might *not* be required to understand all layers of hierarchy above it, just the "important" layers. > I would consider requiring manual configuration of anything to be > completely unacceptable. Undesirable fer sure, but "completely unacceptable"? Unless you are proposing an entirely self-organizing hierarchy completely insensitive to administrative boundaries (maybe something like Landmark Routing?), *some* manual configuration of boundary routers seems inevitable to me. I thought the alternative to cluster addresses that you were considering was AS numbers; don't AS numbers have to manually configured into routers? At least with cluster addresses, there is *some* hope of having them automatically derived, at least in some cases. Steve ------------------------------------------------------------------------------ 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 Fri Aug 19 16:38:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12782; Fri, 19 Aug 94 16:38:02 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12776; Fri, 19 Aug 94 16:37:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03588; Fri, 19 Aug 94 16:35:09 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AB09895; Fri, 19 Aug 94 16:34:56 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA01452; Fri, 19 Aug 1994 16:34:54 -0700 Date: Fri, 19 Aug 1994 16:34:54 -0700 From: Tony Li Message-Id: <199408192334.QAA01452@lager.cisco.com> To: deering@parc.xerox.com Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Fri, 19 Aug 1994 13:52:01 PDT <94Aug19.135213pdt.12171@skylark.parc.xerox.com> Subject: (IPng) Cluster addresses and providers...... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, > The point is that the cluster boundary needs to fall along > administrative lines, and with the current model, administrative lines > and addressing lines are blurred. Well, clearly if we want to use addressing lines to identify administrative boundaries, we have to un-blur them. But it seems to me that it ought to be possible to draw a clear administrative line either between routers or through the middle of routers. Agreed. However, the current spec does not do this. And while it's possible, it's not clear to me that this doesn't have a performance impact on switching, as the input interface is now an important consideration. > A cleaner model would have a router belong to a set of nested clusters. I agree that that's cleaner, but doesn't that imply the need for DMZs, which I thought you didn't like? In the BARRnet/Xerox example you gave, the T1 line between the two organizations would be the DMZ. If Xerox and BARRnet happened to be physically adjacent, and the two organizations agreed to share the cost of a router connecting Xerox facilities to BARRnet facilities, your model would require them to buy two routers instead, connected by a DMZ wire. (I guess if you're in the business of selling routers, that sounds like a pretty good model! :-) ) Yes, I dislike DMZ's. However, it's not clear to me that DMZ's are the only way of achieving this model. For example, we could designate a particular address for a router and use the set of clusters implied by that address for the router. Note that the designated address could be an actual interface address, so this costs nothing in address space. One might also want to add in the subnet cluster addresses as well. Tony ------------------------------------------------------------------------------ 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 Fri Aug 19 16:50:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12806; Fri, 19 Aug 94 16:50:19 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12799; Fri, 19 Aug 94 16:50:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA04073; Fri, 19 Aug 94 16:47:25 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA11965; Fri, 19 Aug 94 16:47:07 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA02001; Fri, 19 Aug 1994 16:47:03 -0700 Date: Fri, 19 Aug 1994 16:47:03 -0700 From: Tony Li Message-Id: <199408192347.QAA02001@lager.cisco.com> To: deering@parc.xerox.com Cc: yakov@watson.ibm.com, ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Fri, 19 Aug 1994 14:10:25 PDT <94Aug19.141030pdt.12171@skylark.parc.xerox.com> Subject: (IPng) cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, > I would consider requiring manual configuration of anything to be > completely unacceptable. Undesirable fer sure, but "completely unacceptable"? Well, ok, anything OTHER than the security key is completely unacceptable. Which I really expect to be plugged in via PCMCIA or similar hardware. I was under the impression that autoconfiguration was a mandatory requirement for IPv6. Unless you are proposing an entirely self-organizing hierarchy completely insensitive to administrative boundaries (maybe something like Landmark Routing?), Yes, something like that is required. Manually managing routing does not scale. Think Big. ;-) I thought the alternative to cluster addresses that you were considering was AS numbers; don't AS numbers have to manually configured into routers? That's not clear to me. The router should be able to determine via some mechanism that it's a domain boundary router and from there dynamically learn what's going on. Configuration of policy will of course need to be done, but that will need to be centralized. Oh, and we call them Routing Domain Identifiers now. ;-) Tony ------------------------------------------------------------------------------ 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 Fri Aug 19 17:11:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12830; Fri, 19 Aug 94 17:11:07 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12823; Fri, 19 Aug 94 17:10:59 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05221; Fri, 19 Aug 94 17:08:14 PDT Received: from nic.ott.hookup.net by Sun.COM (sun-barr.Sun.COM) id AA15591; Fri, 19 Aug 94 17:07:58 PDT Received: from [165.154.16.159] (kgk.ott.hookup.net [165.154.16.159]) by nic.ott.hookup.net (8.6.9/1.28) with SMTP id UAA15849; Fri, 19 Aug 1994 20:07:50 -0400 Message-Id: <199408200007.UAA15849@nic.ott.hookup.net> X-Sender: kgk@nic.ott.hookup.net (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Aug 1994 20:09:33 -0500 To: ipng@sunroof.Eng.Sun.COM From: kgk@hookup.net (Keith G Knightson) Subject: (IPng) IPNG 16 to OSI NSAP mappability Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Why is everybody going to endless lengths to map what is ultimately unmappable? It would be far easier for everbody to adopt to 20 byte address field, period. Addresses are not simply about how many target objects there are. In practice,they are about structured hierarchies. They are even used to define routing strategies. The size of the binary equivalent of 16 or 20 bytes is totally irrelevant unless you want to advocate a totally flat address space and then randomly allocate it. As a matter of fact the Canadian Standard for OSI NSAP addresses only has two non-used, reserved, octets. This structure is being used by the large Air Traffic Control system being set up in Canada, as well as by the Government's Enterprise Core Network. Globally, the International Air Trafiic Association is also using OSI NSAP addresses. Closer to home, I understand that the Cellular Digital Packet Data network is going to allocate zillions of OSI NSAP addresses. It seems to me that the proposal to use 16 bytes should be re-examined. Keith G Knightson KGK Enterprises Tel 613 592 7646 Fax 613 592 6261 Email: kgk@hookup.net ------------------------------------------------------------------------------ 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 Fri Aug 19 20:48:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12911; Fri, 19 Aug 94 20:48:11 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12905; Fri, 19 Aug 94 20:48:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12057; Fri, 19 Aug 94 20:45:18 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA09857; Fri, 19 Aug 94 20:45:06 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA02534; Fri, 19 Aug 94 20:40:35 -0700 Received: by xirtlu.zk3.dec.com; id AA25820; Fri, 19 Aug 1994 23:40:22 -0400 Message-Id: <9408200340.AA25820@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Oct 10-14 IPng Implementors and Base Group Meeting In-Reply-To: Your message of "Thu, 18 Aug 94 16:21:22 PDT." <199408182321.QAA00219@lager.cisco.com> Date: Fri, 19 Aug 94 23:40:16 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Joachim, > >To keep the group making progress, please send only one or two >implementors. > >Thanks, >Tony Folks, I think Tony's request is a good one? Can we say 3 people from each org or entity (I know I hate that word too)? Lets suppose 14 orgs come then we have 45 people. Thats a bunch eh. Also this is the base group meeting and any work that may get added we don't know of yet I guess. Any major objections? thanks /jim ------------------------------------------------------------------------------ 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 Fri Aug 19 20:52:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12924; Fri, 19 Aug 94 20:52:11 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12918; Fri, 19 Aug 94 20:52:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12096; Fri, 19 Aug 94 20:49:18 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA10107; Fri, 19 Aug 94 20:49:08 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA02244; Fri, 19 Aug 94 20:30:58 -0700 Received: by xirtlu.zk3.dec.com; id AA25748; Fri, 19 Aug 1994 23:30:46 -0400 Message-Id: <9408200330.AA25748@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: end2end-interest@ISI.EDU, int-serv@ISI.EDU, posix-net-ptp@nemo.ncsl.nist.gov, keshav@research.att.com Subject: Re: (IPng) Re: Generic QoS Socket Interface In-Reply-To: Your message of "Thu, 18 Aug 94 16:06:28 EDT." <9408182006.AA10093@depot> Date: Fri, 19 Aug 94 23:30:40 -0400 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 am just wondering off the top of my head if we should keep this all in the kernel and transparent to user space. What about using an out-of-band signal with modifications to define a change to the QOS? The change could be a jitter of some sort? Does the application have to know about the change? If so why? Seems messy to pass this in and out of kernel and user space or involving an RPC or library, but I understand why it was done today. Or do we just need a session layer above transport so we don't have to mess with TCP or UDP? I am beginning to see other reasons for a session layer in IP6 besides this topic too, but maybe not???? I really don't think now is the time to mess with the transport layer and change the network layer too. This is most likely too much work for host vendors at one time to absorb. /jim ------------------------------------------------------------------------------ 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 Fri Aug 19 21:10:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12944; Fri, 19 Aug 94 21:10:39 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12938; Fri, 19 Aug 94 21:10:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12454; Fri, 19 Aug 94 21:07:46 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA10911; Fri, 19 Aug 94 21:07:35 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA03256; Fri, 19 Aug 94 21:03:22 -0700 Received: by xirtlu.zk3.dec.com; id AA26112; Sat, 20 Aug 1994 00:01:52 -0400 Message-Id: <9408200401.AA26112@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: alan@datacraft.oz.au, brian@dxcoms.cern.ch Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Fri, 19 Aug 94 14:08:36 +0200." <9408190508.AA03168@necom830.cc.titech.ac.jp> Date: Sat, 20 Aug 94 00:01:46 -0400 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, NSAP mapping is in our to-do list? I think Bill's request to Brian is reasonable. Brian is not around right now so lets give him a chance to respond. I am working with Brian on this and will be asking around the NSAP users I know if the answer is available in someones black book. Let me give you one use of NSAP mappings that could be a possibility. Those using NSAPs are typically also using the OSI stack. Those customers in the market most likley want to traverse the Information Highway without maybe using IP6 or IPv4 in their domain. So will other protocols most likely. Now to traverse the Information Highway it is feasible that at points in the topology entering the Information Highway that an NSAP gets translated via the to-do list mapping to a destination address on the Highway which will deliver the message back to an NSAP conscious domain. This is the simplest case and can be done. More complex cases are under study now but are much more messy by such facts that IP6 still has the notion of subnets and NSAPs don't really per IS-IS (one user of NSAPs). But can we let Brian get his next draft out and give it a chance. thanks /jim ------------------------------------------------------------------------------ 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 Fri Aug 19 22:28:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12977; Fri, 19 Aug 94 22:28:02 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12971; Fri, 19 Aug 94 22:27:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14210; Fri, 19 Aug 94 22:25:09 PDT Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA14797; Fri, 19 Aug 94 22:24:59 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id WAA23111; Fri, 19 Aug 1994 22:20:53 -0700 Date: Fri, 19 Aug 1994 22:20:53 -0700 From: Dave Katz Message-Id: <199408200520.WAA23111@feta.cisco.com> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, alan@datacraft.oz.au, brian@dxcoms.cern.ch In-Reply-To: bound@zk3.dec.com's message of Sat, 20 Aug 94 00:01:46 -0400 <9408200401.AA26112@xirtlu.zk3.dec.com> Subject: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This is the simplest case and can be done. More complex cases are under study now but are much more messy by such facts that IP6 still has the notion of subnets and NSAPs don't really per IS-IS (one user of NSAPs). Subnets and areas are both bottom-level topological abstractions; a subnet is effectively a special case of an area. This should not be an issue. For that matter, IPv6 could easily be implemented with a "subnet" spanning multiple links (using IS-IS). This should be doable either way without the hosts knowing the difference, so long as hosts don't try to know what's on the local wire and what's not. But I digress... ------------------------------------------------------------------------------ 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 Sat Aug 20 02:42:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13018; Sat, 20 Aug 94 02:42:54 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13012; Sat, 20 Aug 94 02:42:46 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19372; Sat, 20 Aug 94 02:40:01 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA26081; Sat, 20 Aug 94 02:39:50 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA08748; Sat, 20 Aug 94 05:35:53 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9408200935.AA08748@pluto.dss.com> Subject: Re: (IPng) Oct 10-14 IPng Implementors and Base Group Meeting To: ipng@sunroof.Eng.Sun.COM Date: Sat, 20 Aug 1994 05:35:51 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo) In-Reply-To: <9408200340.AA25820@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Aug 19, 94 11:40:16 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 929 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >Joachim, > >To keep the group making progress, please send only one or two > >implementors. > >Thanks, > >Tony > Folks, > I think Tony's request is a good one? Can we say 3 people from each org > or entity (I know I hate that word too)? Lets suppose 14 orgs come then > we have 45 people. Thats a bunch eh. Also this is the base group > meeting and any work that may get added we don't know of yet I guess. > Any major objections? > thanks > /jim Actually, to send developers to five days of meetings is too costly and causes a schedule hit. I was intending to send only one person every day for continuity while the rest would be alternated on the other days. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com ------------------------------------------------------------------------------ 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 Sat Aug 20 07:43:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13105; Sat, 20 Aug 94 07:43:04 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13099; Sat, 20 Aug 94 07:42:57 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA23425; Sat, 20 Aug 94 07:40:11 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA06690; Sat, 20 Aug 94 07:40:01 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA17509; Sat, 20 Aug 94 07:36:26 -0700 Received: by xirtlu.zk3.dec.com; id AA02413; Sat, 20 Aug 1994 10:35:26 -0400 Message-Id: <9408201435.AA02413@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: martillo@pluto.dss.com (Joachim Martillo) Subject: Re: (IPng) Oct 10-14 IPng Implementors and Base Group Meeting In-Reply-To: Your message of "Sat, 20 Aug 94 05:35:51 EDT." <9408200935.AA08748@pluto.dss.com> Date: Sat, 20 Aug 94 10:35:20 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joachimm Well we are down to 2.5 days now (Mon-Wed/Noon | Oct 10-12). My experience with the two previous implementor meetings has been that there is continuity in the discussions from topic to topic at this technical level. Your idea of parsing out folks is a good one but continuity will be important too even if your local. Just a thought. /jim ------------------------------------------------------------------------------ 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 Sat Aug 20 07:59:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13122; Sat, 20 Aug 94 07:59:38 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13116; Sat, 20 Aug 94 07:59:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA23639; Sat, 20 Aug 94 07:56:45 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA07268; Sat, 20 Aug 94 07:56:33 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA18113; Sat, 20 Aug 94 07:52:12 -0700 Received: by xirtlu.zk3.dec.com; id AA02538; Sat, 20 Aug 1994 10:51:11 -0400 Message-Id: <9408201451.AA02538@xirtlu.zk3.dec.com> To: Dave Katz Cc: ipng@sunroof.Eng.Sun.COM, alan@datacraft.oz.au, brian@dxcoms.cern.ch Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Fri, 19 Aug 94 22:20:53 PDT." <199408200520.WAA23111@feta.cisco.com> Date: Sat, 20 Aug 94 10:51:04 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Subnets and areas are both bottom-level topological abstractions; a >subnet is effectively a special case of an area. This should not be >an issue. Well it is because in the NSAP model as used today IS-IS is assumed and that assumption is that essentially the NSAP router that receives the incoming packets will know on what link the sysid (for the Host) lives in the domain. In the IP6 Architecture you must also know the subnet. The issue is how can we encode that IP6 subnet in any mappings or translation for an NSAP. In IPX this seems doable. But anyway with NSAPs this is what makes complex doing more than the simple case I proposed so NSAP users could traverse the Internet backbone. We made a recommendation that we have NSAP mapping, but now in hind site I wish we had been less political and a bit more technical so we would have defined what actual use this provides to NSAP users. Mabye Brian and I can put this in the draft (better late than never)? >For that matter, IPv6 could easily be implemented with a "subnet" >spanning multiple links (using IS-IS). This should be doable either Can you expound on this technically in more detail? It sounds interesting and I would like to see your logic tables on this for topology. >way without the hosts knowing the difference, so long as hosts don't >try to know what's on the local wire and what's not. But I digress... Well one place I want to know the subnet is for transport fast path code where I actually may by-pass kernel code. Others are for network management and systems management. Also DNS could use this differentiation too as it evolves and for security implementation of IP6. I don't think we will ever agree on this issue but maybe. I digress too. /jim ------------------------------------------------------------------------------ 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 Sat Aug 20 11:33:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13227; Sat, 20 Aug 94 11:33:19 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13221; Sat, 20 Aug 94 11:33:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA27079; Sat, 20 Aug 94 11:30:25 PDT Received: from CIA.TGV.COM by Sun.COM (sun-barr.Sun.COM) id AA14705; Sat, 20 Aug 94 11:30:16 PDT Date: Sat, 20 Aug 1994 11:30:14 -0700 (PDT) From: "L. Stuart Vance" Subject: Re: (IPng) Re: Generic QoS Socket Interface To: ipng@sunroof.Eng.Sun.COM Cc: end2end-interest@ISI.EDU, int-serv@ISI.EDU, posix-net-ptp@nemo.ncsl.nist.gov, keshav@research.att.com Message-Id: <777407414.587937.VANCE@TGV.COM> In-Reply-To: <9408200330.AA25748@xirtlu.zk3.dec.com> Mail-System-Version: Organization: TGV, Inc. X-Phone: +1 408 457 5200 (work); +1 408 457 5208 (fax) X-Address: 101 Cooper Street; Santa Cruz, CA 95060 (work) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I am just wondering off the top of my head if we should keep this all >in the kernel and transparent to user space. > >What about using an out-of-band signal with modifications to define >a change to the QOS? The change could be a jitter of some sort? > >Does the application have to know about the change? If so why? > >Seems messy to pass this in and out of kernel and user space or >involving an RPC or library, but I understand why it was done today. > >Or do we just need a session layer above transport so we don't >have to mess with TCP or UDP? I am beginning to see other reasons for a >session layer in IP6 besides this topic too, but maybe not???? > >I really don't think now is the time to mess with the transport layer >and change the network layer too. This is most likely too much work >for host vendors at one time to absorb. A good point, but let me offer something to counter it. Let's make all the changes at once, so that the customers only have to deal with it once. It's going to be a difficult enough task to deal with one conversion, let alone two... Regards, -----Stuart ------------------------------------------------------------------------------ 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 Sat Aug 20 12:15:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13254; Sat, 20 Aug 94 12:15:55 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13248; Sat, 20 Aug 94 12:15:47 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA27722; Sat, 20 Aug 94 12:13:02 PDT Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA16168; Sat, 20 Aug 94 12:12:52 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA11132; Sat, 20 Aug 1994 12:09:00 -0700 Date: Sat, 20 Aug 1994 12:09:00 -0700 From: Dave Katz Message-Id: <199408201909.MAA11132@feta.cisco.com> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, alan@datacraft.oz.au, brian@dxcoms.cern.ch In-Reply-To: bound@zk3.dec.com's message of Sat, 20 Aug 94 10:51:04 -0400 <9408201451.AA02538@xirtlu.zk3.dec.com> Subject: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: bound@zk3.dec.com Date: Sat, 20 Aug 94 10:51:04 -0400 X-Mts: smtp >Subnets and areas are both bottom-level topological abstractions; a >subnet is effectively a special case of an area. This should not be >an issue. Well it is because in the NSAP model as used today IS-IS is assumed and that assumption is that essentially the NSAP router that receives the incoming packets will know on what link the sysid (for the Host) lives in the domain. This isn't true, Jim. One could just as easily look at an NSAP and call the left hand 13 bytes the "subnet", declare that such subnets only live on a single wire, and stop advertising the system ID (which by the way only is advertised within the IS-IS area, not throughout the domain). Note that we could do this today in CLNP without changing the hosts at all. This boils down to a simple issue of where you decide to let your address space go flat at the bottom, reflected in deployment and in routing. The difference between the approaches is not reflected in the address structure nor in the architecture of the base protocol, but in the routing protocols and in the deployment (neither of which the host needs knowledge of). In the IP6 Architecture you must also know the subnet. If the "you" in this case is the host, I'm strongly opposed to this idea, as you know. See below. >For that matter, IPv6 could easily be implemented with a "subnet" >spanning multiple links (using IS-IS). This should be doable either Can you expound on this technically in more detail? It sounds interesting and I would like to see your logic tables on this for topology. See below. >way without the hosts knowing the difference, so long as hosts don't >try to know what's on the local wire and what's not. But I digress... Well one place I want to know the subnet is for transport fast path code where I actually may by-pass kernel code. Others are for network management and systems management. Also DNS could use this differentiation too as it evolves and for security implementation of IP6. I'm lost as to how this helps you in the transport layer. Please explain. Topology knowledge (such as the existence of an address prefix that is bound to a wire, commonly called a "subnet" ;-) ) is certainly something that network management needs to know, as does routing and administration. My assertion is that knowing that a wire has a particular prefix is *not* something that a host should know about, for a number of reasons. Giving the host knowledge of the routing paradigm makes it very difficult to change things later. The obvious grievous example of this is the local/distant decision that IPv4 hosts currently make; the fact that many of them don't get it right led to the invention of Proxy ARP (originally known, and more properly I think, as the "ARP Hack"). The second grievous example is the host practice of eavesdropping on routing protocols (I shudder when I see people wanting to eavesdrop on OSPF; RIP was bad enough). This makes changing the protocols a backwards compatibility nightmare (witness the constraints placed on RIP 2). Knowledge of this type makes hosts more complex (and less likely to be done right). I believe that the right way for hosts to forward packets (done for CLNP but also adopted in the SIPP Discovery draft) is to always hand them to a router initially, then building a route cache based on received redirects. If the destination is on the same wire, the redirect reflects this; otherwise the redirect may point to another router (or there may be no redirect at all). If there are no routers present, the host multicasts the packet, and the destination host responds with its datalink address so that further packets may be unicast. If you do this, you are free to do almost anything you want routing-wise, because routing becomes completely opaque to the hosts (all they see is a cache of fully specified addresses of the hosts with which they have active conversations). So if you wanted to make an address prefix span multiple wires, you could use a routing protocol that advertised the low-order part of the addresses (such as what IS-IS does with CLNP) within the topological scope of the prefix, so that the routers know where everybody is. Outside of that scope, only the prefix is advertised. Hosts *don't know the difference* (which is the key); they just hand the packets to the routers, and if the destination is on another wire, the packets continue to go through the router. For people who really like to torque their hosts, the "route add" Unix command would simply update the host's route cache, though hopefully doing all of this properly will make this an extremely rare occurrence. Keeping a host routing cache, rather than the whole routing load, will also greatly reduce the size of the routing information kept in the host, and should presumably speed up routing lookups due to the reduced number of entries. The multihomed host case is best served by a request/response model, I think; the host can ask out each of its interfaces about the route to its destination and attempt to choose among the responses (a non-trivial exercise even today, since you really can't tell much of anything about the destination other than whether it's reachable or not). The information returned in the reply would be equivalent to what would have been gleaned by eavesdropping on the routing protocol, except that the information load is greatly reduced, and the hosts are decoupled from the routing protocol. (RIP requests will never die!) If hosts can be assigned multiple addresses due to policy issues, the idea of what's "local" can become even more complex; if you just let routing take care of it (which is its job after all) the host can be blissfully unaware (which is its job after all [spoken as a routing guy ;-) ] ). I don't think we will ever agree on this issue but maybe. Here's hoping... --Dave ------------------------------------------------------------------------------ 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 Sat Aug 20 22:14:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13426; Sat, 20 Aug 94 22:14:40 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13420; Sat, 20 Aug 94 22:14:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA06708; Sat, 20 Aug 94 22:11:46 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA04293; Sat, 20 Aug 94 22:11:34 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA15386; Sat, 20 Aug 94 22:06:40 -0700 Received: by xirtlu.zk3.dec.com; id AA10949; Sun, 21 Aug 1994 01:05:37 -0400 Message-Id: <9408210505.AA10949@xirtlu.zk3.dec.com> To: Dave Katz Cc: ipng@sunroof.Eng.Sun.COM, alan@datacraft.oz.au, brian@dxcoms.cern.ch Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Sat, 20 Aug 94 12:09:00 PDT." <199408201909.MAA11132@feta.cisco.com> Date: Sun, 21 Aug 94 01:05:31 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Subnets and areas are both bottom-level topological abstractions; a >subnet is effectively a special case of an area. This should not be >an issue. Well it is because in the NSAP model as used today IS-IS is assumed and that assumption is that essentially the NSAP router that receives the incoming packets will know on what link the sysid (for the Host) lives in the domain. >This isn't true, Jim. One could just as easily look at an NSAP and Dave its true but yes it could be different. If I have 5 routers in an area all on different local wires any router in most cases knows the sysid or can determine it for any host on any wire. A second level of indirection such as an IPv4 subnet is not required. So to say what I said is not true is not true. >call the left hand 13 bytes the "subnet", declare that such subnets >only live on a single wire, and stop advertising the system ID (which >by the way only is advertised within the IS-IS area, not throughout >the domain). Note that we could do this today in CLNP without changing >the hosts at all. But they may not and usually don't live on the same wire. Your abstraction is correct. What I am trying to figure out is how to make it work at the detail level after the abstraction. As a comment it will not help that I am hearing that some have used what were to be RESERVED FIELDs in the NSAP. They may just have to live with that pain now, but I hope not. Though I am still not sure what good mapping NSAPs to 16bytes does anyone other then just let them traverse the Internet path at certain points in their geography or at provider overlaps. >>way without the hosts knowing the difference, so long as hosts don't >>try to know what's on the local wire and what's not. But I digress... >>Well one place I want to know the subnet is for transport fast path code >>where I actually may by-pass kernel code. Others are for network >>management and systems management. Also DNS could use this >>differentiation too as it evolves and for security implementation of >>IP6. >I'm lost as to how this helps you in the transport layer. Please Well you answer this below on the how which I will ACK to later. But at the transport if I know the dst addr is on my subnet I an avoid code path in the kernel. In other words no hops means I can do things in a product for a fast path I cannot go into here obviously. >Topology knowledge (such as the existence of an address prefix that is >bound to a wire, commonly called a "subnet" ;-) ) is certainly >something that network management needs to know, as does routing and >administration. My assertion is that knowing that a wire has a >particular prefix is *not* something that a host should know about, >or a number of reasons. We got into this in addrconf list per your draft. I submit to your concerns. As long as I can build network management boxes, transition translators, host gateways, etc. where I have the need to know in a particular application for a customer. >Giving the host knowledge of the routing paradigm makes it very >difficult to change things later. The obvious grievous example of >this is the local/distant decision that IPv4 hosts currently make; the >fact that many of them don't get it right led to the invention of >Proxy ARP (originally known, and more properly I think, as the >"ARP Hack"). The second grievous example is the host practice of >eavesdropping on routing protocols (I shudder when I see people >wanting to eavesdrop on OSPF; RIP was bad enough). This makes >changing the protocols a backwards compatibility nightmare (witness >the constraints placed on RIP 2). I agree and SIPP system discovery previous drafts solved these problems too and I did not object. It comes down to wanting to build what ever I want, when I want, and if I can make money on it. If I want to take a Host computer and make it a router, an address server, or whatever I just don't want any IETF spec to get in the way of my capitalistic endeavers to save person-kind from the evils of this is good for you and you will like the architecture. I see this is not happening via our discussion and I am glad. >I believe that the right way for hosts to forward packets (done for >CLNP but also adopted in the SIPP Discovery draft) is to always hand >them to a router initially, then building a route cache based on >received redirects. If the destination is on the same wire, the >redirect reflects this; otherwise the redirect may point to another >router (or there may be no redirect at all). If there are no routers >present, the host multicasts the packet, and the destination host >responds with its datalink address so that further packets may be >unicast. ACK. >If you do this, you are free to do almost anything you want >routing-wise, because routing becomes completely opaque to the hosts >(all they see is a cache of fully specified addresses of the hosts >with which they have active conversations). So if you wanted to make >an address prefix span multiple wires, you could use a routing >protocol that advertised the low-order part of the addresses (such as >what IS-IS does with CLNP) within the topological scope of the prefix, >so that the routers know where everybody is. Outside of that scope, >only the prefix is advertised. Hosts *don't know the difference* >(which is the key); they just hand the packets to the routers, and >if the destination is on another wire, the packets continue to go >through the router. This will permit the fast path I referenced too. >For people who really like to torque their hosts, the "route add" >Unix command would simply update the host's route cache, though >hopefully doing all of this properly will make this an extremely rare >occurrence. Well developers need to during testing like IP6 sometimes. >Keeping a host routing cache, rather than the whole routing load, >will also greatly reduce the size of the routing information kept >in the host, and should presumably speed up routing lookups due to >the reduced number of entries. ACK. >The multihomed host case is best served by a request/response model, >I think; the host can ask out each of its interfaces about the >route to its destination and attempt to choose among the responses >(a non-trivial exercise even today, since you really can't tell >much of anything about the destination other than whether it's reachable >or not). The information returned in the reply would be equivalent >to what would have been gleaned by eavesdropping on the routing protocol, >except that the information load is greatly reduced, and the hosts >are decoupled from the routing protocol. (RIP requests will never >die!) Interesting view. I need to think about that )--> good concept. >If hosts can be assigned multiple addresses due to policy issues, the >idea of what's "local" can become even more complex; if you just let >routing take care of it (which is its job after all) the host can be >blissfully unaware (which is its job after all [spoken as a routing >guy ;-) ] ). Hmmm. I need to think about firewall products using Hosts presently as screening routers for this case. >I don't think we will ever agree on this issue but maybe. >Here's hoping... We are in synch and thank you for going to the detail level with me. I need to go think on this now. /jim ------------------------------------------------------------------------------ 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 Sat Aug 20 22:54:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13477; Sat, 20 Aug 94 22:54:34 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13471; Sat, 20 Aug 94 22:54:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07321; Sat, 20 Aug 94 22:51:42 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA05726; Sat, 20 Aug 94 22:51:25 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA16269; Sat, 20 Aug 94 22:35:58 -0700 Received: by xirtlu.zk3.dec.com; id AA11240; Sun, 21 Aug 1994 01:34:57 -0400 Message-Id: <9408210534.AA11240@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: end2end-interest@ISI.EDU, int-serv@ISI.EDU, posix-net-ptp@nemo.ncsl.nist.gov, keshav@research.att.com Subject: Re: (IPng) Re: Generic QoS Socket Interface In-Reply-To: Your message of "Sat, 20 Aug 94 11:30:14 PDT." <777407414.587937.VANCE@TGV.COM> Date: Sun, 21 Aug 94 01:34:51 -0400 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 Stuart, >A good point, but let me offer something to counter it. Let's make all the >changes at once, so that the customers only have to deal with it once. It's >going to be a difficult enough task to deal with one conversion, let alone >two... But they may not get IP6 in time because IPv4 addresses will be gone. I say this tongue and cheek as it took almost 4 years to figure out IP6. If it takes the same time for TCPng that could put us near the year 2000 and the way the Internet is getting used up we could be in real trouble. Also think about the testing scenarios and the added resources from those who will participate. We have our hands full now dealing with IP6 and transition. We have to search hard for chairs of WGs and we just got started on IP6 and I am not clear how long this will take to ratify to where the specs are stable and real products can be produced. We have some proposed IETF dates but they are gut feelings and many variables could change the dates. We also are not sure of what the IP6 market is either and if it is even wanted by real customers, and now we go invest in a new TCP and UDP. I am not clear this is a good idea. For research it should be done and I hope is being done. Well I know its being done. As for the needs presented recently a session layer would work fine with the proper QOS model in the network layer. This is very doable and TCP/UDP do not have to change at all. This could also be useful for the anycast model proposed too and RPC could forget about the kernel maybe. And if we are going to mess with the transport layer based on a lot of IETF interest the first topic I would be more interested in working on is the concept of an EID (Steve Deering dont yell at me). The benefits here would provide added value for existing customers not percieved new technologies for which no vendor has yet to make $1billion revenue let alone a profit to even begin to recover their investment in new technology. Sorry if I sound like a capitalist instead of lets do something elegant that will run fast or solve the world hunger problem. Its pretty simple to me. Can any vendor make any money on doing such work and how? Lots of folks say I want this technology or that techonology but unless they buy enough of it suppliers will stop providing it. We are in the cusp of our industries paradigm shift to the information market. Until this flys we need really good reasons to change that which ain't broke. Another problem at hand is UDP I think. The new frag/reassem model in IP6 will stress UDP I predict and we discussed this at SIPP implementor meetings in the past while building that proposals prototype code. In stead of dreaming in architecture land, we saw this transport problem manifest itself in the prototypes as they were being developed by programmers or engineers which ever you prefer. What problem would TCPng be trying to solve for the market? Somone should have to answer this question. We had a definitive problem with IPv4 when undertaking that (actually three). Or whats the business problem? Just doing it because we are there now in IP6 is not a good idea IMHO. /jim ------------------------------------------------------------------------------ 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 Sun Aug 21 10:01:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13697; Sun, 21 Aug 94 10:01:19 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13691; Sun, 21 Aug 94 10:01:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15262; Sun, 21 Aug 94 09:58:23 PDT Received: from CIA.TGV.COM by Sun.COM (sun-barr.Sun.COM) id AA26507; Sun, 21 Aug 94 09:58:14 PDT Date: Sun, 21 Aug 1994 09:58:13 -0700 (PDT) From: "L. Stuart Vance" Subject: Re: (IPng) millions of OSI products To: ipng@sunroof.Eng.Sun.COM Message-Id: <777488293.465937.VANCE@TGV.COM> In-Reply-To: <9408210505.AA10949@xirtlu.zk3.dec.com> Mail-System-Version: Organization: TGV, Inc. X-Phone: +1 408 457 5200 (work); +1 408 457 5208 (fax) X-Address: 101 Cooper Street; Santa Cruz, CA 95060 (work) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I believe that the right way for hosts to forward packets (done for >CLNP but also adopted in the SIPP Discovery draft) is to always hand >them to a router initially, then building a route cache based on >received redirects. If the destination is on the same wire, the >redirect reflects this; otherwise the redirect may point to another >router (or there may be no redirect at all). If there are no routers >present, the host multicasts the packet, and the destination host >responds with its datalink address so that further packets may be >unicast. What do you consider to be an acceptable number of routes for a host to cache? In the general case (in my experience), most hosts do not communicate with more that a couple of dozen other hosts concurrently (actually, less than that, but I'm hedging my bets). However, we have some customers who have large servers that communicate with thousands of hosts (soon to be tens of thousands of hosts) for services that they plan to offer on the Internet. >Keeping a host routing cache, rather than the whole routing load, >will also greatly reduce the size of the routing information kept >in the host, and should presumably speed up routing lookups due to >the reduced number of entries. In the general (even 99th percentile), I agree. As a simple example, however, think about how many systems each of the root nameservers communicate with in a 30 minute period (or however long the route cache timeout will be). >The multihomed host case is best served by a request/response model, >I think; the host can ask out each of its interfaces about the >route to its destination and attempt to choose among the responses >(a non-trivial exercise even today, since you really can't tell >much of anything about the destination other than whether it's reachable >or not). The information returned in the reply would be equivalent >to what would have been gleaned by eavesdropping on the routing protocol, >except that the information load is greatly reduced, and the hosts >are decoupled from the routing protocol. (RIP requests will never >die!) Cool. You have almost killed off most of my IP4 prejudices in analyzing IP6 :-) I'm still concerned about routing table maintenance and searches for mojo hosts, however. Regards! -----Stuart ------------------------------------------------------------------------------ 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 Sun Aug 21 10:40:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13733; Sun, 21 Aug 94 10:40:22 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13727; Sun, 21 Aug 94 10:40:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15884; Sun, 21 Aug 94 10:37:28 PDT Received: from databus.databus.com by Sun.COM (sun-barr.Sun.COM) id AA27677; Sun, 21 Aug 94 10:37:17 PDT Date: Sun, 21 Aug 94 13:33 EDT Message-Id: <9408211334.AA15334@databus.databus.com> From: Barney Wolff To: ipng@sunroof.Eng.Sun.COM Subject: dumb-host/smart-router (was Re: (IPng) millions of OSI products) Content-Length: 2511 Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Sun, 21 Aug 1994 09:58:13 -0700 (PDT) > From: "L. Stuart Vance" > > >I believe that the right way for hosts to forward packets (done for > >CLNP but also adopted in the SIPP Discovery draft) is to always hand > >them to a router initially, then building a route cache based on > >received redirects. If the destination is on the same wire, the > >redirect reflects this; otherwise the redirect may point to another > >router (or there may be no redirect at all). If there are no routers > >present, the host multicasts the packet, and the destination host > >responds with its datalink address so that further packets may be > >unicast. > > What do you consider to be an acceptable number of routes for a host to cache? > In the general case (in my experience), most hosts do not communicate with more > that a couple of dozen other hosts concurrently (actually, less than that, but > I'm hedging my bets). However, we have some customers who have large servers > that communicate with thousands of hosts (soon to be tens of thousands of hosts) > for services that they plan to offer on the Internet. > > >Keeping a host routing cache, rather than the whole routing load, > >will also greatly reduce the size of the routing information kept > >in the host, and should presumably speed up routing lookups due to > >the reduced number of entries. > > In the general (even 99th percentile), I agree. As a simple example, however, > think about how many systems each of the root nameservers communicate with in > a 30 minute period (or however long the route cache timeout will be). The logical extension of this reasoning is the classic X.25 network - just say where you want to go and let the net get you there. TCP/IP has never worked that way for multi-homed hosts. While there are certainly plusses in making the router network a black box (black cloud?) it makes multi- vendor networking difficult when vendors can get away with proprietary routing protocols (just teasing, no flames please). Any host wanting to insulate itself from routing protocols can just choose a single fast interface instead of multiple cheap interfaces. Or maybe router vendors will start making PCI/SBus versions. Barney Wolff, Pres. Voice: 914-591-6572 Databus Inc. Fax: 914-591-5677 15 Victor Drive Internet: barney@databus.com Irvington, NY 10533-1919 USA At the corner of database & datacomm ------------------------------------------------------------------------------ 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 Sun Aug 21 12:10:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13832; Sun, 21 Aug 94 12:10:49 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13826; Sun, 21 Aug 94 12:10:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA17374; Sun, 21 Aug 94 12:07:55 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA00677; Sun, 21 Aug 94 12:07:44 PDT Message-Id: <9408211907.AA00677@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7893; Sun, 21 Aug 94 15:07:47 EDT Date: Sun, 21 Aug 94 15:06:32 EDT From: yakov@watson.ibm.com To: deering@parc.xerox.com, tli@cisco.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Fri, 19 Aug 1994 14:10:25 PDT Steve, >I am suggesting that any important cluster address... Please define what an "important cluster address" is. Thanks. 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 Sun Aug 21 12:38:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13848; Sun, 21 Aug 94 12:38:22 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13842; Sun, 21 Aug 94 12:38:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA17924; Sun, 21 Aug 94 12:35:27 PDT Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA01628; Sun, 21 Aug 94 12:35:18 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA05700; Sun, 21 Aug 1994 12:35:24 -0700 Date: Sun, 21 Aug 1994 12:35:24 -0700 From: Dave Katz Message-Id: <199408211935.MAA05700@feta.cisco.com> To: VANCE@TGV.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "L. Stuart Vance"'s message of Sun, 21 Aug 1994 09:58:13 -0700 (PDT) <777488293.465937.VANCE@TGV.COM> Subject: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM What do you consider to be an acceptable number of routes for a host to cache? In the general case (in my experience), most hosts do not communicate with more that a couple of dozen other hosts concurrently (actually, less than that, but I'm hedging my bets). However, we have some customers who have large servers that communicate with thousands of hosts (soon to be tens of thousands of hosts) for services that they plan to offer on the Internet. An easy optimization is to make the redirect pertain to a prefix (of which a single host is the degenerate case) and have the host access its cache using longest-match lookups. If there is only one path to the outside world, the redirect prefix could be of zero length (a.k.a. "default"). >Keeping a host routing cache, rather than the whole routing load, >will also greatly reduce the size of the routing information kept >in the host, and should presumably speed up routing lookups due to >the reduced number of entries. In the general (even 99th percentile), I agree. As a simple example, however, think about how many systems each of the root nameservers communicate with in a 30 minute period (or however long the route cache timeout will be). The lifetime of cache entries will be delivered with the redirect, so the network administration can tune this aspect. However, there's no harm in the host dropping cache entries in an LRU fashion if things get too out of hand. Note that one can (carefully) refresh redirect entries based on reverse traffic (not forward!), so there is likely to already be an approximation of an LRU mechanism (discard entries with the least remaining lifetime). >The multihomed host case is best served by a request/response model, >I think; the host can ask out each of its interfaces about the >route to its destination and attempt to choose among the responses >(a non-trivial exercise even today, since you really can't tell >much of anything about the destination other than whether it's reachable >or not). The information returned in the reply would be equivalent >to what would have been gleaned by eavesdropping on the routing protocol, >except that the information load is greatly reduced, and the hosts >are decoupled from the routing protocol. (RIP requests will never >die!) Cool. You have almost killed off most of my IP4 prejudices in analyzing IP6 :-) I'm still concerned about routing table maintenance and searches for mojo hosts, however. Relax, we're in Santa Cruz. ;-) --Dave ------------------------------------------------------------------------------ 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 Sun Aug 21 13:47:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13865; Sun, 21 Aug 94 13:47:15 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13859; Sun, 21 Aug 94 13:47:07 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18909; Sun, 21 Aug 94 13:44:20 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA03671; Sun, 21 Aug 94 13:44:07 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03308; Mon, 22 Aug 1994 05:51:24 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Cc: Dave Katz , alan@datacraft.oz.au, brian@dxcoms.cern.ch Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Sun, 21 Aug 1994 01:05:31 -0400." <9408210505.AA10949@xirtlu.zk3.dec.com> Date: Mon, 22 Aug 1994 05:51:17 +1000 Message-Id: <2170.777498677@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Sun, 21 Aug 94 01:05:31 -0400 From: bound@zk3.dec.com Message-ID: <9408210505.AA10949@xirtlu.zk3.dec.com> Though I am still not sure what good mapping NSAPs to 16bytes does anyone [...] A very good question. What good does it do? One of the basic requirements of IPv6 is supposed to be that when sites connect to providers they renumber (in most cases) if necessary so the address they're using fits the routing topology. That's how routing is supposed to be able to be scaled to the sizes we're talking about. Given that, what use can it possibly be to try and fit sites existing NSAP (or IPX, or ...) addressing schemes into IPv6 when they're simply going to be renumbered to something else in any case? I do appreciate that there's some political advantage in making it appear as if IPv6 handles NSAP addressing in order to placate those who believe that existing NSAP schemes have some intrinsic merit in and of themselves, regardless of what effects they may have on global routing. For that reason allocating a code point to NSAPs, and making noises as if they're supported somehow makes some sense, but surely its not worth expensing any particular effort on, is it? kre ------------------------------------------------------------------------------ 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 Sun Aug 21 14:05:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13888; Sun, 21 Aug 94 14:05:12 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13882; Sun, 21 Aug 94 14:05:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19195; Sun, 21 Aug 94 14:02:18 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA04265; Sun, 21 Aug 94 14:02:04 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id OAA20830; Sun, 21 Aug 1994 14:02:03 -0700 Date: Sun, 21 Aug 1994 14:02:03 -0700 From: Tony Li Message-Id: <199408212102.OAA20830@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM, dkatz@cisco.com, alan@datacraft.oz.au, brian@dxcoms.cern.ch In-Reply-To: Robert Elz's message of Mon, 22 Aug 1994 05:51:17 +1000 <2170.777498677@munnari.OZ.AU> Subject: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM One of the basic requirements of IPv6 is supposed to be that when sites connect to providers they renumber (in most cases) if necessary so the address they're using fits the routing topology. That's how routing is supposed to be able to be scaled to the sizes we're talking about. Whoa nelly! Where did THAT come from!? My understanding is that IPv6 does NOT require that you renumber. You simply get an IPv6 prefix in addition to your existing IPv4 prefix. The IPv6 prefix is COMPLETELY UNRELATED to the IPv4 prefix. As part of the transition plan, you may use your IPv4 prefix in "compatibility mode" by mapping it into the IPv6 address space. Having a mapping from other address spaces into the IPv6 address space provides the ability to have a "compatibility mode" for them too. Tony ------------------------------------------------------------------------------ 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 Sun Aug 21 15:08:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13934; Sun, 21 Aug 94 15:08:22 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13928; Sun, 21 Aug 94 15:08:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20552; Sun, 21 Aug 94 15:05:26 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA06528; Sun, 21 Aug 94 15:05:13 PDT Received: from pm002-12.dialip.mich.net (pm002-12.dialip.mich.net [35.1.48.93]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA21678; Sun, 21 Aug 1994 18:05:09 -0400 Date: Sun, 21 Aug 94 20:30:52 GMT From: "William Allen Simpson" Message-Id: <3080.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPNG 16 to OSI NSAP mappability Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: kgk@hookup.net (Keith G Knightson) > Why is everybody going to endless lengths to map what is ultimately unmappable? > If this is true, we need to know for sure. Please give detail. Why is an NSAP unmappable? How many _deployed_ nodes does this affect, and who are the operators of these deployed nodes? > As a matter of fact the Canadian Standard for OSI NSAP addresses only has > two non-used, reserved, octets. This structure is being used by the large > Air Traffic Control system being set up in Canada, as well as by the > Government's Enterprise Core Network. > I thought you said these were already deployed? Being set up is _not_ the same as deployed. Particularly when IPv4 was already deployed. How many _deployed_ nodes will this affect, and who are the operators of these deployed nodes? > Globally, the International Air Trafiic Association is also using OSI NSAP > addresses. > A completely deployed network? Why isn't my local airport hooked up? Why do pilots use IPv4 to get weather and file flight plans? When was the OSI plan put into operation? What is the access information? How many _deployed_ nodes will this affect, and who are the operators of these deployed nodes? > Closer to home, I understand that the Cellular Digital Packet Data network > is going to allocate zillions of OSI NSAP addresses. > They are? Why did they get that big IPv4 block? Why is the software they demonstrate IPv4 based? How close are you to the cited industry? How many _deployed_ nodes will this affect, and who are the operators of these deployed nodes? > It seems to me that the proposal to use 16 bytes should be re-examined. > I agree. If we don't need to map any NSAPs, we can get by with 8 bytes just fine. 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 From owner-ipng Sun Aug 21 15:29:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13950; Sun, 21 Aug 94 15:29:25 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13944; Sun, 21 Aug 94 15:29:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20915; Sun, 21 Aug 94 15:26:31 PDT Received: from nic.near.net by Sun.COM (sun-barr.Sun.COM) id AA07283; Sun, 21 Aug 94 15:26:21 PDT Received: from jcurran-ppp.near.net by nic.near.net id aa21609; 21 Aug 94 18:26 EDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 21 Aug 1994 18:26:18 -0400 To: ipng@sunroof.Eng.Sun.COM From: John Curran Subject: Re: (IPng) IPNG 16 to OSI NSAP mappability Cc: William Allen Simpson Message-Id: <9408211826.aa21609@nic.near.net> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 8:30 PM 8/21/94 +0000, William Allen Simpson wrote: >How many _deployed_ nodes will this affect, and who are the operators of >these deployed nodes? Quite a reasonable question... The CLNP networks that I know are not making use of the reserved fields, are using well-known AFI values, and can be mapped via the proposed mapping. If there's anyone with deployed nodes which cannot cope with the proposed mapping, it's definitely time to speak up. >> From: kgk@hookup.net (Keith G Knightson) >> ... >> It seems to me that the proposal to use 16 bytes should be re-examined. >> >I agree. If we don't need to map any NSAPs, we can get by with 8 bytes >just fine. > >Bill.Simpson@um.cc.umich.edu Bill, the desire for NSAP mapping was not motivation for 16-byte addresses (at least, not by my recollection). The desire to avoid a second transition within 30 years is more than sufficient motivation. /John ------------------------------------------------------------------------------ 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 Sun Aug 21 16:46:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13998; Sun, 21 Aug 94 16:46:45 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13992; Sun, 21 Aug 94 16:46:37 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22198; Sun, 21 Aug 94 16:43:50 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA10148; Sun, 21 Aug 94 16:43:37 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA23377; Sun, 21 Aug 1994 16:43:36 -0700 Date: Sun, 21 Aug 1994 16:43:36 -0700 From: Tony Li Message-Id: <199408212343.QAA23377@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM, bill.simpson@um.cc.umich.edu In-Reply-To: John Curran's message of Sun, 21 Aug 1994 18:26:18 -0400 <9408211826.aa21609@nic.near.net> Subject: (IPng) IPNG 16 to OSI NSAP mappability Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >How many _deployed_ nodes will this affect, and who are the operators of >these deployed nodes? Quite a reasonable question... The CLNP networks that I know are not making use of the reserved fields, are using well-known AFI values, and can be mapped via the proposed mapping. If there's anyone with deployed nodes which cannot cope with the proposed mapping, it's definitely time to speak up. I can pretty much assure you that the vast majority of people who would be affected would never be caught dead reading this list. ;-) Nevertheless, I know of very few people who are not using GOSIP formatted addresses. Those that aren't are using something shorter which can still be mapped. >From our experience helping people deploy CLNP, I would estimate that there are roughly 500k active CLNP hosts out there today, most of which do not have Internet connectivity and have no need for it. Most of this is from DECnet sites which have converted (or are converting) to Phase V. Customer confidentiality prevents me from giving you a list. Tony ------------------------------------------------------------------------------ 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 Mon Aug 22 00:05:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14408; Mon, 22 Aug 94 00:05:08 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14402; Mon, 22 Aug 94 00:05:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00424; Mon, 22 Aug 94 00:02:14 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA03048; Mon, 22 Aug 94 00:01:38 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25013; Mon, 22 Aug 1994 17:01:31 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM, Tony Li Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Sun, 21 Aug 1994 14:02:03 MST." <199408212102.OAA20830@lager.cisco.com> Date: Mon, 22 Aug 1994 17:01:26 +1000 Message-Id: <2220.777538886@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Sun, 21 Aug 1994 14:02:03 -0700 From: Tony Li Message-ID: <199408212102.OAA20830@lager.cisco.com> My understanding is that IPv6 does NOT require that you renumber. huh? You simply get an IPv6 prefix in addition to your existing IPv4 prefix. That to me is renumbering - if you change any part of the number at all you may as well change all of it. The IPv6 prefix is COMPLETELY UNRELATED to the IPv4 prefix. Yes. I'm not sure what the emphasis is needed for there, that's kind of obvious. The low order bits are also likely to be unrelated, as apparently most people will be using MAC addresses (or similar) inthe low 48 (or thereabouts) bits of their v6 addresses. Not many people do that with v4 (it doesn't quite fit). As part of the transition plan, you may use your IPv4 prefix in "compatibility mode" by mapping it into the IPv6 address space. Yes - I conveniently ignored that. We certainly do need IPv4 addresses to keep working - the point is to allow new IPv6 hosts to communicate with old IPv4 only hosts, as there's obviously no way for them to all change at once. For that to work IPv6 hosts need IPv4 addresses, or addresses that can be algorithmically mapped (eg: by prepending a whole lot of zeroes, or something), so we definitely need an IPv4 compatability mode (all the IPv4 addresses to exist). Having a mapping from other address spaces into the IPv6 address space provides the ability to have a "compatibility mode" for them too. OK, but for what? The purpose of IPv4 compatability is to allow applications running on v6 hosts to communicate with v4 hosts. If we have lots of NSAP (or IPX) using hosts that need to communicate with hosts talking the same applications on a v6 host, with the point of gradually making the NSAP hosts go away, then yes, we'd need an algorithmic mapping (like a prefix) so that the old NSAP speaking hosts could communicate with the new v6 hosts. But just exactly what are those applications out there now that need this? Since the whole point of this would be transition away from NSAP addressing, we don't need to worry about new applications and new hosts. We have to know what they are and what addresses they are using so we can make sure that the mapping plan will work for them. We know what the IPv4 noodes that need to be converted are like, we use them every day, so far all I see is requests for info about the NSAP using hosts, and no answers. I also suspect that you missed the point of my message. It wasn't that we will need to renumber when transitioning to IPv6 - it was once we're running IPv6 - once IPv4 has vanished into close enough of obscurity that it can be forgotten, just as today we now forget those hosts that don't know about subnets, or don't use MX records to deliver mail - they still exist but aren't numerous enough, or important enough, to cause any concern). Once we get to that point renumbering from time to time will be a fact of life, I'd expect my net to renumber (that is, if you like, change prefix) every few months at an absolute maximum, perhaps even daily. Since handling this will be (must be) automated, it won't be of any great concern to anyone (it will be of even less concern if hosts hat persistent ID's we could rely on, but I will leave that for now). Now its true that for the net as a whole to survive all that's needed is for sites to be able to change prefixes - but since we have all the mechanism required to do arbitrary address changes, then I can use it just as easily inside my net to keep its addressing rational, and flexible. At the minute we are much too much slaves to the number schemes we invent. That's silly, and must be fixed. Since fixing it is almost free with features of IPv6 that are required (prefix shifts) we should make sure we take the opportunity to fix it completely, and install all the right mechanisms for arbitrary internal prefix shifts as well. That is, apart from the MAC address, assuming that is used as part of your particular v6 numbering scheme, and assuming that it remains constant for some period, no-one should be assuming that any other part of the v6 address will be the same tomorrow as it is today. That is, investments in number plans are a waste of time. Numbers shouldn't be something that we treat as precious. Also, for those wishing for 20 bytes for v6 - surely its better that addresses be less than 20, that way all those applications that handle 20 byte addressing can trivially be converted to v6 by simply adding a standard prefix (call it an ICD if you want) to the v6 address, and representing it in the existing 20 byte field. Applications that neither know, nor want to, anything about 20 byte addressing can then simply ignore that, and not be burdened with 3 bytes of constant prefix, and a 1 byte trailer on every address. kre ps: I detest majordomo - could someone at least nobble it so it no longer adds that absurd meaningless, unnecessary, and incorrect, "Reply-To" header... ------------------------------------------------------------------------------ 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 Mon Aug 22 00:27:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14446; Mon, 22 Aug 94 00:27:56 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14440; Mon, 22 Aug 94 00:27:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00879; Mon, 22 Aug 94 00:25:01 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AB06729; Mon, 22 Aug 94 00:24:51 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA01676; Mon, 22 Aug 1994 00:23:17 -0700 Date: Mon, 22 Aug 1994 00:23:17 -0700 From: Tony Li Message-Id: <199408220723.AAA01676@lager.cisco.com> To: kre@munnari.OZ.AU Cc: ipng@sunroof.Eng.Sun.COM, tli@cisco.com In-Reply-To: Robert Elz's message of Mon, 22 Aug 1994 17:01:26 +1000 <2220.777538886@munnari.OZ.AU> Subject: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Having a mapping from other address spaces into the IPv6 address space provides the ability to have a "compatibility mode" for them too. OK, but for what? The purpose of IPv4 compatability is to allow applications running on v6 hosts to communicate with v4 hosts. The purpose of ALL of the compatibility modes is twofold: 1) It allows us to leverage the existing addressing structure of the other network layer to ease the pain of transition. 2) It allows us to run the transport protocols on top of IPv6. This is wholly independent of the other network layer. Yes, I'm suggesting that SPX and TP4 will run on top of IPv6. [Hint to Provo: get a protocol number, eh? ;-) ] And yes, those running the other transport protocols will not be speaking TCP. That's ok. Fix their network layer and their minds (and the rest of their stacks) will follow. ;-) If we have lots of NSAP (or IPX) using hosts that need to communicate with hosts talking the same applications on a v6 host, with the point of gradually making the NSAP hosts go away, then yes, we'd need an algorithmic mapping (like a prefix) so that the old NSAP speaking hosts could communicate with the new v6 hosts. But just exactly what are those applications out there now that need this? I believe that DEC's syntax is something like: copy [nodename::]filename [nodename::]filename Sorry, it's been a LONG time since I played with it... I also suspect that you missed the point of my message. Always possible... It wasn't that we will need to renumber when transitioning to IPv6 - it was once we're running IPv6 - once IPv4 has vanished into close enough of obscurity that it can be forgotten, just as today we now forget those hosts that don't know about subnets, or don't use MX records to deliver mail - they still exist but aren't numerous enough, or important enough, to cause any concern). That should happen just as soon as the last Fortran IV compiler is scrapped. Once we get to that point renumbering from time to time will be a fact of life, I'd expect my net to renumber (that is, if you like, change prefix) every few months at an absolute maximum, perhaps even daily. Until that point, compatibility mappings make transition much easier for everyone. That is, investments in number plans are a waste of time. Numbers shouldn't be something that we treat as precious. I could not disagree more. With only 16 bytes of address space, conservation is a mandatory requirement. Also, for those wishing for 20 bytes for v6 - surely its better that addresses be less than 20, that way all those applications that handle 20 byte addressing can trivially be converted to v6 by simply adding a standard prefix (call it an ICD if you want) to the v6 address, and representing it in the existing 20 byte field. Applications that neither know, nor want to, anything about 20 byte addressing can then simply ignore that, and not be burdened with 3 bytes of constant prefix, and a 1 byte trailer on every address. ? Compatiblity in the reverse direction is not something that anyone has requested, nor would the IETF be the appropriate body to request it from... Subversively, Tony ps. Remember, the first fix is always free. ;-) ------------------------------------------------------------------------------ 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 Mon Aug 22 02:01:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14481; Mon, 22 Aug 94 02:01:40 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14475; Mon, 22 Aug 94 02:01:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA02768; Mon, 22 Aug 94 01:58:45 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA11493; Mon, 22 Aug 94 01:58:28 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27769; Mon, 22 Aug 1994 18:21:23 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Mon, 22 Aug 1994 00:23:17 MST." <199408220723.AAA01676@lager.cisco.com> Date: Mon, 22 Aug 1994 18:21:18 +1000 Message-Id: <2265.777543678@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 22 Aug 1994 00:23:17 -0700 From: Tony Li Message-ID: <199408220723.AAA01676@lager.cisco.com> The purpose of ALL of the compatibility modes is twofold: 1) It allows us to leverage the existing addressing structure of the other network layer to ease the pain of transition. Yes, making transition easier is a worthy goal, provided there is really something out there that is going to go that way. 2) It allows us to run the transport protocols on top of IPv6. I believe this works only if the other protocol's addressing is larger than v6's - otherwise those applications using that transport protocol (one assumes that moving a transport protocol that isn't used by anything is not an interesting endeavour) won't have allocated enough space (everywhere - in the API, in the directories, in text fields where the things are printed...) to hold a (larger) v6 address. If the v6 address is smaller, pad it, and it simply works (is indistinguishable). Yes, I'm suggesting that SPX and TP4 will run on top of IPv6. That's fine, I have no problems with that - the question is what is out there now with existing addresses that needs to be able to transition (not generically, but specifically - we need to know what addresses are in use to make sure that the mapping can handle them). If this stuff exists there must be some kind of directory, right, even if its just a file, or it would be unuseable. I believe that DEC's syntax is something like: copy [nodename::]filename [nodename::]filename Apart from questioning why the need for yet another file copy utility over ipv6 (a "copy" front end to the ftp, or rcp, whichever is closer, protocol would seem more sane), I'd also be interested in knowing how many sites that have gone through the pain of a move to Decnet 5 are planning to change it again to decnet over IPv6 ? The sites still running Decnet 4 aren't a problem (or even mostly relevant) are they? If its Decnet 5 that's important, then perhaps the transition should not be as Brian's NSAP mapping is planning - perhaps one of his earlier suggestions, that mapped the site dependant part of Decnet 5 addressing into the "allocated to a site" part of IPv6 addresses would be more rational. Apart from the handful of decnets that actually span multiple sites (yes, I know there are a few very big ones) that would seem to fit the more common "all the numbers are mine" theory of your average local site private decnet wouldn't it? That is probably true of IPX as well isn't it? That is, investments in number plans are a waste of time. Numbers shouldn't be something that we treat as precious. I could not disagree more. With only 16 bytes of address space, conservation is a mandatory requirement. No, you're not disagreeing - I totally agree with what you say (except just maybe the "only", but we have had that conversation before). I probably didn't state what I meant clearly enough. We certainly need to conserve address space (which is a little at odds with reserving a huge chunk of it to help compatability with a comparatively little used protocol). One way of conservation is reclycling - very agressive reclycling, I would certainly advocate that - reclaim numbers and reallocate them frequently. That's what I was getting at by the "not precious" comment, I didn't mean the number space, but the particular bit value that has been assigned. As long as I don't steal too many bits for myself, no-one (including me) should care whether the prefix for those bits is 1, 2, or 122345379 - nor whether its one of those one day and another the next. There routing space is what needs conserving, and the ability to dynamically alter meaningless prefix bits seems useful. Inside sites more bits become "meaningless prefix" as the local hierarchy is descended. All that should be free to alter as required to assist routing. ? Compatiblity in the reverse direction is not something that anyone has requested, nor would the IETF be the appropriate body to request it from... No, but it seems the more useful direction in this case all around, to me it seems like it would make transition easier. kre ps: its nice to be able to reply to a direct message instead of one mangled by the mailing list system... ------------------------------------------------------------------------------ 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 Mon Aug 22 02:28:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14507; Mon, 22 Aug 94 02:28:47 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14501; Mon, 22 Aug 94 02:28:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03378; Mon, 22 Aug 94 02:25:53 PDT Received: from survis.surfnet.nl by Sun.COM (sun-barr.Sun.COM) id AA13613; Mon, 22 Aug 94 02:25:41 PDT Message-Id: <9408220925.AA13613@Sun.COM> Received: from survis.surfnet.nl by survis.surfnet.nl with SMTP (PP); Mon, 22 Aug 1994 11:25:29 +0200 To: ipng@sunroof.Eng.Sun.COM Cc: bill.simpson@um.cc.umich.edu Subject: Re: (IPng) IPNG 16 to OSI NSAP mappability In-Reply-To: Your message of Sun, 21 Aug 1994 16:43:36 -0700. <199408212343.QAA23377@lager.cisco.com> Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Mon, 22 Aug 1994 11:25:26 +0200 From: Victor Reijs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hello all of you, ==> From: Tony Li > Nevertheless, I know of very few people who are not using GOSIP > formatted addresses. Those that aren't are using something shorter > which can still be mapped. I don't know if this assumption is true. In the European countries one see a lot of CLNP hosts that have DCC based NSAP address structures that are defined up to 20 octets. In some countries one has a fixed length of 20 octets, while others are more flexibel. In the Netherlands for instance, we still have an option to go to 17 octets (because that was the max. length, when the decimal encoding was still in the picture). Now we give that 3 octets space to the instites that belong to the Dutch SURFnetwork. But remember, there only very few CLNS hosts within the SURFnetwork (I know that there are other commercial CLNS netowrks in the Netherlands; the number of host is unkown to me [they are in another 'domain/world']). But it seems that IPv6 will have 16 octets, then why not just use within the IPv6-domain 16 octet NSAP address? Or does one think that the OSI or other protocols will migrate to IPv6? If that is the case then one should perhaps look at it. But: Is changing the NOT-IPv6 world into an IPv6 world easier, if the NOT-IPv6 world has the same NSAP address length? If you think it is easier, then change the IPv6 address length into 20 octets, because there are already numerous hosts with 20 octet NSAP around in the world (outside the IP world). All the best, Victor ------------------------------------------------------------------------------ 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 Mon Aug 22 02:31:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14522; Mon, 22 Aug 94 02:31:49 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14516; Mon, 22 Aug 94 02:31:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03413; Mon, 22 Aug 94 02:28:54 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AB13916; Mon, 22 Aug 94 02:28:45 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id CAA03592; Mon, 22 Aug 1994 02:28:22 -0700 Date: Mon, 22 Aug 1994 02:28:22 -0700 From: Tony Li Message-Id: <199408220928.CAA03592@lager.cisco.com> To: kre@munnari.OZ.AU Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Robert Elz's message of Mon, 22 Aug 1994 18:21:18 +1000 <2265.777543678@munnari.OZ.AU> Subject: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM 2) It allows us to run the transport protocols on top of IPv6. I believe this works only if the other protocol's addressing is larger than v6's - otherwise those applications using that transport protocol (one assumes that moving a transport protocol that isn't used by anything is not an interesting endeavour) won't have allocated enough space (everywhere - in the API, in the directories, in text fields where the things are printed...) to hold a (larger) v6 address. If the v6 address is smaller, pad it, and it simply works (is indistinguishable). Given that the logical (and minimal) way of doing this is a new release of the host software, I guess I don't see this as a major problem. I believe that DEC's syntax is something like: copy [nodename::]filename [nodename::]filename Apart from questioning why the need for yet another file copy utility over ipv6 (a "copy" front end to the ftp, or rcp, whichever is closer, protocol would seem more sane), I'd also be interested in knowing how many sites that have gone through the pain of a move to Decnet 5 are planning to change it again to decnet over IPv6 ? The sites still running Decnet 4 aren't a problem (or even mostly relevant) are they? One actually has to question why one would want FTP given the nicer user interface of DEC's _existing_ copy command. ;-) I would imagine that all DECnet Phase V sites WILL migrate to IPv6 eventually. They just don't know it yet today. Of course, it would help if DEC could tell them this with a story that made technical (and political!) sense. DECnet Phase IV sites are a problem because they too are going to have to migrate. And there are many more sites still at Phase IV than Phase V... If we can get them to migrate directly, that would be a win. If its Decnet 5 that's important, then perhaps the transition should not be as Brian's NSAP mapping is planning - perhaps one of his earlier suggestions, that mapped the site dependant part of Decnet 5 addressing into the "allocated to a site" part of IPv6 addresses would be more rational. ??? Are you proposing to take away their globally unique DECnet Phase V address and giving them a local address? How does this help? Apart from the handful of decnets that actually span multiple sites (yes, I know there are a few very big ones) that would seem to fit the more common "all the numbers are mine" theory of your average local site private decnet wouldn't it? Certainly, except for the Phase V sites which, as a part of transition, did the right thing and went and got a real NSAP prefix. Are you abandoning these people. That is probably true of IPX as well isn't it? Yes, it's true that IPX addresses are currently (effectively) entirely local. You can bet your bottom dollar that Provo regrets this. This is why they've established a global registry. Unfortunately, the horse has already left the barn. That is, investments in number plans are a waste of time. Numbers shouldn't be something that we treat as precious. I could not disagree more. With only 16 bytes of address space, conservation is a mandatory requirement. No, you're not disagreeing - I totally agree with what you say (except just maybe the "only", but we have had that conversation before). I probably didn't state what I meant clearly enough. We certainly need to conserve address space (which is a little at odds with reserving a huge chunk of it to help compatability with a comparatively little used protocol). You're right. We should really comparatively little used protocols like IPv4. Just get everyone to use SNA, like they should. ;-) The point is that we don't have a whole lot of choice because we do want to try pretty hard to make IPv6 the ubiquitous network layer. That means that we have to lure the other user communities into accepting it. Unlike some others, I believe that seduction will be more effective than edict. I don't believe that the cost is that unreasonable. If address space isn't sufficiently cheap as to be "free", then it's going to be a limited resource and addressing will have severe economic and political consequences. You know what I'll say next, so I won't... One way of conservation is reclycling - very agressive reclycling, I would certainly advocate that - reclaim numbers and reallocate them frequently. Fine. Recycle compatibility prefixes in X years. ? Compatiblity in the reverse direction is not something that anyone has requested, nor would the IETF be the appropriate body to request it from... No, but it seems the more useful direction in this case all around, to me it seems like it would make transition easier. It only seems helpful to me if you're trying to transition into CLNP... Tony ------------------------------------------------------------------------------ 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 Mon Aug 22 02:59:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14558; Mon, 22 Aug 94 02:59:54 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14552; Mon, 22 Aug 94 02:59:46 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03913; Mon, 22 Aug 94 02:56:59 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA16060; Mon, 22 Aug 94 02:56:45 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00636; Mon, 22 Aug 1994 19:56:11 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Mon, 22 Aug 1994 02:28:22 MST." <199408220928.CAA03592@lager.cisco.com> Date: Mon, 22 Aug 1994 19:56:04 +1000 Message-Id: <2314.777549364@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 22 Aug 1994 02:28:22 -0700 From: Tony Li Message-ID: <199408220928.CAA03592@lager.cisco.com> Given that the logical (and minimal) way of doing this is a new release of the host software, I guess I don't see this as a major problem. The problem with host software, unlike router software, is that there isn't just "a new release" - software that runs on hosts comes from all kinds of places, and is collected over time. Upgrading the OS to permit IPv6 to slide in underneath should ideally allow applications that think they're using protocol X to transparently use IPv6 instead - requiring the world to go buy new copies of all of their applications isn't something that's a nice thing to do. Unfortunately with the change from IPv4 to IPv6 we have to do that, or probably do, because the addresses have visibly changed, there's almost no way that the applications can avoid it. That's why we have suggestions for hacks like having the routines that return addresses to the applications return 4 byte magic cookies instead, that are later used by the kernel to insert the correct longer address that has been nicely left around by the library routine (and even then that only works for those applications, fortunately the majority, that use the standard library routines). One actually has to question why one would want FTP given the nicer user interface of DEC's _existing_ copy command. ;-) yes ... but user interfaces aren't what we're designing here... ??? Are you proposing to take away their globally unique DECnet Phase V address and giving them a local address? How does this help? No, a global address - but one that is placed according to where they are connected topologically, rather than one that relates more to politics than network connectivity. That is, they get a normal IPv6 prefix, just the same as the one they get for IPv6 itself (in fact, identically the same) and then layer the area/node stuff under that ... in fact, quite a lot like some plans for how to use IPv6 addresses. Certainly, except for the Phase V sites which, as a part of transition, did the right thing and went and got a real NSAP prefix. Are you abandoning these people. No - but in any case its not all that relevant if they haven't actually built a large (multi-site) decnet out of their new addressing. It only seems helpful to me if you're trying to transition into CLNP... No, as above, just the opposite, it keeps the old applications functioning while the underlying network protocol changes. Transitioning to smaller addresses is typically so easy (and so rare to want to attempt) that its hardly worth describing. Its making addresses grow (as we're discovering now) that is difficult. kre ------------------------------------------------------------------------------ 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 Mon Aug 22 03:31:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14572; Mon, 22 Aug 94 03:31:55 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14566; Mon, 22 Aug 94 03:31:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA04380; Mon, 22 Aug 94 03:28:57 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA21988; Mon, 22 Aug 94 03:28:47 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id DAA21255; Mon, 22 Aug 1994 03:28:46 -0700 Date: Mon, 22 Aug 1994 03:28:46 -0700 From: Tony Li Message-Id: <199408221028.DAA21255@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Robert Elz's message of Mon, 22 Aug 1994 19:56:04 +1000 <2314.777549364@munnari.OZ.AU> Subject: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Sigh, here we go around again... The problem with host software, unlike router software, is that there isn't just "a new release" - software that runs on hosts comes from all kinds of places, and is collected over time. Upgrading the OS to permit IPv6 to slide in underneath should ideally allow applications that think they're using protocol X to transparently use IPv6 instead - requiring the world to go buy new copies of all of their applications isn't something that's a nice thing to do. Yes, that's EXACTLY what we're trying to do. Run CLNP applications on top of IPv6. And when you get a new release, it has the mapping from CLNP to IPv6 in it. The app specifies its normal CLNP address, and magic happens underneath the covers. ??? Are you proposing to take away their globally unique DECnet Phase V address and giving them a local address? How does this help? No, a global address - but one that is placed according to where they are connected topologically, rather than one that relates more to politics than network connectivity. That is, they get a normal IPv6 prefix, just the same as the one they get for IPv6 itself (in fact, identically the same) and then layer the area/node stuff under that ... in fact, quite a lot like some plans for how to use IPv6 addresses. Ok, total agreement here. No, as above, just the opposite, it keeps the old applications functioning while the underlying network protocol changes. Transitioning to smaller addresses is typically so easy (and so rare to want to attempt) that its hardly worth describing. Its making addresses grow (as we're discovering now) that is difficult. I'm lost... Tony ------------------------------------------------------------------------------ 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 Mon Aug 22 06:53:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14645; Mon, 22 Aug 94 06:53:50 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14639; Mon, 22 Aug 94 06:53:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA08266; Mon, 22 Aug 94 06:50:55 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA04168; Mon, 22 Aug 94 06:50:28 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 22 Aug 1994 13:28:51 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Mon, 22 Aug 1994 13:21:06 +0100 Date: Mon, 22 Aug 1994 13:21:06 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003519] Original-Encoded-Information-Types: ia5 text (2),undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3519 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3519*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) NSAP Mappings Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 ------------------------------ Start of body part 2 NSAP Mappings Personal Contribution by Jack Houldsworth. We seem to be missing the basic point in all these discussions. This is not about bits and bytes any more. It's about virtually seamless global h ighways between all communities. It isn't about 'bodging' the address space so that current ISO users c an transit IP6 networks, there is something much bigger at stake. I keep articulating this at IETF meetings but, either I don't articulate the point very clearly or those listening still believe that there is some great holy war between OSI and Internet to be won that will bring great glory and sel f satisfaction to those who regard themselves as Internetters. The big business benefits will come from converging all IT users to a single global platform at some time in the future and, if the IETF create a f air wind, there is a strong chance that this could be IP6 and its ongoing enhanc ements. If this happens, the IP6 user community and the market for Internet se rvices will be magnified out of sight. I suppose Internet could then claim t o have 'won the war' if that satisfies them but, more importantly, the IT com munity, users, suppliers and network implementers, will be the overall winners From owner-ipng Mon Aug 22 07:54:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14720; Mon, 22 Aug 94 07:54:45 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14714; Mon, 22 Aug 94 07:54:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10159; Mon, 22 Aug 94 07:51:51 PDT Received: from relay2.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA14212; Mon, 22 Aug 94 07:51:37 PDT Received: from jalfrezi.ndl.co.uk by relay2.pipex.net with SMTP (PP) id <08751-0@relay2.pipex.net>; Mon, 22 Aug 1994 15:51:11 +0100 Received: from atticus (atticus.ndl.co.uk) by ndl.co.uk (4.1/SMI-4.1) id AA10270; Mon, 22 Aug 94 15:49:27 BST Message-Id: <9408221449.AA10270@ndl.co.uk> X-Sender: davidb@mailhost.ndl.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Aug 1994 15:50:52 +0100 To: ipng@sunroof.Eng.Sun.COM From: davidb@ndl.co.uk (David Boreham) Subject: Re: (IPng) NSAP Mappings X-Mailer: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hmm. I've been listening to all this stuff about NSAPs and OSI. Some clarity of purpose is required. The whole discussion smacks of the "Alternative planet syndrome" which one sometimes sees: Two groups of people, who on their own are following totally logical lines, and are very sane. When they get together all you see is strange looks, furrowed brows, raised eyebrows, people saying "What ?" and "Ugh ?". (Sound Familiar ?) Jack Houldsworth correctly points out that the real issue is global connectivity without tears. However, I'm not sure his contribution leaves me any the wiser ! Let's propose some different worlds: 1. Ignore the NSAP mapping issue altogether. Global connectivity is achieved via IP6, which has a robust IPv4 transition scheme. Other communities invent various relaying and NAT technologies to integrate legacy networking technologies. 2. Work out some "strong" NSAP to IP6 address space mapping scheme which means that IP6 effectively is a new CLNP. The rumoured large deployed NSAP-addressed _networks_ integrate well with and transition well to the new IP6 network. 3. Work out some "weak" way to map NSAP addresses into IP6 such that people with deployed _applications_ which currently expect to run over an NSAP-addressed network, can transition to the IP6 network without hassle. Now, which world are we trying to create. I prefer (3). I think that the OSI die-hards are hankering after (2), and (1) wouldn't be too bad a compromise :) Do these three cover all the discussions ? Which problem are we trying to solve ? David. ------------------------------------------------------------------------------ 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 Mon Aug 22 08:01:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14732; Mon, 22 Aug 94 08:01:16 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14726; Mon, 22 Aug 94 08:01:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10415; Mon, 22 Aug 94 07:58:22 PDT Received: from CIA.TGV.COM by Sun.COM (sun-barr.Sun.COM) id AA15388; Mon, 22 Aug 94 07:58:04 PDT Date: Mon, 22 Aug 1994 07:57:57 -0700 (PDT) From: "L. Stuart Vance" Subject: Re: (IPng) millions of OSI products To: ipng@sunroof.Eng.Sun.COM Message-Id: <777567477.607937.VANCE@TGV.COM> In-Reply-To: <2265.777543678@munnari.OZ.AU> Mail-System-Version: Organization: TGV, Inc. X-Phone: +1 408 457 5200 (work); +1 408 457 5208 (fax) X-Address: 101 Cooper Street; Santa Cruz, CA 95060 (work) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I believe that DEC's syntax is something like: > copy [nodename::]filename [nodename::]filename > >Apart from questioning why the need for yet another file >copy utility over ipv6 (a "copy" front end to the ftp, or >rcp, whichever is closer, protocol would seem more sane), >I'd also be interested in knowing how many sites that have >gone through the pain of a move to Decnet 5 are planning >to change it again to decnet over IPv6 ? The sites >still running Decnet 4 aren't a problem (or even mostly >relevant) are they? Actually, most DECnet sites (by a large majority) are still running DECnet Phase IV. Most folks haven't gone to Phase V (DECnet/OSI) for many of the same reasons that most IP sites haven't gone to OSI. The main reason that folks might want to change protocol stacks is to transition away from a limited functionality stack (say, one with 16 bit addresses). However, they want the transition to be as transparent and painless as possible. If they have to run IP6 to be a good neighbor on the Internet, then running DECnet apps over IP6 is the biggest win. The main reasons they want to keep the existing apps are: o No (well, minimal) user retraining o Better functionality than the IP6 apps between "like" operating systems I realize that I'm digressing from the main thread, but I thought that a word about applications was important for us to think about at this point.... Regards, -----Stuart ------------------------------------------------------------------------------ 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 Mon Aug 22 09:40:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14800; Mon, 22 Aug 94 09:40:35 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14788; Mon, 22 Aug 94 09:40:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14534; Mon, 22 Aug 94 09:37:38 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AB04779; Mon, 22 Aug 94 09:37:08 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 22 Aug 1994 15:49:16 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Mon, 22 Aug 1994 15:39:49 +0100 Date: Mon, 22 Aug 1994 15:39:49 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003526] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3526 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3526*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) NSAP mapping and GOSIP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM NSAP MAPPING AND GOSIP I detect a misunderstanding here, probably caused by a lack of Interna tional experience amongst the IETF fraternity. GOSIP does not only refer to US GOSIP. There are GOSIP organisations run by governments all around the World. UK is run by a Government Agency kn own as the Central Computer Technical Authority (CCTA). CCTA specifies an a ddress structure which uses all 20 bytes of the NSAP. Government department s like the MOD specify this in tenders. They allow some TCP/IP but currently demand that it be replaced with OSI within 5 years. CCTA has collaborated with other GOSIP agencies throughout Europe and have created a European Procurement Handbook for Open Systems which is mand atory for procurement by public authorities within the European Economic Communi ty for systems of value greater than 100000 ECUs (around 150K dollars USA). The figure could have changed slightly since I looked at it. Note that USA companies supplying in Europe have to conform. Australia and NZ have virtually copied UK GOSIP and I think it is mand atory for all Government spend, Alan Lloyd will fill you in no doubt. I also be lieve that a lot of private Corporations there are riding the Australian GOS IP wagon So when you talk about GOSIP you have to explain which GOSIP you are t alking about. You may be right about USA GOSIP but the others are right in l ine which is why so many people are bothered. The Internet declared aim is to be recognised as an International Orga nization. If this is a realistic aim, IP6 design has to support Global addressin g. It's not good enough to just make sure that USA GOSIP NSAP allocations are covered. Do not be outraged if the perception of Internet is that it is a USA b ased Organization if you do. Get the picture? Jack Houldsworth ------------------------------------------------------------------------------ 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 Mon Aug 22 09:40:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14807; Mon, 22 Aug 94 09:40:47 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14794; Mon, 22 Aug 94 09:40:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14549; Mon, 22 Aug 94 09:37:44 PDT Received: from by Sun.COM (sun-barr.Sun.COM) id AB04779; Mon, 22 Aug 94 09:37:30 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 22 Aug 1994 16:05:37 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Mon, 22 Aug 1994 15:56:16 +0100 Date: Mon, 22 Aug 1994 15:56:16 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003529] Original-Encoded-Information-Types: ia5 text (2),undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3529 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3529*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 My contribution was garbled - probably due to large column width. Here it is again. ------------------------------ Start of body part 2 NSAP Mappings Personal Contribution by Jack Houldsworth. We seem to be missing the basic point in all these discussions. This is not about bits and bytes any more. It's about virtually seamless global highways between all communities. It isn't about 'bodging' the address space so that current ISO users can transit IP6 networks, there is something much bigger at stake. I keep articulating this at IETF meetings but, either I don't articulate the point very clearly or those listening still believe that there is some great holy war between OSI and Internet to be won that will bring great glory and self satisfaction to those who regard themselves as Internetters. The big business benefits will come from converging all IT users to a single global platform at some time in the future and, if the IETF create a fair wind, there is a strong chance that this could be IP6 and its ongoing enhancements. If this happens, the IP6 user community and the market for Internet services will be magnified out of sight. I suppose Internet could then claim to have 'won the war' if that satisfies them but, more importantly, the IT community, users, suppliers and network implementers, will be the overall winners. To make this possible IP6 must be made attractive to current OSI users, i.e. it must be easy for them to convert from the OSI stack and all its surrounding frills to IP6 with the ability to retain their existing address structures, even if they transfer to Internet as their primary transfer vehicle. It must also be easy for suppliers who have delivered OSI stacks to provide conversion software. Remember, all large system manufacturers have a mixed installed base of OSI and TCP/IP,in various proportions. The ratio varies around the world but the Internet Society has declared that it is International and geography should be no barrier to decisions. The difference in functionality between IP6 and the OSI network protocol (CLNP) is quite small and, with the exception of addressing, appears to offer a good chance of achieving the above objectives. Surprisingly, ISO seems to be less concerned about the TUBA/SIPP protocol choice than the addressing issue. It is hard to understand why the IETF is so hooked into creating an artificial barrier to easy transition and future ongoing cooperation in this one key area. Everyone can see that 20 into 16 (15 actually) will not go, yet all the ingenuity in the world is being poured into a rapidly created compression bodge which can already be seen to have failed because it deliberately excludes many known NSAP users. In any case, it will be a huge 'turn off' for NSAP users who will see IP6 as an alien domain which they can only enter if they give something up in their addresses. Is this the illusion that Internet wants to create as an International Organization? Stating that some NSAP domains don't matter is not good news in this context. So please let get back to the drawing board in this one key area and forget existing polarised positions. My vote is for 20 byte address space to accommodate full NSAPs. I know some believe that 16 bytes is already too many and would veto such an increase - by what right I know not - probably strong and shaming rhetoric about bits and bytes, processing time, address masks etc. Even an optional extension as suggested by Keith Knightson would be some crumb of comfort! After all, there are other optional fields in IP6. The expanded market for IP6 which could be created by embracing all the current NSAP address users and tempting them to become future members of Internet must be attractive. It could create the potential Global Internet at a stroke. I am sure that my colleagues in ISO will be disappointed if the IETF does rise to the occasion and make the right kind of visionary concession in the area to consummate the emerging spirit of cooperation between our two organizations. Jack Houldsworth ------------------------------ End of body part 2 ------------------------------------------------------------------------------ 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 Mon Aug 22 09:40:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14808; Mon, 22 Aug 94 09:40:52 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14801; Mon, 22 Aug 94 09:40:37 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14553; Mon, 22 Aug 94 09:37:49 PDT Received: from by Sun.COM (sun-barr.Sun.COM) id AB04779; Mon, 22 Aug 94 09:37:37 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 22 Aug 1994 16:05:51 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Mon, 22 Aug 1994 15:59:03 +0100 Date: Mon, 22 Aug 1994 15:59:03 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003530] Original-Encoded-Information-Types: ia5 text (2),undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3530 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3530*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) NSAPs and GOSIP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 Repeated contribution Jack Houldsworth ------------------------------ Start of body part 2 NSAP MAPPING AND GOSIP I detect a misunderstanding here, probably caused by a lack of International experience amongst the IETF fraternity. GOSIP does not only refer to US GOSIP. There are GOSIP organisations run by governments all around the World. UK is run by a Government Agency known as the Central Computer Technical Authority (CCTA). CCTA specifies an address structure which uses all 20 bytes of the NSAP. Government departments like the MOD specify this in tenders. They allow some TCP/IP but currently demand that it be replaced with OSI within 5 years. CCTA has collaborated with other GOSIP agencies throughout Europe and have created a European Procurement Handbook for Open Systems which is mandatory for procurement by public authorities within the European Economic Community for systems of value greater than 100000 ECUs (around 150K dollars USA). The figure could have changed slightly since I looked at it. Note that USA companies supplying in Europe have to conform. Australia and NZ have virtually copied UK GOSIP and I think it is mandatory for all Government spend, Alan Lloyd will fill you in no doubt. I also believe that a lot of private Corporations there are riding the Australian GOSIP wagon So when you talk about GOSIP you have to explain which GOSIP you are talking about. You may be right about USA GOSIP but the others are right in line which is why so many people are bothered. The Internet declared aim is to be recognised as an International Organization. If this is a realistic aim, IP6 design has to support Global addressing. It's not good enough to just make sure that USA GOSIP NSAP allocations are covered. Do not be outraged if the perception of Internet is that it is a USA based Organization if you do. Get the picture? Jack Houldsworth ------------------------------ End of body part 2 ------------------------------------------------------------------------------ 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 Mon Aug 22 10:55:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14895; Mon, 22 Aug 94 10:55:03 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14627; Mon, 22 Aug 94 06:06:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07141; Mon, 22 Aug 94 06:03:43 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA29909; Mon, 22 Aug 94 06:03:31 PDT Received: from relay.imsi.com by wintermute.imsi.com id JAA02635 for ; Mon, 22 Aug 1994 09:03:29 -0400 Received: from snark.imsi.com by relay.imsi.com id JAA08726 for ; Mon, 22 Aug 1994 09:03:29 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA00711; Mon, 22 Aug 94 09:03:28 EDT Message-Id: <9408221303.AA00711@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Mon, 22 Aug 1994 05:51:17 +1000." <2170.777498677@munnari.OZ.AU> X-Reposting-Policy: redistribute only with permission Date: Mon, 22 Aug 1994 09:03:27 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Robert Elz says: > One of the basic requirements of IPv6 is supposed to be > that when sites connect to providers they renumber (in most > cases) if necessary so the address they're using fits the > routing topology. That's how routing is supposed to be able > to be scaled to the sizes we're talking about. Does anyone have any concept at this point about how to do that 1) securely (because if it breaks your security you don't want it.) 2) without completely wrecking your administrative databases? (because if it makes your machines unmanageable you dont want it.) 3) without disrupting running systems? (because if you are like me and have systems that can NOT be brought down and have long running processes disruption is fatal.) Thus far, I've only heard vague claims and not anything that makes me feel confident that this can be done. Perry ------------------------------------------------------------------------------ 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 Mon Aug 22 17:01:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15741; Mon, 22 Aug 94 17:01:38 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15735; Mon, 22 Aug 94 17:01:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03156; Mon, 22 Aug 94 16:58:41 PDT Received: from CU.NIH.GOV by Sun.COM (sun-barr.Sun.COM) id AA13616; Mon, 22 Aug 94 16:58:20 PDT Message-Id: <9408222358.AA13616@Sun.COM> To: tli@cisco.com Cc: ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Mon, 22 Aug 1994 19:56:25 EDT Subject: Re: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > So, not only is there no guarantee of symmetric routing, it is highly > likely that you won't get it. > > Well, that's not clear. You have to recall that most providers are > sensitive to this issue and I've seen some providers go to EXTREME > lengths to provide it. Doing this is, however, labor intensive. Yes, that's the point. It shouldn't be labor intensive. If it's going to handle 10**9-10**12 networks, it better be mostly automatic. > It was my impression that symmetric > routing was considered a very good thing in the past. One reason is so > that traceroute would tell you something about the way packets come > back to you, as well as the way they go. What's the IPv6 tool that > will replace this? SNMP queries of routing tables? > > Hopefully, IPv6 will provide a better tool than traceroute. [Don't > get me wrong, I love it dearly, BUT....] Imagine how useful IPv4 > record route could have been if it didn't have a 9 hop limitation. > This would allow you to clearly see if the route is asymmetric. With an MTU of 576 bytes you can fit only 30-odd 16-byte addresses in a packet. It's better, of course, if you have a larger MTU. But 576 is the minimum MTU for IPv6 right now. Perhaps you are talking about something that sends a packet back for each hop? > Symmetry is good for other reasons (SRTT calculations), but > interdomain routing would get incredibly complcated if you tried to > enforce this automatically. Of course, if someone has a good idea, > please step forward... ;-) > > What I was trying to say about groups is that if the various providers > have some sort of groupings of subscribers that indicate what > inter-provider connection point they are nearest (by a group number in > the address or by use of multiple provider numbers for each provider), > and those groupings are advertised to other providers, then it would be > easier to get symmetric routing, at the cost of larger routing tables. > > I think our suggestions is to do exactly that, but without the > explicit group number.... Please explain to me how it will be done. Using a provider number for each provider and connection point is one way. Another way is to have some externally known structure in the subscriber number. Is there some other way I haven't thought of? > I think it would imply that the provider prefix for a subscriber could > change when the provider changes the topology of their network. So it > would be especially important to be able to do that sort of renumbering > automatically. > > ... and renumbering would not be required. Tho the number of routes > advertised (locally) to achieve optimality might increase without > renumbering. How is that information communicated among providers so that they know what connection point to use? > Anyway, if everyone has given up on symmetric routing as just too hard > to do, it would be worthwhile to explicity say that, so that everyone > understands. > > Agreed, but I don't think that this is the case. > > Tony I think there should be more explanation in the addressing architecture document about how it will work across providers. It glosses over the issue now. Roger ------------------------------------------------------------------------------ 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 Mon Aug 22 17:05:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15756; Mon, 22 Aug 94 17:05:29 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15747; Mon, 22 Aug 94 17:05:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03353; Mon, 22 Aug 94 17:02:33 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA14151; Mon, 22 Aug 94 17:02:09 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14425(6)>; Mon, 22 Aug 1994 16:59:46 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 22 Aug 1994 16:59:36 -0700 To: yakov@watson.ibm.com Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) cluster addresses In-Reply-To: yakov's message of Sun, 21 Aug 94 12:06:32 -0800. <94Aug21.120744pdt.14510(2)@alpha.xerox.com> Date: Mon, 22 Aug 1994 16:59:25 PDT From: Steve Deering Message-Id: <94Aug22.165936pdt.12171@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yakov, > Please define what an "important cluster address" is. An important cluster address is one that someone needs to send packets to. Steve ------------------------------------------------------------------------------ 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 Mon Aug 22 18:21:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15792; Mon, 22 Aug 94 18:21:50 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15786; Mon, 22 Aug 94 18:21:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA04840; Mon, 22 Aug 94 18:18:53 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA18601; Mon, 22 Aug 94 18:18:39 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id RAA05312; Mon, 22 Aug 1994 17:27:06 -0700 Date: Mon, 22 Aug 1994 17:27:06 -0700 From: Tony Li Message-Id: <199408230027.RAA05312@lager.cisco.com> To: RAF@CU.NIH.GOV Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Roger Fajman"'s message of Mon, 22 Aug 1994 19:56:25 EDT <199408222358.QAA08042@hubbub.cisco.com> Subject: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Roger, Yes, that's the point. It shouldn't be labor intensive. If it's going to handle 10**9-10**12 networks, it better be mostly automatic. Well, my comment is unchanged: > Symmetry is good for other reasons (SRTT calculations), but > interdomain routing would get incredibly complcated if you tried to > enforce this automatically. Of course, if someone has a good idea, > please step forward... ;-) If we knew how to make it symmetric, we would certainly consider it. IMHO, this is insoluble, but I would love to have someone prove me wrong. > Hopefully, IPv6 will provide a better tool than traceroute. [Don't > get me wrong, I love it dearly, BUT....] Imagine how useful IPv4 > record route could have been if it didn't have a 9 hop limitation. > This would allow you to clearly see if the route is asymmetric. With an MTU of 576 bytes you can fit only 30-odd 16-byte addresses in a packet. It's better, of course, if you have a larger MTU. But 576 is the minimum MTU for IPv6 right now. Perhaps you are talking about something that sends a packet back for each hop? Either approach would be a significant improvement. Or a hybrid, which, if it discovered that the packet was about to overflow, sent back some of the route and then started a new list... > What I was trying to say about groups is that if the various providers > have some sort of groupings of subscribers that indicate what > inter-provider connection point they are nearest (by a group number in > the address or by use of multiple provider numbers for each provider), > and those groupings are advertised to other providers, then it would be > easier to get symmetric routing, at the cost of larger routing tables. > > I think our suggestions is to do exactly that, but without the > explicit group number.... Please explain to me how it will be done. Using a provider number for each provider and connection point is one way. Another way is to have some externally known structure in the subscriber number. Is there some other way I haven't thought of? I think so. Or maybe you object in some way that I don't understand... In any case, suppose that a provider has prefix P. Suppose that subscribers S1, S2, and S3 are near exit point X. The provider simply advertises the NLRI (hopefully aggregated) for S1, S2, and S3 at X. Because this is a longer prefix than just P, the receiver will perform longest match and use X for those subscribers. > ... and renumbering would not be required. Tho the number of routes > advertised (locally) to achieve optimality might increase without > renumbering. How is that information communicated among providers so that they know what connection point to use? Normal IDRP routing advertisements. Note that IDRP does have the ability to send IDRP advertisements to selected other routing domains, so these longer prefixes are well contained. I think there should be more explanation in the addressing architecture document about how it will work across providers. It glosses over the issue now. Ok, thanks. We'll look into it. Tony ------------------------------------------------------------------------------ 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 Mon Aug 22 18:55:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15877; Mon, 22 Aug 94 18:55:37 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15870; Mon, 22 Aug 94 18:55:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA06896; Mon, 22 Aug 94 18:52:40 PDT Received: from CU.NIH.GOV by Sun.COM (sun-barr.Sun.COM) id AA23491; Mon, 22 Aug 94 18:52:27 PDT Message-Id: <9408230152.AA23491@Sun.COM> To: tli@cisco.com Cc: ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Mon, 22 Aug 1994 21:51:02 EDT Subject: Re: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I think so. Or maybe you object in some way that I don't > understand... In any case, suppose that a provider has prefix P. > Suppose that subscribers S1, S2, and S3 are near exit point X. The > provider simply advertises the NLRI (hopefully aggregated) for S1, S2, > and S3 at X. OK, that makes sense to me. I think it could be explained better in the architecture document. Now what happens when provider P's topology changes and S2 is now nearest exit point Y, instead of X, but S1 and S3 are still nearest X? Does S2 get a different subscriber number? I'm assuming that this wasn't planned for when the subscriber numbers were assigned. People talk a lot about renumbering when a subscriber changes providers, but not when a provider adds an exit point or makes some other major topology change. ------------------------------------------------------------------------------ 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 Mon Aug 22 19:16:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15909; Mon, 22 Aug 94 19:16:20 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15903; Mon, 22 Aug 94 19:16:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA08199; Mon, 22 Aug 94 19:13:21 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA26948; Mon, 22 Aug 94 19:12:55 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA08478; Mon, 22 Aug 94 19:03:51 -0700 Received: by xirtlu.zk3.dec.com; id AA18544; Mon, 22 Aug 1994 22:02:44 -0400 Message-Id: <9408230202.AA18544@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPNG 16 to OSI NSAP mappability In-Reply-To: Your message of "Sun, 21 Aug 94 16:43:36 PDT." <199408212343.QAA23377@lager.cisco.com> Date: Mon, 22 Aug 94 22:02:38 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>Date: Sun, 21 Aug 1994 16:43:36 -0700 >>From: Tony Li >I can pretty much assure you that the vast majority of people who >would be affected would never be caught dead reading this list. ;-) There are some and they should speak up on this list. >Nevertheless, I know of very few people who are not using GOSIP >formatted addresses. Me either. >From our experience helping people deploy CLNP, I would estimate that >there are roughly 500k active CLNP hosts out there today, most of >which do not have Internet connectivity and have no need for it. Most >of this is from DECnet sites which have converted (or are converting) >to Phase V. Customer confidentiality prevents me from giving you a >list. Me too. But a point worth noting is that for those of us that have OSI customers its still early to hear what exactly if anything will be requested by this part of installed base. I have had no requests to run TP4 or TP0 over IP6 at all so far. But I sure don't think most custoemrs want this done in a proprietary fashion (I don't think anyway). Right now all I have heard that I can share is that folks have two needs: 1. Large groups of users have invested in the NSAP addressing plan as a strategy. I don't think they have been asked yet whether they would be open to renumbering based on IP6? I have no opinion on this and not sure its a big deal. But I think understanding the NSAP and IPX address space is a prudent administrative excercise and the mapping possibilities into IP6. This is being figured out now and we are not done, when we are we will send something out. Hold on to your anxiety please (this is to the list not an individual). 2. It is "perceived" that some customers running OSI backbones who use NSAPs as their addressing plan may want to take advantage of the Internet IP6 backbone to communicate with other OSI backbones. If the mapping will work this is very doable. /jim /jim ------------------------------------------------------------------------------ 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 Mon Aug 22 19:31:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15942; Mon, 22 Aug 94 19:31:26 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15936; Mon, 22 Aug 94 19:31:19 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA08890; Mon, 22 Aug 94 19:28:31 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA29027; Mon, 22 Aug 94 19:28:01 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA08952; Mon, 22 Aug 94 19:19:06 -0700 Received: by xirtlu.zk3.dec.com; id AA18622; Mon, 22 Aug 1994 22:16:41 -0400 Message-Id: <9408230216.AA18622@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Mon, 22 Aug 94 00:23:17 PDT." <199408220723.AAA01676@lager.cisco.com> Date: Mon, 22 Aug 94 22:16:35 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Date: Mon, 22 Aug 1994 00:23:17 -0700 >From: Tony Li >This is wholly independent of the other network layer. Yes, I'm >suggesting that SPX and TP4 will run on top of IPv6. [Hint to Provo: >get a protocol number, eh? ;-) ] As far as TP4 and most likely other prototcol transport layers there are many ways to do this. The question is what applications does one want for this purpose? It can be done without messing with the transport at all. >And yes, those running the other transport protocols will not be >speaking TCP. That's ok. Fix their network layer and their minds >(and the rest of their stacks) will follow. ;-) Well some will. Applications on non IP-TYPE protocols can just run over the complete IP stack given the proper engineering in the application space in the host. This could be cheaper and better yet does not involve the IETF or anyone but the vendor that owns the application. And then it would not take up time on this mail list with all the IPv4 and IP6 work we have to figure out. /jim ------------------------------------------------------------------------------ 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 Mon Aug 22 19:37:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15958; Mon, 22 Aug 94 19:37:18 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15952; Mon, 22 Aug 94 19:37:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA09151; Mon, 22 Aug 94 19:34:22 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA29962; Mon, 22 Aug 94 19:34:08 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01053; Tue, 23 Aug 1994 09:52:51 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM, J.Houldsworth@ste0906.wins.icl.co.uk Subject: Re: (IPng) NSAP Mappings In-Reply-To: Your message of "Mon, 22 Aug 1994 13:21:06 +0100." <"3519*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> Date: Tue, 23 Aug 1994 09:50:16 +1000 Message-Id: <2340.777599416@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, I'm going to respond to both of your messages in one reply. Date: Mon, 22 Aug 1994 13:21:06 +0100 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3519*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> The big business benefits will come from converging all IT users to a single global platform at some time in the future and, if the IETF create a fair wind, there is a strong chance that this could be IP6 and its ongoing enhancements. This is fine, I think we'd all like to see this, you don't need to convince anyone. However, I fail to see how doing anything with NSAPs has any immediate relevance to this at all, with the possible exception of throwing a bone to some OSI standards freaks to attempt to convince them to ignore the rest of their network protocol. My experience with some of those people is that every time the internet makes some concession to the OSI protocols they dig their heels in further, convinced that the internet has recognised that it is losing, and so are gradually throwing in the towell. I'd very much appreciate it if you could explain exactly why handling NSAPs will somehow help this worthwhile gain be achieved - and "government regulation" and "deployed plans" aren't good enough. The govt stuff I'll get to in my reply to your second message below. The "deployed plans" stuff simply conflicts with one of the aims of IPv6, which is for sites generally to be assigned numbers that are related to their positions in the Internet topology. This is the only way we currently know to make routing scale. That is, once we're over transitioning from IPv4 (during which period we need to keep IPv4 compatible addressing - and yes, this might be a long time) we must expect everyone (including current IPv4 sites, which will then be IPv6 sites) to renumber - not all at once - but everyone is going to have to fit themselves into a scalable address scheme. I see no evidence at all that NSAPs were designed for that, they seem to have been designed more for politics, so that every country can have its own little space to play in, even if that country has no network providers at all of its own, and no need at all to own any address space because of that. The effect is that any "deployed plans" are going to have to be altered in any case - both NSAP deployed plans, and IP deployed plans, everyone gets to change. Date: Mon, 22 Aug 1994 15:39:49 +0100 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3526*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> I detect a misunderstanding here, probably caused by a lack of International experience amongst the IETF fraternity. GOSIP does not only refer to US GOSIP. Amongst some perhaps - I understand that, and I'm quite sure that Brian does. So do many others. CCTA has collaborated with other GOSIP agencies throughout Europe and have created a European Procurement Handbook for Open Systems which is mandatory for procurement by public authorities That's fine, as long as governments in various countries mandate buying OSI products, I'm willing to let them, and ignore them. That mandate is for much more than NSAPs, and simply supplying NSAPs won't satisfy them. Should they come to their senses, and buy products accepted by the commercial community, then the requirement for NSAPs will vanish along with the requirements for CONS, and all the rest. Australia and NZ have virtually copied UK GOSIP and I think it is mandatory for all Government spend, Very likely - however most govt people here seem to still be using SNA. Here that seems to largely becoming irrelevant as the various governments dispose of most departments that are likely to be affected (the tax dept (IRS for US people) is almost the only thing they're not contemplating selling...) So when you talk about GOSIP you have to explain which GOSIP you are talking about. This is true. Personally, in this forum, I still don't see any need to be concerned much about any GOSIP. The Internet declared aim is to be recognised as an International Organization. If this is a realistic aim, IP6 design has to support Global addressing. Absolutely. If you see any defects in the addressing plans that would prevent them from supporting global addressing, then now is the time to speak. Technical problems that is. Global addressing is not equivalent to NSAP. Further, we have no need of officious organisations controlling the address space and every country having its little piece to hand out (regardless of whether those little pieces together amount to the whole address space, or whether there are alternatives). Sites should be told what address they are to have when they connect to their provider. When they change providers the new one will give them a new address. If they connect to multiple providers they can negotiate with the various parties to determine whether they get two addresses, or whether their first address becomes advertised through the second provider, or something else (maybe a new address that's taken from a special pool for customers of those two providers where it happens to be a common combination). The point is that renumbering has to be simple - the values of the bits in the address should not be something any site cares about. So, can you please explain just what the real benefit is in supporting NSAPs (as an address space) at all? Maybe there is some real technical benefit that I (at least) am missing completely. If there is, I'm afraid that no real attempt has yet been made to explain it to me. kre ------------------------------------------------------------------------------ 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 Mon Aug 22 19:44:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15970; Mon, 22 Aug 94 19:44:52 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15964; Mon, 22 Aug 94 19:44:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA09455; Mon, 22 Aug 94 19:41:52 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AB01284; Mon, 22 Aug 94 19:41:37 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA09316; Mon, 22 Aug 94 19:34:18 -0700 Received: by xirtlu.zk3.dec.com; id AA18742; Mon, 22 Aug 1994 22:33:12 -0400 Message-Id: <9408230233.AA18742@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Mon, 22 Aug 94 02:28:22 PDT." <199408220928.CAA03592@lager.cisco.com> Date: Mon, 22 Aug 94 22:33:06 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Date: Mon, 22 Aug 1994 02:28:22 -0700 >From: Tony Li >One actually has to question why one would want FTP given the nicer >user interface of DEC's _existing_ copy command. ;-) Thanks. >I would imagine that all DECnet Phase V sites WILL migrate to IPv6 >eventually. They just don't know it yet today. Of course, it would >help if DEC could tell them this with a story that made technical (and >political!) sense. Gee. Our model is to listen to our customer we don't tell them anything. They tell us a need and we determine if we can meet it and get back to them. For new markets or technology we share with them where we could take them. As of right now IP6 is unknown territory and not being a marketing person I don't have a clue other than an inkling as an engineer (as opposed to a scientist who in most cases should not deal with costs and customer requirements on a daily basis). As I said in previous mail since the IP6 decision there is no input just yet. But I think its premature to say they will all go to IP6? Unless your saying OSI is dead? >DECnet Phase IV sites are a problem because they too are going to have >to migrate. And there are many more sites still at Phase IV than >Phase V... If we can get them to migrate directly, that would be a win. Hmmm you must have a crystal ball sounds like my company should hire you and pay you big bucks to forcast our customers buying and technology patterns. >??? Are you proposing to take away their globally unique DECnet Phase >V address and giving them a local address? How does this help? I don't think its any of the IETFs business what PhV customers do with their addresses in the tone of this conversation really. Mapping NON-IP protocols into IP6 is a prudent exercise, but lets not start telling customers who are not using IETF protocols what they can or cannot do with their environment. /jim ------------------------------------------------------------------------------ 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 Mon Aug 22 19:56:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15987; Mon, 22 Aug 94 19:56:56 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15981; Mon, 22 Aug 94 19:56:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA09936; Mon, 22 Aug 94 19:54:00 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03110; Mon, 22 Aug 94 19:53:17 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA09506; Mon, 22 Aug 94 19:41:05 -0700 Received: by xirtlu.zk3.dec.com; id AA18796; Mon, 22 Aug 1994 22:40:00 -0400 Message-Id: <9408230240.AA18796@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Mon, 22 Aug 94 03:28:46 PDT." <199408221028.DAA21255@lager.cisco.com> Date: Mon, 22 Aug 94 22:39:54 -0400 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, that's EXACTLY what we're trying to do. Run CLNP applications on >top of IPv6. And when you get a new release, it has the mapping from >CLNP to IPv6 in it. The app specifies its normal CLNP address, and >magic happens underneath the covers. NO. This is not what we are trying to do in any scheduled IETF work I am aware of at this time. We are going to develop a draft of how an NSAP can be mapped into IP6. Thats it period. There is no other IETF work chartered anywhere to deal with what you stated above. I am not saying there should be or should not be just that there is not presently so expectations are set correctly. In addition those applications being used over CLNP today can run over IP6 at via the application space without needing a mapping if folks so desire. >I'm lost... Me too. But thats better than thinking we are going somewhere we are not. /jim ------------------------------------------------------------------------------ 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 Mon Aug 22 20:08:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16015; Mon, 22 Aug 94 20:08:42 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16009; Mon, 22 Aug 94 20:08:35 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10560; Mon, 22 Aug 94 20:05:47 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AB04916; Mon, 22 Aug 94 20:05:27 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA10092; Mon, 22 Aug 94 19:58:49 -0700 Received: by xirtlu.zk3.dec.com; id AA18978; Mon, 22 Aug 1994 22:57:43 -0400 Message-Id: <9408230257.AA18978@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NSAPs In-Reply-To: Your message of "Mon, 22 Aug 94 15:56:16 BST." <"3529*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> Date: Mon, 22 Aug 94 22:57:37 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, I agree with what you stated philosophically. But in reality if customers want to convert from OSI to IP6 quite frankly we may not need the IETF or ISO to get it done if the ROI is great enough and and customers want this to be done. I am beginning to again in life see the beauty of Adam Smiths Wealth of the Nations economic strategy and the futuristic business advice to the capitalistic world from philosopher/writer Ayn Rand (Fountain Head, Atlas Shrugged, or Objectivist Epistemology a Treatise). On the subject of translating NSAPs to IP6 so they are routable to other NSAP sites within the Internet (or for IP6) this maybe can be done as part of IP6 work. But more than that would need a charter and working group to figure it out. But first I would think they need to take your message and determine what the technical goals would be and if we could move the IT world to one unified network layer. I would like to see peace in the world too. I don't mean the last sentence as negative just that its a tall order to the IETF and ISO. IMHO I think this is an effort first for our consultant group to discuss and think about )---> the IAB. /jim ------------------------------------------------------------------------------ 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 Mon Aug 22 20:10:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16027; Mon, 22 Aug 94 20:10:24 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16021; Mon, 22 Aug 94 20:10:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10621; Mon, 22 Aug 94 20:07:29 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA05171; Mon, 22 Aug 94 20:07:06 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id UAA11592; Mon, 22 Aug 1994 20:07:03 -0700 Date: Mon, 22 Aug 1994 20:07:03 -0700 From: Tony Li Message-Id: <199408230307.UAA11592@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: bound@zk3.dec.com's message of Mon, 22 Aug 94 22:33:06 -0400 <9408230233.AA18742@xirtlu.zk3.dec.com> Subject: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM But I think its premature to say they will all go to IP6? Unless your saying OSI is dead? Shout it from the rooftops. Yes, OSI is a corpse that just hasn't fallen down yet. It looked like the heart might restart at Boston, but it went v-fib, and subsequent shock treatments didn't revive it. The final nails went in at Toronto. Hmmm you must have a crystal ball sounds like my company should hire you and pay you big bucks to forcast our customers buying and technology patterns. My phone number is (415) 688-8186. Tony ------------------------------------------------------------------------------ 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 Mon Aug 22 20:17:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16063; Mon, 22 Aug 94 20:17:22 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16057; Mon, 22 Aug 94 20:17:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10886; Mon, 22 Aug 94 20:14:26 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA06069; Mon, 22 Aug 94 20:14:13 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id UAA11816; Mon, 22 Aug 1994 20:13:49 -0700 Date: Mon, 22 Aug 1994 20:13:49 -0700 From: Tony Li Message-Id: <199408230313.UAA11816@lager.cisco.com> To: RAF@CU.NIH.GOV Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Roger Fajman"'s message of Mon, 22 Aug 1994 21:51:02 EDT <199408230152.SAA12334@hubbub.cisco.com> Subject: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Now what happens when provider P's topology changes and S2 is now nearest exit point Y, instead of X, but S1 and S3 are still nearest X? This is case 1: Does S2 get a different subscriber number? I'm assuming that this wasn't planned for when the subscriber numbers were assigned. People talk a lot about renumbering when a subscriber changes providers, but not when a provider adds an exit point or makes some other major topology change. This makes sense if we can make renumbering really cheap and easy. In case 2, no renumbering happens and the provider simply stops advertising a longer prefix for S2 though X. Tony ------------------------------------------------------------------------------ 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 Mon Aug 22 20:43:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16099; Mon, 22 Aug 94 20:43:50 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16093; Mon, 22 Aug 94 20:43:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12107; Mon, 22 Aug 94 20:40:52 PDT Received: from vangogh.CS.Berkeley.EDU by Sun.COM (sun-barr.Sun.COM) id AA10569; Mon, 22 Aug 94 20:40:41 PDT Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Alpha.1/8.6.9.Beta0) id UAA08676 for ipng@sunroof.Eng.Sun.COM; Mon, 22 Aug 1994 20:40:13 -0700 (PDT) Date: Mon, 22 Aug 1994 20:40:13 -0700 (PDT) From: Keith Sklower Message-Id: <199408230340.UAA08676@vangogh.CS.Berkeley.EDU> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) CLNP addressing plans satisfyable by 16 bytes? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM So, what was the resonse to the people who said (in effect) "governments and large corporation have invested many man-hours in devising allocation schemes for dispensing network addresses, and even though they thought they were doing so in the context of OSI NSAPS, it was after all, in reality an allocation (hierarchy) plan, but their plan may have counted on having more than 16 bytes to maneuver in ..." Specifically, the Canadian plan for allocating NSAPs was cited as using 17 non-reserved bytes exclusive of the 1 byte trailing network selector, and therefore if the Canadian government wanted to make use of IPv6 addressing it must rework its addressing plan. Was it: a.) Canada should stick with CLNP and not bother with IPv6? b.) Canada wasted its tax payer's monies and indeed should redo its address allocation plan? Did we ever clearly identify any European Community member whose NSAP allocation plan could not be satisfied with 16 bytes? There were allusions, but in the many messages talking about more general transition issues, I may have overlooked other plans being specifically cited. ------------------------------------------------------------------------------ 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 Mon Aug 22 23:40:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16214; Mon, 22 Aug 94 23:40:28 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16208; Mon, 22 Aug 94 23:40:19 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA17056; Mon, 22 Aug 94 23:37:31 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA03709; Mon, 22 Aug 94 23:37:20 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA17552; Mon, 22 Aug 1994 23:37:20 -0700 Date: Mon, 22 Aug 1994 23:37:20 -0700 From: Tony Li Message-Id: <199408230637.XAA17552@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Perry E. Metzger"'s message of Mon, 22 Aug 1994 09:03:27 -0400 <9408221303.AA00711@snark.imsi.com> Subject: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Robert Elz says: > One of the basic requirements of IPv6 is supposed to be > that when sites connect to providers they renumber (in most > cases) if necessary so the address they're using fits the > routing topology. That's how routing is supposed to be able > to be scaled to the sizes we're talking about. Perry E. Metzger asks: Does anyone have any concept at this point about how to do that 1) securely (because if it breaks your security you don't want it.) 2) without completely wrecking your administrative databases? (because if it makes your machines unmanageable you dont want it.) 3) without disrupting running systems? (because if you are like me and have systems that can NOT be brought down and have long running processes disruption is fatal.) a) First, enhance the routing protocols to carry address delegations as well. "Hi, your prefix is now XYZ...". This is as "secure" as the routing protocol is. b) Maintain your administrative database relative to your prefix. c) (and this is the tough one) Autoconfiguration as currently forseen has you renew your address every 18 hours. Those systems which can accept a new prefix change when they are able. During this period, the routing system actually supports two prefixes. The difficult part is hosts which cannot accept a new prefix AND return their old prefix as they still have some connection open using the old prefix. Today, I don't know of a way whereby you could change prefixes on an open connection AND retain security. The implication is that you have to wait... Does this help? Tony ------------------------------------------------------------------------------ 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 Tue Aug 23 00:28:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16291; Tue, 23 Aug 94 00:28:14 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16285; Tue, 23 Aug 94 00:28:07 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18201; Tue, 23 Aug 94 00:25:19 PDT Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AB11567; Tue, 23 Aug 94 00:25:07 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA28819; Tue, 23 Aug 1994 00:24:48 -0700 Date: Tue, 23 Aug 1994 00:24:48 -0700 From: Dave Katz Message-Id: <199408230724.AAA28819@feta.cisco.com> To: perry@imsi.com Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Tony Li's message of Mon, 22 Aug 1994 23:37:20 -0700 <199408230637.XAA17552@lager.cisco.com> Subject: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM c) (and this is the tough one) Autoconfiguration as currently forseen has you renew your address every 18 hours. Those systems which can accept a new prefix change when they are able. During this period, the routing system actually supports two prefixes. The difficult part is hosts which cannot accept a new prefix AND return their old prefix as they still have some connection open using the old prefix. One additional bit is that the address lifetimes may be advisory, that is, the address can continue to be used after its lifetime expires (this assumes that it is unlikely to be reassigned in the forseeable future). However, once the lifetime runs out, there is no longer any guarantee that the routing system will actually deliver packets to the old address (but local connections could continue to run for awhile). TCP makes it pretty well impossible to renumber without dropping connections. 3) without disrupting running systems? (because if you are like me and have systems that can NOT be brought down and have long running processes disruption is fatal.) Surely there are periodic short outages when boxes crash, software is upgraded, etc. A disruption for renumbering would last as long as it takes to fire up a new TCP connection. (And applications that are critical but croak when a connection is dropped are in dire need of a session layer...) Thus far, I've only heard vague claims and not anything that makes me feel confident that this can be done. Sounds like you should join the addrconf mailing list (addrconf-request@cisco.com) and join in the fun. ------------------------------------------------------------------------------ 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 Tue Aug 23 01:20:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16338; Tue, 23 Aug 94 01:20:52 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16332; Tue, 23 Aug 94 01:20:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19216; Tue, 23 Aug 94 01:17:56 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA16280; Tue, 23 Aug 94 01:17:45 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA27413; Tue, 23 Aug 1994 10:17:49 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA02272; Tue, 23 Aug 1994 10:17:40 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408230817.AA02272@dxcoms.cern.ch> Subject: Re: (IPng) millions of OSI products To: ipng@sunroof.Eng.Sun.COM Date: Tue, 23 Aug 1994 10:17:40 +0200 (MET DST) Cc: In-Reply-To: <3063.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Aug 18, 94 10:20:31 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4668 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Replies to various points under this subject: > >Comments by: Alan Lloyd@Marketing@DCTHQ > ... such as routers, > >switches, X.400, X.500 and X.700 systems - in fact these last application > >level products have to be configured to evaluate the data syntax (not just > >bitstring compare) of NSAPs to do searches and check for equivalence... etc. > > > >It is not just a question that US GOSIP does not use NSAPs widely.. > >Or that one can truncate 20 bytes into 16 because of perceived unused fields. > > Bill Simpson: > This is a very valid concern. Of course, we were planning on truncating > into 12 or fewer bytes. > > This would destroy the ability to have the NSAP mapping into IPv6. Nobody is claiming that mapping N into M bits where N>M gives complete syntactic equivalence. People are inferring all kinds of non-existent goals for the proposed mapping. When it comes out as an I-D we (Jim Bound and I) will try to ensure that it clearly states the goals. They are limited. Bill: > Brian Carpenter, could you please provide a detailed description of the > range and number of currently deployed NSAPs and their mapping into IPv6? Several people have tried to collect such information and failed. It is easy to get info on NSAP allocation schemes and very difficult to get info on deployed, running systems. I speak for what I know: the physics/space science DECnet is part way through its transition to DECnet/OSI and so (assuming we don't abort the transition for some reason) that is o(20K) nodes. I'll make an assertion: there are not more than 200,000 CLNP nodes in real operational use today. (Ignoring industrial PLCs running MAP over null CLNP; there could be millions of these but they clearly don't count.) Can anybody PROVE this assertion is false? Jim Bound: > Those using NSAPs are typically also using the OSI stack. Those > customers in the market most likley want to traverse the Information Highway > without maybe using IP6 or IPv4 in their domain. So will other protocols > most likely. > > Now to traverse the Information Highway it is feasible that at points in > the topology entering the Information Highway that an NSAP gets > translated via the to-do list mapping to a destination address on the > Highway which will deliver the message back to an NSAP conscious domain. > This is the simplest case and can be done. More complex cases are under > study now but are much more messy by such facts that IP6 still has the > notion of subnets and NSAPs don't really per IS-IS (one user of NSAPs). This is a possible use; but tunnels would do it too. Robert Elz: > One of the basic requirements of IPv6 is supposed to be > that when sites connect to providers they renumber (in most > cases) if necessary so the address they're using fits the > routing topology. That's how routing is supposed to be able > to be scaled to the sizes we're talking about. I agree with the people who have disagreed with this paragraph. > Given that, what use can it possibly be to try and fit sites > existing NSAP (or IPX, or ...) addressing schemes into IPv6 > when they're simply going to be renumbered to something else > in any case? A goal of the mapping is precisely to allow people NOT to renumber (and by implication, to use ES-IS and IS-IS for IP6 domains using the NSAP format). > I do appreciate that there's some political advantage in > making it appear as if IPv6 handles NSAP addressing in order > to placate those who believe that existing NSAP schemes have > some intrinsic merit in and of themselves, regardless of > what effects they may have on global routing. It's more than that. National organisations have spent considerable effort on NSAP address allocation and they tell us that they want to re-use this investment. The impact on global routing is that a domain using such addresses has to connect to the rest of IP6 at IDRP level. If the whole of [Country X] aggregates to one point, is that so bad? Stuart Vance: > Actually, most DECnet sites (by a large majority) are still running DECnet > Phase IV. Most folks haven't gone to Phase V (DECnet/OSI) for many of the > same reasons that most IP sites haven't gone to OSI. The reason DECnet sites haven't transitioned to DECnet/OSI is nothing like the reason that IPv4 sites haven't transitioned to OSI. DEC are still supporting Phase IV on some operating systems; when they drop Phase IV support their customers will migrate (or cease to be customers). People haven't transitioned from IPv4 to OSI because there is nothing to transition to. Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ 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 Tue Aug 23 01:29:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16350; Tue, 23 Aug 94 01:29:39 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16344; Tue, 23 Aug 94 01:29:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19392; Tue, 23 Aug 94 01:26:42 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA17007; Tue, 23 Aug 94 01:26:27 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA28797; Tue, 23 Aug 1994 10:26:25 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA02449; Tue, 23 Aug 1994 10:26:17 +0200 X-Delivered: at request of brian on dxcoms.cern.ch Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA00573; Fri, 19 Aug 1994 16:59:42 +0200 X-Rerouted-To: Brian@dxcoms.cern.ch by the CERN Automatic Mail Router (v.2.0, July 1993). Received: from condor.logica.co.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA00421; Fri, 19 Aug 1994 16:59:00 +0200 Received: from smtpmail.logica.com ([158.234.8.102]) by condor.logica.co.uk (MX V3.1C) with SMTP; Fri, 19 Aug 1994 15:56:40 BST Received: by smtpmail.logica.com with Microsoft Mail id <2E54D688@smtpmail.logica.com>; Fri, 19 Aug 94 15:58:00 bst From: Fieldhouse Dirk To: "'Carpenter Brian (CERN-CN)'" Cc: Ashton Anthony , "'Hof Hank (Eurocontrol)'" , 'Whyman Tony ' Subject: (IPng) IPng encoding of NSAP addresses Date: Fri, 19 Aug 94 15:57:00 bst Message-Id: <2E54D688@smtpmail.logica.com> Encoding: 65 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In a recent posting to the IPng mailing list, you proposed an encoding of NSAP addresses for IPng, quoted at the end of this message. You might be interested to know, if you didn't already, that the Air Traffic Services community has adopted a CLNP address structure for its Aeronautical Telecommunications Network that splits the prefix (routing domain ID) into the following fields: Version: 1 octet (2 values allocated) Admin ID: 3 octets (based on 3 character country or airline code) RD format: 1 octet (2 values allocated) Admin Region Sel: 3 octets (based on 3 character ICAO location ID or 24 bit aircraft ID) Thus all 8 of the octets that you propose to contract to 4 are potentially used in this scheme. I know you say the aim of the mapping is to handle pre-existing NSAPAs, and ATN is at present in the experimental stage. However, by the time Ipng is deployed, ATN may well be in use. Or it may not: as with all uses of OSI, the future of this initiative is not assured, although it is widely accepted as the future direction for air traffic data communications. I hope this information is useful. Please feel free to disseminate it further if you need to. Regards, Dirk Fieldhouse #quote on 1. NSAPAs inside a 16-byte IPng address The main goal of this embedding is to allow pre-existing NSAPA allocations, profiled for CLNP, to be re-used for IPng routing. It does not offer a mapping for arbitrary NSAPAs. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0-3 |1 1 0 0 0 0|x x| AFcode| IDI (last 3 digits) |Prefix(octet 0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | Prefix (octets 1 through 3) | Area (octet 0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | Area (octet 1)| ID (octets 0 through 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| ID (octets 3 through 5) | NSEL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The AFcode is 1111 (hexadecimal F) to represent AFI code 39 (DCC, digital country code). Otherwise, AFI code 47 (ICD, international code designator) is implicit and AFcode is the first digit of the ICD. The longest CLNP prefixes in use today appear to be 4 octets, in NORDUNET (the Nordic academic network). Thus the semantics of existing 20-octet NSAPAs are fully mapped. DECnet/OSI address semantics are also fully mapped. The NSEL octet is retained. It is of no use for TCP and UDP traffic, but would be of use if a future revision of CLNP used the same format. The alignment is similar to that for 20-octet NSAPAs. #quote on ------------------------------------------------------------------------------ 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 Tue Aug 23 01:54:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16394; Tue, 23 Aug 94 01:54:32 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16388; Tue, 23 Aug 94 01:54:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19935; Tue, 23 Aug 94 01:51:35 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA19410; Tue, 23 Aug 94 01:51:24 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA02702; Tue, 23 Aug 1994 10:51:21 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA03076; Tue, 23 Aug 1994 10:51:20 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408230851.AA03076@dxcoms.cern.ch> Subject: (IPng) Since 20 into 16 won't go... To: ipng@sunroof.Eng.Sun.COM (ip6) Date: Tue, 23 Aug 1994 10:51:19 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1953 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This is in response to a whole bag of messages basically on the theme "any IP6 addressing scheme that does not allow for full sized 20 byte NSAPAs is no good." Firstly, I proposed inside the IPng Directorate that an alternative, NSAP, address format should be an integral part of IPng. Nobody else supported this idea and I accepted the 16-byte-only consensus. Secondly, there are examples of organizations that have set up allocation schemes using MORE than the number of bytes used by US-GOSIP; thanks to the various people who have sent messages about some of these. However, I believe that there are NO examples of organizations that have DEPLOYED significant networks using such schemes. To me it is therefore clear that there is no reasonable engineering or economic arguments for accomodating such schemes (those needing MORE bytes than US-GOSIP) in IP6. In any case, it can't be done in the agreed 16 bytes. I like Dave Boreham's analysis, and I think the reality is between #2 and #3 (we implement #3, and IP6 becomes CLNP2 by default): > > Let's propose some different worlds: > > 1. Ignore the NSAP mapping issue altogether. Global connectivity > is achieved via IP6, which has a robust IPv4 transition scheme. > Other communities invent various relaying > and NAT technologies to integrate legacy networking technologies. > > 2. Work out some "strong" NSAP to IP6 address space mapping scheme which > means that IP6 effectively is a new CLNP. The rumoured large deployed > NSAP-addressed _networks_ integrate well with and transition well > to the new IP6 network. > > 3. Work out some "weak" way to map NSAP addresses into IP6 such that > people with deployed _applications_ which currently expect > to run over an NSAP-addressed network, can transition to > the IP6 network without hassle. > Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ 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 Tue Aug 23 02:08:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16426; Tue, 23 Aug 94 02:08:39 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16420; Tue, 23 Aug 94 02:08:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20237; Tue, 23 Aug 94 02:05:42 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA20932; Tue, 23 Aug 94 02:05:27 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA14980; Tue, 23 Aug 1994 11:07:16 +0200 Message-Id: <199408230907.AA14980@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Mon, 22 Aug 1994 22:39:54 EDT." <9408230240.AA18796@xirtlu.zk3.dec.com> Date: Tue, 23 Aug 1994 11:07:15 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM => => >Yes, that's EXACTLY what we're trying to do. Run CLNP applications on => >top of IPv6. And when you get a new release, it has the mapping from => >CLNP to IPv6 in it. The app specifies its normal CLNP address, and => >magic happens underneath the covers. => => NO. This is not what we are trying to do in any scheduled IETF work I am => aware of at this time. We are going to develop a draft of how an NSAP => can be mapped into IP6. Thats it period. There is no other IETF work => chartered anywhere to deal with what you stated above. I am not saying => there should be or should not be just that there is not presently so => expectations are set correctly. I have a hard time understanding what a "CLNP application" is. OSI applications supposedly apply the OSI model, which is all about layer independence. Take the flagship OSI application, X.400; it runs over X.25 as well as CLNP. If it had been designed to run solely over CLNP, they would probably not have bothered inserting application level checkpointing and retransmission in the "reliable transport service". For that matter, X.400 (and many other applications) also run on top of IP, through RFC-1006. As far as I can tell, there is no functional difference between X.400 (or X.500, or FTAM, or CMIP) over CLNP and the same over RFC-1006. (We may discuss some performance problems, but that is really related to implementations; even the "extra exchange" imposed by RFC-1006 could be hidden.) Granted, existing OSI applications manipulate NSAPs, or rather PSAPs, all over the place. But they also include one major portability interface, i.e. the transport service. It is quite easy to use TLI or sockets to hide that you are running over RFC-1006 rather than TP4+CLNP or TP0+X.25. As a matter of fact, many implementations already do just that. The application passes an NSAP to the interface; the transport code analyses the first byte of the NSAP and decides to fire one or another protocol. This is by far the simpler transition strategy for OSI applications. Just define an "IP6" prefix for IP6 based NSAPs, such that the IDI says "this is an IP6 address (AFI=International org, IDP=Internet) and that the DSP contains the 16 octets of the IP6 address. Then, register those NSAPs in your OSI name server (X.500, I suppose). It should work very easily... Christian Huitema ------------------------------------------------------------------------------ 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 Tue Aug 23 04:18:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16481; Tue, 23 Aug 94 04:18:40 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16475; Tue, 23 Aug 94 04:18:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22232; Tue, 23 Aug 94 04:15:42 PDT Received: from survis.surfnet.nl by Sun.COM (sun-barr.Sun.COM) id AA02264; Tue, 23 Aug 94 04:15:30 PDT Message-Id: <9408231115.AA02264@Sun.COM> Received: from survis.surfnet.nl by survis.surfnet.nl with SMTP (PP); Tue, 23 Aug 1994 13:15:21 +0200 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) CLNP addressing plans satisfyable by 16 bytes? In-Reply-To: Your message of Mon, 22 Aug 1994 20:40:13 -0700. <199408230340.UAA08676@vangogh.CS.Berkeley.EDU> Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Tue, 23 Aug 1994 13:15:19 +0200 From: Victor Reijs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hello Keith and others, ==> From: Keith Sklower > So, what was the resonse to the people who said (in effect) > > Did we ever clearly identify any European Community member > whose NSAP allocation plan could not be satisfied with 16 bytes? To be concrete: - the 'Dutch R&D and education' network SURFnet has at this moment an NSAP address structure defined of max. 20 octets. It could easily be changed, because there are NO CLNS systems on a production base. If they come under production, we could try to change the present NSAP address structure that would not be a problem, I think). But, the chance that CLNS will be deployed for production traffic in SURFnet seems small, because of a) the introduction of IPv6 and b) the VERY limited need of CLNS-WAN for DECnet/OSI (we see the change from DECnet Phase IV -> IP[v4]). So our environment seems to have no problem. The question is even: Are we going to distributed NSAP address in the future? Is it not better to distribute IPv6 addresses (what ever they are)? - there are in Holland some other cooperations that use NSAP addresses (some ministeries and the PTT). I have no knowlegde about their address structure. The Dutch NSAP allocation scheme of the National Standard Organization (NNI) has a max. length of 20 octets. - some countries in Europe have now defined (and using) NSAP-address with full 20 octets (e.g. Germany for CLNS use). What their policies are on changing their length: You will have to ask them. - I know that someone on the TUBA list made an inventory of NSAP addresses structure in the world (also in Europe [I sent several documents to him]). Perhaps it is good to ask over that list! Furthermore, some of the TUBA people will have an Entity Title Database for ISODE (which holds an overview of endsystems and their NSAP addresses). Remember: How final these NSAP length are, I don't know! - I have the idea that mapping NSAP address on IPv6 addresses is only important for communities that would like to transport their CLNS traffic over an IPv6 network (encapsulation of the protocol, plus a simple mapping of addresses between IPv6-address and NSAP-address of routing purposes). Perhaps these communities have no need for a transition (yet;-)? Hope this clearifies the status of the SURFnet community with regard to NSAP addresses and their mapping on IPv6 address. All the best, Victor > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ 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 Tue Aug 23 05:30:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16537; Tue, 23 Aug 94 05:30:11 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16531; Tue, 23 Aug 94 05:30:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA23546; Tue, 23 Aug 94 05:27:16 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA06636; Tue, 23 Aug 94 05:27:04 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA28759; Tue, 23 Aug 94 05:22:40 -0700 Received: by xirtlu.zk3.dec.com; id AA26499; Tue, 23 Aug 1994 08:21:35 -0400 Message-Id: <9408231221.AA26499@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Tue, 23 Aug 94 11:07:15 +0200." <199408230907.AA14980@mitsou.inria.fr> Date: Tue, 23 Aug 94 08:21:29 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian, You are completely correct if it can be defined that way as input from an implementor. Also the performance issues of 1006 have been figured out and corrected for the most part, but it is an extra step so to speak. Most using it today in my experience is over XTI not sockets though (the API level not the kernel level). Plus a session layer can be added as transparent interface to the application so the protocol is unknown to the application and they only care about the name. /jim ------------------------------------------------------------------------------ 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 Tue Aug 23 05:45:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16558; Tue, 23 Aug 94 05:45:47 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16552; Tue, 23 Aug 94 05:45:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA23915; Tue, 23 Aug 94 05:42:52 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA08329; Tue, 23 Aug 94 05:42:39 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA29454; Tue, 23 Aug 94 05:39:33 -0700 Received: by xirtlu.zk3.dec.com; id AA27249; Tue, 23 Aug 1994 08:38:29 -0400 Message-Id: <9408231238.AA27249@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Tue, 23 Aug 94 10:17:40 +0200." <9408230817.AA02272@dxcoms.cern.ch> Date: Tue, 23 Aug 94 08:38:23 -0400 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 Bound: > Those using NSAPs are typically also using the OSI stack. Those > customers in the market most likley want to traverse the Information Highway > without maybe using IP6 or IPv4 in their domain. So will other protocols > most likely. > > Now to traverse the Information Highway it is feasible that at points in > the topology entering the Information Highway that an NSAP gets > translated via the to-do list mapping to a destination address on the > Highway which will deliver the message back to an NSAP conscious domain. > This is the simplest case and can be done. More complex cases are under > study now but are much more messy by such facts that IP6 still has the > notion of subnets and NSAPs don't really per IS-IS (one user of NSAPs). This is a possible use; but tunnels would do it too. ******************************** Yep. ******************************** Stuart Vance: > Actually, most DECnet sites (by a large majority) are still running DECnet > Phase IV. Most folks haven't gone to Phase V (DECnet/OSI) for many of the > same reasons that most IP sites haven't gone to OSI. The reason DECnet sites haven't transitioned to DECnet/OSI is nothing like the reason that IPv4 sites haven't transitioned to OSI. DEC are still supporting Phase IV on some operating systems; when they drop Phase IV support their customers will migrate (or cease to be customers). People haven't transitioned from IPv4 to OSI because there is nothing to transition to. ********************************** Thanks for clarifying IPv4-OSI it is different. Phase IV support will not be dropped this seems to be something that got out and confused all. Phase IV DECnet will be part of all Phase V ships its a name change not a product drop. I mean we still support PDP-11s running on plant floors all over the world. If you need more on this contact a Digital Sales Rep (not to brian but to anyone). Or come to DECUS in the South of France Sept 12-16 I will be thinking of all of you and all the mail I will not see (I don't believe in lap-tops for me until I can get mail from my GPS device). /jim ------------------------------------------------------------------------------ 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 Tue Aug 23 07:06:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16600; Tue, 23 Aug 94 07:06:46 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16594; Tue, 23 Aug 94 07:06:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA26244; Tue, 23 Aug 94 07:03:50 PDT Received: from ftp.com (wd40.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA17120; Tue, 23 Aug 94 07:03:39 PDT Received: from ftp.com by ftp.com ; Tue, 23 Aug 1994 10:03:36 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 23 Aug 1994 10:03:36 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA16799; Tue, 23 Aug 94 10:00:55 EDT Date: Tue, 23 Aug 94 10:00:55 EDT Message-Id: <9408231400.AA16799@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products From: kasten@ftp.com (Frank Kastenholz) Cc: perry@imsi.com, tli@cisco.com, dkatz@cisco.com Content-Length: 1142 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > c) (and this is the tough one) Autoconfiguration as currently forseen > has you renew your address every 18 hours. Those systems which can > accept a new prefix change when they are able. During this period, > the routing system actually supports two prefixes. The difficult part > is hosts which cannot accept a new prefix AND return their old prefix > as they still have some connection open using the old prefix. > > One additional bit is that the address lifetimes may be advisory, that is, > the address can continue to be used after its lifetime expires (this > assumes that it is unlikely to be reassigned in the forseeable future). > However, once the lifetime runs out, there is no longer any guarantee > that the routing system will actually deliver packets to the old address > (but local connections could continue to run for awhile). > > TCP makes it pretty well impossible to renumber without dropping > connections. I sort of hate to open up previously nailed shut and deeply buried coffins -- but the concept of an endpoint identifier might be useful here... -- Frank Kastenholz ------------------------------------------------------------------------------ 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 Tue Aug 23 07:41:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16612; Tue, 23 Aug 94 07:41:44 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16606; Tue, 23 Aug 94 07:41:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA27483; Tue, 23 Aug 94 07:38:48 PDT Received: from newdaisy.ee.und.ac.za by Sun.COM (sun-barr.Sun.COM) id AA22375; Tue, 23 Aug 94 07:38:08 PDT Received: by newdaisy.ee.und.ac.za (Smail3.1.28.1 #12) id m0qcwz0-0007WSC; Tue, 23 Aug 94 16:37 GMT+0200 Date: Tue, 23 Aug 1994 16:37:43 +0200 (GMT+0200) From: Alan Barrett Subject: Re: (IPng) millions of OSI products To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9408231400.AA16799@mailserv-D.ftp.com> Message-Id: 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 Tue, 23 Aug 1994, Frank Kastenholz wrote: > > TCP makes it pretty well impossible to renumber without dropping > > connections. > > I sort of hate to open up previously nailed shut and deeply buried > coffins -- but the concept of an endpoint identifier might be useful > here... I am not sure that it is too late for a session layer, perhaps with a DNS name as its identifier. The session layer would include stuff for closing old TCP connections and opening new ones when the hosts get renumbered. --apb (Alan Barrett) ------------------------------------------------------------------------------ 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 Tue Aug 23 08:02:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16641; Tue, 23 Aug 94 08:02:55 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16635; Tue, 23 Aug 94 08:02:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA28309; Tue, 23 Aug 94 07:59:58 PDT Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA26058; Tue, 23 Aug 94 07:59:45 PDT Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.4/8.6.4) with ESMTP id KAA08354 for ; Tue, 23 Aug 1994 10:59:41 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.4/8.6.4) with SMTP id KAA18417 for ; Tue, 23 Aug 1994 10:59:41 -0400 Received: from grid (bobsgrid.clis.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA22027; Tue, 23 Aug 94 11:06:13 EDT Message-Id: <9408231506.AA22027@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Aug 1994 10:59:47 -0500 To: ipng@sunroof.Eng.Sun.COM From: RGMoskowitz-3@is.chrysler.com (Robert Moskowitz) Subject: (IPng) Address transitions.... X-Mailer: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I am again a few days behind on my mail, and I was unable to break away to go over to U of Michigan to listen into the walkthrough. So I might be covering somethings already discussed. I have a VERY big problem with the NSAP discussions going on. Not becuase they are OSI addressing and we are IP addressing. Rather it is the most vocal and problematic of the 3 cases that we have afforded for in IP6. To wit, backward address, or even worst, old addressing enshirenment. Everybody has an addressing scheme (or anybody of size) for their network architecture. I have an SNA, IPX, and IPv4 addressing scheme that has had a lot of thought and sweat poured into them. I realize that I am being offered a new addressing scheme. I except it as that and am working on a TRANSITION to it. This OSI thread reflects a desire to keep the current addressing scheme inside of a new architecture, maybe. I suspect that some IPv4ers and IPXers are feeling snug-as-a-bug that they have been accomidated (like PUP was to IP?). People REALLY need to realize that we are working for a new addressing architecture. If NSAP components really bring something to the table in terms of segmenting an address, perhaps an address mapping that reflects the concepts of NSAPs is what is really needed. All of this talk about everyone's commitments to a particular layout should not carry significant weight, even to those that make these statements. The keys should be: 1) Transition to a new addressing architecture. a) Multiple address layouts to address valid architectual issues. b) Old to interim address mappings to speed the transition (not as a stop point). 2) Auto address configuration (see the draft on the addrconf list). 3) Growth of a new addressing architecture to support new networking ideas. OBTW, the plea for 20 byte IP6 addresses is all off. They should be asking for 21 byte addresses, as there is those header bits in the address to indicate the type of address layout (everyone likes a wise guy ;-) ). I really find interesting the discussions between Katz and Bound to understand what is involved in the NSAP and how to really transition into IP6. Go for it guys! Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ 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 Tue Aug 23 08:28:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16657; Tue, 23 Aug 94 08:28:23 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16651; Tue, 23 Aug 94 08:28:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA29354; Tue, 23 Aug 94 08:25:26 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA00622; Tue, 23 Aug 94 08:25:12 PDT Received: from relay.imsi.com by wintermute.imsi.com id LAA05453 for ; Tue, 23 Aug 1994 11:24:29 -0400 Received: from snark.imsi.com by relay.imsi.com id LAA18049 for ; Tue, 23 Aug 1994 11:24:28 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02084; Tue, 23 Aug 94 11:24:28 EDT Message-Id: <9408231524.AA02084@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Automatic Renumbering (was Re: (IPng) millions of OSI products) In-Reply-To: Your message of "Tue, 23 Aug 1994 16:37:43 +0200." X-Reposting-Policy: redistribute only with permission Date: Tue, 23 Aug 1994 11:24:27 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As a person who has clients that depend on having their machines functioning well in a 24x7 environment, let me state that all this talk of new untested technologies like mandatory automatic network renumbering makes me very very nervous. I feel much more comfortable with the "IPv6 as incremental improvement" way of thinking. If we really require that your networks automatically renumber at the touch of a button in order to function in the IPv6 world, I think we will have made a mistake. It would be fine, a couple of years from now, in an environment where people had experimented with automatic renumbering, especially in the large, and found it worked just fine, but that working experience doesn't yet exist. Lets not go the "specify and then test" route -- that way lies ISO-style madness. Perry Alan Barrett says: > On Tue, 23 Aug 1994, Frank Kastenholz wrote: > > > TCP makes it pretty well impossible to renumber without dropping > > > connections. > > > > I sort of hate to open up previously nailed shut and deeply buried > > coffins -- but the concept of an endpoint identifier might be useful > > here... > > I am not sure that it is too late for a session layer, perhaps with a DNS > name as its identifier. The session layer would include stuff for closing > old TCP connections and opening new ones when the hosts get renumbered. > > --apb (Alan Barrett) > > ----------------------------------------------------------------------------- - > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ 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 Tue Aug 23 09:34:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16696; Tue, 23 Aug 94 09:34:11 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16690; Tue, 23 Aug 94 09:34:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA02071; Tue, 23 Aug 94 09:31:15 PDT Received: from cnaf43.infn.it by Sun.COM (sun-barr.Sun.COM) id AA12549; Tue, 23 Aug 94 09:30:41 PDT Date: Tue, 23 Aug 1994 18:28:51 +0200 (WET-DST) From: VISTOLI@infn.it To: ipng@sunroof.Eng.Sun.COM Cc: VISTOLI@infn.it Message-Id: <940823182851.20207475@infn.it> Subject: (IPng) nsap and IPng address mapping Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I'm following the discussion and probably I missed some key points: What are the advantages keeping in the routers both the routing table for the INPG addresses containing the 'mapped' NSAP and the routing table for the 'native' IPNG addresses ? Could be easier to have an IPNG routing protocol for the IPng addresses and continue to have ISIS/I-ISIS and IDRP protocols for the 20 byte NSAP, in a multiprotocol, ship in the night style as we have now? We are talking about the IPv4 transition and not CLNP transition. I don't see any advantages in mapping the 20-byte working NSAP in a IP6 16 byte address. Usually, mapping or not mapping, two addresses means two networks topologies. Why you need to manage both of them with IPng? Why get rid of multiprotocol? When the IPNG will be working well, and the OSI (and also Decnet ???) applications will be available in the End-node over IP6 stack, I don't foresee any particular problem changing the end nodes address or removing the NSAP address and eventually migrate OSI to IP6. Best Regards, Cristina Vistoli ------------------------------------------------------------------------------ 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 Tue Aug 23 09:40:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16722; Tue, 23 Aug 94 09:40:39 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16716; Tue, 23 Aug 94 09:40:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA02316; Tue, 23 Aug 94 09:37:43 PDT Received: from MVS.OAC.UCLA.EDU by Sun.COM (sun-barr.Sun.COM) id AA13840; Tue, 23 Aug 94 09:37:30 PDT Message-Id: <9408231637.AA13840@Sun.COM> Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1) with BSMTP id 2334; Tue, 23 Aug 94 09:37:42 PST Date: Tue, 23 Aug 94 09:37 PDT To: ipng@SUNROOF.Eng.Sun.COM From: Michael Stein Subject: (IPng) Re: Automatic Renumbering Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > As a person who has clients that depend on having their machines > functioning well in a 24x7 environment, let me state that all this > talk of new untested technologies like mandatory automatic network > renumbering makes me very very nervous. I feel much more comfortable > with the "IPv6 as incremental improvement" way of thinking. If we > really require that your networks automatically renumber at the touch > of a button in order to function in the IPv6 world, I think we will > have made a mistake. It would be fine, a couple of years from now, in > an environment where people had experimented with automatic > renumbering, especially in the large, and found it worked just fine, > but that working experience doesn't yet exist. Lets not go the > "specify and then test" route -- that way lies ISO-style madness. My impression of this from the lists and the Mbone presentions yesterday is large scale use of IPv6 is at least a couple of years away. Testing is planned. Certainly the general idea of "soft state" in the network isn't new. Even the idea of a host address being "soft state" isn't really new -- DNS entries do time out allowing for name to address mapping changes. The shock is the maximum 18 hour address lifetime in IPv6. However as explain on the Mbone, it's unlikely at any particular timeout point that the addresses will actually change. Assuming you control your local routers, you would be in control of any changes (if you wanted to be). You would have to follow changes required by your Internet provider or risk finding your site unreachable from the Internet though. Probably a good provider will try to minimize these changes as well as have a larger overlap where both old and new addresses would work. Not having the automatic renumbering would be madness. Since we don't know how to do routing in the general case the addresses have to map the topology and this topology will change over time. Implementing some new untesting routing would be "specify and then test". I would also like to see a way to keep a TCP connection up over renumbering. I'm starting to believe that the flexability of SIPP might make this possible, however I haven't seen any ideas which directly solve this. ------------------------------------------------------------------------------ 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 Tue Aug 23 10:18:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16742; Tue, 23 Aug 94 10:18:18 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16736; Tue, 23 Aug 94 10:18:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03874; Tue, 23 Aug 94 10:15:22 PDT Received: from ski.utah.edu ([128.110.124.10]) by Sun.COM (sun-barr.Sun.COM) id AA19985; Tue, 23 Aug 94 10:13:12 PDT Received: (from haas@localhost) by ski.utah.edu (8.6.9/8.6.9) id LAA20182; Tue, 23 Aug 1994 11:16:19 -0600 From: Tired of the Information Superhype Message-Id: <199408231716.LAA20182@ski.utah.edu> Date: Tue, 23 Aug 94 11:16:18 MDT Subject: Re: (IPng) Re: Automatic Renumbering To: ipng@SUNROOF.Eng.Sun.COM In-Reply-To: ipng@SUNROOF.Eng.Sun.COM, Tue, 23 Aug 94 09:37 PDT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Not having the automatic renumbering would be madness. Since we >don't know how to do routing in the general case the addresses >have to map the topology and this topology will change over time. >Implementing some new untesting routing would be "specify and >then test". > >I would also like to see a way to keep a TCP connection up over >renumbering. I'm starting to believe that the flexability of >SIPP might make this possible, however I haven't seen any ideas >which directly solve this. Well, the main motivation for automatic renumbering is to allow users to track changes in WAN providers. The main motivation for keeping connections open is typically to support local uses within an organization (at least, around here). Perhaps we should think along the lines of specifying connections in terms of a default provider address ("whoever our WAN provider is this week") rather than a specific number, so that a change in provider wouldn't affect connections within a local branch of a user organization. True this wouldn't solve every problem, but it might help the most pressing cases. -- Walt ------- ------------------------------------------------------------------------------ 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 Tue Aug 23 10:40:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16754; Tue, 23 Aug 94 10:40:09 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16748; Tue, 23 Aug 94 10:40:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA04795; Tue, 23 Aug 94 10:37:13 PDT Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA24368; Tue, 23 Aug 94 10:36:50 PDT Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id NAA16981; Tue, 23 Aug 1994 13:33:47 -0400 Message-Id: <199408231733.NAA16981@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Tue, 23 Aug 1994 10:00:55 EDT." <9408231400.AA16799@mailserv-D.ftp.com> From: Valdis.Kletnieks@vt.edu Date: Tue, 23 Aug 1994 13:33:45 +22306356 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Tue, 23 Aug 1994 10:00:55 EDT, Frank Kastenholz said: > I sort of hate to open up previously nailed shut and deeply buried > coffins -- but the concept of an endpoint identifier might be useful > here... OK.. I'll bite - is there room in the IPv6 framework for an EID? Anybody working on a draft, or should I oil up my chainsaw and get to work? ;) /Valdis ------------------------------------------------------------------------------ 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 Tue Aug 23 14:41:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17149; Tue, 23 Aug 94 14:41:42 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17143; Tue, 23 Aug 94 14:41:33 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14876; Tue, 23 Aug 94 14:38:44 PDT Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA03893; Tue, 23 Aug 94 14:38:31 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id OAA08265; Tue, 23 Aug 1994 14:34:34 -0700 Date: Tue, 23 Aug 1994 14:34:34 -0700 From: Dave Katz Message-Id: <199408232134.OAA08265@feta.cisco.com> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, alan@datacraft.oz.au, brian@dxcoms.cern.ch In-Reply-To: bound@zk3.dec.com's message of Sun, 21 Aug 94 01:05:31 -0400 <9408210505.AA10949@xirtlu.zk3.dec.com> Subject: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: bound@zk3.dec.com Date: Sun, 21 Aug 94 01:05:31 -0400 X-Mts: smtp >Subnets and areas are both bottom-level topological abstractions; a >subnet is effectively a special case of an area. This should not be >an issue. Well it is because in the NSAP model as used today IS-IS is assumed and that assumption is that essentially the NSAP router that receives the incoming packets will know on what link the sysid (for the Host) lives in the domain. >This isn't true, Jim. One could just as easily look at an NSAP and Dave its true but yes it could be different. If I have 5 routers in an area all on different local wires any router in most cases knows the sysid or can determine it for any host on any wire. A second level of indirection such as an IPv4 subnet is not required. So to say what I said is not true is not true. My point is that the single-wire vs. multiple-wire model is *not* reflected in CLNP or the NSAP address structure, but only in the IS-IS protocol and the typical mode of deployment. Yes, IS-IS does assume a multiple-wire model for CLNP. >call the left hand 13 bytes the "subnet", declare that such subnets >only live on a single wire, and stop advertising the system ID (which >by the way only is advertised within the IS-IS area, not throughout >the domain). Note that we could do this today in CLNP without changing >the hosts at all. But they may not and usually don't live on the same wire. True. My point is that if you build the host functionality correctly, you are not locked into one model or the other. CLNP networks could be deployed in a single-wire model without any host changes. Your abstraction is correct. What I am trying to figure out is how to make it work at the detail level after the abstraction. As a comment it will not help that I am hearing that some have used what were to be RESERVED FIELDs in the NSAP. This is orthogonal. The reserved fields have no impact on the bottom-tier routing design, since they were reserved in the middle (for much the same reason that the IPv6 address discussions include holes for growth). The use of reserved fields has impact only in that it makes it much harder to stuff 20 kilos of dung into a 16 kilo bag. ;-) ------------------------------------------------------------------------------ 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 Tue Aug 23 17:48:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17304; Tue, 23 Aug 94 17:48:55 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17298; Tue, 23 Aug 94 17:48:47 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25275; Tue, 23 Aug 94 17:45:58 PDT Received: from CU.NIH.GOV by Sun.COM (sun-barr.Sun.COM) id AA08691; Tue, 23 Aug 94 17:45:44 PDT Message-Id: <9408240045.AA08691@Sun.COM> To: tli@cisco.com Cc: ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Tue, 23 Aug 1994 20:40:31 EDT Subject: Re: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Now what happens when provider P's topology changes and S2 is now > nearest exit point Y, instead of X, but S1 and S3 are still nearest X? > > This is case 1: > > Does S2 get a different subscriber number? I'm assuming that this > wasn't planned for when the subscriber numbers were assigned. People > talk a lot about renumbering when a subscriber changes providers, but > not when a provider adds an exit point or makes some other major > topology change. > > This makes sense if we can make renumbering really cheap and easy. > > In case 2, no renumbering happens and the provider simply stops > advertising a longer prefix for S2 though X. > > Tony If no renumbering happens, S2 might be one out of a block of many subscriber numbers being advertised through X. If the topology change wasn't planned for at the time the subscriber numbers were assigned (so the block doesn't split nicely), won't S2 most likely have to be advertised as an exception at X and maybe Y? ------------------------------------------------------------------------------ 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 Tue Aug 23 17:59:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17321; Tue, 23 Aug 94 17:59:24 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17315; Tue, 23 Aug 94 17:59:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25753; Tue, 23 Aug 94 17:56:27 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA10702; Tue, 23 Aug 94 17:56:17 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id RAA23165; Tue, 23 Aug 1994 17:56:14 -0700 Date: Tue, 23 Aug 1994 17:56:14 -0700 From: Tony Li Message-Id: <199408240056.RAA23165@lager.cisco.com> To: RAF@CU.NIH.GOV Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Roger Fajman"'s message of Tue, 23 Aug 1994 20:40:31 EDT <199408240045.RAA06349@hubbub.cisco.com> Subject: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM If no renumbering happens, S2 might be one out of a block of many subscriber numbers being advertised through X. If the topology change wasn't planned for at the time the subscriber numbers were assigned (so the block doesn't split nicely), won't S2 most likely have to be advertised as an exception at X and maybe Y? Actually, advertising the exception at Y is probably sufficient. This works because the longer prefix at Y causes the other network to use Y over the block advertisement at X. You should note that this is already standard CIDR stuff... Tony ------------------------------------------------------------------------------ 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 Tue Aug 23 18:15:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17333; Tue, 23 Aug 94 18:15:57 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17327; Tue, 23 Aug 94 18:15:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA26578; Tue, 23 Aug 94 18:12:59 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA13949; Tue, 23 Aug 94 18:12:49 PDT Received: from relay.imsi.com by wintermute.imsi.com id VAA06829 for ; Tue, 23 Aug 1994 21:12:46 -0400 Received: from snark.imsi.com by relay.imsi.com id VAA21743 for ; Tue, 23 Aug 1994 21:12:45 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02870; Tue, 23 Aug 94 21:12:44 EDT Message-Id: <9408240112.AA02870@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Address Allocation Architecture for IP6 In-Reply-To: Your message of "Tue, 23 Aug 1994 20:40:31 EDT." <9408240045.AA08691@Sun.COM> X-Reposting-Policy: redistribute only with permission Date: Tue, 23 Aug 1994 21:12:44 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have clients that wish to be able to get internet service from multiple providers in order to assure reliable service. I know of other companies that have multiple geographically dispersed internet connections from different providers as well -- although their internal internets have single network numbers and are fully connected. How will the proposed address allocation structures function smoothly under these conditions? (I ask this semi-rhetorically -- I have difficulty seeing how to reconcile these requirements with some of the currently proposed schemes.) Perry Metzger ------------------------------------------------------------------------------ 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 Tue Aug 23 18:29:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17345; Tue, 23 Aug 94 18:29:09 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17339; Tue, 23 Aug 94 18:29:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA27170; Tue, 23 Aug 94 18:26:12 PDT Received: from CU.NIH.GOV by Sun.COM (sun-barr.Sun.COM) id AA16465; Tue, 23 Aug 94 18:25:57 PDT Message-Id: <9408240125.AA16465@Sun.COM> To: tli@cisco.com Cc: ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Tue, 23 Aug 1994 21:23:35 EDT Subject: Re: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > If no renumbering happens, S2 might be one out of a block of many > subscriber numbers being advertised through X. If the topology change > wasn't planned for at the time the subscriber numbers were assigned (so > the block doesn't split nicely), won't S2 most likely have to be > advertised as an exception at X and maybe Y? > > Actually, advertising the exception at Y is probably sufficient. This > works because the longer prefix at Y causes the other network to use Y > over the block advertisement at X. > > You should note that this is already standard CIDR stuff... > > Tony OK, right. Longest match first. But the important thing is that S2 has to be advertised as an exception. A lot of exceptions could accumulate over time. It's one thing to have this in CIDR, which is a stopgap until IPv6 addressing is fully deployed. It's quite another to have it in IPv6 itself. If there are 10**9 networks and only 0.1% exceptions, that's a million exceptions. Renumbering seems to be the solution. But no one talks about having to renumber even when you haven't changed providers. Why not? ------------------------------------------------------------------------------ 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 Tue Aug 23 18:39:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17361; Tue, 23 Aug 94 18:39:26 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17355; Tue, 23 Aug 94 18:39:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA27524; Tue, 23 Aug 94 18:36:25 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA18155; Tue, 23 Aug 94 18:36:14 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id SAA25122; Tue, 23 Aug 1994 18:36:10 -0700 Date: Tue, 23 Aug 1994 18:36:10 -0700 From: Tony Li Message-Id: <199408240136.SAA25122@lager.cisco.com> To: RAF@CU.NIH.GOV Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Roger Fajman"'s message of Tue, 23 Aug 1994 21:23:35 EDT <199408240125.SAA07990@hubbub.cisco.com> Subject: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM But the important thing is that S2 has to be advertised as an exception. A lot of exceptions could accumulate over time. It's one thing to have this in CIDR, which is a stopgap until IPv6 addressing is fully deployed. It's quite another to have it in IPv6 itself. If there are 10**9 networks and only 0.1% exceptions, that's a million exceptions. Correct. However, recall that these exceptions can be advertised only to the immediately neighboring domains. Renumbering seems to be the solution. But no one talks about having to renumber even when you haven't changed providers. Why not? Haven't thought about it enough yet. Getting renumbering to work at ALL seems to be a sufficient chore. Once it is in place, it may be possible to perform a variety of interesting optimizations using it. Tony ------------------------------------------------------------------------------ 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 Tue Aug 23 19:10:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17374; Tue, 23 Aug 94 19:10:09 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17368; Tue, 23 Aug 94 19:10:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA28407; Tue, 23 Aug 94 19:07:11 PDT Received: from CU.NIH.GOV by Sun.COM (sun-barr.Sun.COM) id AA22395; Tue, 23 Aug 94 19:07:00 PDT Message-Id: <9408240207.AA22395@Sun.COM> To: tli@cisco.com Cc: ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Tue, 23 Aug 1994 22:04:35 EDT Subject: Re: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > But the important thing is that S2 has to be advertised as an > exception. A lot of exceptions could accumulate over time. It's one > thing to have this in CIDR, which is a stopgap until IPv6 addressing is > fully deployed. It's quite another to have it in IPv6 itself. If > there are 10**9 networks and only 0.1% exceptions, that's a million > exceptions. > > Correct. However, recall that these exceptions can be advertised only > to the immediately neighboring domains. Yes, I understand that. However, the trend seems to be towards lots more interconnection points. I doubt that the NAPs are the end of it. > Renumbering seems to be the solution. But no one talks about > having to renumber even when you haven't changed providers. Why > not? > > Haven't thought about it enough yet. Getting renumbering to work at > ALL seems to be a sufficient chore. Once it is in place, it may be > possible to perform a variety of interesting optimizations using it. > > Tony Yes, I agree that renumbering is a hard problem to solve. What we have been talking about could affect how often it is necessary to renumber and therefore how easy it has to be. It's one thing if I decide I want or need to change providers and therefore must renumber. It's another if my current provider tells me I have to renumber because of topology changes in their network. It better be very easy in the latter case (maybe even automatic). ------------------------------------------------------------------------------ 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 Tue Aug 23 19:17:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17386; Tue, 23 Aug 94 19:17:32 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17380; Tue, 23 Aug 94 19:17:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA28649; Tue, 23 Aug 94 19:14:36 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA23631; Tue, 23 Aug 94 19:14:25 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id TAA26532; Tue, 23 Aug 1994 19:14:23 -0700 Date: Tue, 23 Aug 1994 19:14:23 -0700 From: Tony Li Message-Id: <199408240214.TAA26532@lager.cisco.com> To: RAF@CU.NIH.GOV Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Roger Fajman"'s message of Tue, 23 Aug 1994 22:04:35 EDT <199408240206.TAA09235@hubbub.cisco.com> Subject: (IPng) Address Allocation Architecture for IP6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yes, I agree that renumbering is a hard problem to solve. What we have been talking about could affect how often it is necessary to renumber and therefore how easy it has to be. It's one thing if I decide I want or need to change providers and therefore must renumber. It's another if my current provider tells me I have to renumber because of topology changes in their network. It better be very easy in the latter case (maybe even automatic). I would hope that it would be automatic in EITHER case. Well, ok, triggered by a human... Tony ------------------------------------------------------------------------------ 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 Tue Aug 23 19:36:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17412; Tue, 23 Aug 94 19:36:43 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17406; Tue, 23 Aug 94 19:36:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA29314; Tue, 23 Aug 94 19:33:47 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA27262; Tue, 23 Aug 94 19:33:36 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA04185; Tue, 23 Aug 94 19:05:30 -0700 Received: by xirtlu.zk3.dec.com; id AA15975; Tue, 23 Aug 1994 22:05:18 -0400 Message-Id: <9408240205.AA15975@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: Automatic Renumbering In-Reply-To: Your message of "Tue, 23 Aug 94 09:37:00 PDT." <9408231637.AA13840@Sun.COM> Date: Tue, 23 Aug 94 22:05:12 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Assuming you control your local routers, you would be in control >of any changes (if you wanted to be). You would have to follow >changes required by your Internet provider or risk finding your >site unreachable from the Internet though. Probably a good >provider will try to minimize these changes as well as have a >larger overlap where both old and new addresses would work. Ouch this brings up heartburn for me. Today we have a class A address. We pay a provider to route in/out. Why with IP6 is the model changing? Or is it not changing? Why would a provider have anything to say about anyones address. They just route packets. I understand the phone company scenario. Are we saying that Internet Addresses will not be given to organizations anymore in IP6? Or what? If anyone understands this can you post the answer or I hope a suggestion to the list. I don't want providers controlling addresses on the Internet? I have no choice with the phone company it was underway before I could vote or participate with my congressman and senators to make sure they take MY view for MY vote to destroy monopolies. But I assume this is up for discussion somewhere? Lots of other questions but for now this should get some kind of response. This affects my input to the technical work for base IPng and Autoconfiguration, or else I would not be asking this on this list. We need to state our assumptions and criteria with CLARITY. I think we need some here. I am trying to weigh this entire issue of runumbering during for the technical tradeoffs we make for autoconfiguration, discovery, and most likely transition when IPv4 addresses run out. thanks /jim ------------------------------------------------------------------------------ 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 Tue Aug 23 23:25:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17529; Tue, 23 Aug 94 23:25:45 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17523; Tue, 23 Aug 94 23:25:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05852; Tue, 23 Aug 94 23:22:47 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA23813; Tue, 23 Aug 94 23:22:36 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA07568; Wed, 24 Aug 1994 08:22:41 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA26167; Wed, 24 Aug 1994 08:22:33 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408240622.AA26167@dxcoms.cern.ch> Subject: (IPng) Service providers beware! To: ipng@sunroof.Eng.Sun.COM Date: Wed, 24 Aug 1994 08:22:32 +0200 (MET DST) In-Reply-To: <9408240205.AA15975@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Aug 23, 94 10:05:12 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2372 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Heartburn is too mild. Beware! Paying customers WILL NOT accept renumbering as a consequence of changing service providers or (even less likely) of Internet topology changes. If you plan to make money out of IP6 service provision, don't accept the notion that subscriber addresses may change readily. Otherwise..... NAT :-( Brian >--------- Text sent by bound@zk3.dec.com follows: > > > >Assuming you control your local routers, you would be in control > >of any changes (if you wanted to be). You would have to follow > >changes required by your Internet provider or risk finding your > >site unreachable from the Internet though. Probably a good > >provider will try to minimize these changes as well as have a > >larger overlap where both old and new addresses would work. > > Ouch this brings up heartburn for me. Today we have a class A address. > We pay a provider to route in/out. Why with IP6 is the model changing? > Or is it not changing? Why would a provider have anything to say about > anyones address. They just route packets. > > I understand the phone company scenario. Are we saying that Internet > Addresses will not be given to organizations anymore in IP6? Or what? > If anyone understands this can you post the answer or I hope a > suggestion to the list. > > I don't want providers controlling addresses on the Internet? I have no > choice with the phone company it was underway before I could vote or > participate with my congressman and senators to make sure they take MY > view for MY vote to destroy monopolies. But I assume this is up for > discussion somewhere? Lots of other questions but for now this should > get some kind of response. > > This affects my input to the technical work for base IPng and > Autoconfiguration, or else I would not be asking this on this list. > We need to state our assumptions and criteria with CLARITY. I think we > need some here. I am trying to weigh this entire issue of runumbering > during for the technical tradeoffs we make for autoconfiguration, > discovery, and most likely transition when IPv4 addresses run out. > > thanks > /jim > ------------------------------------------------------------------------------ > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ 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 Wed Aug 24 00:58:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17552; Wed, 24 Aug 94 00:58:00 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17546; Wed, 24 Aug 94 00:57:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07799; Wed, 24 Aug 94 00:55:04 PDT Received: from survis.surfnet.nl by Sun.COM (sun-barr.Sun.COM) id AA04825; Wed, 24 Aug 94 00:54:52 PDT Message-Id: <9408240754.AA04825@Sun.COM> Received: from survis.surfnet.nl by survis.surfnet.nl with SMTP (PP); Wed, 24 Aug 1994 09:54:37 +0200 To: ipng@sunroof.Eng.Sun.COM Cc: VISTOLI@infn.it Subject: Re: (IPng) nsap and IPng address mapping In-Reply-To: Your message of Tue, 23 Aug 1994 18:28:51 +0200. <940823182851.20207475@infn.it> Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Wed, 24 Aug 1994 09:54:32 +0200 From: Victor Reijs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ==> From: VISTOLI@infn.it > I don't see any advantages in mapping the 20-byte working NSAP in a IP6 > 16 byte address. Effectively it is 20 octets in 15 octets (one octet is used to decided in the IP6 address that a 'mapped-NSAP'-address is following). It could be halve an octet longer (see proposal of Brian and others). All the best, Victor > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ 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 Wed Aug 24 02:02:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17616; Wed, 24 Aug 94 02:02:01 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17610; Wed, 24 Aug 94 02:01:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA09019; Wed, 24 Aug 94 01:59:03 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA11214; Wed, 24 Aug 94 01:58:27 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA18295; Wed, 24 Aug 1994 11:00:04 +0200 Message-Id: <199408240900.AA18295@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Service providers beware! In-Reply-To: Your message of "Wed, 24 Aug 1994 08:22:32 +0200." <9408240622.AA26167@dxcoms.cern.ch> Date: Wed, 24 Aug 1994 11:00:02 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, I do not think that nailing down all the details of the future addressing plan makes much sense today. It is certainly not in the critical path for deploying IP6: what we need right know is one workable plan. It may not be entirely optimal, we can be pretty sure that we will change it in the next years. So another aspect is that we should burn out too much of the initial address space. In between, there are a number of technologies that we should work on. Automatic renumbering (automatic numbering, in fact) is one of them. Having it to work does not mean that people will effectively renumber every second day, or that the reason they renumber is a "change of provider". Internal reorganizations, acquisitions and merges also come to mind as classical example. We may also want to develop some form of "address compression" in the routing protocols. If most of the addresses in your table have a common prefix, there should be a way to factor that, which would both diminish table size and make updates easier. That being said, there are two objects that should be taken into account by the addressing plan, i.e. "regional assignment authorities" and "neutral interconnects". Both point towards some form of geographical addressing. Many providers have a regional scope, should get their provider id from a "regional pool", if only to decentralize assignment - we already do that. Then, we could regard the provision of "neutral interconnects" as the enabling technology for provider independent addressing: the neutral interconnect appears like a "pseudo provider". Is someone working on this? Christian Huitema ------------------------------------------------------------------------------ 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 Wed Aug 24 05:14:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17840; Wed, 24 Aug 94 05:14:52 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17834; Wed, 24 Aug 94 05:14:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12497; Wed, 24 Aug 94 05:11:54 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA27620; Wed, 24 Aug 94 05:11:43 PDT Received: by rodan.UU.NET id QQxeii00557; Wed, 24 Aug 1994 08:11:42 -0400 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) renumbering Date: Wed, 24 Aug 1994 08:11:41 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Reality check time.... We are currently asking new subscribers to renumber and they are doing so. If we make it (almost) infinitely easier than it is now, most will continue to do so. The other part of the equation is that we charge for routing services. That is, if I have to carry an explicit route for you through my infrastructure and all my routing coordination, then I will charge you more money to do so because it costs EVERYONE with a core router and it certainly takes a lot of my staff's time and energy. You can then look at that price and see whether it effects your decision about how hard renumbering really is. Like many other things in the world, it's a cost-benefit tradeoff. You decide whether you think the benefit is worth the cost. But the important point remains that making it easy to renumber is EXTREMELY important, because if we don't maintain most of the addresses in their natural clusters, no one will be able to afford enough memory for the routing tables. Renumbering is not an option, it is necessary for scaling, so we must make it as easy as possible, and we must set expectations that people WILL usually renumber when changing providers. There is no other known solution to the problem. The alternative is that the Internet will eventually collapse from routing failure. And customers *really* don't want that to happen. -Mike O'Dell Resident Crank ------------------------------------------------------------------------------ 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 Wed Aug 24 05:39:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17852; Wed, 24 Aug 94 05:39:40 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17846; Wed, 24 Aug 94 05:39:33 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA13077; Wed, 24 Aug 94 05:36:44 PDT Received: from ecrc.de by Sun.COM (sun-barr.Sun.COM) id AA29836; Wed, 24 Aug 94 05:36:30 PDT Received: from scorpio.ecrc.de by ecrc.de with SMTP id AA05634 ( for ); Wed, 24 Aug 1994 14:36:18 +0200 Received: from acrab25.ecrc.de by scorpio.ecrc.de (4.1/SMI-3.2) id AA15800; Wed, 24 Aug 94 14:36:17 +0200 Date: Wed, 24 Aug 94 14:36:17 +0200 From: Dave Morton Message-Id: <9408241236.AA15800@scorpio.ecrc.de> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) renumbering Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Fully agree with Mike, those points key issues. Dave ------------------------------------------------------------------------------ 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 Wed Aug 24 06:08:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17869; Wed, 24 Aug 94 06:08:12 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17863; Wed, 24 Aug 94 06:08:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA13778; Wed, 24 Aug 94 06:05:13 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA02633; Wed, 24 Aug 94 06:04:50 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 24 Aug 94 21:57:41 +0900 From: Masataka Ohta Message-Id: <9408241257.AA14781@necom830.cc.titech.ac.jp> Subject: Re: (IPng) renumbering To: ipng@sunroof.Eng.Sun.COM Date: Wed, 24 Aug 94 21:57:40 JST In-Reply-To: ; from "Mike O'Dell" at Aug 24, 94 8:11 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Reality check time.... > > We are currently asking new subscribers to renumber and they are doing so. > > If we make it (almost) infinitely easier than it is now, most will > continue to do so. How can we have multiple providers, then? > The other part of the equation is that we charge for routing services. > That is, if I have to carry an explicit route for you through my > infrastructure and all my routing coordination, then I will charge you > more money to do so because it costs EVERYONE with a core router and > it certainly takes a lot of my staff's time and energy. That's an issue to be solved by separating identification and routing. Masataka Ohta ------------------------------------------------------------------------------ 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 Wed Aug 24 06:47:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17924; Wed, 24 Aug 94 06:47:31 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17918; Wed, 24 Aug 94 06:47:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14782; Wed, 24 Aug 94 06:44:34 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA07530; Wed, 24 Aug 94 06:44:23 PDT Received: by rodan.UU.NET id QQxeio08194; Wed, 24 Aug 1994 09:44:22 -0400 Date: Wed, 24 Aug 1994 09:44:22 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Multi-homed organizations Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In the most common case, an organization with one internal addressing structure but more than one provider could have a natural assignment with at most one provider and the others would carry special announcements. this is obvious. there are advantages to being multi-homed, and there are costs. some organizations are large enough to merit a prefix like that given to large providers regardless of their topological attachment. The model here is a hybrid - some part of the space is flat-routed, and within the provider-based subspace of IP6, traffic between "provider clusters" is essentially flat-routed (you carry a route to each target aggregate), with the addition of explicit routes for non-natural routes carried outside their natural clusters. SO the "top level" is flat-routed, but from that vantage point, the interior of clusters *appears* to be hierarchically routed - note that I said *appears*. Inside a provider cluster, the provider does his magic down to some point, at which point a cluster is handed off to a customer for further interior routing. Ahah! At any one "level" (which corresponds to some contiguous substring of the address, grouping to the left), the current level seems flat-routed (probably *is* flat-routed) but lower and upper levels appear to be hierarchically routed (for at least the next level). this limits the amount of flat-routing which must be carried world-wide. -mo ------------------------------------------------------------------------------ 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 Wed Aug 24 07:10:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17950; Wed, 24 Aug 94 07:10:23 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17944; Wed, 24 Aug 94 07:10:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15544; Wed, 24 Aug 94 07:07:25 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA10783; Wed, 24 Aug 94 07:07:14 PDT Received: from relay.imsi.com by wintermute.imsi.com id KAA07704 for ; Wed, 24 Aug 1994 10:07:02 -0400 Received: from snark.imsi.com by relay.imsi.com id KAA26092 for ; Wed, 24 Aug 1994 10:07:01 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA03354; Wed, 24 Aug 94 10:07:00 EDT Message-Id: <9408241407.AA03354@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) renumbering In-Reply-To: Your message of "Wed, 24 Aug 1994 08:11:41 EDT." X-Reposting-Policy: redistribute only with permission Date: Wed, 24 Aug 1994 10:07:00 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "Mike O'Dell" says: > But the important point remains that making it easy to renumber is > EXTREMELY important, because if we don't maintain most of the > addresses in their natural clusters, no one will be able to afford > enough memory for the routing tables. I ask again -- what is the natural cluster for a customer with two or more providers, or with connections to providers at multiple geographically dispersed locations, or both? Perry ------------------------------------------------------------------------------ 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 Wed Aug 24 07:45:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18040; Wed, 24 Aug 94 07:45:44 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18034; Wed, 24 Aug 94 07:45:37 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA16883; Wed, 24 Aug 94 07:42:48 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA17299; Wed, 24 Aug 94 07:42:35 PDT Received: by rodan.UU.NET id QQxeis13887; Wed, 24 Aug 1994 10:42:29 -0400 Date: Wed, 24 Aug 1994 10:42:29 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) geographically-dispersed locations.... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry asked about organizations with multiple dispersed sites. If they have no interior connectivity, then there is no problem with them just being different sites served by (potentially) different providers. if they are internally connected, then previous mail applies. -mo ------------------------------------------------------------------------------ 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 Wed Aug 24 07:50:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18052; Wed, 24 Aug 94 07:50:30 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18046; Wed, 24 Aug 94 07:50:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA17072; Wed, 24 Aug 94 07:47:34 PDT Received: from ski.utah.edu by Sun.COM (sun-barr.Sun.COM) id AA18176; Wed, 24 Aug 94 07:47:20 PDT Received: (from haas@localhost) by ski.utah.edu (8.6.9/8.6.9) id IAA28809; Wed, 24 Aug 1994 08:51:54 -0600 From: Tired of the Information Superhype Message-Id: <199408241451.IAA28809@ski.utah.edu> Date: Wed, 24 Aug 94 08:51:54 MDT Subject: Re: (IPng) Service providers beware! To: ipng@sunroof.Eng.Sun.COM In-Reply-To: ipng@sunroof.Eng.Sun.COM, Wed, 24 Aug 1994 08:22:32 +0200 (MET DS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Brian Carpenter writes: >Heartburn is too mild. Beware! Paying customers WILL NOT accept >renumbering as a consequence of changing service providers or >(even less likely) of Internet topology changes. If you plan to make >money out of IP6 service provision, don't accept the notion that >subscriber addresses may change readily. Otherwise..... NAT :-( I suspect that we would be willing to renumber if the costs outweighed the benefits. Currently renumbering is done manually and is extremely disruptive, and the benefits are essentially non-existant. A good method of renumbering automatically would change that equation drastically. -- Walt ------- ------------------------------------------------------------------------------ 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 Wed Aug 24 07:53:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18065; Wed, 24 Aug 94 07:53:55 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18059; Wed, 24 Aug 94 07:53:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA17215; Wed, 24 Aug 94 07:50:58 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA18751; Wed, 24 Aug 94 07:50:43 PDT To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) renumbering Date: Wed, 24 Aug 94 15:48:08 GMT From: Ran Atkinson Message-Id: <9408241548.aa01456@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As Mike and some others will already know, provider-based addressing does not work well enough to be very sensible for sites with multiple concurrent providers. NRL has about 8 major external providers of IP service right now. Its unlikely that we'll ever get down to just a single provider. Administrative burden and other factors make provider-oriented addressing a non-starter for NRL and other similar multi-homed sites. Now geographic addressing will work for some sites now (incuding NRL which is 1 hop out from FIX-East). We should experiment with geographic addressing some. We should also continue to permit organisations to have permanent non-provider based addresses. Now it is possible that folks not using provider-oriented addressing would need to join the CIX (or some similar equivalent) if they want their routes to be widely advertised. This would seem reasonable. However, we must not at any time impose hard requirements (such as thou shalt use provider-oriented addressing) that reduce capabilities from the present. Ran atkinson@Itd.nrl.navy.mil ------------------------------------------------------------------------------ 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 Wed Aug 24 08:51:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18125; Wed, 24 Aug 94 08:51:40 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18119; Wed, 24 Aug 94 08:51:29 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19816; Wed, 24 Aug 94 08:48:39 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA29854; Wed, 24 Aug 94 08:47:39 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 25 Aug 94 00:40:00 +0900 From: Masataka Ohta Message-Id: <9408241540.AA15492@necom830.cc.titech.ac.jp> Subject: (IPng) Multi-homed organizations, geographical constraint, security and more To: ipng@sunroof.Eng.Sun.COM Date: Thu, 25 Aug 94 0:39:58 JST In-Reply-To: ; from "Mike O'Dell" at Aug 24, 94 9: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 > In the most common case, an organization with one internal addressing > structure but more than one provider could have a natural assignment > with at most one provider and the others would carry special announcements. > this is obvious. Obviously wrong. You don't understand how large 256^16 is. See PS. > there are advantages to being multi-homed, and there are costs. And the cost should be minimized. If, > a natural assignment > with at most one provider and the others would carry special announcements. is enforced, I'm afraid there is no advantage. > The model here is a hybrid - some part of the space is flat-routed, and > within the provider-based subspace of IP6, traffic between "provider clusters" No provider clusters please. We need a free selection of providers between clusters. Masataka Ohta ------------------------------------------------------------------------ PS The following is a draft on provider-based, and at the same time, provider-independent address assignment plan with geographical restriction. The same will be posted posted for big-i for EID/locator discussion. PPS EID is a trademark of Noel Chiappa. ------------------------------------------------------------------------ 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 Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 24 09:29:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18197; Wed, 24 Aug 94 09:29:27 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18191; Wed, 24 Aug 94 09:29:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA21474; Wed, 24 Aug 94 09:26:30 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA06103; Wed, 24 Aug 94 09:26:12 PDT Received: from pm002-00.dialip.mich.net (pm002-00.dialip.mich.net [35.1.48.81]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA19551 for ; Wed, 24 Aug 1994 12:25:31 -0400 Date: Wed, 24 Aug 94 15:35:15 GMT From: "William Allen Simpson" Message-Id: <3091.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Rapid Automatic Renumbering Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Automatic renumbering has been in my SIPP Neighbor Discovery drafts since the beginning. It was a requirement raised in WG meetings. Since we have adopted SIPP, we have adopted automatic renumbering. No human intervention is required. The same packet that advertises the routing service advertises the renumbering to the host. The trust relationship is simple -- if you trust the router to whom you are sending packets, you can trust the renumbering. ---- There was a comment that TCP could not renumber a current connection. This is not true! TCP takes no position on renumbering. Every packet has its own checksum calculation. The connection can certainly be reliably renumbered, with an AUTHENTICATED message, which has already been defined. Authentication is a required element of IPv6. ---- The only question that remains is HOW OFTEN renumbering may occur. I believe that because of NAPs, and rapid changes in routing, renumbering must occur on the order of seconds. A Treework, where every provider has a single attachment point, is contrary to the spirit of IP. It does not allow dynamic routing past points of failure. The suggestion that every COUNTRY have a single point of attachment was completely ludicrous. While some countries may be smaller than moderately sized cities, can anyone justify the premise that every news, mail, video, and audio feed for even the tiny country of United Kingdoms would go through a single centralized router? However, this is more than network robustness. The IMMENSE SIZE of the provider-subscriber fields will not scale when flat routed. Therefore, every single internal change to provider or subscriber topology MUST result in dynamic renumbering. 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 From owner-ipng Wed Aug 24 09:34:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18209; Wed, 24 Aug 94 09:34:07 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18203; Wed, 24 Aug 94 09:34:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA21726; Wed, 24 Aug 94 09:31:10 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA05971; Wed, 24 Aug 94 09:25:43 PDT Received: from pm002-00.dialip.mich.net (pm002-00.dialip.mich.net [35.1.48.81]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA19534; Wed, 24 Aug 1994 12:25:17 -0400 Date: Wed, 24 Aug 94 15:58:23 GMT From: "William Allen Simpson" Message-Id: <3092.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) > > Brian Carpenter, could you please provide a detailed description of the > > range and number of currently deployed NSAPs and their mapping into IPv6? > > Several people have tried to collect such information and failed. > It is easy to get info on NSAP allocation schemes and very difficult > to get info on deployed, running systems. I speak for what I know: > the physics/space science DECnet is part way through its transition > to DECnet/OSI and so (assuming we don't abort the transition for some > reason) that is o(20K) nodes. > > I'll make an assertion: there are not more than 200,000 CLNP nodes > in real operational use today. (Ignoring industrial PLCs running > MAP over null CLNP; there could be millions of these but they clearly > don't count.) Can anybody PROVE this assertion is false? > Thank you for the clear statement on the number of nodes. Interesting that you have 10% of them. Until someone comes up with a contrary assertion with strong evidence, I will be happy to quote you every time someone asserts there are millions of deployed NSAP nodes. 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 From owner-ipng Wed Aug 24 09:39:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18229; Wed, 24 Aug 94 09:39:35 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17187; Tue, 23 Aug 94 16:12:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19554; Tue, 23 Aug 94 16:09:49 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA19919; Tue, 23 Aug 94 16:09:30 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 24 Aug 1994 09:04:15 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 24 Aug 1994 09:07:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 24 Aug 1994 09:06:31 +1000 Date: Wed, 24 Aug 1994 09:06:31 +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 Aug 24 09:06:30 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 300609240894 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <300609240894*/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[2]: (IPng) IPNG 16 to OSI NSAP mappability Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> From: kgk@hookup.net (Keith G Knightson) >> Why is everybody going to endless lengths to map what is ultimately >>unmappable? >> >If this is true, we need to know for sure. Please give detail. Why is >an NSAP unmappable? >How many _deployed_ nodes does this affect, and who are the operators of >these deployed nodes? >> As a matter of fact the Canadian Standard for OSI NSAP addresses only has >> two non-used, reserved, octets. This structure is being used by the large >> Air Traffic Control system being set up in Canada, as well as by the >> Government's Enterprise Core Network. >> >I thought you said these were already deployed? Being set up is _not_ >the same as deployed. Particularly when IPv4 was already deployed. IPv4 is not the issue, is it? Or we would not be discussing IPv6. >How many _deployed_ nodes will this affect, and who are the operators of >these deployed nodes? >> Globally, the International Air Trafiic Association is also using OSI NSAP >> addresses. >> >A completely deployed network? Why isn't my local airport hooked up? >Why do pilots use IPv4 to get weather and file flight plans? When was >the OSI plan put into operation? What is the access information? IATA is the commercial side is it not? >How many _deployed_ nodes will this affect, and who are the operators of >these deployed nodes? >> Closer to home, I understand that the Cellular Digital Packet Data network >> is going to allocate zillions of OSI NSAP addresses. >> >They are? Why did they get that big IPv4 block? Why is the software >they demonstrate IPv4 based? How close are you to the cited industry? >How many _deployed_ nodes will this affect, and who are the operators of >these deployed nodes? Does it really matter? >> It seems to me that the proposal to use 16 bytes should be re-examined. >> >I agree. If we don't need to map any NSAPs, we can get by with 8 bytes >just fine. It would seem that the case for 16 or 8 byte addresses is not really made and some huffing and puffing is taking place. From my perspective, I have not seen the debate but I have seem IPv4 run out of space. From an NSAP point of view the size of the network to be handled is much bigger than the current Internet. >From an engineering point of view, why limit yourself to 8 bytes of address when bandwidth is expanding rapidly and becoming cheaper by the day. The argument for 8 bytes seems similar to the argument for writing cunning code in assembler that saves every bit and causes a nightmare in maintenance later on. Now is the time to cooperate and get it right, for the globes network, not just the Internet. We would like a common network out of all this. >Bill.Simpson@um.cc.umich.edu Jeff.Latimer@finance.ausgovfinance.telememo.au ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ 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 Wed Aug 24 09:42:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18255; Wed, 24 Aug 94 09:42:11 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18249; Wed, 24 Aug 94 09:42:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22093; Wed, 24 Aug 94 09:39:14 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA09626; Wed, 24 Aug 94 09:39:01 PDT Received: from jalfrezi.ndl.co.uk by relay1.pipex.net with SMTP (PP) id <07534-0@relay1.pipex.net>; Wed, 24 Aug 1994 16:28:54 +0100 Received: from atticus (atticus.ndl.co.uk) by ndl.co.uk (4.1/SMI-4.1) id AA07675; Wed, 24 Aug 94 16:27:07 BST Message-Id: <9408241527.AA07675@ndl.co.uk> X-Sender: davidb@mailhost.ndl.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Aug 1994 16:28:17 +0100 To: ipng@sunroof.Eng.Sun.COM From: davidb@ndl.co.uk (David Boreham) Subject: Re: (IPng) Service providers beware! X-Mailer: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I suspect that we would be willing to renumber if the costs outweighed >the benefits. Currently renumbering is done manually and is extremely >disruptive, and the benefits are essentially non-existant. A good method >of renumbering automatically would change that equation drastically. Could someone give a description of exactly what would happen when I decide to change service providers ? I'm trying to imagine what the sequence would be, and to work out whether there would be any service disruption in the changeover. If I change telephone company, I need to have someone come to my premises on a sunday and play about with cables and PBXs and suchlike. Condiserable hassle is entailed, but everything (hopefully) works on Monday 9am. Is this the kind of picture, or is there going to be some "big nob" that the net admin can twiddle to change providers at will ? David. ------------------------------------------------------------------------------ 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 Wed Aug 24 09:46:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18300; Wed, 24 Aug 94 09:46:09 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17558; Wed, 24 Aug 94 01:02:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07874; Wed, 24 Aug 94 00:59:31 PDT Received: from ns.iij.ad.jp by Sun.COM (sun-barr.Sun.COM) id AA05599; Wed, 24 Aug 94 00:59:18 PDT Received: from terminus.iij.ad.jp (terminus.iij.ad.jp [192.244.191.56]) by ns.iij.ad.jp (8.6.9+2.4Wb/3.3Wb-NS) with ESMTP id QAA27588; Wed, 24 Aug 1994 16:59:13 +0900 Received: from terminus.iij.ad.jp by terminus.iij.ad.jp (8.6.5/iij-slave) id QAA09870; Wed, 24 Aug 1994 16:59:12 +0900 Message-Id: <199408240759.QAA09870@terminus.iij.ad.jp> To: ipng@sunroof.Eng.Sun.COM Cc: davidc@terminus.iij.ad.jp Subject: Re: (IPng) Service providers beware! In-Reply-To: Your message of "Wed, 24 Aug 1994 08:22:32 +0200." <9408240622.AA26167@dxcoms.cern.ch> Date: Wed, 24 Aug 1994 16:57:57 +0900 From: David R Conrad Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Quoted from: brian@dxcoms.cern.ch >Heartburn is too mild. Beware! Paying customers WILL NOT accept >renumbering as a consequence of changing service providers or >(even less likely) of Internet topology changes. If you plan to make >money out of IP6 service provision, don't accept the notion that >subscriber addresses may change readily. Otherwise..... NAT :-( I'll probably regret this, but I have to ask why. Why will customers care what their IP6 addresses are? I mean, its not like they are going to be manually configuring their workstation ethernet interfaces or router ports with 16 byte addresses, right? If they are, there is definitely a NAT in your future... >Quoted from: bound@zk3.dec.com >> Ouch this brings up heartburn for me. Today we have a class A address. >> We pay a provider to route in/out. Why with IP6 is the model changing? >> Or is it not changing? Why would a provider have anything to say about >> anyones address. They just route packets. Since routing information is tied in with the , won't the service providers who are providing the routing need to have something to say about what the is? If the service providers have no say, then won't you get the same situation you have with IPv4 where aggregation has a tendency to break down due to holes and everybody's routers become quite unhappy? It would seem to me that if you don't renumber at least part of the address, 16 bytes is way too small... Regards, -drc ------------------------------------------------------------------------------ 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 Wed Aug 24 09:46:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18312; Wed, 24 Aug 94 09:46:44 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17778; Wed, 24 Aug 94 03:54:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA11053; Wed, 24 Aug 94 03:51:46 PDT Received: from gatekeeper.mcimail.com by Sun.COM (sun-barr.Sun.COM) id AA23021; Wed, 24 Aug 94 03:51:32 PDT Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA02178; Wed, 24 Aug 94 11:53:56 +0100 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ab27390; 24 Aug 94 10:47 GMT Date: Wed, 24 Aug 94 05:49 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: ipng Subject: (IPng) Fwd: Re: local address token... Message-Id: <50940824104905/0003858921NA3EM@mcimail.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In my on-going fight for a small host token, this just showed up in the addrconf list... Bob ----------------- Forwarded Message Date: Wed Aug 24, 1994 12:45 am EST Source-Date: Wed, 24 Aug 94 00:30:20 EDT From: mpatrick EMS: INTERNET / MCI ID: 376-5414 MBX: mpatrick@merlin.dev.cdx.mot.com TO: * Robert G. Moskowitz / MCI ID: 385-8921 TO: crawdad EMS: INTERNET / MCI ID: 376-5414 MBX: crawdad@munin.fnal.gov CC: Gary Scott Malkin EMS: INTERNET / MCI ID: 376-5414 MBX: gmalkin@xylogics.com CC: addrconf EMS: INTERNET / MCI ID: 376-5414 MBX: addrconf@cisco.com CC: mpatrick EMS: INTERNET / MCI ID: 376-5414 MBX: mpatrick@merlin.dev.cdx.mot.com Subject: Re: local address token... Message-Id: 71940824054517/0003765414DC4EM Source-Msg-Id: <199408240430.AAA24743@zerbin.dev.cdx.mot.com> As a bridge developer, I've been burned -badly- by trying to implement quick, shift/xor hash schemes on mac addresses (kinda important for the forwarding table, ya know?) The big problem is that Decnet IV uses --locally administered-- MAC addresses, where the last 8 bits are always identical: hex 04!! Decnet IV sites really screw up anyone trying a simple MAC hash. To solve the problem, I went to the book (Sedgewick's Algorithms) and implemented "linear congruent" hashing. It requires a 32x32 bit multiply, but believe me, its worth it. Here's what's worked for me. I'm copying from an internal memo I wrote. (Quotes are from Sedgewicks "Algorithms") ------------------------------ p. 202 (in chapter 16, "Hashing") "What is needd is a function which transforms keys...into integers in the range [0..M-1]... "One commonly used method is to take M to be prime and, for any key k, compute h(k) = k mod M. This is a straightorward method which is easy to compute in many environemnts and spreads the key values out well. "A second commonly used method is similar to the linear congruential random number generator: take M = 2**m and ha(k) to be the leading m bits of (bk mod w), where w is the word size of the computer and b is chosen as for the random number generator. This can be more efficiently computed than the method above on some computers, and it has the advantage that is can spread out key values which are close to one another (e.g. temp1, temp2, temp3). As we've noted before, languages like Pacal are not well-suited to such operations." The linear congruential method for random numbers uses the following algorithm to generate a series of random numbers in the array a[], assuming a[1] has a seed integer: for i:= 2 to N do a[i] := (a[i-1]*b + 1) mod m I'm now quoting from page 35, where it describes how to select the constants: "Simple as it may seem, the linear congruential random number generator has been the subject of volumes of detailed and difficult mathematical analysis. This work gives us some guidance in choosing the constants b and m. Some "common sense" principles apply, but in this case common sense isn't enough to ensure good random numbers. First, m should be large: it can be the computer word size, as mentioned above, but it needn't be quite that large if that's inconvenient... It will normally be convenient to make m a power of 10 or 2. Second, b shouldn't be too large or too small: a safe choice is to use a number with one digit less than m. Third, b should be an arbitrary constant with no particular pattern in its digits, except that it should end with ...x21, with x even: this last requirement is admittedly peculiar, but it prevents the occurrence of some bad cases that have been uncovered by the mathematical analysis. The rules described above were developed by D.E.Knuth, whose textbook covers the subject in some detail... For our hashing algorithm, I think we should be safe, not sorry, and include all 6 bytes. Here's my suggested algorithm: 1) Add the top 16-bit word to the bottom 32-bit long, forming a 32 bit sum 2) Multiply unsigned the sum by the constant 314159212 (decimal). (This forms a 64 bit result). 3) Return the most significant 11 bits of the lower 32 bits of the result. Another way of stating it is in C: unsigned int hash (unsigned char *mac) { register unsigned long h; h = * (unsigned long *) (mac+2); h += *(unsigned short int *) mac; return ((h * 314159212) >> 21); The actual implementation, of course, should be in assembly language. I implemented a similar algorithm in my last bridging company, and it spread a 1000-node database of decnet addresses among (in our case) 1024 chains beautifully--no chain had more than 2 entries. (In my case, I had used only "3412" as my constant.) I think we should take their advice and make b "one less digit" than m. The constant 314159212, at 9 decimal digits, is one less than the 10 digits in the largest 32 bit integer (4294967295). FYI, 314159212 in hex is 0x12b9b06C. ----------------- That above text was for our bridge's forwarding table, using an 11 bit hash. The 16-bit hash would be bits 16-31 of the 64-bit result of the multiply. (i.e. the second 16-bit word from the least significant side). The magic number "b" with its nonrepeating digits is of course pi to 7 digits with 21 on the end. Matt, can you run this linear congruential algorithm through the fermi database? If we use a hashing algorithm, I strongly suggest using the linear congruential one. Regards, -mike ------------------------------------------------------------------------ Michael W. Patrick x7664 Motorola Codex Network Access mpatrick@merlin.dev.cdx.mot.com (617) 821-7664 ------------------------------------------------------------------------------ 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 Wed Aug 24 09:47:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18324; Wed, 24 Aug 94 09:47:19 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17907; Wed, 24 Aug 94 06:33:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14467; Wed, 24 Aug 94 06:30:46 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA05856; Wed, 24 Aug 94 06:30:30 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA02278; Wed, 24 Aug 1994 15:30:28 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA11975; Wed, 24 Aug 1994 15:30:27 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408241330.AA11975@dxcoms.cern.ch> Subject: Re: (IPng) renumbering To: ipng@sunroof.Eng.Sun.COM Date: Wed, 24 Aug 1994 15:30:26 +0200 (MET DST) In-Reply-To: from "Mike O'Dell" at Aug 24, 94 08:11:41 am X-Mailer: ELM [version 2.4 PL22] 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 Would it help if we talked about re-prefixing instead of re-numbering? Brian ------------------------------------------------------------------------------ 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 Wed Aug 24 09:50:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18336; Wed, 24 Aug 94 09:50:36 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17907; Wed, 24 Aug 94 06:33:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14467; Wed, 24 Aug 94 06:30:46 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA05856; Wed, 24 Aug 94 06:30:30 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA02278; Wed, 24 Aug 1994 15:30:28 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA11975; Wed, 24 Aug 1994 15:30:27 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408241330.AA11975@dxcoms.cern.ch> Subject: Re: (IPng) renumbering To: ipng@sunroof.Eng.Sun.COM Date: Wed, 24 Aug 1994 15:30:26 +0200 (MET DST) In-Reply-To: from "Mike O'Dell" at Aug 24, 94 08:11:41 am X-Mailer: ELM [version 2.4 PL22] 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 Would it help if we talked about re-prefixing instead of re-numbering? Brian ------------------------------------------------------------------------------ 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 Wed Aug 24 09:52:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18356; Wed, 24 Aug 94 09:52:45 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18347; Wed, 24 Aug 94 09:52:37 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22617; Wed, 24 Aug 94 09:49:47 PDT Received: from ncc.ripe.net by Sun.COM (sun-barr.Sun.COM) id AA12226; Wed, 24 Aug 94 09:48:02 PDT Received: from belegen.ripe.net by ncc.ripe.net with SMTP id AA24741 (5.65a/NCC-2.3); Wed, 24 Aug 1994 18:47:35 +0200 Received: from localhost.ripe.net by belegen.ripe.net with SMTP id AA01051 (5.65a/NCC-2.2); Wed, 24 Aug 1994 18:47:34 +0200 Message-Id: <9408241647.AA01051@belegen.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) Rapid Automatic Renumbering In-Reply-To: Your message of "Wed, 24 Aug 1994 15:35:15 GMT." <3091.bill.simpson@um.cc.umich.edu> Date: Wed, 24 Aug 1994 18:47:33 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Wed, 24 Aug 94 15:35:15 GMT "William Allen Simpson" wrote: > There was a comment that TCP could not renumber a current connection. > This is not true! TCP takes no position on renumbering. Every packet > has its own checksum calculation. > > The connection can certainly be reliably renumbered, with an > AUTHENTICATED message, which has already been defined. Authentication > is a required element of IPv6. Since TCP works on a {src IPnum, src port, dst IPnum, dst port} tuple, and these numbers are included in the TCP checksum, how are you going to avoid TCP rejecting 'bad' packets, causing it to send a RST back or ignoring it altogether? I am afraid TCP needs some surgery before it flies on IP6. I do agree that we need renumbering, but the logistics are more complex than you describe. Geert Jan ------------------------------------------------------------------------------ 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 Wed Aug 24 10:44:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18508; Wed, 24 Aug 94 10:44:20 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18502; Wed, 24 Aug 94 10:44:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24375; Wed, 24 Aug 94 10:41:14 PDT Received: from netcom11.netcom.com ([192.100.81.121]) by Sun.COM (sun-barr.Sun.COM) id AA22091; Wed, 24 Aug 94 10:37:13 PDT Received: by netcom11.netcom.com (8.6.8.1/Netcom) id KAA05907; Wed, 24 Aug 1994 10:17:27 -0700 Date: Wed, 24 Aug 1994 10:17:27 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199408241717.KAA05907@netcom11.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Service providers beware! Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I do not think that nailing down all the details of the future addressing plan >makes much sense today. It is certainly not in the critical path for deploying >IP6: what we need right know is one workable plan. It may not be entirely >optimal, we can be pretty sure that we will change it in the next years. So >another aspect is that we should burn out too much of the initial address >space. I would hope this statement is somewhat false. Many people objected of having 8 bytes today and moving towards 16 bytes 30 years from now because of the pains of change. Changing address plans has the same potential of problems (maybe on a slightly smaller scale, but who knows). So I think we need to nail down what we can and hopefully NOT have to change in a couple of years. >Christian Huitema ------------------------------------------------------------------------------ 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 Wed Aug 24 10:46:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18523; Wed, 24 Aug 94 10:46:57 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18517; Wed, 24 Aug 94 10:46:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24480; Wed, 24 Aug 94 10:44:00 PDT Received: from tiny.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA23694; Wed, 24 Aug 94 10:43:25 PDT 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 NAA18369 for ; Wed, 24 Aug 1994 13:42:31 -0400 Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id NAA02029 for ipng@sunroof.Eng.Sun.COM; Wed, 24 Aug 1994 13:41:15 -0400 Date: Wed, 24 Aug 1994 13:41:15 -0400 From: Vadim Antonov Message-Id: <199408241741.NAA02029@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Rapid Automatic Renumbering Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Since TCP works on a {src IPnum, src port, dst IPnum, dst port} tuple, >and these numbers are included in the TCP checksum, how are you >going to avoid TCP rejecting 'bad' packets, causing it to send >a RST back or ignoring it altogether? >I am afraid TCP needs some surgery before it flies on IP6. You can always fool TCP by giving it a pseudoheader with all zeros, no matter what actual addresses are. --vadim ------------------------------------------------------------------------------ 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 Wed Aug 24 11:30:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18644; Wed, 24 Aug 94 11:30:48 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18638; Wed, 24 Aug 94 11:30:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA26710; Wed, 24 Aug 94 11:27:50 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA02982; Wed, 24 Aug 94 11:26:13 PDT Received: by rodan.UU.NET id QQxejh06141; Wed, 24 Aug 1994 14:25:20 -0400 Date: Wed, 24 Aug 1994 14:25:20 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) how often to renumber.... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, i cannot disagree more strongly. Renumbering, for most clusters, will be *very* infrequent (ie, on the order of a provider change) but inevitable. If we are stupid enough to encode all the details of the topology in the addressing plan, then yes, you'd have to renumber with considerable frequency. that's the design issue - how much topology to encode so we don't have to do that. i cannot believe, though, that we will end up with massive flapping of the address space. if for no other reason than it simply isn't tractable. "Doctor, Doctor! I hurts when I do this!" "Then don't do that!" -Mike ------------------------------------------------------------------------------ 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 Wed Aug 24 11:57:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18665; Wed, 24 Aug 94 11:57:32 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18659; Wed, 24 Aug 94 11:57:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA28486; Wed, 24 Aug 94 11:54:33 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA09411; Wed, 24 Aug 94 11:54:18 PDT Received: from relay.imsi.com by wintermute.imsi.com id OAA08622 for ; Wed, 24 Aug 1994 14:53:27 -0400 Received: from snark.imsi.com by relay.imsi.com id OAA28024 for ; Wed, 24 Aug 1994 14:53:26 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA03787; Wed, 24 Aug 94 14:53:25 EDT Message-Id: <9408241853.AA03787@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) automatic renumbering In-Reply-To: Your message of "Wed, 24 Aug 1994 16:57:57 +0900." <199408240759.QAA09870@terminus.iij.ad.jp> X-Reposting-Policy: redistribute only with permission Date: Wed, 24 Aug 1994 14:53:25 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM David R Conrad says: > I'll probably regret this, but I have to ask why. Why will customers > care what their IP6 addresses are? I mean, its not like they are > going to be manually configuring their workstation ethernet interfaces > or router ports with 16 byte addresses, right? If they are, there is > definitely a NAT in your future... I'm not a player in any of these discussions -- I spend my time in the IP security WG, and frankly feel out of my area of expertise when the routing issues are brought up. However, having been involved in the management of large sites and sites with very mission critical hardware, I've got to say that a lot of this stuff is frightening. Lots is being assumed on the basis that protocols that haven't yet been developed will work smoothly. The reason people care what their IP addresses are is not because they want a particular number or some such but because most systems make it very administratively difficult to change addresses quickly even if they do partially automate the process. At one site I worked at, we built a complete automated systems management infrastructure and largely automated most of these processes. Even given our level of automation (which allowed me to bring down and reinstall the o/s on hardware in different cities safely!) I doubt we could have pulled off all the alterations needed to safely and quickly change our addresses. There are just too many things that have addresses hardcoded in them, and too many administrative databases that have to be informed, and too many persistant applications that would have to be restarted. Lots of questions come to mind. How would I interface my automated systems management tool, which thinks it owns the address space, into the automated renumbering tool? How would the myriads of different kinds of hardware be interfaced in? How is the security managed (because the security nightmares here are amazing). How do you continue to operate while renumbering, and only half your net is renumbered? (Having had a network completely crap out on me during an experiment at automated renumbering, and having found myself unable to use any tools any longer because the network no longer functioned, I've still got big questions about that one.) How will your applications that assume more than they should about IP addresses (things like sybase interface files, license manager databases, etc, etc) all be informed of your new numbers, especially if, in many cases like license managers, you suddenly will have to call the manufacturer for new magic cookies? There is also no answer yet given about what to do about machines that cannot go down and cannot have their connections dropped. Real money is spent on such systems by companies with real critical needs. It can be argued that given a sufficiently sophisticated renumbering system all the problems will disappear and the world will be happy. Fine. Show me one such a system. I'm willing to believe only in implemented code. I'm sure that given enough engineering effort one could integrate everything together. However, this isn't going to be a simple change from the current modus operandi of the internet -- this is a major alteration. As I've said, I'm not a player in this discussion. However, I beg people to make sure that the magic wand to do all the renumbering has been tested and debugged BEFORE the assumption is made that it can be built and will work perfectly. Perry ------------------------------------------------------------------------------ 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 Wed Aug 24 12:35:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18720; Wed, 24 Aug 94 12:35:05 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18714; Wed, 24 Aug 94 12:34:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00871; Wed, 24 Aug 94 12:32:07 PDT Received: from tiny.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA19126; Wed, 24 Aug 94 12:31:21 PDT 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 PAA20677 for ; Wed, 24 Aug 1994 15:30:49 -0400 Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id PAA03006 for ipng@sunroof.Eng.Sun.COM; Wed, 24 Aug 1994 15:29:34 -0400 Date: Wed, 24 Aug 1994 15:29:34 -0400 From: Vadim Antonov Message-Id: <199408241929.PAA03006@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) automatic renumbering Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The Big Problem of renumbering is that transport-level addresses are known to applications. If they're completely opaque (i.e. when applications can refer to network entities only by *names*) the renumbering becomes nearly trivial. It is not a problem of any particular numbering plan or frame format but the problem of implementation (i.e. socket semantics). What's interesting it can be fixed with minimal changes in socket interface -- i.e. allow binding DNS names to sockets! --vadim ------------------------------------------------------------------------------ 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 Wed Aug 24 16:36:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19055; Wed, 24 Aug 94 16:36:45 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19049; Wed, 24 Aug 94 16:36:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA13917; Wed, 24 Aug 94 16:33:46 PDT Received: from CU.NIH.GOV by Sun.COM (sun-barr.Sun.COM) id AA10271; Wed, 24 Aug 94 16:33:35 PDT Message-Id: <9408242333.AA10271@Sun.COM> To: ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Wed, 24 Aug 1994 19:32:20 EDT Subject: Re: (IPng) Service providers beware! Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Heartburn is too mild. Beware! Paying customers WILL NOT accept > renumbering as a consequence of changing service providers or > (even less likely) of Internet topology changes. If you plan to make > money out of IP6 service provision, don't accept the notion that > subscriber addresses may change readily. Otherwise..... NAT :-( I think we would accept renumbering IF (that's a big IF) it were easy enough. It's far too hard now with IPv4 to be acceptable to us, with >10,000 machines on our network. DHCP won't do the whole job either. It's not just the ordinary hosts that have to be taken care of, but also the routers, name servers, network management stations, gopher servers (for access restrictions), etc. etc. Roger Fajman Telephone: +1 301 402 4265 National Institutes of Health BITNET: RAF@NIHCU Bethesda, Maryland, USA Internet: RAF@CU.NIH.GOV ------------------------------------------------------------------------------ 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 Wed Aug 24 16:54:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19138; Wed, 24 Aug 94 16:54:11 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19130; Wed, 24 Aug 94 16:54:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14650; Wed, 24 Aug 94 16:51:14 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA12845; Wed, 24 Aug 94 16:51:01 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 25 Aug 1994 09:47:10 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Thu, 25 Aug 1994 09:50:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 25 Aug 1994 09:50:10 +1000 Date: Thu, 25 Aug 1994 09:50:10 +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 Aug 25 09:50:10 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 105009250894 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <105009250894*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: (IPng) geographically-dispersed locations.... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Most large organisations will have internal connections as well. Jeff Perry asked about organizations with multiple dispersed sites. If they have no interior connectivity, then there is no problem with them just being different sites served by (potentially) different providers. if they are internally connected, then previous mail applies. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ 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 Wed Aug 24 17:11:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19200; Wed, 24 Aug 94 17:11:31 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19194; Wed, 24 Aug 94 17:11:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15484; Wed, 24 Aug 94 17:08:33 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA16631; Wed, 24 Aug 94 17:08:12 PDT Message-Id: <9408250008.AA16631@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1419; Wed, 24 Aug 94 20:08:00 EDT Date: Wed, 24 Aug 94 19:57:17 EDT From: yakov@watson.ibm.com To: deering@parc.xerox.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Mon, 22 Aug 1994 16:59:25 PDT Steve, >An important cluster address is one that someone needs to send >packets to. If you need to send a packet to an entity associated with a particular address you need routing system to know how to get to this address. Which brings me to the question I asked Christian before -- what is the relationship between one or more cluster addresses assigned to a router and the routing information that the router advertises to other routers ? In other words, do you expect the routing system to carry reachability information to cluster addresses separate from the unicast reachability information, or would the routing system carry just unicast reachability information, and cluster reachability information would be derivable from the unicast reachability information ? 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 Wed Aug 24 17:21:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19216; Wed, 24 Aug 94 17:21:19 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19210; Wed, 24 Aug 94 17:21:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15878; Wed, 24 Aug 94 17:18:22 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA18646; Wed, 24 Aug 94 17:18:12 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14750(2)>; Wed, 24 Aug 1994 17:17:59 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 24 Aug 1994 17:17:54 -0700 To: yakov@watson.ibm.com Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) cluster addresses In-Reply-To: yakov's message of Wed, 24 Aug 94 16:57:17 -0800. <94Aug24.170807pdt.14829(3)@alpha.xerox.com> Date: Wed, 24 Aug 1994 17:17:38 PDT From: Steve Deering Message-Id: <94Aug24.171754pdt.12171@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yakov, > If you need to send a packet to an entity associated with a particular > address you need routing system to know how to get to this > address. Which brings me to the question I asked Christian before -- > what is the relationship between one or more cluster addresses > assigned to a router and the routing information that the > router advertises to other routers ? In other words, do you > expect the routing system to carry reachability information > to cluster addresses separate from the unicast reachability > information, or would the routing system carry just unicast > reachability information, and cluster reachability information > would be derivable from the unicast reachability information ? The latter. The support of cluster addresses does not require the distribution of any additional reachability information. That is the difference between cluster addresses and more general anycast addresses. Steve ------------------------------------------------------------------------------ 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 Wed Aug 24 18:47:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19420; Wed, 24 Aug 94 18:47:43 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19414; Wed, 24 Aug 94 18:47:35 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19416; Wed, 24 Aug 94 18:44:44 PDT Received: from bunyip.cc.uq.oz.au by Sun.COM (sun-barr.Sun.COM) id AA02701; Wed, 24 Aug 94 18:44:31 PDT Received: from clix.aarnet.edu.au by bunyip.cc.uq.oz.au with SMTP (PP); Thu, 25 Aug 1994 11:44:27 +1000 X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 25 Aug 1994 11:40:26 +1000 X400-Received: by /PRMD=AUSGOVDEFENCENET/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 25 Aug 1994 11:39:22 +1000 Date: Thu, 25 Aug 1994 11:39:22 +1000 X400-Originator: Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au X400-Recipients: IPNG@SUNROOF.ENG.SUN.COM X400-Mts-Identifier: [/PRMD=AUSGOVDEFENCENET/ADMD=TELEMEMO/C=AU/;40A 940825113753] X400-Content-Type: P2-1984 (2) Content-Identifier: 40A 940825113753 From: Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au Message-Id: <"40A 940825113753*"@MHS> To: IPNG@SUNROOF.Eng.Sun.COM (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: (IPng) NSAPs and GOSIP -Reply Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Kim Fenley - Comments to Jack Houldsworths' ********************* NSAP MAPPING AND GOSIP I detect a misunderstanding here, probably caused by a lack of International experience amongst the IETF fraternity. GOSIP does not only refer to US GOSIP. There are GOSIP organisations run by governments all around the World. UK is run by a Government Agency known as the Central Computer Technical Authority (CCTA). CCTA specifies an address structure which uses all 20 bytes of the NSAP. Government departments like the MOD specify this in tenders. They allow some TCP/IP but currently demand that it be replaced with OSI within 5 years. CCTA has collaborated with other GOSIP agencies throughout Europe and have created a European Procurement Handbook for Open Systems which is mandatory for procurement by public authorities within the European Economic Community for systems of value greater than 100000 ECUs (around 150K dollars USA). The figure could have changed slightly since I looked at it. Note that USA companies supplying in Europe have to conform. Australia and NZ have virtually copied UK GOSIP and I think it is mandatory for all Government spend, Alan Lloyd will fill you in no doubt. I also believe that a lot of private Corporations there are riding the Australian GOSIP wagon >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> First, the Australian Government has mandated the use of OSI in its contracts as the first preference, then in its Australian Governemt Guidelines for Open Systems (AGGOS) the order of preference of standards implementation is list thereafter. I recent times the Australian government has reitered this mandation. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So when you talk about GOSIP you have to explain which GOSIP you are talking about. You may be right about USA GOSIP but the others are right in line which is why so many people are bothered. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Secondly, this is exactly why I raised the issue of trashing the "res" field in the NSAP address when mapping to IPv6, as we in the Australian Defence Force will utilise some of this "reserve" space being the owners of an ICD though primarily based on the Australian GOSIP structure. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The Internet declared aim is to be recognised as an International Organization. If this is a realistic aim, IP6 design has to support Global addressing. It's not good enough to just make sure that USA GOSIP NSAP allocations are covered. Do not be outraged if the perception of Internet is that it is a USA based Organization if you do. Get the picture? Jack Houldsworth >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would like to raise another issue, 20 was not just plucked out of the air. ISO realised that the existing addressing scheme would run out some time. (as has IP addresses). It could have picked 16, and if my memory is right it was mooted at one point, but the view was taken that technolgy changes are rapid (as in the uptake of IP address) and systems are used in a way that was never visualised in the first place. So a comfortable size was choosen (not too excessive) to allow for scalability and extensibility in the future. It is my belief that the US DoD (and Allies) are moving towards OSI slowly too, and there are many statements from them is this regard - Military messaging will be X.400, and used solely after 2007 - ACP 123 (militarised X.400) as an example. The whole thrust is for ubiquitous communications and ease of interworking. It is only at the network layer that there are any differences between OSI and internet and they are small, 4 bytes. This is the "switch over" point for Internet and OSI. That is the only sticking point, and why? No one wants extensive tables and huge amounts of cashing in routers. The internet may be the future. But why bugger the Carrires (big money there) and governments and some large business. I raise business issue because of EDI and CALS initiatives. Even the US X.12 group are moving towards the ISO EDIFACT standard, even if slowly. 4 Bytes provides for change, no one wants yet another IPv7....9 etc Kim Fenley >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------ 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 Wed Aug 24 20:28:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19587; Wed, 24 Aug 94 20:28:05 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19581; Wed, 24 Aug 94 20:27:57 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22597; Wed, 24 Aug 94 20:25:07 PDT Received: from CU.NIH.GOV by Sun.COM (sun-barr.Sun.COM) id AA14943; Wed, 24 Aug 94 20:24:56 PDT Message-Id: <9408250324.AA14943@Sun.COM> To: atkinson@sundance.itd.nrl.navy.mil, ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Wed, 24 Aug 1994 23:22:26 EDT Subject: Re: (IPng) renumbering Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > As Mike and some others will already know, provider-based addressing does > not work well enough to be very sensible for sites with multiple > concurrent providers. NRL has about 8 major external providers of > IP service right now. Its unlikely that we'll ever get down to > just a single provider. Administrative burden and other factors make > provider-oriented addressing a non-starter for NRL and other similar > multi-homed sites. We have only one provider now (used to be two), but I can see us having multiple providers in the future. There's a fairly extensive discussion of alternatives for multi-homed customers in the Addressing Architecture document. ------------------------------------------------------------------------------ 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 Wed Aug 24 20:39:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19603; Wed, 24 Aug 94 20:39:59 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19597; Wed, 24 Aug 94 20:39:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22924; Wed, 24 Aug 94 20:37:01 PDT Received: from CU.NIH.GOV by Sun.COM (sun-barr.Sun.COM) id AA16122; Wed, 24 Aug 94 20:36:50 PDT Message-Id: <9408250336.AA16122@Sun.COM> To: bill.simpson@um.cc.umich.edu, ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Wed, 24 Aug 1994 23:34:21 EDT Subject: Re: (IPng) Rapid Automatic Renumbering Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Since we have adopted SIPP, we have adopted automatic renumbering. No > human intervention is required. The same packet that advertises the > routing service advertises the renumbering to the host. Renumbering the hosts is not enough. What renmumbers all the rest of the stuff, such as routers, name server data bases, network management station data bases, gopher server access control lists, etc. etc.? ------------------------------------------------------------------------------ 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 Wed Aug 24 21:04:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19630; Wed, 24 Aug 94 21:04:01 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19624; Wed, 24 Aug 94 21:03:46 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA23548; Wed, 24 Aug 94 21:00:55 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA18526; Wed, 24 Aug 94 21:00:41 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 25 Aug 1994 13:56:30 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Thu, 25 Aug 1994 13:58:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 25 Aug 1994 13:56:08 +1000 Date: Thu, 25 Aug 1994 13:56:08 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com, Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au, Bruce-Steer@saa.sa.telememo.au X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Aug 25 13:56:07 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 075613250894 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <075613250894*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Receipt Notification Requested) (Non Receipt Notification Requested) Cc: Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au (Non Receipt Notification Requested), Bruce-Steer@saa.sa.telememo.au (Non Receipt Notification Requested) Subject: (IPng) Multi-homed organizations, geographical constrain... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM There are some fairly amazing assumptions included in here as to how networks get addressed etc. In fact, if one looks at it from a superhighway or global network view, this is designing a network for the world based on narrow assumptions. I would assume many Providers operating in any number of overlapping 100km radius areas. I suppose the definition of a "Provider" may help. I would also assume that my internal network addressing would use the same plan as my Internet addressing. I would be loath to renumber, map and manage addresses while I would like control over my internal network addressing space. The assumption that 16 bytes and the proposed addressing scheme will meet the requirements of the world needs to be tested further. It may well meet the needs of the Internet but as the Internet is seen by many to be a potential forerunner to the super highway and as private network sizes and complexities will continue to grow, does the whole thing hold water? Is there a possiblity that the requirements and limitations of the Internet experience are creating a myopia? >> In the most common case, an organization with one internal addressing >> structure but more than one provider could have a natural assignment >> with at most one provider and the others would carry special announcements. >> this is obvious. >Obviously wrong. You don't understand how large 256^16 is. >See PS. >> there are advantages to being multi-homed, and there are costs. >And the cost should be minimized. >If, >> a natural assignment >> with at most one provider and the others would carry special announcements. >is enforced, I'm afraid there is no advantage. >> The model here is a hybrid - some part of the space is flat-routed, and >> within the provider-based subspace of IP6, traffic between "provider >>clusters" >No provider clusters please. We need a free selection of providers between >clusters. Masataka Ohta ------------------------------------------------------------------------ PS The following is a draft on provider-based, and at the same time, provider-independent address assignment plan with geographical restriction. The same will be posted posted for big-i for EID/locator discussion. PPS EID is a trademark of Noel Chiappa. ------------------------------------------------------------------------ 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 Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ 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 Wed Aug 24 22:22:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19673; Wed, 24 Aug 94 22:22:12 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19667; Wed, 24 Aug 94 22:22:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25225; Wed, 24 Aug 94 22:19:14 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA25772; Wed, 24 Aug 94 22:18:36 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 25 Aug 94 14:11:32 +0900 From: Masataka Ohta Message-Id: <9408250511.AA19412@necom830.cc.titech.ac.jp> Subject: Re: (IPng) Multi-homed organizations, geographical constrain... To: ipng@sunroof.Eng.Sun.COM Date: Thu, 25 Aug 94 14:11:29 JST Cc: (Receipt Notification Requested) (Non Receipt Notification Requested), Kim.Fenley@aditcs.cm-dimp.hqadf.defencenet.gov.au, Bruce-Steer@saa.sa.telememo.au In-Reply-To: <075613250894*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS>; from "Jeff.Latimer@FINANCE.ausgovfinance.telememo.au" at Aug 25, 94 1:56 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > There are some fairly amazing assumptions included in here as to how networks > get addressed etc. In fact, if one looks at it from a superhighway or global > network view, this is designing a network for the world based on narrow > assumptions. I would assume many Providers operating in any number of > overlapping 100km radius areas. I suppose the definition of a "Provider" may > help. What? To cover the entire Earth with 100Km radius areas, 17,000 areas are enough. And I discuss how to support 10^8 provider IDs. 10^8 is a lot larger than 17,000. OK? So, of course, at a specific point on Earth, a lot of providers, each having different provider IDs, may operate. > I would also assume that my internal network addressing would use the same plan > as my Internet addressing. I would be loath to renumber, map and manage > addresses while I would like control over my internal network addressing space. Fine. Do so. You can do so even with autoconfiguration. > The assumption that 16 bytes and the proposed addressing scheme will meet the > requirements of the world needs to be tested further. At least, unlike heavily-provider-dependent proposal, IPv4 is the real world test for my proposal. > It may well meet the > needs of the Internet but as the Internet is seen by many to be a potential > forerunner to the super highway and as private network sizes and complexities > will continue to grow, does the whole thing hold water? It is proved to be so at least up to 10^12 netowrks and 10^15 hosts. Masataka Ohta ------------------------------------------------------------------------------ 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 Wed Aug 24 22:34:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19709; Wed, 24 Aug 94 22:34:25 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19703; Wed, 24 Aug 94 22:34:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25528; Wed, 24 Aug 94 22:31:27 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA26709; Wed, 24 Aug 94 22:31:17 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA00125; Wed, 24 Aug 94 22:25:46 -0700 Received: by xirtlu.zk3.dec.com; id AA23885; Thu, 25 Aug 1994 01:25:30 -0400 Message-Id: <9408250525.AA23885@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Service providers beware! In-Reply-To: Your message of "Wed, 24 Aug 94 19:32:20 EDT." <9408242333.AA10271@Sun.COM> Date: Thu, 25 Aug 94 01:25:24 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From: "Roger Fajman" >Date: Wed, 24 Aug 1994 19:32:20 EDT >I think we would accept renumbering IF (that's a big IF) it were easy >enough. It's far too hard now with IPv4 to be acceptable to us, with > >10,000 machines on our network. DHCP won't do the whole job either. >It's not just the ordinary hosts that have to be taken care of, but >also the routers, name servers, network management stations, gopher >servers (for access restrictions), etc. etc. I think Roger's dose of a reality sandwich is a bell ringing to us. We need to make sure all the pieces work etc. etc. and not just think because we solve the runumbering for the network, router, and hosts we are done with the specification or prototype. We need to solve all the software systems dependent on addresses changing. We need to view this from a systems engineering perspective too, as an implementor comment. Gee as others have said and I have said privately to a few if we had been able to figure out EIDs and Locators all of this would be much simpler. /jim ------------------------------------------------------------------------------ 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 Wed Aug 24 23:02:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19742; Wed, 24 Aug 94 23:02:27 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19736; Wed, 24 Aug 94 23:02:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA26170; Wed, 24 Aug 94 22:59:30 PDT Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA29702; Wed, 24 Aug 94 22:59:18 PDT Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id BAA05265 for ipng@sunroof.Eng.Sun.COM; Thu, 25 Aug 1994 01:59:17 -0400 Date: Thu, 25 Aug 1994 01:59:17 -0400 From: Vadim Antonov Message-Id: <199408250559.BAA05265@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >OK.. I'll bite - is there room in the IPv6 framework for an EID? >Anybody working on a draft, or should I oil up my chainsaw and get to work? ;) Who needs EID anyway? After attacking many people at IETF in Toronto the only rationale i got was "it appears to be useful". --vadim ------------------------------------------------------------------------------ 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 Thu Aug 25 00:03:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19773; Thu, 25 Aug 94 00:03:02 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19767; Thu, 25 Aug 94 00:02:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA27747; Thu, 25 Aug 94 00:00:03 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA05196; Wed, 24 Aug 94 23:59:25 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10661; Thu, 25 Aug 1994 08:59:00 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA14015; Thu, 25 Aug 1994 08:58:59 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408250658.AA14015@dxcoms.cern.ch> Subject: Re: (IPng) millions of OSI products To: ipng@sunroof.Eng.Sun.COM Date: Thu, 25 Aug 1994 08:58:59 +0200 (MET DST) In-Reply-To: <3092.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Aug 24, 94 03:58:23 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1753 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, You can quote me (with reference to CLNP, not OSI in general please!) but note that Tony Li said 500,000 the other day. So we are in the same order of magnitude, which is good enough I think, until proof of the contrary. Brian >--------- Text sent by William Allen Simpson follows: > > > From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) > > > Brian Carpenter, could you please provide a detailed description of the > > > range and number of currently deployed NSAPs and their mapping into IPv6? > > > > Several people have tried to collect such information and failed. > > It is easy to get info on NSAP allocation schemes and very difficult > > to get info on deployed, running systems. I speak for what I know: > > the physics/space science DECnet is part way through its transition > > to DECnet/OSI and so (assuming we don't abort the transition for some > > reason) that is o(20K) nodes. > > > > I'll make an assertion: there are not more than 200,000 CLNP nodes > > in real operational use today. (Ignoring industrial PLCs running > > MAP over null CLNP; there could be millions of these but they clearly > > don't count.) Can anybody PROVE this assertion is false? > > > Thank you for the clear statement on the number of nodes. Interesting > that you have 10% of them. > > Until someone comes up with a contrary assertion with strong evidence, > I will be happy to quote you every time someone asserts there are > millions of deployed NSAP nodes. > > 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 > ------------------------------------------------------------------------------ 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 Thu Aug 25 00:53:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19801; Thu, 25 Aug 94 00:53:02 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19795; Thu, 25 Aug 94 00:52:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA29283; Thu, 25 Aug 94 00:50:05 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA12809; Thu, 25 Aug 94 00:49:50 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14318; Thu, 25 Aug 1994 09:32:10 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA15360; Thu, 25 Aug 1994 09:31:55 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408250731.AA15360@dxcoms.cern.ch> Subject: Re: (IPng) NSAPs and GOSIP -Reply To: ipng@sunroof.Eng.Sun.COM Date: Thu, 25 Aug 1994 09:31:55 +0200 (MET DST) In-Reply-To: <"40A 940825113753*"@MHS> from "Kim.Fenley@aditcs.cm-dimp.hqadf.defencenet.gov.au" at Aug 25, 94 11:39:22 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 686 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, All this is getting us nowhere. There were some inputs to the IPng decision process in favour of full NSAP support but nothing like enough to sway the consensus. The various GOSIPs, the air traffic proposal, and the CDPD proposal were all aired during this process. What we have as an action in the IP6 working group is to define a mapping for the mappable subset of NSAP space into IP6 space. The next draft on this will come as soon as Jim Bound and I can do it. If organizations want to continue using CLNP and full 20-byte NSAPs, good luck to them, but it is not IP6. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ 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 Thu Aug 25 01:39:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19819; Thu, 25 Aug 94 01:39:20 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19813; Thu, 25 Aug 94 01:39:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00365; Thu, 25 Aug 94 01:36:23 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA16526; Thu, 25 Aug 94 01:36:10 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 25 Aug 1994 18:32:21 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Thu, 25 Aug 1994 18:35:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 25 Aug 1994 18:34:53 +1000 Date: Thu, 25 Aug 1994 18:34:53 +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 Aug 25 18:34:52 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 523418250894 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <523418250894*/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) NSAPs and GOSIP -Reply Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Brian, Maybe you hear the voice of the disenfranchised when you hear this GOSIP talk. The GOSIP/NSAP camp were not really party to the IP6 process. You have made a technical decision that has an effect on us all and we can't understand the basis. What was asked for was simple, allow the address to be 20 bytes and be done with it. Everyone could easily get behind it. The only basis for not allowing 20 bytes is cache management, bandwidth etc. All technical issues of a capacity nature have way of being overcome by technology. That the decision was made that IP6 would be 16 bytes can be changed. The reasons that drive the decision could be communicated more clearly. It still appears arbitrary. Rather than take it or leave it why not work to concessus? Politically, the handling of the whole thing appear to be inept. Jeff Latimer >Folks, >All this is getting us nowhere. There were some inputs to the >IPng decision process in favour of full NSAP support but nothing >like enough to sway the consensus. The various GOSIPs, the air >traffic proposal, and the CDPD proposal were all aired during this >process. What we have as an action in the IP6 working group is >to define a mapping for the mappable subset of NSAP space into >IP6 space. The next draft on this will come as soon as Jim Bound >and I can do it. If organizations want to continue using CLNP >and full 20-byte NSAPs, good luck to them, but it is not IP6. >Regards, > Brian Carpenter (CERN) (brian@dxcoms.cern.ch) > voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ 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 Thu Aug 25 02:43:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19904; Thu, 25 Aug 94 02:43:34 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19898; Thu, 25 Aug 94 02:43:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA01686; Thu, 25 Aug 94 02:40:34 PDT Received: from wscn02.infn.it by Sun.COM (sun-barr.Sun.COM) id AA21403; Thu, 25 Aug 94 02:40:22 PDT Date: Thu, 25 Aug 1994 11:35:41 +0200 (WET-DST) From: GHISELLI@infn.it To: ipng@sunroof.Eng.Sun.COM Cc: GHISELLI@infn.it Message-Id: <940825113541.2080084c@infn.it> Subject: (IPng) some comments Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Some contribution from users... when we received the message announcing the Directorate recommendations on IPng, based on SIPP/16, we asked about the reasons of this choice, because reading the IPng requirements doc we did not understand. Now, going through the mailing list IPng, we argued that an important reason of the choice probably is that SIPP/16 has many aspects to be defined, whereas OSI-CLNP (on which TUBA is based) is already operative. This could be a good reason, provided that IPng will result in something better than OSI-CLNP. To achieve the goal of IPng better than OSI-CLNP, we consider very important the experience done with the existing OSI-CLNP networks, and this could also cause the future convergence of ISO-CLNP to IPng. Even not publicized, there are many OSI-CLNP networks in production and one of them is a research network in Europe, mainly used by the HEP community, as a result of DECnet transition (DEC and CISCO but also 3COM and Wellfleet should know about it). From the topological point of view, it consists of one european routing domain, running IS-IS (in some countries also I-ISIS), with about 200 L2, and 800 L1 routers. Even if it is not a 'big' network, we consider it a good benchmark for routing evaluation and address allocation solutions. Now let us make some comments on the document 'An Architecture for IPv6 Unicast Address Allocation'. Address format and administration (chapter 5) The proposals of 'address administration' are based on the assumption that 'service provider' and the present internet topology, mainly based on leased lines, have an important role also in the future of the network. In our opinion the development of the communication technology will promote 'virtual topologies', that will be mainly driven by the 'user needs' and by the new distributed applications with special bandwidth and QoS requirements. Probably the future network topology will be more meshed, backed up and variable than today. Moreover the huge network developments at site level, 'user driven', often are more complex than those at geographical level, and the users certainly don't like to change addresses only because of a different 'service provider' for geographical connectivity. In summary, from our point of view the users (or subscribers) have an important role in the network development, and we think better to assign addresses directly to them. Even if it will be easy to change address in the future, it is better to leave it as an optional feature. In any case which problems should have the provider in routing the user prefix instead of its prefix? Of course we consider very important to reduce the reachability information, and that could be done using geographical prefixes, they allow a consistent reduction of routing information. Hierarchical dynamic routing From our experience we have verified that in order to get an efficient hierarchical routing, it is necessary to define the routing entities like areas and domains with the appropriate size. From the document we have interpreted 'subnetwork' as an area. We assume that the subnet meaning is the same as in IPv4, i.e. one router with n interfaces should have n subnetworks defined and then n areas. If it is true, we think that it is not always a good way to define areas. Prefix allocation It is a good point not to waste address space with fields not directly related to the address, but we think convenient to define a 'format field' in order to allocate prefixes of different length to organizations on the bases of their size. The RARE document "RARE WG4 recommandations for NSAP address format for national research network organizations" describes an interesting proposal. Regards A.Ghiselli, C.Vistoli, D.salomoni INFN-CNAF ------------------------------------------------------------------------------ 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 Thu Aug 25 04:23:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19928; Thu, 25 Aug 94 04:23:21 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19922; Thu, 25 Aug 94 04:23:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03432; Thu, 25 Aug 94 04:20:21 PDT Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA01653; Thu, 25 Aug 94 04:20:09 PDT Message-Id: <9408251120.AA01653@Sun.COM> From: smb@research.att.com Received: by gryphon; Thu Aug 25 07:19:04 EDT 1994 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NSAPs and GOSIP -Reply Date: Thu, 25 Aug 94 07:19:03 EDT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Maybe you hear the voice of the disenfranchised when you hear this GOSIP talk. The GOSIP/NSAP camp were not really party to the IP6 process. I'm sorry, but you're wrong. The desire for GOSIP/NSAP compatibility was made, loudly and repeatedly, during the deliberations. In the end, a decision had to be made -- and it was for 16 bytes, fixed length. You may think it was wrong -- for that matter, I think it was wrong (though for other reasons), and I was on the directorate -- but it was made, and now we have to live with it. Of late, this list has just been rehashing the debates that should have (and did) take place before Toronto. Let's move on, and figure out how best to do the mappings and encapsulations. --Steve Bellovin ------------------------------------------------------------------------------ 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 Thu Aug 25 05:02:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19955; Thu, 25 Aug 94 05:02:32 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19949; Thu, 25 Aug 94 05:02:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA04090; Thu, 25 Aug 94 04:59:34 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA04898; Thu, 25 Aug 94 04:59:23 PDT To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) NSAP discussions Date: Thu, 25 Aug 94 12:55:25 GMT From: Ran Atkinson Message-Id: <9408251255.aa02538@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, et. al., There are a number of outright untruths being said on this list by various parties. This kind of disinformation is not helpful to the process. 1) OSI users were NEVER disenfranchised by the IETF process. The process was fully open and MANY OSI folks participated even though they had not previously participated in the Internet. Those whining now could easily have participated then had they wished to. I know that Jack in fact did participate along the way as a concerned individual. 2) Claims that the US DoD has a significant OSI installed base or any serious liklihood of moving to OSI are just plain FALSE. Even the plan for X.400 military messaging is floundering these days because the projected costs are way too high for most activities to be able to afford more than one X.400 address and terminal per command. Individual email will almost certainly continue to be based on either proprietary solutions (e.g. CCmail, MS-Mail) or on MIME/SMTP. DISA is profiling Internet protocols for DoD use and this time they are mostly just citing the RFCs and saying "do that". 3) Folks who have NSAP address space that is not mappable directly don't have to lose their internal address plan work. They just take the low order bits and keep them, substitute a new IPv6 routing prefix, and go. 4) I agree strongly with Brian Carpenter and Steve Bellovin that this discussion is just a rehash of prior discussions and there is little or no new data here. A decision has already been made and we must do the best we can with it. I for one think that 16 bytes is twice as large as we need and I know that 16 bytes is going to make my existing IPv4 radio networks hard to migrate to IPv6. (Hint: We tried but cannot use CLNP on those links because CLNP uses too much overhead). Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ 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 Thu Aug 25 05:02:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19967; Thu, 25 Aug 94 05:02:51 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19956; Thu, 25 Aug 94 05:02:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA04096; Thu, 25 Aug 94 04:59:49 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA04935; Thu, 25 Aug 94 04:59:38 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22213; Thu, 25 Aug 1994 13:59:35 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28762; Thu, 25 Aug 1994 13:59:32 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408251159.AA28762@dxcoms.cern.ch> Subject: Re: (IPng) NSAPs and GOSIP -Reply To: ipng@sunroof.Eng.Sun.COM Date: Thu, 25 Aug 1994 13:59:31 +0200 (MET DST) In-Reply-To: <523418250894*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> from "Jeff.Latimer@finance.ausgovfinance.telememo.au" at Aug 25, 94 06:34:53 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 933 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jeff, >--------- Text sent by Jeff.Latimer@finance.ausgovfinance.telememo.au follows: > > Brian, > > Maybe you hear the voice of the disenfranchised when you hear this GOSIP talk. > The GOSIP/NSAP camp were not really party to the IP6 process. I want to stop this thread but I can't let that by. The IPng process started 3 years ago or so and there have been CLNP defenders involved from the beginning. I personally was active in the Directorate in reminding people of the need for CLNP convergence and NSAP support. Several people who were closely involved in CLNP standardisation, and in (US) GOSIP definition, were in the process. Anybody with email who wanted to could join the discussion. None of the arguments I have seen in the last 3 weeks are new. I know, I used some of them myself. They didn't win, that's all. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ 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 Thu Aug 25 05:54:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20012; Thu, 25 Aug 94 05:54:16 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20006; Thu, 25 Aug 94 05:54:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05269; Thu, 25 Aug 94 05:51:18 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AB10339; Thu, 25 Aug 94 05:51:05 PDT Received: by rodan.UU.NET id QQxemd05537; Thu, 25 Aug 1994 08:51:04 -0400 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) 16 vs 20 bytes..... Date: Thu, 25 Aug 1994 08:51:04 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The primary reason that IPng addresses are 16 bytes long is BECAUSE they are IPng addresses and NOT CLNP NSAPs. There are those of us (me included) that still believe 8 bytes was actually enough to do whatever needed doing in the known universe, but 16 turned out to be a workable compromise between the 8-byters (who DO understand how big 256**8 really is) and those who either couldn't decided or wanted "lots more than 8". 16-byte addresses is the number around which the rough consensus congealed, and THAT is how we make these decisions. The notion that the NSAP community had no input is plain wrong. The IPng Area Directorate certainly included same, and a phenominal outreach effort was made to solicit requirements from the known universe. Go read the white papers that were submitted and see for yourself. The fact that some particular party wasn't explicitly invited is a non-starter. We don't work that way. To wit: "We don't believe in Kings, Presidents, or Voting. We believe in Rough Consensus and Running Code." Them what's wants to participate show up, and we assume them what don't show up don't care. The people participating made the decision and that's that. Come to think about it, it's hard to see how people not participating could make the decision. Oh well. -Mike O'Dell Resident Crank ------------------------------------------------------------------------------ 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 Thu Aug 25 05:59:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20024; Thu, 25 Aug 94 05:59:50 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20018; Thu, 25 Aug 94 05:59:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05467; Thu, 25 Aug 94 05:56:53 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA11070; Thu, 25 Aug 94 05:56:42 PDT Message-Id: <9408251256.AA11070@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5523; Thu, 25 Aug 94 08:56:40 EDT Date: Thu, 25 Aug 94 08:54:57 EDT From: yakov@watson.ibm.com To: deering@parc.xerox.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Wed, 24 Aug 1994 17:17:38 PDT Steve, >>..do you expect the routing system to carry reachability information >>to cluster addresses separate from the unicast reachability information, >>or would the routing system carry just unicast reachability information, >>and cluster reachability information would be derivable from the >>unicast reachability information ? > >The latter. The support of cluster addresses does not require the >distribution of any additional reachability information. Since you assume that cluster reachability information will be derivable from the unicast reachability information, what are the rules for deriving this information ? Specifically, what is the relationship between the set of unicast address prefixes that a router injects into the routing system and the set of cluster addresses associated with the router ? 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 Thu Aug 25 06:25:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20051; Thu, 25 Aug 94 06:25:21 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20045; Thu, 25 Aug 94 06:25:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA06139; Thu, 25 Aug 94 06:22:23 PDT Received: from nic.near.net by Sun.COM (sun-barr.Sun.COM) id AA14088; Thu, 25 Aug 94 06:22:12 PDT Received: from jcurran-ppp.near.net by nic.near.net id aa17195; 25 Aug 94 9:21 EDT X-Sender: jcurran@nic.near.net (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Aug 1994 09:22:05 -0400 To: ipng@sunroof.Eng.Sun.COM From: John Curran Subject: Re: (IPng) Re: Automatic Renumbering Message-Id: <9408250922.aa17195@nic.near.net> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 10:05 PM 8/23/94 -0400, bound@zk3.dec.com wrote: >Ouch this brings up heartburn for me. Today we have a class A address. >We pay a provider to route in/out. Why with IP6 is the model changing? >Or is it not changing? Why would a provider have anything to say about >anyones address. They just route packets. Hmm. Providers do a lot more than "just route packets", but that's a different discussion for a different mailing list. Jim, in order to "just route packets", providers need to maintain routing tables. These routing tables have a cost, and historically this cost was not directly visible to the organization connecting to the Internet. I imagine that sometime in the near future such costs _will_ be visible (or, at least, they will be visible to those organizations which contribute disproportionately to the size of the overall routing tables. :-) At that time, folks will have an incentive to not generate routing table entries... i.e. to renumber into the provider's address space. Software that supports autoconfiguration (and even better: auto-re-configuration) will be highly desired as a result. /John ------------------------------------------------------------------------------ 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 Thu Aug 25 06:56:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20104; Thu, 25 Aug 94 06:56:11 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20090; Thu, 25 Aug 94 06:56:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07058; Thu, 25 Aug 94 06:53:10 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA18040; Thu, 25 Aug 94 06:52:55 PDT Received: from skidrow.lkg.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA19734; Thu, 25 Aug 94 06:40:19 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA12915; Thu, 25 Aug 1994 09:42:30 -0400 Message-Id: <9408251342.AA12915@skidrow.lkg.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NSAPs and GOSIP -Reply In-Reply-To: Your message of "Thu, 25 Aug 94 18:34:53 +1000." <523418250894*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> Date: Thu, 25 Aug 94 09:42:30 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Content-Identifier: 523418250894 To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) >Brian, > >Maybe you hear the voice of the disenfranchised when you hear this GOSIP talk. ^^^^^^^^^^^^^^^ This is nonsense. The IETF process is open and and anyone who wanted to participate could do so. >The GOSIP/NSAP camp were not really party to the IP6 process. You have made a If, by their choice, they did not particpate, why should they be listened to now? >technical decision that has an effect on us all and we can't understand the >basis. What was asked for was simple, allow the address to be 20 bytes and be >done with it. Everyone could easily get behind it. Nonsense. It is quite possible that those, like myself, who believe that 8 bytes is adequte, would have gone off and started developing an incompatible IPng if more than 16 bytes were adopted. (Or if a variable length size were adopted. Note that the behaviour of various NSAP administrators in instantly grabbing use of every address byte they can get their hands on was one of the primary things that defeated variable length addresses.) >The only basis for not allowing 20 bytes is cache management, bandwidth etc. >All technical issues of a capacity nature have way of being overcome by >technology. So why not make if 40 or 80 or 160 bytes? 8 bytes would have been enough. The tiny number of NSAPs that have been deployed would fit in a small corner of an 8 byte address space. >That the decision was made that IP6 would be 16 bytes can be changed. The >reasons that drive the decision could be communicated more clearly. It still >appears arbitrary. Rather than take it or leave it why not work to concessus? >Politically, the handling of the whole thing appear to be inept. Nonsense. It was the consensus. I support 16 bytes as a compromise even though 8 is sufficient for the forseeable needs. What would you suggest would be more "ept"? Sounds to me like adopting as many OSIisms as practical, despite the obviousl failure of OSI, is the only thing that would make you happy. >Jeff Latimer Donald ------------------------------------------------------------------------------ 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 Thu Aug 25 07:12:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20154; Thu, 25 Aug 94 07:12:15 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20148; Thu, 25 Aug 94 07:12:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07574; Thu, 25 Aug 94 07:09:18 PDT Received: from CLYNN.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA20448; Thu, 25 Aug 94 07:09:07 PDT Message-Id: <9408251409.AA20448@Sun.COM> Date: Thu, 25 Aug 94 10:03:03 EDT From: Charles Lynn To: ipng@sunroof.Eng.Sun.COM Cc: CLynn@BBN.COM Subject: Re: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Valdis, I am working on a transition plan for NIMROD, in bothe the IPv4 and IPv6 contexts. I have not written anything detailed about IPv6 yet but am thinking along the lines of an end-to-end option for EIDs. I think that providing variable length EIDs, at least in syntax is better than trying to nail down a fixed length now. It seems that one could use a format of , but I am not an NSAP expert. I am interested in learning your thoughts. I do not think that there should be two flavors of eid in IPv6, but vanilla IPv6 might not embrace "extra bits" needed by NIMROD. Charlie ------------------------------------------------------------------------------ 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 Thu Aug 25 08:10:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20167; Thu, 25 Aug 94 08:10:44 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20161; Thu, 25 Aug 94 08:10:37 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA09751; Thu, 25 Aug 94 08:07:47 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA29863; Thu, 25 Aug 94 08:07:33 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA01931; Thu, 25 Aug 94 08:04:20 -0700 Received: by xirtlu.zk3.dec.com; id AA07973; Thu, 25 Aug 1994 11:04:08 -0400 Message-Id: <9408251504.AA07973@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NSAP discussions In-Reply-To: Your message of "Thu, 25 Aug 94 12:55:25 GMT." <9408251255.aa02538@sundance.itd.nrl.navy.mil> Date: Thu, 25 Aug 94 11:04:02 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ACK on Steve, Brian, and Ran. The decision was made lets move on. If pointers were not sent out of the IPng Area Directors presentation to the IETF plenary then can we post them to this list which are a nice view of the process. These should not be discussed here. Clarifications on what it means should be sent to the Area Directors directly not to this workiing group. We have techncial work to do and for example I think we need to digest and understand the recent input from HEPNET on subnets and also their network transition experience and the technical tradeoffs made. This is useful work for this group. Debating the decision is counter-productive to proposed dates for ipng base specs. I also think reviewing Jeff's idea of 16byte address structure is good work too. /jim ------------------------------------------------------------------------------ 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 Thu Aug 25 08:36:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20179; Thu, 25 Aug 94 08:36:28 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20173; Thu, 25 Aug 94 08:36:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10656; Thu, 25 Aug 94 08:33:31 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03618; Thu, 25 Aug 94 08:33:13 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA03506; Thu, 25 Aug 94 08:27:26 -0700 Received: by xirtlu.zk3.dec.com; id AA08908; Thu, 25 Aug 1994 11:27:14 -0400 Message-Id: <9408251527.AA08908@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: Automatic Renumbering In-Reply-To: Your message of "Thu, 25 Aug 94 09:22:05 EDT." <9408250922.aa17195@nic.near.net> Date: Thu, 25 Aug 94 11:27:08 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM John, >>Ouch this brings up heartburn for me. Today we have a class A address. >>We pay a provider to route in/out. Why with IP6 is the model changing? >>Or is it not changing? Why would a provider have anything to say about >>anyones address. They just route packets. >Hmm. Providers do a lot more than "just route packets", but that's a >different discussion for a different mailing list. Of course my response was based on my interaction as a customer of my use for providers. It was not mean't to be a negative comment. >Jim, in order to "just route packets", providers need to maintain routing >tables. These routing tables have a cost, and historically this cost was >not directly visible to the organization connecting to the Internet. >I imagine that sometime in the near future such costs _will_ be visible >(or, at least, they will be visible to those organizations which contribute >disproportionately to the size of the overall routing tables. :-) At that >time, folks will have an incentive to not generate routing table entries... >i.e. to renumber into the provider's address space. Software that supports >autoconfiguration (and even better: auto-re-configuration) will be highly >desired as a result. I have no problem with paying for connections in the future or today to get what I need as a path to a site I am doing business with. In fact I like the idea of competition for providers so I can dump the one I have if they are too expensive or the service is not what I need. Its like the effect of Open Systems Software on hosts. If a customer demands Open Systems for all hosts then if a particular vendor does something they don't like they just stop using that vendor and move the applications to another Open System vendor. I like everything about Open Systems cause it causes a level playing field for competition. But I digress. So I think renumbering is important. But what I think is more important is that any perceived technology requirements be weighted against other requirements and then the affect of the technical integration on those systems be reviewed at the deepest technical levels with extreme attention to detail. Renumbering will affect DNS, Autoconfiguration, Routing Architecture, Services from servers like our Remote Installtion Software (RIS), bootp, system discovery, and I am sure much more. As others and I have stated (essentially) we cannot slam dunk this without understanding the effect on the Total System. This includes all aspects of the work at hand for IP6. So lets just do it and get on with it and see if we can figure it out. So how does DNS get updated during renumbering? I am thinking about this now I hope others are too. The point is that those proposing renumbering can't say we will figure that out later, this is unacceptable. /jim ------------------------------------------------------------------------------ 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 Thu Aug 25 09:13:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20195; Thu, 25 Aug 94 09:13:10 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20189; Thu, 25 Aug 94 09:13:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12222; Thu, 25 Aug 94 09:10:13 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA10001; Thu, 25 Aug 94 09:09:39 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Thu, 25 Aug 1994 17:07:31 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Thu, 25 Aug 1994 17:03:29 +0100 Date: Thu, 25 Aug 1994 17:03:29 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003565] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3565 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3565*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <3092.bill.simpson@um.cc.umich.edu> Subject: RE: Re: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Don't assume all the NSAP users are running CLNP. We have been shipping X.25 connection oriented stuff for years and lots of X.25 users are planning to replace their connection oriented systems with router systems. You know, it doesn't do much for your image to advertise the fact that you prefer to listen to the guy who gives you the answers you want to hear - that's not very scientific. The only way to find out the real answer is to send out a questionaire to all NSAP issuing agencies like BSI asking how many users have been granted a DCC allocation, how many of these are using the full 20 byte spread and how many nodes they each have. I will try and obtain some scientific information of this kind. Jack Houldsworth ------------------------------------------------------------------------------ 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 Thu Aug 25 09:55:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20303; Thu, 25 Aug 94 09:55:49 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20030; Thu, 25 Aug 94 06:00:12 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05490; Thu, 25 Aug 94 05:57:21 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA11047; Thu, 25 Aug 94 05:56:31 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA21008; Thu, 25 Aug 1994 13:50:04 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA00620; Thu, 25 Aug 94 09:48:35 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00449; Thu, 25 Aug 1994 09:48:34 EST Date: 15 Aug 94 12:58:39 +1000 To: ipng@sunroof.Eng.Sun.COM (Receipt Notification Requested) Subject: (IPng) COMMENTS ON IPNG Ua-Content-Id: 940815 11:36:05 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940815 11:36:05 031 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940815125839+1000 deferred 940815125839+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940825094746+1000 deferred 940825094746+1000 action Relayed Message-Id: <"940815 11:36:05"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gentlemen... I am somewhat associated with the development of OSI and large scale carrier, defence and govt networks and have just seen the documents from brian@ SUN released on IPNG and its new address forms and inclusion of NSAPs.. Oh dear! >From an overall perspective I am concerned why 16 byte addressing has been chosen What is the rationale for this knowing that OSI uses 20 bytes? The comments in the document associated with applying NSAPAs to the 16 byte form is certainly US and Internet centric (as one would expect). However, perhaps the following should be observed. Networks have been for some time and still ARE being designed with full length NSAPs and therefore need the full 20 byte form. NSAP Structure -- It is more than just "20 bytes". The NSAP format provides an ISO agreed routing hierarchy which is also related to the administration hierarchy of countries, authorities, sub registration authorities (SRAs) and Sub RAS (SSRAs).. These have been formally established within countries and large organisations. With ISO NSAPS we can design globally ready networks for national infrastructure (ie. global infrastructure).. eg. for aviation, defence, transport systems because we can logically address aircraft, tactical units, ships - emergency vehicles, etc. AND this design, allocation and implementation process has started.. NSAPs are also configured into millions of OSI products such as routers, switches, X.400, X.500 and X.700 systems - in fact these last application level products have to be configured to evaluate the data syntax (not just bitstring compare) of NSAPs to do searches and check for equivalence... etc. There are many ITU documents contain definitions of NSAPs.. eg X.300 (Network Interworking), Q.2931 (ISDN and B-ISDN signalling) and X.25 facilities as well as all the X.500 and X.700, CLNP/ES-IS and IS-IS code and documents that reside on this planet.. So with all this in place.. why is IPNG is now planning to have ANOTHER NSAP format. It is not just a question that US GOSIP does not use NSAPs widely.. Or that one can truncate 20 bytes into 16 because of perceived unused fields. IT is a question of the extra cost in implementing code and configuration tools in every piece of internetworking equipment.. and X.400 messaging, X.500 directory systems and X.700 management systems right across the planet to deal with two formats of the same information. Plus many people will have to deal with two network design methodologies and possibly address registration facilities. Given the assumption that the Internet and every TCP/IP product will have to be upgraded to adopt IPNG.. ($BBBB) Is the IETF also requesting that all the OSI products and documents in existance etc are also upgraded to cater for two forms of NSAPs. AS there will be no single network out there which will escape OSI NSAPs or interworking with IPNG. Is it not more logical to adopt 20 byte addressing in IPNG NOW and then utilise an ICD for the Internet (as do other global and national organisations) and permit sub division of the Internet space within this ie.. an RD for 4 byte addressing and RDs for logical components of the bigger Internet. Where broadcast and other "internetwork" features are required other fields can be used .. eg.. NSEL at the low end if that is appropriate or identification in the routing domain .. if the higher level broadcasting is used. On a small point.. the comment that NSEL is not required because TCP/UDP do not use it.. Is it not possible that voice, video and image could be transferred over IPNG in the future and this could have "network service" selection requirements.. In closing .. and not being party to the initial decision.. Please can you inform me why the 16 byte addressing scheme has been chosen when the Internet has to be reconfigured anyway.. Is there any reason why the Internet addressing cannot just be structured as an independent ICD with a field set aside for indicating backwards compatibility or broadcast features? What are the issues with NSAPs and IPNG.. eg is an option that the 16 bytes could be used and another 4 as address extensions... as per X.25 facilities? and then the whole NSAP (as defined by ISO and the ITU) will fit correctly and be compatible. Regards Alan Lloyd alan@datacraft.oz.au X.400 G=alan;s=lloyd;o=dcthq;p=datacraft;a=telememo;c=au ------------------------------------------------------------------------------ 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 Thu Aug 25 09:57:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20315; Thu, 25 Aug 94 09:57:44 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20309; Thu, 25 Aug 94 09:57:37 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA12281; Thu, 25 Aug 1994 09:54:53 -0700 Date: Thu, 25 Aug 1994 09:54:53 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <9408251654.AA12281@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9408250731.AA15360@dxcoms.cern.ch> Subject: Re: (IPng) NSAPs and GOSIP -Reply Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Brian, > process. What we have as an action in the IP6 working group is > to define a mapping for the mappable subset of NSAP space into > IP6 space. The next draft on this will come as soon as Jim Bound > and I can do it. If organizations want to continue using CLNP > and full 20-byte NSAPs, good luck to them, but it is not IP6. I agree that this the the correct course of action. Looking forward to the new document. Bob ------------------------------------------------------------------------------ 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 Thu Aug 25 10:25:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20399; Thu, 25 Aug 94 10:25:24 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20387; Thu, 25 Aug 94 10:25:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15186; Thu, 25 Aug 94 10:22:23 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA21849; Thu, 25 Aug 94 10:21:14 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Thu, 25 Aug 1994 18:10:53 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Thu, 25 Aug 1994 18:06:34 +0100 Date: Thu, 25 Aug 1994 18:06:34 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003577] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3577 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3577*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9408251120.AA01653@Sun.COM> Subject: RE: Re: (IPng) NSAPs and GOSIP -Reply Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I don't know where the NSAP/16 debate took place during the run up to the announcement in Toronto but I only heard about it by the grace of Scott Bradner about a week before the meeting when he contacted me by 'phone. It was not tested on the ISO people and I suspect that it came as a major surprise (if not a shock) to the OSI community outside the USA. Indeed the compression bodge' was still being worked out at the meeting and even Brian Carpenter declared that he was unsure that it would be feasible. The current proposal was not circulated until after Toronto. I have said several times that it would be a great pity if the IETF, which is seeking to sanitise its image as an international organisation, is perceived to be telling the International community to 'take it or leave it - we have decided what's best for you'. This would be a clear statement of UDI and a disenfranchisement. I suspect that there are a few who feel that way but I believe that the majority are behind what is best for the International IT community. I hope that debate of the key issue of NSAPs will continue until the real requirements are clarified in a non-polarised fashion. In my book it is the only major hang up that the OSI community has right now with the SIPP scenario. With the right compromises we can all be back on track and working together. It then will not matter what the ratio of OSI to TCP/IP is because we can add all the numbers together to establish the number of potential users of the new IP6 platform. Jack Houldsworth ------------------------------------------------------------------------------ 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 Thu Aug 25 10:25:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20400; Thu, 25 Aug 94 10:25:29 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20393; Thu, 25 Aug 94 10:25:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15189; Thu, 25 Aug 94 10:22:27 PDT Received: from by Sun.COM (sun-barr.Sun.COM) id AB21849; Thu, 25 Aug 94 10:22:15 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Thu, 25 Aug 1994 18:11:52 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; Relayed; Thu, 25 Aug 1994 18:09:15 +0100 Date: Thu, 25 Aug 1994 18:09:15 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003578] X400-Content-Type: P2-1984 (2) Content-Identifier: 3578 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3578*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9408251159.AA28762@dxcoms.cern.ch> Subject: RE: Re: (IPng) NSAPs and GOSIP -Reply Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM There are no triumphant victors Brian. Jack ------------------------------------------------------------------------------ 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 Thu Aug 25 12:11:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20594; Thu, 25 Aug 94 12:11:03 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20588; Thu, 25 Aug 94 12:10:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20016; Thu, 25 Aug 94 12:08:05 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA17179; Wed, 24 Aug 94 10:09:47 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 25 Aug 94 02:02:35 +0900 From: Masataka Ohta Message-Id: <9408241702.AA15791@necom830.cc.titech.ac.jp> Subject: Re: (IPng) Rapid Automatic Renumbering To: ipng@sunroof.Eng.Sun.COM Date: Thu, 25 Aug 94 2:02:34 JST In-Reply-To: <3091.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Aug 24, 94 3:35 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The trust relationship is simple -- if you trust the router to whom you > are sending packets, you can trust the renumbering. The problem is that, if ID of the router I trust changes because of renumbering, I can't identify the router to whom I was sending packets without knowing how the renumbering was. > The connection can certainly be reliably renumbered, with an > AUTHENTICATED message, which has already been defined. Authentication > is a required element of IPv6. How, do you think, the authentication relationships can be established? Isn't it through secure DNS mapping from IP address to host public key? What happens to DNS if IP address changes once per a second? Masataka Ohta ------------------------------------------------------------------------------ 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 Thu Aug 25 12:14:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20606; Thu, 25 Aug 94 12:14:39 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20600; Thu, 25 Aug 94 12:14:33 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20219; Thu, 25 Aug 94 12:11:42 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA10632; Thu, 25 Aug 94 12:11:19 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA18132; Thu, 25 Aug 94 11:17:16 -0700 Received: by xirtlu.zk3.dec.com; id AA20977; Thu, 25 Aug 1994 14:17:01 -0400 Message-Id: <9408251817.AA20977@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NSAPs and GOSIP -Reply In-Reply-To: Your message of "Thu, 25 Aug 94 18:09:15 BST." <"3578*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> Date: Thu, 25 Aug 94 14:16:55 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, How about CLNP could not cut it as a network protocol for the Information Highway and we took the best we could from all ideas using he SIPP protocol as a basis to begat that work. This is not a reflection of OSI or CLNP its a matter of evolution. Also I remind you that TCP/IP6 is the real victor here for the Internet (not necessarily for private enterprise that remains to be proven). /jim ------------------------------------------------------------------------------ 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 Thu Aug 25 12:52:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20654; Thu, 25 Aug 94 12:52:57 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20648; Thu, 25 Aug 94 12:52:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22074; Thu, 25 Aug 94 12:49:59 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA16764; Thu, 25 Aug 94 12:48:50 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA23221; Thu, 25 Aug 94 12:42:38 -0700 Received: by xirtlu.zk3.dec.com; id AA24997; Thu, 25 Aug 1994 15:42:23 -0400 Message-Id: <9408251942.AA24997@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NSAPs and GOSIP -Reply In-Reply-To: Your message of "Thu, 25 Aug 94 14:16:55 EDT." <9408251817.AA20977@xirtlu.zk3.dec.com> Date: Thu, 25 Aug 94 15:42:17 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, I just got to say this too. I spent 7 years of my life working on MAP and POSIX in the dejure stds committees, wrote code for some of this, and even championed them and long before my present employer. And what have I seen lots of revenue streams for TCP/IP, DECnet, SNA, and IPX. And lots of end systems supporting protocols. Now lets talk APIs and system services. What have I seen Sockets, XTI, X/Open Work, WINsockets, CORBA, OSF and Sun RPCs, NFS, quipo making X.400 and X.500 more available, MIT X11/Kerberos, Microsoft Windows, and hosts of vendor consortia solve real customer problems. I even once did a couple of X3 committees so I know the process. My point is what has ISO or its associatives done that is widespread where the IT vendors you speak of have together (not individually) made billions of dollars (not millions). I think this forum causes the first need then it appears in the more ad hoc groups like X/Open, IETF, or vendor consortia go off and make it happen. Mabye ISO should be coming to the IETF to learn how to produce widespread standards in use on a wide scale and learn what they could do better too. And the IETF can learn how to deal with International concerns but please don't try and tell IPng or the IETF that we have something to learn from ISO about effective standarization of protocols. I am not sure I can believe this at all. I am very interested in your scientfic data for sure. /jim ------------------------------------------------------------------------------ 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 Thu Aug 25 23:52:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21047; Thu, 25 Aug 94 23:52:38 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21041; Thu, 25 Aug 94 23:52:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA17751; Thu, 25 Aug 94 23:49:39 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA26826; Thu, 25 Aug 94 23:49:28 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA15635; Fri, 26 Aug 1994 08:49:26 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA06386; Fri, 26 Aug 1994 08:49:24 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408260649.AA06386@dxcoms.cern.ch> Subject: Re: Re: (IPng) NSAPs and GOSIP -Reply To: ipng@sunroof.Eng.Sun.COM Date: Fri, 26 Aug 1994 08:49:23 +0200 (MET DST) In-Reply-To: <"3578*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> from "J.Houldsworth@ste0906.wins.icl.co.uk" at Aug 25, 94 06:09:15 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 331 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > There are no triumphant victors Brian. > Jack > I hope I didn't write something that read like that; if it did, I'm sorry. I'll say again: my site exchanges more than 80 Gbytes a month of CLNP packets with the outside world (as well as more than 400 Gbytes of IPv4). I felt reasonably unprejudiced in this debate. Brian ------------------------------------------------------------------------------ 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 Fri Aug 26 03:02:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21263; Fri, 26 Aug 94 03:02:12 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21257; Fri, 26 Aug 94 03:02:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA21670; Fri, 26 Aug 94 02:59:11 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA15754; Fri, 26 Aug 94 02:58:46 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Fri, 26 Aug 1994 10:57:58 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Fri, 26 Aug 1994 10:48:24 +0100 Date: Fri, 26 Aug 1994 10:48:24 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003583] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3583 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3583*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9408251942.AA24997@xirtlu.zk3.dec.com> Subject: RE: Re: (IPng) NSAPs and GOSIP -Reply Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, Two answers: First message: I already agreed that SIPP would do as a compromise solution but not without the ability to carry the already installed base NSAPs in some way - even an extended address option would do. ISO would almost certainly cooperate with an ongoing scenario of that type and it would stop all the rhetoric and get us back on track to work on the real issues. Second message: It is getting counterproductive to keep talking about the commercial success of TCP/IP, which is undoubtedly true. This is claimed to be due to technical superiority but we all know that the real reason for the success of TCP/IP was that it came free with UNIX and some major suppliers (no finger pointing) charged an arm and a leg for OSI, thereby shooting it in the remaining foot. Most shipments in the early days were closed TCP/IP systems, usually client server and went nowhere near the Internet. Having said all that, the rest is history and we should be looking at the way forward. Remember, this time the parameters are different. There may not be a premium charge for having OSI in preference to IP6 and OSI users will therefore continue to upgrade. We suppliers will have to service two main line protocols and that sure as hell costs. What I'm shooting for is convergence, which means that we can get the number of alternatives down. To do this we need to grease the wheels a bit - only a bit! Sticking out against the ability to carry the last 4 bytes of NSAP, which would crack the whole problem is so bizarre and so hard to believe. It would also buy the Internet a lot of international credibility - for which I know it craves. Jack ------------------------------------------------------------------------------ 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 Fri Aug 26 03:50:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21277; Fri, 26 Aug 94 03:50:08 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21271; Fri, 26 Aug 94 03:49:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22404; Fri, 26 Aug 94 03:47:07 PDT Received: from runix.runit.sintef.no by Sun.COM (sun-barr.Sun.COM) id AA21888; Fri, 26 Aug 94 03:46:49 PDT Received: from runit.sintef.no by runix.runit.sintef.no id <26615-0@runix.runit.sintef.no>; Fri, 26 Aug 1994 12:45:52 +0200 Date: Fri, 26 Aug 1994 12:45:49 +0200 (MET DST) From: Steinar Haug Subject: RE: Re: (IPng) NSAPs and GOSIP -Reply To: J.Houldsworth@ste0906.wins.icl.co.uk Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <"3583*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> Message-Id: 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 > It is getting counterproductive to keep talking about > the commercial success of TCP/IP, which is undoubtedly > true. I agree, it does not get us any further. > This is claimed to be due to technical > superiority but we all know that the real reason for > the success of TCP/IP was that it came free with UNIX > and some major suppliers (no finger pointing) charged > an arm and a leg for OSI, thereby shooting it in the > remaining foot. No, we do not all "know" this. I certainly disagree strongly with such a characterization. To my mind the some of the reasons for the failure of OSI (and the success of TCP/IP) are the following: - OSI standards are unnecessarily complex, and full of features which are thrown in to reach a compromise between all parties on the standards committee - but which are later not used. - OSI has a long history of standardization before implementation. In the Internet environment, protocols aren't standardized until it is known that they actually can be implemented! - In the OSI world, formal conformance testing is important. Unfortunately, this doesn't ensure interoperability. In the Internet world, testing for interoperability comes first. None of the points mentioned above are particularly new - it's all been said before. But when you come out with statements like "we all know..." above, you should expect reactions. Steinar Haug, SINTEF RUNIT ------------------------------------------------------------------------------ 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 Fri Aug 26 05:21:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21295; Fri, 26 Aug 94 05:21:13 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21289; Fri, 26 Aug 94 05:21:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA23986; Fri, 26 Aug 94 05:18:13 PDT Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA27456; Fri, 26 Aug 94 05:18:01 PDT Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.4/8.6.4) with ESMTP id IAA05475 for ; Fri, 26 Aug 1994 08:17:59 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.4/8.6.4) with SMTP id IAA21935 for ; Fri, 26 Aug 1994 08:17:58 -0400 Received: from grid (bobsgrid.clis.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA01009; Fri, 26 Aug 94 08:24:39 EDT Message-Id: <9408261224.AA01009@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 Aug 1994 08:18:06 -0500 To: ipng@sunroof.Eng.Sun.COM From: RGMoskowitz-3@is.chrysler.com (Robert Moskowitz) Subject: Re: (IPng) Multi-homed organizations X-Mailer: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >In the most common case, an organization with one internal addressing >structure but more than one provider could have a natural assignment >with at most one provider and the others would carry special announcements. >this is obvious. I submit that the most common case is within a organizational entity, one group routes through one provider and another through a different. Of course, I doubt that there is anyway to collect stats on this. And the internal routing needs to be prioritized over the external routing. Normally. Thus somewhere in our addressing model we have failed. Or perhaps, our real failure is in including routing with addressing so that every connection for an aggregate address has the same routing. Perhaps the cluster address might be the answer? That is I use my regular address for internal use, but a cluster address from a providers space for external access? This might be interesting for the internal routers, although the cluster addresses would colapse in this case to a single entry pointing at the egress router... Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ 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 Fri Aug 26 05:41:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21316; Fri, 26 Aug 94 05:41:17 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21310; Fri, 26 Aug 94 05:41:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24353; Fri, 26 Aug 94 05:38:17 PDT Received: from ecrc.de by Sun.COM (sun-barr.Sun.COM) id AA28901; Fri, 26 Aug 94 05:37:50 PDT Received: from scorpio.ecrc.de by ecrc.de with SMTP id AA07660 ( for ); Fri, 26 Aug 1994 14:37:46 +0200 Received: from acrab25.ecrc.de by scorpio.ecrc.de (4.1/SMI-3.2) id AA02069; Fri, 26 Aug 94 14:37:45 +0200 Date: Fri, 26 Aug 94 14:37:45 +0200 From: Dave Morton Message-Id: <9408261237.AA02069@scorpio.ecrc.de> To: ipng@sunroof.Eng.Sun.COM Subject: RE: Re: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Don't assume all the NSAP users are running CLNP. We > have been shipping X.25 connection oriented stuff for > years and lots of X.25 users are planning to replace > their connection oriented systems with router systems. > You know, it doesn't do much for your image to > advertise the fact that you prefer to listen to the guy > who gives you the answers you want to hear - that's not > very scientific. > > The only way to find out the real answer is to send out > a questionaire to all NSAP issuing agencies like BSI > asking how many users have been granted a DCC > allocation, how many of these are using the full 20 > byte spread and how many nodes they each have. > > I will try and obtain some scientific information of > this kind. For what it's worth I just went through the DFN list of allocated NSAPs - I counted 86 in total. How many of these are actually being used I couldn't say. Dave Morton ECRC ------------------------------------------------------------------------------ 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 Fri Aug 26 06:04:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21355; Fri, 26 Aug 94 06:04:19 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21349; Fri, 26 Aug 94 06:04:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24900; Fri, 26 Aug 94 06:01:12 PDT Received: from ftp.com (wd40.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA01263; Fri, 26 Aug 94 06:00:47 PDT Received: from ftp.com by ftp.com ; Fri, 26 Aug 1994 09:00:46 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 26 Aug 1994 09:00:46 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA21518; Fri, 26 Aug 94 08:58:03 EDT Date: Fri, 26 Aug 94 08:58:03 EDT Message-Id: <9408261258.AA21518@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) NSAPs and GOSIP And ISO and IP and... From: kasten@ftp.com (Frank Kastenholz) Content-Length: 395 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Here are three thoughts on this whole topic: 1. Why don't the IETF-based "All ISO efforts are wastes time" people go find someplace else to bash the ISO. 2. Why don't all the ISO-based "When is the IETF going to grow up and start acting like an adult" people go find someplace else to scold the IETF. 3. Why don't the rest of us stay here and do useful work. -- Frank Kastenholz ------------------------------------------------------------------------------ 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 Fri Aug 26 06:13:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21367; Fri, 26 Aug 94 06:13:26 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21361; Fri, 26 Aug 94 06:13:19 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25140; Fri, 26 Aug 94 06:10:27 PDT Received: from frostbite-falls.uoregon.edu by Sun.COM (sun-barr.Sun.COM) id AA02252; Fri, 26 Aug 94 06:10:16 PDT Received: (meyer@localhost) by frostbite-falls.uoregon.edu (8.6.9/8.6.5.Beta7) id GAA02149; Fri, 26 Aug 1994 06:10:08 -0700 Message-Id: <199408261310.GAA02149@frostbite-falls.uoregon.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NSAPs and GOSIP And ISO and IP and... In-Reply-To: kasten@ftp.com's message of Fri, 26 Aug 1994 08:58:03 -0400. <9408261258.AA21518@mailserv-D.ftp.com> X-Btw: ns.uoregon.edu is phloem.uoregon.edu X-Mailer: exmh version 1.5gamma 8/15/94 Date: Fri, 26 Aug 1994 06:10:08 -0700 From: "David M. Meyer 503/346-1747" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Frank, >> Here are three thoughts on this whole topic: Thanks for injecting some sanity. Dave ------------------------------------------------------------------------------ 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 Fri Aug 26 06:17:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21379; Fri, 26 Aug 94 06:17:55 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21373; Fri, 26 Aug 94 06:17:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25295; Fri, 26 Aug 94 06:14:56 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AB03005; Fri, 26 Aug 94 06:14:43 PDT Received: from relay.imsi.com by wintermute.imsi.com id JAA15119 for ; Fri, 26 Aug 1994 09:14:41 -0400 Received: from snark.imsi.com by relay.imsi.com id JAA13769 for ; Fri, 26 Aug 1994 09:14:40 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA06194; Fri, 26 Aug 94 09:14:40 EDT Message-Id: <9408261314.AA06194@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NSAPs and GOSIP -Reply In-Reply-To: Your message of "Fri, 26 Aug 1994 10:48:24 BST." <"3583*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> X-Reposting-Policy: redistribute only with permission Date: Fri, 26 Aug 1994 09:14:39 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM J.Houldsworth@ste0906.wins.icl.co.uk says: > It is getting counterproductive to keep talking about > the commercial success of TCP/IP, which is undoubtedly > true. This is claimed to be due to technical > superiority but we all know that the real reason for > the success of TCP/IP was that it came free with UNIX > and some major suppliers (no finger pointing) charged > an arm and a leg for OSI, thereby shooting it in the > remaining foot. This is the IPng mailing list. If people would like to discuss what protocols are best and why they've done as they have in the marketplace, perhaps a separate mailing list could be set up for this discussion. However, at this point, on this mailing list, there is work to be done on IPv6. > It would also buy the Internet a lot of international > credibility - for which I know it craves. I don't think the internet craves very much -- its a large number of wires, and programs. Its users, such as myself, are by and large happy, and have real work to do, which we would like to get on with. Perry ------------------------------------------------------------------------------ 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 Fri Aug 26 07:08:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21414; Fri, 26 Aug 94 07:08:52 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21408; Fri, 26 Aug 94 07:08:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA26711; Fri, 26 Aug 94 07:05:54 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA09605; Fri, 26 Aug 94 07:05:40 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA10739; Fri, 26 Aug 94 06:57:36 -0700 Received: by xirtlu.zk3.dec.com; id AA05324; Fri, 26 Aug 1994 09:56:21 -0400 Message-Id: <9408261356.AA05324@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NSAPs and GOSIP -Reply In-Reply-To: Your message of "Fri, 26 Aug 94 10:48:24 BST." <"3583*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> Date: Fri, 26 Aug 94 09:56:13 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, > First message: > > I already agreed that SIPP would do as a compromise >> solution but not without the ability to carry the > already installed base NSAPs in some way - even an > extended address option would do. ISO would almost > certainly cooperate with an ongoing scenario of that > type and it would stop all the rhetoric and get us back > on track to work on the real issues. OK. I think the IESG and IAB can work this issue as far as I am concerned a decision has been made and it will not be changed on this mail list. I am going to go begin building IP6. In addition you will see an NSAP draft real soon. I do not think futhter discussion is productive on my end. We can pick it up with the NSAP draft. >Second message: >It is getting counterproductive to keep talking about >the commercial success of TCP/IP, which is undoubtedly >true. This is the bottom line TCP/IP is a commercial success and money talks. >Sticking out against the ability to carry the last 4 >bytes of NSAP, which would crack the whole problem is >so bizarre and so hard to believe. Again this has pro and con technical arguments. This has all been discussed and the Area Directors provided archives of the discussion. > It would also buy the Internet a lot of international > credibility - for which I know it craves. This IMHO has already happened based on deployment I see for TCP/IP products in Europe and Pacrim, and customer inquiry for our firewall product for the Internet. But I agree with you there needs to be the political signoff somewhere in the International community with the Internet Society and then the IETF. I think this is beyond the scope of this working group. IMHO this won't get resolved and IP6 will just get deployed Internationally. But I hope ISO and the IETF can work together to reach a common political ground but I doubt 16bytes will be changed to 20 bytes to make this happen. If customers say they want IP6 vendors will build it, if customers say they want OSI new features vendors will build it, if customers want to migrate from OSI to IP6 vendors will make it happen, if customers want machines in their environment to shine their shoes and it is "profitable" vendors will build it. There is a relationship between the vendor and the customer that has nothing to do with the IETF or ISO. If the customer can use a standard to leverage their business need they require it of the vendor. Regardless of what ISO or the IETF do vendors will build products that solve customer problems. If IP6 does not solve a customer problem mine and others work to build software to test IP6 and build code base that can be the initial software for IP6 will just sit on a shelf. What we do care about as vendors is that the specifications are technically accurate and are implementable. Hence, we need to get to work on IP6. Again a decision has been made in the IETF I support that decision. /jim ------------------------------------------------------------------------------ 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 Fri Aug 26 07:52:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21478; Fri, 26 Aug 94 07:52:43 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21472; Fri, 26 Aug 94 07:52:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA28022; Fri, 26 Aug 94 07:49:44 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA16028; Fri, 26 Aug 94 07:49:22 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA12703; Fri, 26 Aug 94 07:37:04 -0700 Received: by xirtlu.zk3.dec.com; id AA07320; Fri, 26 Aug 1994 10:35:49 -0400 Message-Id: <9408261435.AA07320@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NSAPs and GOSIP -Reply In-Reply-To: Your message of "Fri, 26 Aug 94 09:56:13 EDT." <9408261356.AA05324@xirtlu.zk3.dec.com> Date: Fri, 26 Aug 94 10:35:43 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Regarding this discussion. Though I agree we have real work to do and I have my name on several specs to write that are being written and working to see if we can get autoconfiguration per Dave / Sue up and running I believe dialogue to resolve an issue with the liaison to the IETF from ISO is a valid dialogue. I would like to encourage the discussion of ISO relationships off this list. I would like to encourage the discussion of NSAPs until that Draft is out I think next week, to be put on hold. I would like to encourage the discussion of 16bytes is not enough to the IPng Area Directors privately. But you don't have to listen to any of this and just do what you want to do. And I would like to encourage those in this discussion if they don't know that there are no kings or bosses in the IETF that you DO NOT HAVE TO LISTEN TO ANYONE WHO TELLS YOU TO GO AWAY ESPECIALLY WHEN THEY DO IT IN AN ARROGANT AND NEGATIVE WAY. I recommend hitting the 'd' key as I did. And always take the time to tell them to stuff it as I just did because they don't sign your paycheck so who cares. Presentation is everything folks if yours is offensive my response will be offensive. /jim ------------------------------------------------------------------------------ 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 Fri Aug 26 08:19:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21493; Fri, 26 Aug 94 08:19:44 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21487; Fri, 26 Aug 94 08:19:37 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA29150; Fri, 26 Aug 94 08:16:45 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AB19970; Fri, 26 Aug 94 08:16:15 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Fri, 26 Aug 1994 16:15:16 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Fri, 26 Aug 1994 11:04:20 +0100 Date: Fri, 26 Aug 1994 11:04:20 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003584] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3584 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3584*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9408260649.AA06386@dxcoms.cern.ch> Subject: RE: Re: Re: (IPng) NSAPs and GOSIP -Reply Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Brian It did look a bit like that but I am sure that I got it out of context - comment withdrawn. Maybe I'm just a little bit blinded by some of the IETF rhetoric which has been clouding this debate, like: 'Shout it from the rooftops OSI is dead'; 'Users will come to their senses'; 'we dont want national bodies to have their own little bit of address space'...'the provider will tell the user what his address is when he connects' etc. (not strictly accurate quotes but the sense is there). I know these to be individual views but the authors should know that their wide expression creates a bad image for Internet and this was reflected in the results of the recent IAB survey. I would actually like to work with the IETF to improve this image and it can only be done by taking real steps towards becoming a truly international body such as setting up regional chapters. This would ensure that the global IT participants would be truly involved in the decision making process. Jack ------------------------------------------------------------------------------ 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 Fri Aug 26 08:56:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21506; Fri, 26 Aug 94 08:56:54 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21500; Fri, 26 Aug 94 08:56:46 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00727; Fri, 26 Aug 94 08:53:55 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA26167; Fri, 26 Aug 94 08:53:31 PDT Received: from cssec4.pcs.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA15821; Fri, 26 Aug 94 08:46:42 -0700 Received: by cssec4.pcs.dec.com (5.57/jmh-inet-gw-v1.05); id AA24672; Fri, 26 Aug 94 17:45:21 +0200 Message-Id: <9408261545.AA24672@cssec4.pcs.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: ihanson@cssec4.pcs.dec.com Subject: Re: (IPng) NSAPs and GOSIP -Reply In-Reply-To: Your message of "Fri, 26 Aug 94 10:35:43 EDT." <9408261435.AA07320@xirtlu.zk3.dec.com> Date: Fri, 26 Aug 94 17:45:20 +0200 From: "Iain K. Hanson" X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim Bound wrote: >Regarding this discussion. >I would like to encourage the discussion of ISO relationships off this list. Would not i2i be an appropiate place for this? >I would >like to encourage the discussion of 16bytes is not enough to the IPng >Area Directors privately. Or presumably, Big-I ? /ikh ------------------------------------------------------------------------------ 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 Fri Aug 26 09:35:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21530; Fri, 26 Aug 94 09:35:48 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21524; Fri, 26 Aug 94 09:35:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA02276; Fri, 26 Aug 94 09:32:46 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA02472; Fri, 26 Aug 94 09:32:29 PDT Received: from relay.imsi.com by wintermute.imsi.com id MAA15542 for ; Fri, 26 Aug 1994 12:32:20 -0400 Received: from snark.imsi.com by relay.imsi.com id MAA14923 for ; Fri, 26 Aug 1994 12:32:19 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA06574; Fri, 26 Aug 94 12:32:18 EDT Message-Id: <9408261632.AA06574@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NSAPs and GOSIP -Reply In-Reply-To: Your message of "Fri, 26 Aug 1994 11:04:20 BST." <"3584*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> X-Reposting-Policy: redistribute only with permission Date: Fri, 26 Aug 1994 12:32:18 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM J.Houldsworth@ste0906.wins.icl.co.uk says: > I would actually like to work with the IETF to improve > this image and it can only be done by taking real steps > towards becoming a truly international body such as > setting up regional chapters. This is the IETF, the Internet Engineering Taskforce. We do ENGINEERING on the INTERNET. We do not do POLITICS on the INTERNET. This is the IPng working group, which does work on deciding on the design of IPv6. This is not a political body. If you wish to, go to the IAB and to the ISOC and all those guys and see if you can convince them that we need an Internet Politics Task Force. Please do not try to turn this into that body. We have work to do. Lets get to the work. Those that enjoy politics should go and find groups of other people that also enjoy politics and form political bodies with them. We have ENGINEERING to do. Perry ------------------------------------------------------------------------------ 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 Fri Aug 26 09:38:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21542; Fri, 26 Aug 94 09:38:58 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21536; Fri, 26 Aug 94 09:38:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA02428; Fri, 26 Aug 94 09:35:59 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA03031; Fri, 26 Aug 94 09:35:36 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA27717; Fri, 26 Aug 1994 18:37:23 +0200 Message-Id: <199408261637.AA27717@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) cluster addresses In-Reply-To: Your message of "Thu, 25 Aug 1994 08:54:57 EDT." <9408251256.AA11070@Sun.COM> Date: Fri, 26 Aug 1994 18:37:22 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM => Since you assume that cluster reachability information will be derivable => from the unicast reachability information, what are the rules for => deriving this information ? Specifically, what is the relationship between => the set of unicast address prefixes that a router injects into => the routing system and the set of cluster addresses associated => with the router ? => => Yakov. The cluster addresses recognized by the router should fall within the routes advertized by that router. That is, if the router recognizes the cluster C composed of Lc significant bits and 128-L1 zeroes, it must advertize at least one routing prefix R of length Lr, where Lr <= Lc and where the first Lr bits of R match the first Lr bits of C. This, indeed, modulo policy routing - reachability information is not always announced to all neighbors... Note that the converse is not true. There may be routes which are announced and which do not correspond to any of the router's cluster addresses. The assumption is that clusters would be configured in much the same way that AS numbers or area numbers are configured today. You should indeed feel entirely free to invent an autoconfiguration mechanism. Christian Huitema ------------------------------------------------------------------------------ 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 Fri Aug 26 10:09:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21609; Fri, 26 Aug 94 10:09:07 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21603; Fri, 26 Aug 94 10:09:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03483; Fri, 26 Aug 94 10:06:08 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA07501; Fri, 26 Aug 94 10:05:49 PDT Received: by rodan.UU.NET id QQxeqm27639; Fri, 26 Aug 1994 13:04:48 -0400 Message-Id: To: ipng@sunroof.Eng.Sun.COM Cc: RGMoskowitz-3@is.chrysler.com Subject: Re: (IPng) Multi-homed organizations In-Reply-To: Your message of "Fri, 26 Aug 1994 08:18:06 CDT." <9408261224.AA01009@clncrdv1.is.chrysler.com> Date: Fri, 26 Aug 1994 13:04:47 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob, I don't see how "we've failed." If there are multiple ways to get somewhere, you either remember the alternatives, or decide not to use some of them. This is a fundamental routing issue and not really an addressing issue. I think of the routing/addressing interplay as follows: There is a bumpy, granular greyscale ("continuum" isn't the right choice) of alternatives based on where the routing information comes from. At one end we have: Address encoding: No Topology Discernable Routing Decisions: External with Complete Flat Routing And at the other end we have: Address encoding: Full Source Routes (eg, UUCP) Routing Decisions: None needed - address includes topology I believe that to scale beyond where we are now (actually, to continue to survive even at the current size, much less a 10x overall growth), we must operate at a point in the middle. Part of this is driven by where the routing information comes from. If we conceptually "divide" an address into two parts, leftmost being "prefix" and rightmost being "relatively local", at any "level" in the routing structure, we find that the left prefix will tend to be flat-routed and the "relatively local" part will tend to be hierarchically routed. NOTE: the reason the "relatively local" part is hierarchically routed is because it serves as the argument to the recursion. the image is rather like "areas", but they are generally recursive. In the absence of other more explicit routing, one can use the left-most bits which match a large cluster address to route toward the cluster, then when the cluster boundary is reached the next lower subcluster bits come into play for more fine-grained routing decisions. This way, a site's boarder router might decide to only keep cluster advertisements for some set of "distant" destinations, knowing that "toward the cluster" is sufficient, but maybe not perfectly optimal. And it might keep finer-grained routes to more "local" destinations. This creates a natural coupling between cluster addresses and CIDRization and what are now AS numbers, creating one common abstraction that should allow a dramatic reduction of *some* routing tables. Or said another way, if it doesn't I can't figure out what does. Nothing prevents anyone keeping a long-match route for more explicit routing, but It's a choice - the cluster announcements let one decide to keep less routing detail. -mo ------------------------------------------------------------------------------ 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 Fri Aug 26 10:13:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21623; Fri, 26 Aug 94 10:13:30 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21385; Fri, 26 Aug 94 06:26:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25557; Fri, 26 Aug 94 06:23:18 PDT Received: from osi.ncsl.nist.gov by Sun.COM (sun-barr.Sun.COM) id AB04204; Fri, 26 Aug 94 06:23:07 PDT Received: from emu.ncsl.nist.gov.noname by osi.ncsl.nist.gov (4.1/SMI-4.0-MHS-7.0) id AA28419; Fri, 26 Aug 94 09:22:24 EDT Date: Fri, 26 Aug 94 09:22:24 EDT Message-Id: <9408261322.AA28419@osi.ncsl.nist.gov> To: kasten@ftp.com Subject: Re: (IPng) NSAPs and GOSIP And ISO and IP and... Cc: colella@nist.gov, ipng@sunroof.Eng.Sun.COM From: colella@nist.gov Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Frank, Amen. Too often the real issues are obscured by the emotional baggage (in both directions). The IPng ADs have made a recommendation. Breathe deeply...count to ten. Now, unless there is something new to be put on the table, let's just get on with the technical work. --Richard > From owner-ipng@sunroof2.Eng.Sun.COM Fri Aug 26 09:04:36 1994 > Date: Fri, 26 Aug 94 08:58:03 EDT > To: ipng@sunroof.Eng.Sun.COM > Subject: (IPng) NSAPs and GOSIP And ISO and IP and... > From: kasten@ftp.com (Frank Kastenholz) > Content-Length: 627 > Sender: owner-ipng@sunroof.Eng.Sun.COM > Reply-To: ipng@sunroof.Eng.Sun.COM > > > Here are three thoughts on this whole topic: > > 1. Why don't the IETF-based "All ISO efforts are wastes time" people go > find someplace else to bash the ISO. > > 2. Why don't all the ISO-based "When is the IETF going to grow up and > start acting like an adult" people go find someplace else to scold > the IETF. > > 3. Why don't the rest of us stay here and do useful work. > > -- > Frank Kastenholz > > > ------------------------------------------------------------------------------ > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ 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 Fri Aug 26 10:51:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21665; Fri, 26 Aug 94 10:51:43 PDT Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21659; Fri, 26 Aug 94 10:51:35 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05141; Fri, 26 Aug 94 10:48:43 PDT Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA14309; Fri, 26 Aug 94 10:48:27 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA07670; Fri, 26 Aug 1994 10:48:23 -0700 Date: Fri, 26 Aug 1994 10:48:23 -0700 From: Dave Katz Message-Id: <199408261748.KAA07670@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Perry E. Metzger"'s message of Fri, 26 Aug 1994 12:32:18 -0400 <9408261632.AA06574@snark.imsi.com> Subject: (IPng) NSAPs and GOSIP -Reply Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This is the IETF, the Internet Engineering Taskforce. We do ENGINEERING on the INTERNET. We do not do POLITICS on the INTERNET. Ah, if only this were really true... ------------------------------------------------------------------------------ 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 Fri Aug 26 12:20:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21726; Fri, 26 Aug 94 12:20:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21720; Fri, 26 Aug 94 12:20:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26816; Fri, 26 Aug 94 12:17:36 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA00595; Fri, 26 Aug 94 12:17:00 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA13499; Fri, 26 Aug 94 10:12:22 -0700 Received: by xirtlu.zk3.dec.com; id AA12392; Fri, 26 Aug 1994 13:12:04 -0400 Message-Id: <9408261712.AA12392@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) engineering specs needed Date: Fri, 26 Aug 94 13:11:57 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ICMP/Discovery Pretty good idea of Autoconfig direction to begin design but we really need icmp/discovery specs to engineer a prototype????? I don't feel comfortable using previous specs on this. PMTU Do we need more stated in arch spec about PMTU or do we need a new PMTU Internet Draft? Should talk about UDP and how its affected by the new IP6 arch model too. Transition I think this is in pretty good shape but there were other documents listed in SST we may need to move forward. SNMP? Anyone working on this? Does our security affect this work? MUST, SHOULD, MAY Time to enter these nasty words in all specs. Routing.? I sent mail to sdrp-request group but no response and colleague tells me who is on it its pretty quiet. Whats up with OSPF, RIPv2, or IDRP for IP6. What about the source route header is it valid as Steve presented it? Jumbograms ? Is this going to change the header? or not ? Ethernet demux? Are we going to get a SAP for IP6 or should we keep dumuxing on version number? DNS IP6 AA (whatever) Record spec? Security rules? In an offline design discussion in Toronto someone said that source route must have authentication if we want to use it. Where is this rule written? Not saying its not a good rule but is it written.? thanks /jim ------------------------------------------------------------------------------ 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 Fri Aug 26 12:25:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21738; Fri, 26 Aug 94 12:25:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21732; Fri, 26 Aug 94 12:25:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27192; Fri, 26 Aug 94 12:22:24 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA01900; Fri, 26 Aug 94 12:21:55 PDT Message-Id: <9408261921.AA01900@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5093; Fri, 26 Aug 94 15:21:38 EDT Date: Fri, 26 Aug 94 15:18:47 EDT From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM, Christian.Huitema@sophia.inria.fr Cc: deering@parc.xerox.com Subject: (IPng) cluster addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Fri, 26 Aug 1994 18:37:22 +0200 Christian, >The cluster addresses recognized by the router should fall within the >routes advertized by that router. This is a VERY IMPORTANT part of the cluster address definition. It seems that the current document (draft-ietf-sipp-routing-addr-02.txt) misses this. Let me suggest that the section of the document that talks about cluster addresses should include the text that defines relationship between cluster addresses that may be assigned to a router and the set of address prefixes that the router advertises into the routing system (pretty much along the lines suggested by Christian's message). Comments ? 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 Fri Aug 26 12:27:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21750; Fri, 26 Aug 94 12:27:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21744; Fri, 26 Aug 94 12:27:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27358; Fri, 26 Aug 94 12:24:34 PDT Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA02442; Fri, 26 Aug 94 12:24:11 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA12358; Fri, 26 Aug 1994 12:24:09 -0700 Date: Fri, 26 Aug 1994 12:24:09 -0700 From: Dave Katz Message-Id: <199408261924.MAA12358@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Robert Moskowitz's message of Fri, 26 Aug 1994 08:18:06 -0500 <9408261224.AA01009@clncrdv1.is.chrysler.com> Subject: (IPng) Multi-homed organizations Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I submit that the most common case is within a organizational entity, one group routes through one provider and another through a different. Of course, I doubt that there is anyway to collect stats on this. And the internal routing needs to be prioritized over the external routing. Normally. There's no problem in doing this; one approach is to assign different address prefixes to the different parts of the organization, and prefer internal routes over external (or longer prefixes over shorter, for that matter). ------------------------------------------------------------------------------ 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 Fri Aug 26 13:00:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21777; Fri, 26 Aug 94 13:00:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21771; Fri, 26 Aug 94 13:00:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00243; Fri, 26 Aug 94 12:57:52 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA08746; Fri, 26 Aug 94 12:57:35 PDT Message-Id: <9408261957.AA08746@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5649; Fri, 26 Aug 94 15:55:06 EDT Date: Fri, 26 Aug 94 15:52:41 EDT From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Subject: (IPng) engineering specs needed Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Fri, 26 Aug 94 13:11:57 -0400 Jim, >Whats up with OSPF, RIPv2, or IDRP for IP6. The following is from the minutes of IDR (aka BGP/IDRP-IP) WG. Hope that answers the IDRP's part of your question. 7. IPng transition IDRP for IPng Decisions: Working Group reached clear consensust that BGP-4 will not be extended or modified for IPng, rather IDRP will be used as a basis for the IPng idrp. IDRP will be used with the following changes: - IDRP's MULTI_EXIT_DISCRIMINATOR and LOCAL_PREF fields will be changed from one octet to 4 octets in length to match BGP4 - A form of BGP4's optional AGGREGATOR attribute should be added to IDRP - IDRP should be changed to not prepend the local RD to the RD path until an advertisement is sent outside the current RD (ala BGP). If reason(s) can be found for this change between BGP and IDRP, this will need to be reviewed. Action item: Tony Li, Yakov Rekhter, and Paul Traina will write the IDRP for IPng document. Action item: Dennis Ferguson will write a document describing constraints upon IDRP to ease the transition from BGP to IDRP/IP and eventually IDRP/IPng. Action item: Fred Baker, Dennis Ferguson and Paul Traina will produce a document that will be presented by the working group to the people working on IPng's IGPs listing desired features in an IGP that will improve igp/idrp cooperation (examples might include carrying RD path information, extending tag fields, etc.) Action item: Vadim Antonov has volunteered to write an internet draft on security and authentication uses and requirements for an idrp. Open Action item: There is a need for an IDRP <-> IGP interaction document covering both IPv4 and IPng. Volunteers please contact the working group chair. Yakov. P.S. There is *at least* one public domain implementation of IDRP that is available in GATED. ------------------------------------------------------------------------------ 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 Fri Aug 26 13:01:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21789; Fri, 26 Aug 94 13:01:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21783; Fri, 26 Aug 94 13:01:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00311; Fri, 26 Aug 94 12:58:55 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA08907; Fri, 26 Aug 94 12:58:38 PDT To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) IPng specs Date: Fri, 26 Aug 94 20:57:45 GMT From: Ran Atkinson Message-Id: <9408262057.aa04570@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim We're also quite eager to see some ICMP Discovery specs so we can implement and test them. I believe that all source routes require authentication. I believe that Steve Bellovin's IPng security white paper also raised concerns about un-authenticated source routes. I believe this rule should be mandatory and should be stated as part of the IPv6 source routing specification. I'm also willing to put it in the security specs, but folks implementing source routing will definitely read the source routing spec and might not read the security spec at implementation time. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ 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 Fri Aug 26 13:16:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21865; Fri, 26 Aug 94 13:16:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21859; Fri, 26 Aug 94 13:16:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01633; Fri, 26 Aug 94 13:13:50 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA11259; Fri, 26 Aug 94 13:13:32 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14440(3)>; Fri, 26 Aug 1994 13:13:06 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 26 Aug 1994 13:12:54 -0700 To: yakov@watson.ibm.com, Christian.Huitema@sophia.inria.fr Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) cluster addresses In-Reply-To: yakov's message of Fri, 26 Aug 94 12:18:47 -0800. <9408261921.AA01900@Sun.COM> Date: Fri, 26 Aug 1994 13:12:39 PDT From: Steve Deering Message-Id: <94Aug26.131254pdt.12171@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >The cluster addresses recognized by the router should fall within the > >routes advertized by that router. > > This is a VERY IMPORTANT part of the cluster address definition. I'm afraid I must disagree with my esteemed French colleague. Cluster addresses are a topological or an addressing concept, not a routing concept. You draw a circle around the piece of topology identified by an address prefix. (The circle may slice through interfaces or it may slice through the middle of routers). The cluster address identifies the set of entry points into that circle, where an entry point is a router with at least one interface belonging to the particular address prefix and at least one link to an interface that does not belong to that prefix. The question of what routers advertise what prefixes is an orthogonal issue. For example, an entry router C1 into cluster C may be connected to the outside (i.e., non-C) world by a point-to-point link to a router N1, which is not in C. N1 may be configured to advertise prefix C to the rest of the world, on behalf of C1 (say, bacause C1 isn't running any routing protocol across the p-to-p link). In this case, C1 must be configured to recognize cluster address C as one of its own addresses (even though it is not advertising C) and N1 must *not* recognize cluster address C as one of its own addresses (even though it is advertising C). Now, in the case where the entry router for a cluster *is* (one of) the router(s) that advertises that cluster address, auto-recognition of the cluster address by that router ought to be possible. But when that is not the case, manual configuration seems necessary. I don't understand why this is such a difficult concept to grasp. The picture is very clear in my mind. :-) Steve ------------------------------------------------------------------------------ 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 Fri Aug 26 13:49:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21942; Fri, 26 Aug 94 13:49:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21936; Fri, 26 Aug 94 13:49:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05001; Fri, 26 Aug 94 13:46:56 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA17967; Fri, 26 Aug 94 13:46:35 PDT Received: by rodan.UU.NET id QQxerb15623; Fri, 26 Aug 1994 16:46:33 -0400 Message-Id: To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) cluster addresses and routing and such.... In-Reply-To: Your message of "Fri, 26 Aug 1994 13:12:39 PDT." <94Aug26.131254pdt.12171@skylark.parc.xerox.com> Date: Fri, 26 Aug 1994 16:46:33 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, Cluster addresses is where routing and addressing co-mingle. That is how you actually mix the topology coding into the addressing structure. I agree, you COULD assign the cluster addresses independently of the topology, but WHY? If you assign them as address prefixes, we win really big. the reason Christian suggests what is does is so that a router could infer a minimal set of cluster addresses from the prefixes assigned to the interior behind the router boundary. One might, however, advertise a larger cluster, but the locally-specific cluster addresses basically become the prefixes (which are nominally announced by the routing). as you get further and futher away from the inner-most cluster, the router is acting on behalf of a larger and larger collection (cluster) and hence can make less and less specific (and hence fewer and fewer) announcements. If we don't assign clusters as the prefixes, then I don't see any value to having them. and if they aren't announced via routing protocols, then we don't get the routing aggergation out of them that we could otherwise. That said, if you want to announce some other cluster address, i see no reason why you can't do that (a scenario where two clusters overlap and you assign an arbitrary address carried with an arbitrary announcement), but I don't see why one would do that for real (other than to verify it will work). IN the end, routing and addressing are vitally related - you can't find an address unless there is a routing advertisement "covering" the address - advertising an aggregate containing the desired address. Otherwise, there is no way to get back to the original topology because the space isn't metric. and if aggregates are clusters (but not all clusters are formal aggregates (ie, are carried by explicit announcements)), then the routing and addressing mesh nicely to produce natural routing compression and a vehicle for doing "horizon" routes (just large clusters) for advertising "distant" pieces of the topology. -Mike ------------------------------------------------------------------------------ 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 Fri Aug 26 14:19:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21974; Fri, 26 Aug 94 14:19:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21968; Fri, 26 Aug 94 14:19:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07975; Fri, 26 Aug 94 14:16:45 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA25071; Fri, 26 Aug 94 14:16:29 PDT Message-Id: <9408262116.AA25071@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6943; Fri, 26 Aug 94 17:16:30 EDT Date: Fri, 26 Aug 94 17:15:39 EDT From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Subject: (IPng) engineering specs needed Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Fri, 26 Aug 94 13:11:57 -0400 Jim, >I sent mail to sdrp-request group but no response and collegue tells me >who is on it its pretty quiet. Actually most of the discussion about cluster addresses (that happened on ipng mailing list) is driven by the work on introducing SDRP capabilities into IPv6. An element in the SDRP Header may be a cluster address, so understanding of cluster addresses is quite important for the work on SDRP Header. 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 Fri Aug 26 14:30:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21994; Fri, 26 Aug 94 14:30:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21988; Fri, 26 Aug 94 14:30:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09352; Fri, 26 Aug 94 14:27:55 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA27965; Fri, 26 Aug 94 14:27:38 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14638(3)>; Fri, 26 Aug 1994 14:27:03 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 26 Aug 1994 14:26:51 -0700 To: "Mike O'Dell" Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) cluster addresses and routing and such.... In-Reply-To: mo's message of Fri, 26 Aug 94 13:46:33 -0800. Date: Fri, 26 Aug 1994 14:26:39 PDT From: Steve Deering Message-Id: <94Aug26.142651pdt.12171@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Mike, > I agree, you COULD assign the cluster > addresses independently of the topology, but WHY? If you > assign them as address prefixes, we win really big. Sigh. I did *not* suggest that cluster addresses should be assigned independently of topology. I said exactly the opposite! Cluster addresses *are* the address prefixes. The fact that you think we disagree tells me I'm still failing to communicate what is, to me, a very simple and straightforward notion. I was simply trying to point out that Yakov's and Christian's attempt to define cluster addresses operationally, in terms of the behaviour of routing protocols, though covering the dominant case, does not embrace all the possibilities. Clusters (and addresses) are defined in terms of topology, not in terms of how routers learn or exchange information. That way leaves more flexibility in the design and/or deployment of routing protocols. > If we don't assign clusters as the prefixes, then I don't see > any value to having them. The clusters *are* the prefixes! > and if they aren't announced via > routing protocols, then we don't get the routing aggergation > out of them that we could otherwise. They are *already* being announced by routing protocols! The simplest example is the subnet cluster. Its cluster address is the subnet prefix. All the routers that have an interface to the subnet are the entry routers for that cluster and they recognize the subnet prefix as identifying themselves. In most cases, those routers announce the subnet prefix in some routing protocol, which *is the same thing* as announcing the cluster address; no additional "announcements" are required to support cluster addresses. Note, however, there are *some*, *atypical* cases where a router into a subnet does not "announce" the subnet prefix in any routing protocol, e.g., in the case where no IGP is being used and all routes within an organization are manually configured. However, this does not change the fact that the routers are entry routers into their subnet clusters. The definition of a cluster does not depend on what the routing protocols do, or even on whether routing protocols exist! It depends only on how addresses are assigned to interfaces (which, of course, is done to facilitate scalable routing, at least in the IPng world). I've gotta run to catch a plane, so I've gotta stop here. Steve ------------------------------------------------------------------------------ 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 Fri Aug 26 15:05:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22025; Fri, 26 Aug 94 15:05:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22019; Fri, 26 Aug 94 15:05:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13236; Fri, 26 Aug 94 15:02:22 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA05789; Fri, 26 Aug 94 15:01:53 PDT Received: by rodan.UU.NET id QQxerg22650; Fri, 26 Aug 1994 18:01:51 -0400 Message-Id: To: Steve Deering Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) cluster addresses and routing and such.... In-Reply-To: Your message of "Fri, 26 Aug 1994 14:26:39 PDT." <94Aug26.142651pdt.12171@skylark.parc.xerox.com> Date: Fri, 26 Aug 1994 18:01:51 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM so, we are violently agreeing. good! -mo ------------------------------------------------------------------------------ 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 Fri Aug 26 15:17:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22037; Fri, 26 Aug 94 15:17:40 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22031; Fri, 26 Aug 94 15:17:31 PDT Received: by jurassic.Eng.Sun.COM (8.6.9/SMI-SVR4) id PAA23623; Fri, 26 Aug 1994 15:14:42 -0700 Date: Fri, 26 Aug 1994 15:14:42 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <199408262214.PAA23623@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com In-Reply-To: <9408261957.AA08746@Sun.COM> Subject: (IPng) engineering specs needed Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yakov, > The following is from the minutes of IDR (aka BGP/IDRP-IP) WG. > Hope that answers the IDRP's part of your question. .... This looks good to me. Glad this one is under control. Bob ------------------------------------------------------------------------------ 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 Fri Aug 26 15:46:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22064; Fri, 26 Aug 94 15:46:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22058; Fri, 26 Aug 94 15:46:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17283; Fri, 26 Aug 94 15:43:41 PDT Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA13691; Fri, 26 Aug 94 15:43:24 PDT Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA14546; Fri, 26 Aug 94 18:39:17 EDT Received: from cabernet.wellfleet by wellfleet (4.1/SMI-4.1) id AA12440; Fri, 26 Aug 94 18:37:40 EDT Date: Fri, 26 Aug 94 18:37:40 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9408262237.AA12440@wellfleet> To: tli@cisco.com, kre@munnari.OZ.AU Subject: Re: (IPng) millions of OSI products Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 1) It allows us to leverage the existing addressing structure of the > other network layer to ease the pain of transition. > > Yes, making transition easier is a worthy goal, provided there > is really something out there that is going to go that way. I certainly agree about the importance of easy and straightforward transition. In fact I think that the IPv4 to IPv6 transition is the most important part of the IPng effort. Assuming that folks will transition applications that are currently running over CLNP to instead run over IPv6 (which I believe is a good thing) then clearly this transition plan is also very important. However, stating that address mapping is to be used for transition, and that transition is important, doesn't answer the question for me. Why is mapping an NSAP address into an IPv6 address useful in order to help make CLNP to IPv6 transition easier? What does it mean to leverage the existing address structure for this purpose? Is this to allow humans to avoid the problem of making a new set of address assignments? If so, then we could devise local mapping plans for each NSAP addressing domain, and create management tools to ease the creation of initial name to address mappings. Is this to allow protocol translation in routers between CLNP and IPv6? If so, then I would like to see a transition plan which explains how IPv4 to IPv6 translation, CLNP to IPv6 translation, and NAT IPv4 address translation is all going to coexist at the same time in the same network (presumeably at the same time that we are also doing IPX to IPv6 translation). The thought of this makes me very sympathetic with Bill Simpson's comment at the last IETF, that we don't want to devise a transition plan that will take years just to explain to folks who have to deploy it. I think that CLNP to IPv6 transition is important. I think that this is best done via a dual stack approach. I don't see how having an general algorithm for mapping NSAP addresses into IPv6 addresses is necessary for this transition to take place. Ross ------------------------------------------------------------------------------ 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 Fri Aug 26 19:00:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22263; Fri, 26 Aug 94 19:00:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22257; Fri, 26 Aug 94 19:00:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01585; Fri, 26 Aug 94 18:57:36 PDT Received: from drax.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA10575; Fri, 26 Aug 94 18:57:06 PDT Received: from drax.isi.edu by drax.isi.edu (5.65c/5.61+local-16) id ; Fri, 26 Aug 1994 18:57:05 -0700 To: ipng@sunroof.Eng.Sun.COM From: Craig Milo Rogers Subject: (IPng) On NSAP/IP6 Translation Date: Fri, 26 Aug 94 18:57:05 PDT Message-Id: <22825.777952625@drax.isi.edu> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This memo describes a generic translation between ISO/OSI NSAPs and IP6 16-octet addresses by using DNS. It is speculative; no trial implementation has been made. Also, similar proposals may have been made already by others; if so, my apologies for the repetition. 1) Problems being solved: NSAP host addresses are 20 octets long. IP6 addresses are 16 octets long. NSAP addresses could subsume IP6 addresses, but not vice versa. However: 1) It is desirable to assign and administer only a single address space if possible. 2) It is anticipated that IP6-based routers will form a cheap substrate on which it will be desirable to transport packets that use NSAP addressing. 3) There may be opportunities for gatewaying higher-level protocols between IP6-based and NSAP-based environments. 2) Overview of solution: 1) Create NSAP-to-IP6 and IP6-to-NSAP mapping tables in the DNS. 2) At the point in which a OSI (CLNP) packet is encapsulated in IP6, or higher-level gateway translation takes place, use the DNS to locate the IP6 address. 3) Reverse translate between IP6 and NSAP when gatewaying in that direction. 4) Dynamically allocate and register new IP6 addresses under certain circumstances, to reduce the need for manual address space allocation. 3) DNS mapping tables for NSAP-to-IP6 and IP6-to-NSAP: 1) These would take the "usual" format. Lively discussions could be held on the relative merits of decimal and hexadecimal notation, and octet- or double-octet-based notation. 2) If there are 500,000 CLNP-based hosts in the world, and a mapping entry takes, say, 40 octets, then the global map would occupy 20 Mbytes. 1) My laptop PC has more memory than that. 2) Hosts, routers, and gateways would *not* need to hold the complete map. The local cache used should be insignificant, with rare exceptions (the host with the NCSA Mosaic home page, for example :-). 3) Even if there were one NSAP for each person on Earth, say 5e9, that's only 200e9 octets. SCSI drives holding 5e9 octets are available for about US$2500, so a complete global database would cost US$100,000. This is bound to go down. 3) At worst, a DNS registration will be needed each time a host is booted (imagine a wave of DNS registrations circling the Earth at 0800 local time). With better design, a DNS registration will be needed only when a machine is installed or a major topological or administrative change forces renumbering. 4) DNS lookups (described below) that do not succeed in the local DNS cache should take place at roughly the same rate as host name lookups; this should be an acceptable cost. 4) NSAP-to-IP6 address translation: 1) Translation would take place in a host (when directly connected to an IP6-based network), a router (when moving traffic between an NSAP-based network and an IP6-based network), or a higher-level protocol translation gateway. 2) Both TO and FROM addresses need to be translated. 1) I assume, without waving numbers around, that a satisfactory percentage will be found in the local DNS cache for most applications. 3) TO addresses use straight DNS lookups. If the lookup fails, the packet is rejected (or passed to another module for special processing). 4) FROM addresses are first looked up in the DNS. If that fails, a new IP6 address may be allocated (perhaps through DHCP) and registered in the DNS. 1) Another option would be to translate certain NSAPs into a subset of the IP6 address space. Such translations could be established on a case-by-case basis. However, DNS entries would still be made for all active NSAP addresses. 2) Another option is to use a media-level address associated with the host, such as an 8-octet Ethernet address, to form the IP6 address. 5) It can be generally assumed that a host will send some packet or another, and force the (automatic) creation of an NSAP-to-IP6 DNS map, whenever the host boots. In the rare case that a host might want to receive NSAP-based packets before it receives any, an alternate (manual?) DNS registration procedure will be required. 6) Except as noted in 4.4.1, above, the NSAP-to-IP6 address translation procedure is generic, It can handle full 20-octet NSAPs; it could be programmed to work even if NSAPs were made longer still! In essence, it is ARP, using the DNS. 1) For that matter, ARP could be used by hosts that don't want to or aren't able to participate directly in DNS. 7) Local "DNS cache" lookup could easily be implemented in hardware for high-performance routers ("he asserts nonchalantly" :-). Cache lookup failures would require software intervention, of course. 5) IP6-to-NSAP address translation: 1) An IP6-to-NSAP address translation will undoubtedly be useful for maintenance and administration of the combined NSAP/IP6 internetwork. 2) It will also be useful for gateways/translators, for example, IP6(TP4) <=> CLNP(TP4). 6) Dynamic allocation of IP6 addresses: 1) As described in (4.4), above, the necessity for dual address spaces need not impose a major administrative burden. Automatic allocation and registration procedures can perform most of the operations. 2) As a side note, it would be useful to increase the level of security in the DNS: 1) to trap runaway automatic IP6 allocation, 2) to reduce spoofing, break-ins, etc. 7) Implicit biases in this proposal: 1) Even though this proposal imposes very small administrative and operational burdens on the use of NSAPs with the IP6 backbone, the costs are, nontheless, there. There is an implicit bias that NSAP-based protocol use will eventually wither away in favor of IP6. This may bother some people. 2) I have used DNS throughout this proposal. I suppose that an X.500 database could provide the equivalent functionality. I haven't researched this. 8) Security issues: 1) Making NSAP-to-IP6 address translations visible in the DNS may increase opportunities for access violations. 1) Since the translations are not generally needed except at NSAP/IP6 borders, read-access to those parts of the DNS could be similarly restricted. 2) Except as noted here and in (6.2), security issues are not discussed in this memo. 9) Conclusion (assertion?): Using the approach outlined in this proposal, generic NSAP-to-IP6 interconnection is technically, economically, and administratively feasible. Craig Milo Rogers ------------------------------------------------------------------------------ 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 Fri Aug 26 23:49:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22310; Fri, 26 Aug 94 23:49:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22304; Fri, 26 Aug 94 23:49:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08936; Fri, 26 Aug 94 23:47:04 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA24394; Fri, 26 Aug 94 23:46:48 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA01800; Fri, 26 Aug 1994 23:46:46 -0700 Date: Fri, 26 Aug 1994 23:46:46 -0700 From: Tony Li Message-Id: <199408270646.XAA01800@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPng specs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, I believe that all source routes require authentication. I believe that Steve Bellovin's IPng security white paper also raised concerns about un-authenticated source routes. I believe this rule should be mandatory and should be stated as part of the IPv6 source routing specification. I'm also willing to put it in the security specs, but folks implementing source routing will definitely read the source routing spec and might not read the security spec at implementation time. I certainly take issue with this because of your blanket condemnation of "all" source routes. Seeing as how we expect to perform provider selection and reservation of alternate routes using source routing technology your proposal would add the unnecessary and unwanted overhead even in cases where no security whatsoever is required. I think that it is much more appropriate to say that unauthenticated source routes can be a security hazard, and that hosts and firewalls should take appropriate precautions, but this may not need to extend to authentication of the source route itself. For example, a host may find that source identity authentication is quite sufficient. Keep the baby, toss the bathwater... ;-) Tony ------------------------------------------------------------------------------ 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 Sat Aug 27 00:30:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22327; Sat, 27 Aug 94 00:30:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22321; Sat, 27 Aug 94 00:30:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09932; Sat, 27 Aug 94 00:27:41 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA29464; Sat, 27 Aug 94 00:27:24 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA18272; Sat, 27 Aug 1994 00:27:22 -0700 Date: Sat, 27 Aug 1994 00:27:22 -0700 From: Tony Li Message-Id: <199408270727.AAA18272@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: mo@uunet.uu.net, ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Fri, 26 Aug 1994 14:26:39 PDT <94Aug26.142651pdt.12171@skylark.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 The clusters *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 induldge me... Suppose that my local subnet is 131.108.0.0/24. According to the above, this gives me the cluster address 131.108.0.0. However, this subnet probably resides within the bigger aggregate 131.108.0.0/16, which ALSO has the cluster address 131.108.0.0. How then can a host, located outside of the 131.108.0.0/16 aggregate, address a packet to the cluster 131.108.0.0/24? The destination address in the packet would contain 131.108.0.0, which is now ambiguous. Tony p.s. Credit for discovering this problem belongs to Dave Katz. ------------------------------------------------------------------------------ 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 Sat Aug 27 07:53:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22441; Sat, 27 Aug 94 07:53:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22435; Sat, 27 Aug 94 07:53:47 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22424; Sat, 27 Aug 94 07:51:00 PDT Received: from ski.utah.edu by Sun.COM (sun-barr.Sun.COM) id AA14872; Sat, 27 Aug 94 07:50:44 PDT Received: (from haas@localhost) by ski.utah.edu (8.6.9/8.6.9) id IAA16364; Sat, 27 Aug 1994 08:55:30 -0600 From: Tired of the Information Superhype Message-Id: <199408271455.IAA16364@ski.utah.edu> Date: Sat, 27 Aug 94 08:55:30 MDT Subject: Re: (IPng) cluster addresses and routing and such.... To: Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: ipng@sunroof.Eng.Sun.COM, Sat, 27 Aug 1994 00:27:22 -0700 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Suppose that my local subnet is 131.108.0.0/24. Using current IP notation, I believe this is illegal, isn't it? Subnet addresses have different constraints than Class C addresses. >How then can a host, located outside of the 131.108.0.0/16 aggregate, >address a packet to the cluster 131.108.0.0/24? The destination >address in the packet would contain 131.108.0.0, which is now >ambiguous. IPv4 deals with this by making the address class disambiguate the notation. Probably a good idea. -- Walt ------- ------------------------------------------------------------------------------ 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 Sat Aug 27 11:22:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22501; Sat, 27 Aug 94 11:22:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22495; Sat, 27 Aug 94 11:22:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27763; Sat, 27 Aug 94 11:19:47 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA21808; Sat, 27 Aug 94 11:19:30 PDT To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) security & source routing Date: Sat, 27 Aug 94 19:17:20 GMT From: Ran Atkinson Message-Id: <9408271917.aa05819@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony, There is a fundamental problem with source routes from a security perspective: one CANNOT dependably identify the origin of the data unless authentication is used on source-routed packets. Source routing attacks are currently happening in the current IPv4 Internet. I really don't think we can ignore them. There is no good reason that source-routed packets can't be authenticated using the defined Authentication Header, which is both mandatory to implement and (apparently) easily exported. No one is saying not to use source routing, just that source routing needs authentication. Even unidirectional source routes create this problem -- without authentication there is no dependable way to know who sent the packet. Without authentication neither hosts, nor firewalls, nor routers can dependably identify the actual source of the source-routed packets. Please don't mistake my security concerns for a dislike of source routing; I happen to think that source routing is a very handy tool in a number of circumstances. If I'm confused, which is possible, then please educate me on how a receiver or intermediate router can dependably identify the source of a source-routed packet that lacks authentication and encryption. Regards, Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ 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 Sat Aug 27 11:39:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22521; Sat, 27 Aug 94 11:39:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22515; Sat, 27 Aug 94 11:39:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28091; Sat, 27 Aug 94 11:36:15 PDT Received: from nic.ott.hookup.net by Sun.COM (sun-barr.Sun.COM) id AA22465; Sat, 27 Aug 94 11:35:53 PDT Received: from [165.154.16.159] (kgk.ott.hookup.net [165.154.16.159]) by nic.ott.hookup.net (8.6.9/1.32) with SMTP id OAA14204; Sat, 27 Aug 1994 14:35:42 -0400 Message-Id: <199408271835.OAA14204@nic.ott.hookup.net> X-Sender: kgk@nic.ott.hookup.net (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 27 Aug 1994 14:37:22 -0500 To: ipng@sunroof.Eng.Sun.COM From: kgk@hookup.net (Keith G Knightson) Subject: (IPng) IPNG Capabilities Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Gentlemen, The recent discussions seem to fall into two categories: a) I'm not going to listen whatever you say, or, b) This is a political issue, and should be discussed elsewhere. I, for one, would like to have a technical discussion with someone who was at least prepared to listen, and who might provide some reasonably objective and unoffensive responses. Judging by the recent exchanges, this mght be somewhat difficult on this group. One has to start somewhere, however, so here goes. If there is a more appropriate group I would be glad to join that, provided it's not simply a question of providing a black-hole of convenience. As you can see the recent exchanges leave me with a cynical view of humanity. Some technical input follows............. 1 Introduction This input contains proposals for the addressing scheme(s) and the related address carriage mechanism (protocol) for IPNG. 2 Objective The objective of these proposals is to ensure the longevity of IPNG and to enhance its universal applicability and reachability. 3 Distinction between the Address Scheme and its carriage mechanism (protocol) A very important distinction can be made between the address itself, i.e. the 16 byte address scheme (and its structure), and the protocol mechanism for carrying the address. For example, it does not necessarily follow that the adoption of a 16 byte address fixed length scheme restricts the protocol to a fixed 16 byte address field. I believe that a protocol that is transparent to the address scheme is technically superior to one that confuses the logical nature of addresses with the physical encoding used to carry them. A more flexible carriage mechanism would not only allow the carriage of a 16 byte address but it would additionally be inherently capable of carrying even longer addresses at some time in the future. Similarly, a more flexible address carriage mechanism would enable a smaller address to be carried, i.e. the existing IP or other alternative address schemes. Thus, all existing or future INTERNET address schemes could be carried in a single new protocol. Historically, many network protocols have suffered from the restricted length field problem, by gearing the protocol around an address scheme, with extremely adverse consequences when faced with a need for address enlargement. It would be prudent not to make the same mistake yet again. [It is interesting to note that the Internet has already made this mistake (excuse me included this feature) twice now!] This is not necessary a plea for a 24 byte address scheme, but a plea for the capability in the protocol. A plea for future-proofing, if you will. It will be argued (no doubt) that such a mechanism will be inefficient. I would argue that changing protocols every few years, with all the side effects of that, is what is really inefficient, and usually quite disastrous. The protocol transition problem can hardly be regarded as efficient and stems directly from poor initial protocol design. Processing power is increasing continually, and upgrading processors is preferable to rewriting all the processes. Keeping the system stable should be the goal, not the diminishing returns of the last 0.0001% of efficiency. Additionally, there may be a need for the coexistence of multiple INTERNET address schemes in the future, perhaps for specific applications. The really really long term must be considered. "Never again" might be an appropriate and laudable objective in this particular area. Thus, I contend that variable length protocol address field mechanism would be of significant benefit, and ensure the technical longevity and flexibility of IPNG. Additionally, I feel there is also another and perhaps equally important benefit to a flexible and address-transparent protocol mechanism, and that is the ability to carry non-Internet-address schemes as discussed below]. 4 Interworking with other networks The major problem with interconnecting dissimilar peer networks is the difference in addressing schemes. It is clear that schemes which have different lengths are difficult, and potentially impossible to deal with from a mapping perspective. It is very advantageous, technically, if a given network can actually carry, and to some extent route on, the address scheme of a peer network. Naturally, for this to work all the networks involved must be able to do this. Experience shows that had a flexible carriage scheme been built into X.25 and ISDN, at the outset, the interconnection of a separate X.25 network with X.121 addressing with an ISDN with E.164 addressing would have been trivial and sans contortion. Let's consider an example closer to home. Suppose CLNP were able to carry an IPNG address (in place of the OSI NSAP address), and similarly that IPNG were able to carry an OSI NSAP address.(in place of normal IPNG address). This would enable a user on an OSI network to address a user on the INTERNET and vice-versa. This would make interconnection of IPNG and CLNP networks a piece of cake. I actually believe there is a requirement for this, based on the number of existing/planned OSI networks, which I don't think will all simply just go away. Also, it would remove any further arguments or requirements for about a common single protocol. CLNP could, if the OSI folks desire, be enhanced to be functionally equivalent without impacting on the control of IPNG developments themselves. Clearly protocol mapping would still be required in gateways, but this is child's play compared to address mapping. I see a big advantage to this scenario in the sense that this would extend the scope and reach of the INTERNET into the OSI world. This would make the INTERNET a truly global and supreme entity. This does mean however, that each network has to route, to some extent, on the basis of the "alien" address. Routing on the basis of an AFI, or AFI plus some, is extremely simple. From the mechanistic point of view this is no different to routing on the various parts of an IPNG address. Routing on the basis of a variable length prefix is just that. Perhaps there is scope for fixing a common maximum for that, for the purposes of interconnection. The use of IDRP would be also helpful between the two "worlds". In this scheme, ISO would be required to allocate an AFI (or set of AFIs perhaps) to ISOC, which is no big deal, and would be a reality test of the new found detente between ISO and the ISOC. I think that both sides could at least achieve this without getting in each other's way too much afterwards. I believe this would be a significant step forward. 5 Summary As a result of the foregoing considerations I would propose the following: a) that a variable length address field be defined for IPNG, so that longevity of IPNG is assured: b) that ISO be requested to allocate AFIs for INTERNET Addresses; c) that IPNG and INTERNET infrastructure include the capability to carry, and route on, OSI NSAP addresses for the purpose of interconnecting to CLNP based networks. The proposed 16 byte address scheme for normal pure INTERNET usage would not be affected by the above accommodations. ------------------------------------------------------------------------------ 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 Sat Aug 27 11:44:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22537; Sat, 27 Aug 94 11:44:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22531; Sat, 27 Aug 94 11:44:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28220; Sat, 27 Aug 94 11:41:39 PDT Received: from achilles.ctd.anl.gov by Sun.COM (sun-barr.Sun.COM) id AA22714; Sat, 27 Aug 94 11:41:23 PDT Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA01059; Sat, 27 Aug 94 13:41:21 CDT Date: Sat, 27 Aug 94 13:41:21 CDT Message-Id: <9408271841.AA01059@achilles.ctd.anl.gov> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products From: "Richard Carlson" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Vadim Antonov Writes: >Who needs EID anyway? After attacking many people at IETF in Toronto >the only rationale i got was "it appears to be useful". Vadim; You never asked me about EID's and you probably never read my paper on the subject (ftp from achilles.ctd.anl.gov:/pub/ietf/tcpv11b.txt). As a strong proponent of EID's (actually transport layer independent addressing) let me try and give you my slant on this topic. In order to get from IPv4 to IP6 I need to change the networking code in all my workstations, servers, and routers. Since not all of them can change at once, I will wind up with a mix of both. A lot of my users communicate with their peers at other sites. Since I have no control over the other sites I will have to support whatever protocol they are running. To me this means running both IPv4 and IP6 forever. With this as a given, I am very interested in how the transition plan will work. From what I have read so far, I'm worried. Dual stacks, compatable and non-compatable addresses, and IPv4 <--> IP6 translators simply seem to complacated for my taste. I think there should be an easier way to transition and that is to use EID's. If TCP would operate over multiple IP layers, then I see an easier transition path. The way to make TCP do this is to remove the IP address from the TCP pseudo header and replace it with an EID. You will need to send the src and dest EID's back and forth in each packet so the end hosts will know that they are talking to the correct party. The extra bandwitdh used is more that made up by the increased flexability. Yes in 1980 when 56 Kbps point to point lines were fast, using the IP address in the TCP checksum was smart. But nowadays T1's are common (the increase of the MTU in IP6 acknowledges this), so I contend that making the TCP header larger has a negligible effect on todays networks. I can clearly see how using EID's would make integrating my prototype ATM and Fibre Channel networks into my existing IP networks easier. I see a lot of advantages to making TCP (and UDP) network layer independent. The disadvantages are 1) bigger TCP headers, 2) new versions of TCP everywhere, and 3) new versions of user applications. Both 2 & 3 need to be done anyway to support IP6, why not do it right the first time? That is change TCP to use EID's and applications to use DNS names. This way users will only need to remember names, and maybe my job will get easier instead of harder. Rich Carlson ----------------------- Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 ------------------------------------------------------------------------------ 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 Sat Aug 27 15:25:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22697; Sat, 27 Aug 94 15:25:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22691; Sat, 27 Aug 94 15:25:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03250; Sat, 27 Aug 94 15:22:33 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA01183; Sat, 27 Aug 94 15:22:17 PDT Received: by rodan.UU.NET id QQxeuz11856; Sat, 27 Aug 1994 18:22:13 -0400 Message-Id: To: Kgk@hookup.net Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) rehashing old 16/20/?? discussions... In-Reply-To: Your message of "Sat, 27 Aug 1994 14:37:22 CDT." <199408271835.OAA14204@nic.ott.hookup.net> Date: Sat, 27 Aug 1994 18:22:13 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Good sir, I realise you mean well, but... Please stop now and go re-read the archives to see how we got here. This line of discussion was beaten to death like most of the others. IP6 has 16 byte addresses in 16 byte slots in the packets. We are working on IP6, not something else. Thank you for your interest. Next topic. Cordially, =Mike O'Dell ------------------------------------------------------------------------------ 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 Sat Aug 27 17:27:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22757; Sat, 27 Aug 94 17:27:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22745; Sat, 27 Aug 94 17:27:35 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05684; Sat, 27 Aug 94 17:24:47 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA05548; Sat, 27 Aug 94 17:24:32 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id RAA11812; Sat, 27 Aug 1994 17:24:30 -0700 Date: Sat, 27 Aug 1994 17:24:30 -0700 From: Tony Li Message-Id: <199408280024.RAA11812@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: Ran Atkinson's message of Sat, 27 Aug 94 19:17:20 GMT <9408271917.aa05819@sundance.itd.nrl.navy.mil> Subject: (IPng) security & source routing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, There is a fundamental problem with source routes from a security perspective: one CANNOT dependably identify the origin of the data unless authentication is used on source-routed packets. True. However, your statement is too strong. One cannot dependably identify the origin of the data unless authentication is used on packets. Please explain why source routing makes a difference... Source routing attacks are currently happening in the current IPv4 Internet. I really don't think we can ignore them. There is no good reason that source-routed packets can't be authenticated using the defined Authentication Header, which is both mandatory to implement and (apparently) easily exported. Actually, we have some very interesting and simple applications which require EXACTLY this. For example, we would like to include the ability to add source routing to an existing packet. However, this may not happen at the source. An application for this is with provider selection. We would very much like to allow the net admin to control the few machines which constitute domain border routers and NOT have to manage provider selection by controlling all hosts in the domain. No one is saying not to use source routing, just that source routing needs authentication. Even unidirectional source routes create this problem -- without authentication there is no dependable way to know who sent the packet. Without authentication neither hosts, nor firewalls, nor routers can dependably identify the actual source of the source-routed packets. Please don't mistake my security concerns for a dislike of source routing; I happen to think that source routing is a very handy tool in a number of circumstances. If I'm confused, which is possible, then please educate me on how a receiver or intermediate router can dependably identify the source of a source-routed packet that lacks authentication and encryption. Suppose that there is a permutation of a source route header whereby the source route itself is NOT included in the authentication computation. Use the mechanisms for computing authentication as you've described them already. I believe that you should be happy as you can perform the authentication of the IPv6 fixed header and the other authenticated headers. If you do this, I believe that you can say "this packet came from fred.pizzahut.com". You cannot say "this packet came through PizzaNet". Note that you MAY also have authenticated source routes. If I'm being clueless, please rent me one.... In the meantime, I think it's dinnertime. ;-) Tony ------------------------------------------------------------------------------ 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 Sat Aug 27 17:27:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22758; Sat, 27 Aug 94 17:27:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22746; Sat, 27 Aug 94 17:27:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05684; Sat, 27 Aug 94 17:24:47 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA05548; Sat, 27 Aug 94 17:24:32 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id RAA11812; Sat, 27 Aug 1994 17:24:30 -0700 Date: Sat, 27 Aug 1994 17:24:30 -0700 From: Tony Li Message-Id: <199408280024.RAA11812@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: Ran Atkinson's message of Sat, 27 Aug 94 19:17:20 GMT <9408271917.aa05819@sundance.itd.nrl.navy.mil> Subject: (IPng) security & source routing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, There is a fundamental problem with source routes from a security perspective: one CANNOT dependably identify the origin of the data unless authentication is used on source-routed packets. True. However, your statement is too strong. One cannot dependably identify the origin of the data unless authentication is used on packets. Please explain why source routing makes a difference... Source routing attacks are currently happening in the current IPv4 Internet. I really don't think we can ignore them. There is no good reason that source-routed packets can't be authenticated using the defined Authentication Header, which is both mandatory to implement and (apparently) easily exported. Actually, we have some very interesting and simple applications which require EXACTLY this. For example, we would like to include the ability to add source routing to an existing packet. However, this may not happen at the source. An application for this is with provider selection. We would very much like to allow the net admin to control the few machines which constitute domain border routers and NOT have to manage provider selection by controlling all hosts in the domain. No one is saying not to use source routing, just that source routing needs authentication. Even unidirectional source routes create this problem -- without authentication there is no dependable way to know who sent the packet. Without authentication neither hosts, nor firewalls, nor routers can dependably identify the actual source of the source-routed packets. Please don't mistake my security concerns for a dislike of source routing; I happen to think that source routing is a very handy tool in a number of circumstances. If I'm confused, which is possible, then please educate me on how a receiver or intermediate router can dependably identify the source of a source-routed packet that lacks authentication and encryption. Suppose that there is a permutation of a source route header whereby the source route itself is NOT included in the authentication computation. Use the mechanisms for computing authentication as you've described them already. I believe that you should be happy as you can perform the authentication of the IPv6 fixed header and the other authenticated headers. If you do this, I believe that you can say "this packet came from fred.pizzahut.com". You cannot say "this packet came through PizzaNet". Note that you MAY also have authenticated source routes. If I'm being clueless, please rent me one.... In the meantime, I think it's dinnertime. ;-) Tony ------------------------------------------------------------------------------ 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 Sat Aug 27 17:35:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22781; Sat, 27 Aug 94 17:35:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22775; Sat, 27 Aug 94 17:35:29 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05868; Sat, 27 Aug 94 17:32:41 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA05959; Sat, 27 Aug 94 17:32:25 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id RAA20937; Sat, 27 Aug 1994 17:31:53 -0700 Date: Sat, 27 Aug 1994 17:31:53 -0700 From: Tony Li Message-Id: <199408280031.RAA20937@lager.cisco.com> To: haas@ski.utah.edu Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Tired of the Information Superhype's message of Sat, 27 Aug 94 08:55:30 MDT <199408271455.IAA16364@ski.utah.edu> Subject: (IPng) cluster addresses and routing and such.... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Tired of the Information Superhype Wrong place to turn, methinks. ;-) >Suppose that my local subnet is 131.108.0.0/24. Using current IP notation, I believe this is illegal, isn't it? Subnet addresses have different constraints than Class C addresses. According to current RFCs, yes. However, if you follow out the implications of CIDR, you find that you can have some severe problems if you do this in all cases. Thus, there is work underway to declare this to be legal. Note that you do have to run classless routing protocols to deal with this. RFC 1519 does discuss this in some detail. You'll find that ISPs are the ones most affected by this. >How then can a host, located outside of the 131.108.0.0/16 aggregate, >address a packet to the cluster 131.108.0.0/24? The destination >address in the packet would contain 131.108.0.0, which is now >ambiguous. IPv4 deals with this by making the address class disambiguate the notation. Probably a good idea. An address class? What's that? ;-) Tony ------------------------------------------------------------------------------ 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 Sat Aug 27 17:42:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22793; Sat, 27 Aug 94 17:42:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22787; Sat, 27 Aug 94 17:42:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05994; Sat, 27 Aug 94 17:39:53 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA06206; Sat, 27 Aug 94 17:39:37 PDT Received: from relay.imsi.com by wintermute.imsi.com id UAA17670 for ; Sat, 27 Aug 1994 20:39:36 -0400 Received: from snark.imsi.com by relay.imsi.com id UAA24650 for ; Sat, 27 Aug 1994 20:39:35 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA08753; Sat, 27 Aug 94 20:39:35 EDT Message-Id: <9408280039.AA08753@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing In-Reply-To: Your message of "Sat, 27 Aug 1994 17:24:30 PDT." <199408280024.RAA11812@lager.cisco.com> X-Reposting-Policy: redistribute only with permission Date: Sat, 27 Aug 1994 20:39:34 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony Li says: > True. However, your statement is too strong. One cannot dependably > identify the origin of the data unless authentication is used on > packets. Please explain why source routing makes a difference... Source routing allows attacks in which the attacker can masquerade as another host even for connection oriented service. Without source routing, you can at best fire packets at a host without being able to get the replies. Ran is completely right -- this is FAR worse. Perry ------------------------------------------------------------------------------ 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 Sat Aug 27 17:55:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22806; Sat, 27 Aug 94 17:55:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22800; Sat, 27 Aug 94 17:55:26 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06231; Sat, 27 Aug 94 17:52:38 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA06604; Sat, 27 Aug 94 17:52:15 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id RAA12968; Sat, 27 Aug 1994 17:52:14 -0700 Date: Sat, 27 Aug 1994 17:52:14 -0700 From: Tony Li Message-Id: <199408280052.RAA12968@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) security & source routing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Source routing allows attacks in which the attacker can masquerade as another host even for connection oriented service. Without source routing, you can at best fire packets at a host without being able to get the replies. Ran is completely right -- this is FAR worse. Is he? Are we doing security by half-measures? I thought we were supposed to design in strong security from the start. Either you have some means of trusting parts of the packet or you don't. In my book IPv4's "best-effort" security just doesn't cut the mustard. Tony ------------------------------------------------------------------------------ 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 Sat Aug 27 18:16:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22834; Sat, 27 Aug 94 18:16:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22828; Sat, 27 Aug 94 18:16:19 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06659; Sat, 27 Aug 94 18:13:32 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA07177; Sat, 27 Aug 94 18:13:16 PDT Received: from relay.imsi.com by wintermute.imsi.com id VAA17693 for ; Sat, 27 Aug 1994 21:13:15 -0400 Received: from snark.imsi.com by relay.imsi.com id VAA24860 for ; Sat, 27 Aug 1994 21:13:15 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA08820; Sat, 27 Aug 94 21:13:14 EDT Message-Id: <9408280113.AA08820@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing In-Reply-To: Your message of "Sat, 27 Aug 1994 17:52:14 PDT." <199408280052.RAA12968@lager.cisco.com> X-Reposting-Policy: redistribute only with permission Date: Sat, 27 Aug 1994 21:13:14 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony Li says: > Source routing allows attacks in which the attacker can masquerade as > another host even for connection oriented service. Without source > routing, you can at best fire packets at a host without being able to > get the replies. > > Ran is completely right -- this is FAR worse. > > Is he? Are we doing security by half-measures? No. We are recognising that there are several kinds of threat model. We cannot impose authentication on everyone at all times, as much as that would be nice. Given that, one must recognise that bogus source route attacks are a distinct escalation of threat. > I thought we were supposed to design in strong security from the > start. Thats true, and the plan is to try to make implementation of the authentication header mandatory. However, there will be circumstances like high speed connections in closed LANs in which mandatory use of the header would be too much of a burden. Therefore, the notion is to try to make things mandatory only on things that are felt to always be an unacceptable threat, and as Steve Bellovin, Ran, and many others have noted, the games that can be played with source routes are far, far worse than those you can play without them. There are a few other things I'd also like to see authentication made mandatory on, by the way -- routing packets being one of them, since attacks on the routing infrastructure could be made by an informed attacker that could shut down the internet. That, however, is another topic. Perry ------------------------------------------------------------------------------ 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 Sat Aug 27 18:51:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22855; Sat, 27 Aug 94 18:51:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22849; Sat, 27 Aug 94 18:51:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07310; Sat, 27 Aug 94 18:48:22 PDT Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA08576; Sat, 27 Aug 94 18:48:06 PDT Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id VAA20475 for ipng@sunroof.Eng.Sun.COM; Sat, 27 Aug 1994 21:48:05 -0400 Date: Sat, 27 Aug 1994 21:48:05 -0400 From: Vadim Antonov Message-Id: <199408280148.VAA20475@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > You never asked me about EID's and you probably never read my paper > on the subject (ftp from achilles.ctd.anl.gov:/pub/ietf/tcpv11b.txt). As a > strong proponent of EID's (actually transport layer independent addressing) > let me try and give you my slant on this topic. Well, i read the paper and although i agree with the goal i completely disagree with the proposed solution (also, the problems witch TAs are supposed to solve in reality look quite different -- for example, growth of routing tables in not the problem per se given intelligent planning on part of router vendors; routing flap is THE problem). > In order to get from IPv4 to IP6 I need to change the networking code >in all my workstations, servers, and routers. Since not all of them can >change at once, I will wind up with a mix of both. Yes. So what? Is it wise to write a kluge for transition period into canons? There are other ways to get it done without adding new entities for network administrators to have nightmares about. >Dual stacks, compatable >and non-compatable addresses, and IPv4 <--> IP6 translators simply seem to >complacated for my taste. I think there should be an easier way to transition >and that is to use EID's. You still need modifications to the old hosts to be able to communicate with new hosts in the "extended" address space. Communication within old address space can be done by existing stacks. > If TCP would operate over multiple IP layers, then I see an easier >transition path. There is a simple and trivial idea on how to make TCP to be *completely* unaware of the transport locators. The idea is to kill the notion of "one port -- many TCP connections" and replace it with "one port -- one connection". In other words, make the semantics of the network identical to the semantics of the socket interface. The quick fix required is introduction of TCP option "Connection Accepted At" with the value of the new destination transport locator (including port). Well known services create "passive" ports which accept incoming SYNs and reply with the aforementioned option to tell the peer where all following packets should go. The pseudoheader can be simply filled with 0s in this case. For backward compatibility the originating party should use "Connection Rehoming Allowed" option. It is not like having dual stacks but rather 10 to 20 lines of additional code to the existing TCP. I would like to go even further and completely remove the artificial boundary between "insides" of hosts and "outside" i.e. networks -- i.e. to unify port number and host address into single transport locator. It will allow migration of addressable network entities or their unnamed instances. It will also allow things like "ftp xyz.com" to be served by one machine and "telnet xyz.com" by another. As a side advantage you will no longer need to switch incoming packets by protocols and host numbers but *only* by port part of destination transport locator (fast check on single source transport locator can be done then). Consequently, there is no need to carry protocol numbers in data packets anymore (as there is no need to maintain registry of assigned protocol numbers!) Actually, there is a clever idea (by Noel Chiappa, i believe) of how to make all IPv4 applications to work with big addresses w/o *ANY* modifications in application code. The idea is following: when an application does DNS mapping, an IPv4-address-looking number is allocated (sequentially) by the name daemon, installed in the kernel translation table together with the real address and returned as the result of the query to the appliication. Consequential queries resulting in the same big addresses should return the same pseudo-IPv4 address. Then, when application tries to bind sockets to those pseudo-addresses kernel translates them into real big addressess. > I can clearly see how using EID's would make integrating my prototype >ATM and Fibre Channel networks into my existing IP networks easier. And i can clearly see how *not* integrating it will make it even easier. Please note that i didn't discuss mobility and its implications; however it was beaten on big-internet list for quite a lot of time so i had a chance to put my approach to test. Let's weight pros and cons of both approaches. I will defend my approach, ok? ;-) - No additional bytes in data packets - No new unique entity allocation bureaucracy - Addititonal flexibility in defining advertised services - Single-step name-to-locator resolution - Implementation is inherently more efficient - More privacy in moving machines and people who own the machines. Any reasonable scheme for allocating TAs assumes making them identical to MAC addresses which are often hardwired and unalterable. Reminds me about OJ somehow :-) - It does not multiply entities without necessity (and therefore does not trigger Occam alarm of my bogometer) Regards, --vadim ------------------------------------------------------------------------------ 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 Sat Aug 27 20:05:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22899; Sat, 27 Aug 94 20:05:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22893; Sat, 27 Aug 94 20:05:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AB08778; Sat, 27 Aug 94 20:02:20 PDT Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA12061; Sat, 27 Aug 94 20:02:04 PDT Message-Id: <9408280302.AA12061@Sun.COM> From: smb@research.att.com Received: by gryphon; Sat Aug 27 23:01:52 EDT 1994 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing Date: Sat, 27 Aug 94 23:01:51 EDT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Is he? Are we doing security by half-measures? I thought we were supposed to design in strong security from the start. Either you have some means of trusting parts of the packet or you don't. In my book IPv4's "best-effort" security just doesn't cut the mustard. IPv4's address-based security -- such as it is! -- works at all because subverting it usually means subverting the routing infrastructure of (a piece of) the Internet. (No, routing subversion is not the only attack, but it is the one under discussion here; please don't quote back to me what I wrote up five years ago.) The problem with source routing is that it breaks that assumption; an attacker can launch a fine-grained attack on a single connection. If source routing is to be supported at all -- and I'm not arguing that point -- we must have an absolute rule that no service may (a) use address-based authentication, and (b) accept source-routed packets. (I should note that this is already done by some implementations of rlogind and rshd for IPv4. I further note that the main reason we haven't seen serious attacks based on source routing is that people don't use it because of its effect on router performance -- and that in turn means that host implementations are pretty buggy; source routed packets are likely to be a denial of service attack, since they can crash the machines involved....) Frankly, I reject that rule I'm positing. The IPng requirements mandate strong authentication precisely because there are other attacks on address-based authentication, and because source routing is useful. In other words, I claim that we should satisfy the rule by ensuring that clause (a) is always false. Let's not only declare address-based authentication dead, let's drive a steak through its heart, and let it die of cholesterol poisoning. If a service requires authentication, it should do it for real. I still have a 4.2bsd manual around; under BUGS for rlogind and rshd, it says The authentication procedure used here assumes the integrity of each client machine and the connecting medium. This is insecure, but is useful in an "open" environment. That paragraph is still present on SunOS 4.1.3, IRIX 5.2, and BSDI, and probably on most of their cousins as well. Let's finally be able to scrawl ``FIXED in IPv6'' across it. I should note that I agree with Tony that end-to-end authentication says nothing about the integrity of the source route. So be it -- I don't see what that matters, as a rule, if you have end-to-end authentication and encryption. If you're really worried about it, you can fake it by using nested IP-in-IP, albeit at a high cost. But I'm not going to worry about the problem unless and until someone can convince me that it really matters in the real world. --Steve Bellovin P.S. *What* are we arguing about? I didn't think anyone questioned the problems with source routing and address-based authentication. Has a requirement that we support it slithered back in? ------------------------------------------------------------------------------ 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 Sat Aug 27 20:05:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22911; Sat, 27 Aug 94 20:05:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22905; Sat, 27 Aug 94 20:05:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08794; Sat, 27 Aug 94 20:03:01 PDT Received: from tymix.Tymnet.COM by Sun.COM (sun-barr.Sun.COM) id AA12099; Sat, 27 Aug 94 20:02:39 PDT Received: by tymix.Tymnet.COM (4.1/SMI-4.1) id AA05461; Sat, 27 Aug 94 20:02:34 PDT Received: from puff by tymix.Tymnet.COM (in.smtpd); 27 Aug 94 20:02:34 PDT Received: by puff.Tymnet.COM (8.6.8.1/UCB) id UAA06537; Sat, 27 Aug 1994 20:02:33 -0700 Date: Sat, 27 Aug 1994 20:02:33 -0700 From: krumvp@spiff.Tymnet.COM (Paul Krumviede) Message-Id: <199408280302.UAA06537@puff.Tymnet.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199408280052.RAA12968@lager.cisco.com> (message from Tony Li on Sat, 27 Aug 1994 17:52:14 -0700) Subject: Re: (IPng) security & source routing Content-Type: text Content-Length: 229 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Out of curiosity, would it be possible to only reverse those source routes in fully authenticated packets? This would seem to address the concern of address spoofing, while allowing some of the things that Tony mentioned. -paul ------------------------------------------------------------------------------ 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 Sat Aug 27 23:26:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23023; Sat, 27 Aug 94 23:26:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23017; Sat, 27 Aug 94 23:25:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12745; Sat, 27 Aug 94 23:23:07 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA19306; Sat, 27 Aug 94 23:22:51 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA03662; Sat, 27 Aug 1994 23:22:50 -0700 Date: Sat, 27 Aug 1994 23:22:50 -0700 From: Tony Li Message-Id: <199408280622.XAA03662@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: smb@research.att.com's message of Sat, 27 Aug 94 23:01:51 EDT <9408280302.AA12061@Sun.COM> Subject: (IPng) security & source routing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM P.S. *What* are we arguing about? I didn't think anyone questioned the problems with source routing and address-based authentication. Has a requirement that we support it slithered back in? What we're discussing (we need another 10db to be arguing ;-) is whether unauthenticated source routes are permissible in IPv6. I think you and I are in complete agreement. "If a service requires authentication, it should do it for real." Paint that up on the wall along with "be conservative in what you send, liberal in what you receive". Tony ------------------------------------------------------------------------------ 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 Sun Aug 28 03:12:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23189; Sun, 28 Aug 94 03:12:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23177; Sun, 28 Aug 94 03:12:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20196; Sun, 28 Aug 94 03:09:30 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA02828; Sun, 28 Aug 94 03:09:01 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) security & source routing To: ipng@sunroof.Eng.Sun.COM Date: Sun, 28 Aug 1994 11:06:18 +0200 (BST) Cc: ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: <199408280024.RAA11812@lager.cisco.com> from "Tony Li" at Aug 27, 94 05:24:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1251 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Suppose that there is a permutation of a source route header whereby > the source route itself is NOT included in the authentication > computation. Use the mechanisms for computing authentication as > you've described them already. I believe that you should be happy as > you can perform the authentication of the IPv6 fixed header and the > other authenticated headers. > > If you do this, I believe that you can say "this packet came from > fred.pizzahut.com". You cannot say "this packet came through > PizzaNet". This sounds very sensible. From a security perspective most routers already say if source_routed the destination=dustbin. Being able to say if source_routed and !matches our encryption then destination=dustbin is more useful. However it's all yet another complexity, another task routers must handle. Given the rare use of source routing it would have been better (IMHO) to have dropped source routing entirely and left it up to intelligent use of IPng over IPng tunneling eliminating another special case from all the routers in the world. Granted it means more setup work since you have to prepare the targets of your source route to do IPng/IPng but it doesn't impact the world for one occasionally useful tool. Alan ------------------------------------------------------------------------------ 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 Sun Aug 28 03:12:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23190; Sun, 28 Aug 94 03:12:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23183; Sun, 28 Aug 94 03:12:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20200; Sun, 28 Aug 94 03:09:35 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA02836; Sun, 28 Aug 94 03:09:18 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) security & source routing To: ipng@sunroof.Eng.Sun.COM Date: Sun, 28 Aug 1994 11:06:18 +0200 (BST) Cc: ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: <199408280024.RAA11812@lager.cisco.com> from "Tony Li" at Aug 27, 94 05:24:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1251 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Suppose that there is a permutation of a source route header whereby > the source route itself is NOT included in the authentication > computation. Use the mechanisms for computing authentication as > you've described them already. I believe that you should be happy as > you can perform the authentication of the IPv6 fixed header and the > other authenticated headers. > > If you do this, I believe that you can say "this packet came from > fred.pizzahut.com". You cannot say "this packet came through > PizzaNet". This sounds very sensible. From a security perspective most routers already say if source_routed the destination=dustbin. Being able to say if source_routed and !matches our encryption then destination=dustbin is more useful. However it's all yet another complexity, another task routers must handle. Given the rare use of source routing it would have been better (IMHO) to have dropped source routing entirely and left it up to intelligent use of IPng over IPng tunneling eliminating another special case from all the routers in the world. Granted it means more setup work since you have to prepare the targets of your source route to do IPng/IPng but it doesn't impact the world for one occasionally useful tool. Alan ------------------------------------------------------------------------------ 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 Sun Aug 28 03:19:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23209; Sun, 28 Aug 94 03:19:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23203; Sun, 28 Aug 94 03:19:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20315; Sun, 28 Aug 94 03:16:34 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA03153; Sun, 28 Aug 94 03:16:16 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) millions of OSI products To: ipng@sunroof.Eng.Sun.COM Date: Sun, 28 Aug 1994 11:13:34 +0200 (BST) In-Reply-To: <199408280148.VAA20475@titan.sprintlink.net> from "Vadim Antonov" at Aug 27, 94 09:48:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 572 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The pseudoheader can be simply filled with 0s in this case. For > backward compatibility the originating party should use "Connection > Rehoming Allowed" option. It is not like having dual stacks but > rather 10 to 20 lines of additional code to the existing TCP. Why so much obsession with dual stacks. If the TCP code is layered ok one TCP layer will handle both IP and IPng. The upper layer has few decisions to make on a per protocol basis (checksum, and user side addressing view/opts). Dual stack is a bit of an exaggeration in the size of the problem. Alan ------------------------------------------------------------------------------ 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 Sun Aug 28 03:22:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23221; Sun, 28 Aug 94 03:22:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23215; Sun, 28 Aug 94 03:22:26 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20357; Sun, 28 Aug 94 03:19:39 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA03217; Sun, 28 Aug 94 03:19:14 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) security & source routing To: ipng@sunroof.Eng.Sun.COM Date: Sun, 28 Aug 1994 11:16:29 +0200 (BST) In-Reply-To: <199408280302.UAA06537@puff.Tymnet.COM> from "Paul Krumviede" at Aug 27, 94 08:02:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 553 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Out of curiosity, would it be possible to only reverse those source routes > in fully authenticated packets? This would seem to address the concern of > address spoofing, while allowing some of the things that Tony mentioned. No because I can subvert a router and issue packets that have half of the source route made up. The reply would hit the subverted router and be acquired by my software. All you would know is that somewhere along the route was the trouble. It's also a half measure because some attacks don't need replies to succeed. Alan ------------------------------------------------------------------------------ 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 Sun Aug 28 05:04:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23278; Sun, 28 Aug 94 05:04:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23272; Sun, 28 Aug 94 05:04:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24597; Sun, 28 Aug 94 05:01:15 PDT Received: from hsdndev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA04986; Sun, 28 Aug 94 05:00:58 PDT Date: Sun, 28 Aug 94 08:00:46 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9408281200.AA22835@hsdndev.harvard.edu> To: iialan@iifeak.swan.ac.uk Subject: Re: (IPng) security & source routing Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, > dropped source routing entirely some others have also suggested that but many of the advanced routing people seem to think that source routing (or things that look like source routing) are in our future. Take a looks at SDRP for example. Scott ------------------------------------------------------------------------------ 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 Sun Aug 28 07:53:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23350; Sun, 28 Aug 94 07:53:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23344; Sun, 28 Aug 94 07:53:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00888; Sun, 28 Aug 94 07:50:27 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA07871; Sun, 28 Aug 94 07:50:10 PDT To: tli@cisco.com Subject: (IPng) source routing & authentication Cc: ip-ng@sunroof2.Eng.Sun.COM Date: Sun, 28 Aug 94 15:46:32 GMT From: Ran Atkinson Message-Id: <9408281546.aa06200@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony, I've been assuming that you might have both unidirectional and bidirectional source routing in mind. The cases are a bit different from a security perspective, I suspect. You are almost certainly correct that my prior statement was overly broad. I'd like to talk about how that statement should be narrowed to still provide important authentication capabilities while supporting appropriate uses of source routing. First, Steve Bellovin is quite correct that the current practice of "authenticating" (sic) based on source address really needs to be deprecated because it isn't really authentication and isn't secure. I'm not sure how to deprecate it in the real world, particularly with the (very useful to some folks) TCP Wrapper code being so widespread these days. Ideas on how we "make it so" are solicited. Ideas that involve implementation tweaks might be feasible if proposed this fall, but aren't very feasible much after the end of 1994 because there are several real implementations out there. One item that was brought up last Monday at the IPng Open Design Review talk on the MBONE is that perhaps we need to identify some set of "important" packets (e.g. TCP OPEN, TCP FIN, TCP FIN ACK) that should always be authenticated end-to-end. Suggestions on which packets are "important" should be emailed to me (Ran) and I'll summarise back to the list. With bidirectional source routing, the receiver should never reverse the claimed source route from the source unless the source route information is included in (at least) end-to-end authentication with the Authentication Header. I've been thinking that this might reasonably be narrowed to (1) when the bidirectional source route first appears and (2) when the bidirectional source route information changes for some reason. When unidirectional source routing is inserted at some intermediate point for provider selection, then authentication of that source route might not always be necessary so long as the rest of the packet really is authenticated end-to-end on all "important" packets (these "important" packets need to be clearly defined; see above for possible examples) AND we are not attempting to use RSVP or some other resource reservation protocol to get predictable QoS. If we are using RSVP or some similar resource reservation protocol, then intermediate routers might well want/need to authenticate every Nth packet, including the unidirectional source route, to protect the provided QoS in the manner described in the IAB Security Retreat RFC. I understand that this would imply that some routers might have copies of a symmetric authentication key in use between source and destination. Such "trusted" routers could actually insert the unidirectional source route and recompute the authentication, though the computational cost of recomputing authentication should not be underestimated. Thoughts ? Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ 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 Sun Aug 28 07:57:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23390; Sun, 28 Aug 94 07:57:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23384; Sun, 28 Aug 94 07:57:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01006; Sun, 28 Aug 94 07:54:30 PDT Received: from MVS.OAC.UCLA.EDU by Sun.COM (sun-barr.Sun.COM) id AA08033; Sun, 28 Aug 94 07:54:14 PDT Message-Id: <9408281454.AA08033@Sun.COM> Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1) with BSMTP id 5305; Sun, 28 Aug 94 07:54:10 PST Date: Sun, 28 Aug 94 07:53 PDT To: ipng@SUNROOF.Eng.Sun.COM From: Michael Stein Subject: (IPng) TCP pseudoheader & checksums Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > The pseudoheader can be simply filled with 0s in this case. Which removes the check if this packet is really for this connection. Isn't this part of TCP's end-to-end check? And isn't this needed even more in IPv6 since the IP header checksum was dropped? > > For > > backward compatibility the originating party should use "Connection > > Rehoming Allowed" option. It is not like having dual stacks but > > rather 10 to 20 lines of additional code to the existing TCP. > > Why so much obsession with dual stacks. If the TCP code is layered ok > one TCP layer will handle both IP and IPng. The upper layer has few decisions > to make on a per protocol basis (checksum, and user side addressing view/opts) On the Mbone IPv6 overview, the following address mappings into IPv6 space were described: IPv6 address of a IPv4 only host: 10 bytes of zeros followed by 0000 IPv6 address of a IPv6 & IPv4 host with an IPv4 address: 10 bytes of zeros followed by FFFF The trick here is that the TCP checksums of each of these are the same. And they also match the checksum of just the IPv4 address. So no special checksum code is really needed in TCP on an IPv6 host other than to checksum the longer header -- it doesn't matter if the other side is IPv6 or IPv4. > Dual stack is a bit of an exaggeration in the size of the problem. Exactly. ------------------------------------------------------------------------------ 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 Sun Aug 28 08:22:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23556; Sun, 28 Aug 94 08:22:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23539; Sun, 28 Aug 94 08:22:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01955; Sun, 28 Aug 94 08:19:14 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA08852; Sun, 28 Aug 94 08:18:56 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA19726; Sun, 28 Aug 94 11:14:55 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9408281514.AA19726@pluto.dss.com> Subject: Re: (IPng) source routing & authentication To: ipng@sunroof.Eng.Sun.COM Date: Sun, 28 Aug 1994 11:14:53 -0400 (EDT) Cc: tli@cisco.com, ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: <9408281546.aa06200@sundance.itd.nrl.navy.mil> from "Ran Atkinson" at Aug 28, 94 03:46:32 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1681 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Tony, > One item that was brought up last Monday at the IPng Open Design > Review talk on the MBONE is that perhaps we need to identify some set > of "important" packets (e.g. TCP OPEN, TCP FIN, TCP FIN ACK) that > should always be authenticated end-to-end. Suggestions on which > packets are "important" should be emailed to me (Ran) and I'll > summarise back to the list. I probably should have said something on Monday, but it was the first time I had ever attended an IETF related meeting. These attempts to specify the "important" packets are almost invariably ill-considered and suggest a certain naivete with respect to internetworking issues. Everyone considers those packets nearest and dearest to his heart, work or expertise the "important" packets. Rose has explicitly stated that as networks fail priority must be given to management traffic. Rob Coltun told me that during periods of congestion routing protocol packets should be given priority. And of course those worried about applications would probably claim data packets associated with their favorite application are the highest priority. As for considering various TCP circuit control packets the "important" packets. If my most critical application were NFS file service provided by a machine managed by SNMP (a disgusting concept I admit), I doubt I would consider any TCP packets important. > Thoughts ? > Ran > atkinson@itd.nrl.navy.mil Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com ------------------------------------------------------------------------------ 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 Sun Aug 28 08:22:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23557; Sun, 28 Aug 94 08:22:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23549; Sun, 28 Aug 94 08:22:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01961; Sun, 28 Aug 94 08:19:21 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA08863; Sun, 28 Aug 94 08:19:04 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA19726; Sun, 28 Aug 94 11:14:55 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9408281514.AA19726@pluto.dss.com> Subject: Re: (IPng) source routing & authentication To: ipng@sunroof.Eng.Sun.COM Date: Sun, 28 Aug 1994 11:14:53 -0400 (EDT) Cc: tli@cisco.com, ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: <9408281546.aa06200@sundance.itd.nrl.navy.mil> from "Ran Atkinson" at Aug 28, 94 03:46:32 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1681 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Tony, > One item that was brought up last Monday at the IPng Open Design > Review talk on the MBONE is that perhaps we need to identify some set > of "important" packets (e.g. TCP OPEN, TCP FIN, TCP FIN ACK) that > should always be authenticated end-to-end. Suggestions on which > packets are "important" should be emailed to me (Ran) and I'll > summarise back to the list. I probably should have said something on Monday, but it was the first time I had ever attended an IETF related meeting. These attempts to specify the "important" packets are almost invariably ill-considered and suggest a certain naivete with respect to internetworking issues. Everyone considers those packets nearest and dearest to his heart, work or expertise the "important" packets. Rose has explicitly stated that as networks fail priority must be given to management traffic. Rob Coltun told me that during periods of congestion routing protocol packets should be given priority. And of course those worried about applications would probably claim data packets associated with their favorite application are the highest priority. As for considering various TCP circuit control packets the "important" packets. If my most critical application were NFS file service provided by a machine managed by SNMP (a disgusting concept I admit), I doubt I would consider any TCP packets important. > Thoughts ? > Ran > atkinson@itd.nrl.navy.mil Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com ------------------------------------------------------------------------------ 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 Sun Aug 28 08:54:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23631; Sun, 28 Aug 94 08:54:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23625; Sun, 28 Aug 94 08:54:12 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02616; Sun, 28 Aug 94 08:51:25 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA10132; Sun, 28 Aug 94 08:51:08 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29611; Mon, 29 Aug 1994 01:51:03 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) source routing & authentication In-Reply-To: Your message of "Sun, 28 Aug 1994 11:14:53 -0400." <9408281514.AA19726@pluto.dss.com> Date: Mon, 29 Aug 1994 01:50:57 +1000 Message-Id: <3141.778089057@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Sun, 28 Aug 1994 11:14:53 -0400 (EDT) From: martillo@pluto.dss.com (Joachim Martillo) Message-ID: <9408281514.AA19726@pluto.dss.com> These attempts to specify the "important" packets are almost invariably ill-considered and suggest a certain naivete with respect to internetworking issues. You're mis-interpreting "important" here - or perhaps Ran didn't say what he meant quite clearly enough. The issue is whether authenticating some subset of packets might give adequate security performance - ie: whether the security (authentication security) provided by an overall system where only some packets are authenticated is adequate for some definition of adequate. If so, then the object is to identify exactly which packets need to be authenticated to provide a suitable level of confidence. Whatever packets are identified there are the "important" ones in this context. None of this has anything whatever to do with any other notions of what might be an important packet - for which you're right, there might be lots of interpretations in different contexts. Further, the use of "important" here should basically result in a non subjective set. kre ------------------------------------------------------------------------------ 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 Sun Aug 28 08:56:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23643; Sun, 28 Aug 94 08:56:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23637; Sun, 28 Aug 94 08:56:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02655; Sun, 28 Aug 94 08:53:33 PDT Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA10231; Sun, 28 Aug 94 08:53:10 PDT Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 28 Aug 1994 16:47:17 +0100 To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPng slotting into kernels..... Date: Sun, 28 Aug 94 16:47:14 +0100 Message-Id: <2806.778088834@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM on unix ip6 problems? currently, we experiemnt with new protocols by just reconfiguing kernels (e.g. most mbone work, and some early sip and pip experiements worked fine that way) not only do 16 byte addrs not go in a struct sockaddr, so you need recompile (i.e. source) of kernels to work on this - i.e. the community helping out won't include people like us [as we're mainly solaris based for research/kernel work]:-( but also, i note that ip6 with 16 byte addrs now may not fit into the end of an mbuf with any options and a TCP/UDP header with space to prepend a link layer header....so 4.4BSD derivative people have something else to worry about... on header compression: audio ( a thing we do a lot) typically can be compressed to 14kbps very easily. if i'm sending RTP/UDP/IP6, multicast audio from home (say from my 2*64kbps ISDN home itnernet access), am i gonna have problems figuring out where to do header compression? does sensible addr allocation for aggregation help with compression? if it does, and does everywhere, couldn't we have used smaller addresses:-)? anyhow, is there a pre-alpha ip6 BSD style implementaton we can look at/help/port-to-SVID? cheers jon ------------------------------------------------------------------------------ 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 Sun Aug 28 09:02:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23663; Sun, 28 Aug 94 09:02:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23657; Sun, 28 Aug 94 09:02:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02759; Sun, 28 Aug 94 09:00:01 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA10530; Sun, 28 Aug 94 08:59:37 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29892; Mon, 29 Aug 1994 01:59:34 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Service providers beware! In-Reply-To: Your message of "Wed, 24 Aug 1994 10:17:27 MST." <199408241717.KAA05907@netcom11.netcom.com> Date: Mon, 29 Aug 1994 01:59:27 +1000 Message-Id: <3146.778089567@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 24 Aug 1994 10:17:27 -0700 From: kck@netcom.com (Richard Fox) Message-ID: <199408241717.KAA05907@netcom11.netcom.com> >Christian Huitema >I do not think that nailing down all the details of the future addressing plan >makes much sense today. So I think we need to nail down what we can and hopefully NOT have to change in a couple of years. I think you're misunderstanding what Christian meant. I don't believe he intended that the addressing plan be changed after deployment, but that the addressing plan isn't critical until we're ready to start deploying IPv6. Before then there are more important issues to solve - protocols to get defined, and implementations to create. Once all that is done, there will be something of a lull while the final touches are added to the implementations, distribution is sorted out, etc - that might be the right time to get the addressing plan sorted out. kre ------------------------------------------------------------------------------ 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 Sun Aug 28 11:37:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23840; Sun, 28 Aug 94 11:37:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23834; Sun, 28 Aug 94 11:37:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06133; Sun, 28 Aug 94 11:34:50 PDT Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA16095; Sun, 28 Aug 94 11:34:28 PDT Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id OAA22215 for ipng@SUNROOF.Eng.Sun.COM; Sun, 28 Aug 1994 14:34:27 -0400 Date: Sun, 28 Aug 1994 14:34:27 -0400 From: Vadim Antonov Message-Id: <199408281834.OAA22215@titan.sprintlink.net> To: ipng@SUNROOF.Eng.Sun.COM Subject: Re: (IPng) TCP pseudoheader & checksums Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Which removes the check if this packet is really for this >connection. Isn't this part of TCP's end-to-end check? And >isn't this needed even more in IPv6 since the IP header checksum >was dropped? I would think that the threat of mis-directed packets is greatly exaggregated. How often does it happen in the real life? Please have in mind that destination transport locator is usually checked, so the only "wrong" which can happen is bad port number. Inclusion of pseudoheader in TCP checksum calculation is only meaningful in one port -- many connections paradigm. This problem can be easily dealt with in my model by assigning random port numbers out of, say, lower 8 bytes of 16-byte IPng address. This is much stronger than TCP checksum! It also provides reasonable source authentication for established sessions (i.e. there is no need to authenticate data packets if they came to the right port), this does not provide protection against sniffing, but for all practical purposes eliminates possiblity of attacks on established TCP sessions and unpublished ports (i.e. ports not associated with DNS names). Just by deciding which sets of DNS names should be visible from "inside" and "outside" the company users could effectively control the access -- providing that ports are assigned randomly out of large space. The sniffer-secure variant of this scheme may include "jumping" ports, with port numbers generated with some strong encryption depending on time and key. As you see, *not* including TAs or TLs into things known at TCP level provides lots of opportunities for various neat tricks :-) --vadim ------------------------------------------------------------------------------ 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 Sun Aug 28 12:39:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24003; Sun, 28 Aug 94 12:39:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23997; Sun, 28 Aug 94 12:39:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07674; Sun, 28 Aug 94 12:36:55 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA18379; Sun, 28 Aug 94 12:36:39 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA14292; Sun, 28 Aug 1994 12:36:35 -0700 Date: Sun, 28 Aug 1994 12:36:35 -0700 From: Tony Li Message-Id: <199408281936.MAA14292@lager.cisco.com> To: atkinson@sundance.itd.nrl.navy.mil Cc: ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: Ran Atkinson's message of Sun, 28 Aug 94 15:46:32 GMT <9408281546.aa06200@sundance.itd.nrl.navy.mil> Subject: (IPng) source routing & authentication Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, I agree completely, however the thought of a trusted router with my key is more than disturbing. Can you say "central attack point"? ;-) I do have to question whether your example of RSVP really requires that level of complexity, tho. I would expect that RSVP would identify a flow. As the flow id is in the fixed header and authenticated, is this not sufficient? The intermediate router establishes authentication of the flow when it receives the RSVP setup, and then verifies the authentication (probably statistically) on the running flow. Tony ------------------------------------------------------------------------------ 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 Sun Aug 28 17:02:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24299; Sun, 28 Aug 94 17:02:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24293; Sun, 28 Aug 94 17:02:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13628; Sun, 28 Aug 94 16:59:21 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA27361; Sun, 28 Aug 94 16:59:05 PDT Received: from relay.imsi.com by wintermute.imsi.com id TAA18651 for ; Sun, 28 Aug 1994 19:59:03 -0400 Received: from snark.imsi.com by relay.imsi.com id TAA01283 for ; Sun, 28 Aug 1994 19:59:03 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA09817; Sun, 28 Aug 94 19:59:02 EDT Message-Id: <9408282359.AA09817@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing In-Reply-To: Your message of "Sat, 27 Aug 1994 23:22:50 PDT." <199408280622.XAA03662@lager.cisco.com> X-Reposting-Policy: redistribute only with permission Date: Sun, 28 Aug 1994 19:59:02 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony Li says: > P.S. *What* are we arguing about? I didn't think anyone questioned > the problems with source routing and address-based authentication. > Has a requirement that we support it slithered back in? > > What we're discussing (we need another 10db to be arguing ;-) is > whether unauthenticated source routes are permissible in IPv6. > > I think you and I are in complete agreement. Does that mean that we all agree that unauthenticated source routes are impermissable? Perry ------------------------------------------------------------------------------ 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 Sun Aug 28 17:16:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24332; Sun, 28 Aug 94 17:16:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24326; Sun, 28 Aug 94 17:16:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13986; Sun, 28 Aug 94 17:13:29 PDT Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA27977; Sun, 28 Aug 94 17:13:12 PDT Message-Id: <9408290013.AA27977@Sun.COM> From: smb@research.att.com Received: by gryphon; Sun Aug 28 20:12:25 EDT 1994 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing Date: Sun, 28 Aug 94 20:12:25 EDT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony Li says: > P.S. *What* are we arguing about? I didn't think anyone questio ned > the problems with source routing and address-based authentication . > Has a requirement that we support it slithered back in? > > What we're discussing (we need another 10db to be arguing ;-) is > whether unauthenticated source routes are permissible in IPv6. > > I think you and I are in complete agreement. Does that mean that we all agree that unauthenticated source routes are impermissable? ``Unauthenticated source routes'' are impermissible *if* the service is using address-based authentication. I don't care who send a source-routed connection message to, say, my echo server. ------------------------------------------------------------------------------ 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 Sun Aug 28 17:37:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24358; Sun, 28 Aug 94 17:37:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24352; Sun, 28 Aug 94 17:37:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14479; Sun, 28 Aug 94 17:34:41 PDT Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA28971; Sun, 28 Aug 94 17:34:24 PDT Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id UAA23049 for ipng@sunroof.Eng.Sun.COM; Sun, 28 Aug 1994 20:34:22 -0400 Date: Sun, 28 Aug 1994 20:34:22 -0400 From: Vadim Antonov Message-Id: <199408290034.UAA23049@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > ``Unauthenticated source routes'' are impermissible *if* the service > is using address-based authentication. I don't care who send a > source-routed connection message to, say, my echo server. Even if he sends it at 20 Mbps? Today our operations woke me up at 7:30 because some crazy host at Microsoft started sending a stream of bogons of about that intensity -- enough to kill a small router. If the source address was forged the chances of fixing that fast would be closer to zero. Now, with source-based routing it is easy to produce bogon flooding attack w/o creating noticeable incoming bogon streams -- if you want to kill link between A and B just use path 1 2 3 4 5 A B A B A B A B A B A B A B A B A B More clever attacker could have small bogon streams to converge from different directions to create jam. As an operator of a production network i'm definitely opposed to source based routing! We already had customers who are on courtroom terms with each other and received reports on net terrorism. Serivce providers should *unquestionably* have complete control of routing in their networks. Moving the control to originating hosts may be a nice idea but i somehow doubt it will ever fly in the real world. --vadim ------------------------------------------------------------------------------ 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 Sun Aug 28 17:44:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24382; Sun, 28 Aug 94 17:44:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24376; Sun, 28 Aug 94 17:44:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14672; Sun, 28 Aug 94 17:41:27 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA29398; Sun, 28 Aug 94 17:41:10 PDT Received: from relay.imsi.com by wintermute.imsi.com id UAA18767 for ; Sun, 28 Aug 1994 20:41:09 -0400 Received: from snark.imsi.com by relay.imsi.com id UAA01548 for ; Sun, 28 Aug 1994 20:41:09 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA09916; Sun, 28 Aug 94 20:41:08 EDT Message-Id: <9408290041.AA09916@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing In-Reply-To: Your message of "Sun, 28 Aug 1994 20:12:25 EDT." <9408290013.AA27977@Sun.COM> X-Reposting-Policy: redistribute only with permission Date: Sun, 28 Aug 1994 20:41:08 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM smb@research.att.com says: > Does that mean that we all agree that unauthenticated source routes > are impermissable? > > ``Unauthenticated source routes'' are impermissible *if* the service > is using address-based authentication. I don't care who send a > source-routed connection message to, say, my echo server. True, but I will note that its difficult to enforce such a policy except by stopping all unauthenticated source routed packets. Perry ------------------------------------------------------------------------------ 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 Sun Aug 28 18:36:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24438; Sun, 28 Aug 94 18:36:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24432; Sun, 28 Aug 94 18:36:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15853; Sun, 28 Aug 94 18:33:34 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA01872; Sun, 28 Aug 94 18:32:34 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA16469; Mon, 29 Aug 1994 11:32:18 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA00456; Mon, 29 Aug 94 11:27:14 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00438; Mon, 29 Aug 1994 11:27:13 EST Date: 25 Aug 94 16:55:14 +1000 To: ipng@sunroof.Eng.Sun.COM, /G=kim/S=fenley/OU2=cm-dimp/OU=aditcs/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@x400gw.datacraft.com.au, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, kgk@nic.ott.hookup.net Cc: mo@uunet.uu.net, /S=bruce-steer/O=saa/P=sa/A=telememo/C=au/@x400gw.datacraft.com.au Subject: (IPng) WHAT ELSE -- IPNG AND MADNESS Ua-Content-Id: 940825 13:33:09 P1-Recipient: ipng@sunroof.eng.sun.com, /G=kim/S=fenley/OU2=cm-dimp/OU=aditcs/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@x400gw.datacraft.com.au, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, kgk@nic.ott.hookup.net, mo@uunet.uu.net, /S=bruce-steer/O=saa/P=sa/A=telememo/C=au/@x400gw.datacraft.com.au Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940825 13:33:09 031 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940825165514+1000 deferred 940825165514+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940825165416+1000 deferred 940825165416+1000 action Relayed Message-Id: <"940825 13:33:09"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Gentlefolk. . I hope my comments (although could be considered undiplomatic) are being seen as trying to get some common sence into the debate.. The real issues are to me is the one upgrading the Internet and TCP/IP in the right direction because like it or not the whole IT industry will have to deal with this, the other is the issue of address allocation procedures in the current communications environment. Naturullay if the IETF wish to ignore both of these points, then the IT industry will become I believe fragmented. Simply because of the false beliefs that on one hand, one can deploy a commercially viable "global network" by quick standards and "working code".. The Internet's problems of today prove that is not the case.. ie continually chasing fix up's, hackers, mis use, no or little accountability or accounting or security or defined service levels. Products related to this environment have short lifetimes and have fast a furious market share programs.. ie This week's protocol for lesser and lesser margin.. ie. the process is self defeating because one cannot prove a thousand handcarved protocols in a week for global use and deploy it all over the planet for 5% margin.. and make it work in a large scale commercial network ..if one is commercially liable for its success.. What do the users of large networks think of this approach to their IT infrastructure procurement programs.. Cheap IT chaos!! On the other hand large scale system designers will steer toward carrier/ ISO standards approach to global networking because of the preferred engineering approach, the twenty year lifetime of solutions, the horsepower provided by the carriers and media industries combined and the ablity to adminster the radio/ satellite spectrum, addressing schemes and international public services.. Obviously I have little desire to see this fragmentation but given the choice I will direct my energies to the longer term stable, global IT environments rather than the fast a furious, self defeating approach to IT.. Addressing::The burning question. ouch! On the addressing issue the debate should be supported by recognising that we all use the telephone numbering schemes with comfort because they are a unique across the planet.. They are formally assigned.. by the ITU and carriers / regulatory bodies within the respective countries... Now hopefully we all see the benefit of this and do realise that even in a deregulated environment, that the network numbering schemes for international working must be global, unique and administered by recognised authorities.. otherwise global chaos will result. In the Internet case where TCP/IP started life as an interconnectivity tool for LANs, the addressing was "just a funny number". ie It had local significance only. Applied globally though..a limited number form obvious problems will creep in.. scale, allocation, duplication, routing algorithms, etc, etc.. Given a fundamental rule of mine is "the first action of any network design is to determine its naming and addressing scheme " simply because getting it wrong means digging it up (and switching the network off).. the internet in my eyes has a serious problem. Ie how will it manage this upgrade and more importantly how will it be done and who is going to pay? The point here is there will be a massive cost to change the IP equipment on this planet.. Is there any guarentee that IPv6 will work or be recognised by aviation, transport, government systems, mobile systems, ships, aircraft.. probably not. Why? because the consensus mode and working code approach to development cannot be applied to the administrative and commercial aspects of multi/international commercial operations.. One cannot design a carriers or major industries technical and operational interfaces with other carriers/organisations in a few RFCs on a week end! Perhaps the marketing people in the multi national IT organisations should question what is really happening to the stability of product with this "consensus" and rapid approach to development. Deregulation and Statutary bodies. This may seem a weird one but it could get overlooked.. I will crystal ball a bit here.. The carriers are deregulated and because of this Australia has set up a regulatory board called AUSTEL which along with other matters related to communications.. controls the allocation of carrier and network numbering plans - just to make sure that every one has a unique address and that Australia is uniquely placed in the world and that any carrier / network providor does not advantage itself by "limiting" the allocation of addresses to other network providors/customers.. THe IETF seems to believe that because it can "design a 16 byte" address for the whole planet, it will automatically get the support of the IT industry and regulatory bodies to propagate this around the world.. Some router vendors will naturally support this because there is money in "connectivity" tools but the bottom line stuff is why would any supplier put in a network into an international operation such as defence, govt, avaiation, etc where there is a major risk of the network having large scale problems because of issues with regulatory matters, assorted addressing schemes, routing algorithms, interworking and dealing with international switched carrier services.. Is the scenario going to be as the Internet becomes a commercial network operator, that it will have to upgrade its management (say to X.700, TMN, carrier billing systems, service level agreements , etc, etc and possibly use X.500 directory systems.. etc.. just because its the only global directory standard on the block) and that it (the Internet) should come under the regulatory requirements of a country .. ie does the IETF as a commercial network operator have to comply with the regulatory issues of a country as per Telecom, OPtus, etc. I will raise this one with Austel perhaps other countries should review this.. MORE and MORE Upgrades.. Is IPNG just the start... I think so. I suppose the next point I have is that because of the address changes to the IP 4 byte field.. does this also mean that OSPF will be updated to something else... eg.. (joke coming guys ) OSOFNPVQ - Open some other funny numbered path very quickly.. Whats the impact of this.. And THEN dont forget the mighty SNPM... Simple -- Network Management Protocol Simple Network -- Management Protocol Simple Network Management - Protocol I am never sure of which one it is.. In my previous comments I mentioned that SNMP is associated with a flat information model.. Whereas CMIP is associated with an Object model.. And Objects have names (global names in global networks).. as per X.500 naming.. Now given that SNMP was designed for interfaces on connectionless networks and CMIP was designed so that it can deal with a switched connection oriented environment with objects (which get created and destroyed) that can represent circuits.. How do the vendors plan to manage switched B-ISDN and ATM in a large scale environment with SNMP! Particularly when the large scale evironment will be controlled by the carriers -- (X.700/CMIP and TMN). Why did I raise this? Well I see that if the Internet wants to go to ATM and B-ISDN - This uses carrier numbering plans..and NSAPs. The management system (just because of the carrier / switched focus) will orient itself to X.700 and X.500 because of the object methodology and global naming.. There seems little point in having a network which has internationally defined management and directory system technologies that use global naming, which runs over internationaly defined carrier services with international addressing schemes but in the middle an internetworking protocol that uses a bag of funny numbers which have no official tie to the geography of the planet or the authorities that allocate names and addresses.. In closing In the new internet.. which I assume will be commercial, managed, secure and have accounting tools and be using elements of B-ISDN, X.700, E.164 addressing, NSAPs, X.500 and be in a "deregulated" carrier environment, there will many issues. What is the IETFs view of this? Simply because if the IETF cannot provide any objective answers oe guidance on these, the IT industry and the User community should know.. There is no point in believing one can produce world standards based on "working code" if one has no accountability or credibility.. regards alan ------------------------------------------------------------------------------ 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 Sun Aug 28 19:24:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24580; Sun, 28 Aug 94 19:24:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24574; Sun, 28 Aug 94 19:24:07 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16986; Sun, 28 Aug 94 19:21:19 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA05269; Sun, 28 Aug 94 19:21:00 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA05173; Sun, 28 Aug 94 19:19:12 -0700 Received: by xirtlu.zk3.dec.com; id AA04552; Sun, 28 Aug 1994 22:17:44 -0400 Message-Id: <9408290217.AA04552@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) engineering specs needed In-Reply-To: Your message of "Fri, 26 Aug 94 17:15:39 EDT." <9408262131.AA18645@decvax.dec.com> Date: Sun, 28 Aug 94 22:17:38 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yakov, ------------------------------------------------------ >I sent mail to sdrp-request group but no response and collegue tells me >who is on it its pretty quiet. Actually most of the discussion about cluster addresses (that happened on ipng mailing list) is driven by the work on introducing SDRP capabilities into IPv6. An element in the SDRP Header may be a cluster address, so understanding of cluster addresses is quite important for the work on SDRP Header. ----------------------------------------------------- I agree and thanks. Also thanks for the IDRP update too. /jim ------------------------------------------------------------------------------ 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 Sun Aug 28 19:58:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24671; Sun, 28 Aug 94 19:58:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24665; Sun, 28 Aug 94 19:58:07 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17849; Sun, 28 Aug 94 19:55:19 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA07440; Sun, 28 Aug 94 19:55:02 PDT Received: by rodan.UU.NET id QQxezj05005; Sun, 28 Aug 1994 22:55:00 -0400 Date: Sun, 28 Aug 1994 22:55:00 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) "Can't build a network with working code" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I'd like to know what other kind you propose? ------------------------------------------------------------------------------ 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 Sun Aug 28 20:13:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24736; Sun, 28 Aug 94 20:13:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24730; Sun, 28 Aug 94 20:13:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18295; Sun, 28 Aug 94 20:10:53 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA08450; Sun, 28 Aug 94 20:10:35 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA06964; Sun, 28 Aug 94 20:08:44 -0700 Received: by xirtlu.zk3.dec.com; id AA05250; Sun, 28 Aug 1994 23:07:31 -0400 Message-Id: <9408290307.AA05250@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing In-Reply-To: Your message of "Sun, 28 Aug 94 19:59:02 EDT." <9408282359.AA09817@snark.imsi.com> Date: Sun, 28 Aug 94 23:07:25 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ******************************* Tony Li says: > P.S. *What* are we arguing about? I didn't think anyone questioned > the problems with source routing and address-based authentication. > Has a requirement that we support it slithered back in? > > What we're discussing (we need another 10db to be arguing ;-) is > whether unauthenticated source routes are permissible in IPv6. > > I think you and I are in complete agreement. Does that mean that we all agree that unauthenticated source routes are impermissable? **************************************** No I don't agree with the word "all". I would agree with the word "some" if we define which ones and in what cases. /jim ------------------------------------------------------------------------------ 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 Sun Aug 28 20:14:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24751; Sun, 28 Aug 94 20:14:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24745; Sun, 28 Aug 94 20:14:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18320; Sun, 28 Aug 94 20:11:40 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA08495; Sun, 28 Aug 94 20:11:21 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA06849; Sun, 28 Aug 94 20:05:39 -0700 Received: by xirtlu.zk3.dec.com; id AA05222; Sun, 28 Aug 1994 23:04:23 -0400 Message-Id: <9408290304.AA05222@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) source routing & authentication In-Reply-To: Your message of "Sun, 28 Aug 94 15:46:32 GMT." <9408281546.aa06200@sundance.itd.nrl.navy.mil> Date: Sun, 28 Aug 94 23:04:17 -0400 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 don't think we can mandate that the extended sercurity option be MANDATORY in IP6 unless the packet is traversing the Internet. In other words if company XYZ does not want security inside of their domain because they have made their environment secure its their option not the IETFs. Even with much tweeking to your spec we are still a sub-optimal levels (about 70Mbs) on Alpha OSF/1. I don't want an entire development code path in assembly language either. I think all the knowledge stated here for security is very important, but not everyone wants it or needs it. If IP6 can provide it in the architecture then it has done a great service. This gets to the issue someone raised at the IPng last Monday (Mbone) review -- that vendors will have it in their products but will the products be delivered with security on as the default? I don't think this is the IETF business. Its up to us to turn it on if our customers want security. Hence, all words in any specs I think might be more apt to get ratified if the say SHOULD instead of MUST. Now how to 'legislate' for the public net it must have security turned on is something we need to think about. Also source routing is very valuable and it must be part of IP6. /jim ------------------------------------------------------------------------------ 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 Sun Aug 28 20:16:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24767; Sun, 28 Aug 94 20:16:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24761; Sun, 28 Aug 94 20:16:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18350; Sun, 28 Aug 94 20:13:43 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA08667; Sun, 28 Aug 94 20:13:22 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 29 Aug 94 12:06:02 +0900 From: Masataka Ohta Message-Id: <9408290306.AA08794@necom830.cc.titech.ac.jp> Subject: Re: (IPng) Service providers beware! To: ipng@sunroof.Eng.Sun.COM Date: Mon, 29 Aug 94 12:06:00 JST In-Reply-To: <3146.778089567@munnari.OZ.AU>; from "Robert Elz" at Aug 29, 94 1:59 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >Christian Huitema > > >I do not think that nailing down all the details of the future addressing plan > >makes much sense today. Details of the future addressing plan on how long each field should be is surely unimportant. > So I think we need to nail down what we can and hopefully NOT > have to change in a couple of years. > > I think you're misunderstanding what Christian meant. I don't > believe he intended that the addressing plan be changed after > deployment, but that the addressing plan isn't critical until > we're ready to start deploying IPv6. Before then there are > more important issues to solve - protocols to get defined, and > implementations to create. Wrong. The framework for the addressing plain, such as how to support multi-homing, affects routing a lot and is critical to design auto-configuration mechanism. Masataka Ohta ------------------------------------------------------------------------------ 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 Sun Aug 28 20:20:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24811; Sun, 28 Aug 94 20:20:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24805; Sun, 28 Aug 94 20:20:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18444; Sun, 28 Aug 94 20:17:26 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA09015; Sun, 28 Aug 94 20:17:08 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA07127; Sun, 28 Aug 94 20:12:14 -0700 Received: by xirtlu.zk3.dec.com; id AA05279; Sun, 28 Aug 1994 23:10:59 -0400 Message-Id: <9408290310.AA05279@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing In-Reply-To: Your message of "Sun, 28 Aug 94 20:12:25 EDT." <9408290013.AA27977@Sun.COM> Date: Sun, 28 Aug 94 23:10:52 -0400 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, >``Unauthenticated source routes'' are impermissible *if* the service >is using address-based authentication. I don't care who send a >source-routed connection message to, say, my echo server. Please define "address-based authentication" thanks /jim ------------------------------------------------------------------------------ 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 Sun Aug 28 20:56:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24893; Sun, 28 Aug 94 20:56:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24887; Sun, 28 Aug 94 20:56:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19248; Sun, 28 Aug 94 20:53:57 PDT Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA11195; Sun, 28 Aug 94 20:53:40 PDT Message-Id: <9408290353.AA11195@Sun.COM> From: smb@research.att.com Received: by gryphon; Sun Aug 28 23:53:24 EDT 1994 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing Date: Sun, 28 Aug 94 23:53:23 EDT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, >``Unauthenticated source routes'' are impermissible *if* the service >is using address-based authentication. I don't care who send a >source-routed connection message to, say, my echo server. Please define "address-based authentication" Granting privileges based on the source address contained in the IP header, without stronger checking (i.e., without some form of password or cryptographic validation). Current examples include rlogind, rshd, NFS's export files, the TCP wrapper, and packet filters that use source addresses. ------------------------------------------------------------------------------ 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 Sun Aug 28 21:06:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24920; Sun, 28 Aug 94 21:06:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24914; Sun, 28 Aug 94 21:06:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19420; Sun, 28 Aug 94 21:03:13 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA11712; Sun, 28 Aug 94 21:02:56 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA08702; Sun, 28 Aug 94 20:55:33 -0700 Received: by xirtlu.zk3.dec.com; id AA05730; Sun, 28 Aug 1994 23:54:21 -0400 Message-Id: <9408290354.AA05730@xirtlu.zk3.dec.com> To: Jon Crowcroft Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: IPng slotting into kernels..... In-Reply-To: Your message of "Sun, 28 Aug 94 16:47:14 BST." <2806.778088834@cs.ucl.ac.uk> Date: Sun, 28 Aug 94 23:54:15 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >not only do 16 byte addrs not go in a struct sockaddr, so you need >recompile (i.e. source) of kernels to work on this - i.e. the >community helping out won't include people like us [as we're mainly >solaris based for research/kernel work]:-( Well one way to look at is: Yes this is true but the IP_PROTO tables can be changed to support IP_IP6 and IP_IPv4. At TCP/UDP the AF_FAMILY needs to be checked which can select the PRU_(IP6 | IPv4) ctrl path. At IP layer its up to you if you want a dual stack or not. We have done it both ways. Its an architecture decision for a host to decide which will affect all other code at IP and to Datalink (dual stack or no dual stack). >but also, i note that ip6 with 16 byte addrs now may not fit into the end >of an mbuf with any options and a TCP/UDP header with space to prepend >a link layer header....so 4.4BSD derivative people have something else >to worry about... yep it will require either a change to the mbuf and VM or a set of pointers to use pullups to bring in the entire header with options and user data (TCP/UDP). Then it all needs to be demuxed again at ones preference at the IP layer. Very trick stuff. If you look at the last api spec for SIPP-8 we included the use of extended addresses as a possibity which was an array for the socket_struct. Got this to work and essentially dealt with a fixed variable address depending on how it came in at the transport or from the datalink. If code base bit the bullet in 4.4 and extended the kernel to use the 4.4 variable address then half the work is already done. But if the new 4.4 sa_len field was not incorpororated into the unix kernel then everything is fixed and needs work from word go. ON recompile. I think the goal is so that apps dont have to recompile until they port to IP6 (and some dont like this). And yes you got to recompile the kernel when we left 8bytes. I know. I know. I know. >on header compression: >audio ( a thing we do a lot) typically can be compressed to 14kbps >very easily. if i'm sending RTP/UDP/IP6, multicast audio from home >(say from my 2*64kbps ISDN home itnernet access), am i gonna >have problems figuring out where to do header compression? does >sensible addr allocation for aggregation help with compression? if it >does, and does everywhere, couldn't we have used smaller addresses:-)? Well Bill Simpson last I heard was on the hook for compression and understands how to do this better than I so I will hope he is listening and will let him respond. But I think we need header compression for the cases you pointed out and for WWW traffic over a serial link. >anyhow, is there a pre-alpha ip6 BSD style implementaton we can look >at/help/port-to-SVID? Not sure what you mean by "pre-alpha".... But I do know we have helped with some funding for some very bright people to put 4.4 on Alpha and it is in the works outside of Digital. Yes when I have that OS given the time we would like to tHen put our IP6 on a 4.4 Alpha. But IP6 is on hold per me until I see more specs I can't afford to just wing this one its time to get some stable specs we can build code from. Clearly the arch spec gives us enough work for a few months but I hope we see more clarity in a few months. I have not been trying to build a pub domain but let me check and see what I can do. /jim ------------------------------------------------------------------------------ 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 Sun Aug 28 21:26:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25012; Sun, 28 Aug 94 21:26:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24995; Sun, 28 Aug 94 21:26:35 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19825; Sun, 28 Aug 94 21:23:47 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA13210; Sun, 28 Aug 94 21:23:30 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id VAA23052; Sun, 28 Aug 1994 21:23:18 -0700 Date: Sun, 28 Aug 1994 21:23:18 -0700 From: Tony Li Message-Id: <199408290423.VAA23052@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Perry E. Metzger"'s message of Sun, 28 Aug 1994 20:41:08 -0400 <9408290041.AA09916@snark.imsi.com> Subject: (IPng) security & source routing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM True, but I will note that its difficult to enforce such a policy except by stopping all unauthenticated source routed packets. Nonsense. The service tells the receiving host stack what its policy is. If authenticated source routes are required, then the packets are not delivered to the service. If unauthenticated source routes are permitted, then the data is delivered to the service. Tony ------------------------------------------------------------------------------ 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 Sun Aug 28 22:37:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25187; Sun, 28 Aug 94 22:37:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25181; Sun, 28 Aug 94 22:37:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21218; Sun, 28 Aug 94 22:34:16 PDT Received: from thor.tjhsst.edu by Sun.COM (sun-barr.Sun.COM) id AA16892; Sun, 28 Aug 94 22:33:55 PDT Received: by thor.tjhsst.edu (Smail3.1.28.1 #1) id m0qezPI-000AefC; Mon, 29 Aug 94 01:37 EDT Message-Id: To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) source routing & authentication In-Reply-To: Your message of "Sun, 28 Aug 1994 23:04:17 EDT." <9408290304.AA05222@xirtlu.zk3.dec.com> Date: Mon, 29 Aug 1994 01:37:09 EDT From: Craig Metz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message <9408290304.AA05222@xirtlu.zk3.dec.com>, you write: >I don't think we can mandate that the extended sercurity option be >MANDATORY in IP6 unless the packet is traversing the Internet. In other >words if company XYZ does not want security inside of their domain >because they have made their environment secure its their option not the >IETFs. Even with much tweeking to your spec we are still a sub-optimal >levels (about 70Mbs) on Alpha OSF/1. I don't want an entire >development code path in assembly language either. >Hence, all words in any specs I think might be more apt to get ratified >if the say SHOULD instead of MUST. >Now how to 'legislate' for the public net it must have security turned >on is something we need to think about. The kind of security provided by the IPv6 Authentication Header cannot work well unless virtually all hosts on the Internet support it. Timeless examples have shown that most users don't know and/or care enough to make their systems conform with standards specifications. Most users will install their software and then do as little configuration is necessary to get things to look like they work. We simply cannot leave it to the end user to turn on support and use of the Authentication Header, because too many people won't do it. We can ``legislate'' all we want; most end users have never seen the standards and don't particularly care what's in them so long as things seem to work. Trying to force users to switch something like AH use or support on when a system goes onto the net would be futile. Most service providers aren't even in a position to be able to suggest that their customers conform to standards, and I don't know of any that are in a position to force their customers to comply with standards. I doubt that any attempt to change this situation would give the IETF a good reputation with network customers. The painful, but probably correct, solution to performance problems with the Authentication Header is to have hardware or coprocessor assistance with the secure hash (be it MD5, or whatever else you might use). Since this is not a very good solution for existing systems, a very high level of optimization including well-written assembler code is necessary. If you are unwilling to do this, then you shouldn't be complaining about performance. Though it may not count as much, I would strongly favor shipping all IPv6 implementations with the Authentication Header both supported and used by default unless the appropriate key management component would seriously delay deployment of the protocol. If users who know what they are doing want to get that extra bit of performance out of their systems and are willing to forgo the security benefits, then they can turn it off (IMO, this should be made a somewhat involved process to discourage the average Joe from doing it). Any other way would end up defeating the Authentication Header's purpose - to provide strong authentication on a net-wide scale. >Also source routing is very valuable and it must be part of IP6. Not to open another can of worms, but what can be done with source routing that can't be implemented through flows? It would seem to me that flows would better serve applications that would otherwise use source routes. -Craig ------------------------------------------------------------------------------ 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 Mon Aug 29 01:08:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25596; Mon, 29 Aug 94 01:08:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25590; Mon, 29 Aug 94 01:08:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25262; Mon, 29 Aug 94 01:05:28 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA28781; Mon, 29 Aug 94 01:05:11 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA07753; Mon, 29 Aug 1994 10:05:08 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05336; Mon, 29 Aug 1994 10:05:06 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408290805.AA05336@dxcoms.cern.ch> Subject: Re: (IPng) On NSAP/IP6 Translation To: ipng@sunroof.Eng.Sun.COM Date: Mon, 29 Aug 1994 10:05:06 +0200 (MET DST) In-Reply-To: <22825.777952625@drax.isi.edu> from "Craig Milo Rogers" at Aug 26, 94 06:57:05 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 416 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, Can you specify the functional requirement that your proposal addresses (your problem statement already assumes that somebody wants to solve that problem)? Can you generalise your proposal to support any kind of "tunnel X through the Internet" problem? Manual configuration of tunnels is a real drag. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ 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 Mon Aug 29 04:12:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25902; Mon, 29 Aug 94 04:12:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25896; Mon, 29 Aug 94 04:12:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03347; Mon, 29 Aug 94 04:09:46 PDT Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA12191; Mon, 29 Aug 94 04:09:28 PDT Message-Id: <9408291109.AA12191@Sun.COM> From: smb@research.att.com Received: by gryphon; Mon Aug 29 07:08:08 EDT 1994 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing Date: Mon, 29 Aug 94 07:08:07 EDT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM True, but I will note that its difficult to enforce such a policy except by stopping all unauthenticated source routed packets. Nonsense. The service tells the receiving host stack what its policy is. If authenticated source routes are required, then the packets are not delivered to the service. If unauthenticated source routes are permitted, then the data is delivered to the service. Yup. That was Perry just being Perry... ------------------------------------------------------------------------------ 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 Mon Aug 29 05:13:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25951; Mon, 29 Aug 94 05:13:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25945; Mon, 29 Aug 94 05:12:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04547; Mon, 29 Aug 94 05:10:08 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA15016; Mon, 29 Aug 94 05:09:51 PDT Received: from relay.imsi.com by wintermute.imsi.com id IAA19505 for ; Mon, 29 Aug 1994 08:09:50 -0400 Received: from snark.imsi.com by relay.imsi.com id IAA05190 for ; Mon, 29 Aug 1994 08:09:49 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA10442; Mon, 29 Aug 94 08:09:48 EDT Message-Id: <9408291209.AA10442@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) WHAT ELSE -- IPNG AND MADNESS In-Reply-To: Your message of "25 Aug 1994 16:55:14 +1000." <"940825 13:33:09"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> X-Reposting-Policy: redistribute only with permission Date: Mon, 29 Aug 1994 08:09:48 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ALAN LLOYD says: [Lots more ISO sour grapes political nonsense.] Look, maybe the ISO people are right and they are going to "win" the marketplace. If so, go off and work on the ISO protocols. Frankly, I don't care if you "win". My customers, my paying customers, use TCP/IP, commercially, today, right as we speak, and they are interested in seeing IP upgraded so that it can keep working robustly into the next century. If this means that the Australian National Condom Board's requirement of having all Australian prophylactic manufacturers use 75 byte addresses conflicts with the desire of some of them to use our protocols, well, fine. Let them go and argue about that in an appropriate forum. This isn't the appropriate forum. This is the forum where people are discussing the engineering of IPv6, not whether the Australian National Antelope Commission will be happy with decisions made by the IESG. Lets get back to talking about the ENGINEERING of the IPv6, not the engineering of the ISO/OSI network stack, the politics of international standards bodies, or whether the New Caledonian Coastal Fishing Authority has recently passed a regulation requiring all tourists to be tatooed bright purple. Perry ------------------------------------------------------------------------------ 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 Mon Aug 29 05:30:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25979; Mon, 29 Aug 94 05:30:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25973; Mon, 29 Aug 94 05:30:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04982; Mon, 29 Aug 94 05:27:27 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA16256; Mon, 29 Aug 94 05:27:10 PDT Received: from relay.imsi.com by wintermute.imsi.com id IAA19524 for ; Mon, 29 Aug 1994 08:27:09 -0400 Received: from snark.imsi.com by relay.imsi.com id IAA05281 for ; Mon, 29 Aug 1994 08:27:08 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA10462; Mon, 29 Aug 94 08:27:08 EDT Message-Id: <9408291227.AA10462@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing In-Reply-To: Your message of "Sun, 28 Aug 1994 21:23:18 PDT." <199408290423.VAA23052@lager.cisco.com> X-Reposting-Policy: redistribute only with permission Date: Mon, 29 Aug 1994 08:27:07 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony Li says: > > True, but I will note that its difficult to enforce such a policy > except by stopping all unauthenticated source routed packets. > > Nonsense. The service tells the receiving host stack what its policy > is. If authenticated source routes are required, then the packets are > not delivered to the service. If unauthenticated source routes are > permitted, then the data is delivered to the service. I did not mean to say that technically people requesting authentication could not. I meant simply that if you allow people to build applications that don't request authentication under certain circumstances they will -- and such applications will in fact dominate. Perry ------------------------------------------------------------------------------ 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 Mon Aug 29 05:59:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26028; Mon, 29 Aug 94 05:59:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26022; Mon, 29 Aug 94 05:59:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05957; Mon, 29 Aug 94 05:56:22 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA19072; Mon, 29 Aug 94 05:56:05 PDT From: Ran Atkinson Message-Id: <9408290853.ZM6661@sundance.itd.nrl.navy.mil> Date: Mon, 29 Aug 1994 08:53:53 -0500 In-Reply-To: Tony Li "source routing & authentication" (Aug 28, 12:36) References: <199408281936.MAA14292@lager.cisco.com> X-Mailer: Z-Mail (3.0.1 04apr94) To: Tony Li Subject: (IPng) Re: source routing & authentication Cc: ip-ng@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 Aug 28, 12:36, Tony Li wrote: % Subject: source routing & authentication % I agree completely, however the thought of a trusted router with my % key is more than disturbing. Can you say "central attack point"? ;-) I understand your concern. The example and notions come fairly directly out of the IAB Security Retreat RFC and are not particularly mine. However, they are strongly possible scenarios for the future. If one used asymmetric algorithms then the "central attack point" issue disappears, however symmetric algorithms typically have better performance than asymmetric algorithms. Also, if only "well selected" routers (e.g. a firewall router at an administrative domain boundary) had the key and did the authentication, then the risk might be acceptable to some. % I do have to question whether your example of RSVP really requires % that level of complexity, tho. I would expect that RSVP would % identify a flow. As the flow id is in the fixed header and % authenticated, is this not sufficient? The intermediate router % establishes authentication of the flow when it receives the RSVP % setup, and then verifies the authentication (probably statistically) % on the running flow. % %-- End of excerpt from Tony Li I believe that my RSVP example is from the IAB Security Retreat RFC. I think it is also very similar to something that Dave Clark has suggested within one of the integrated services/rsvp working groups. One reason that the router wants to authenticate some/all of the traffic (in addition to authenticating flow establishment, etc.) is to establish that the traffic using the flow legitimately belongs to that flow and isn't stealing someone else's higher performance service. IMNVHO, these are all hard problems. It seems to me that many of them would be much more easily solved if there were a fast asymmetric authentication-only algorithm that could be used (and easily exported). I'm trying to find a reasonably clear and strong enough statement about what needs authentication so that we mandate what's needed without undue impact operationally. Other Thoughts ? What am I missing here ? Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ 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 Mon Aug 29 06:57:13 1994 Return-Path: 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 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 Mon Aug 29 07:13:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26136; Mon, 29 Aug 94 07:13:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26130; Mon, 29 Aug 94 07:13:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10098; Mon, 29 Aug 94 07:10:55 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA27653; Mon, 29 Aug 94 07:10:38 PDT Message-Id: <9408291410.AA27653@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9755; Mon, 29 Aug 94 10:10:40 EDT Date: Mon, 29 Aug 94 10:08:05 EDT From: yakov@watson.ibm.com To: avg@sprint.net, ipng@sunroof.Eng.Sun.COM Subject: (IPng) security & source routing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Sun, 28 Aug 1994 20:34:22 -0400 Vadim, >Now with source-based routing it is easy to produce bogon flooding >attack w/o creating noticeable incoming bogon streams -- if you >want to kill link between A and B just use path > 1 2 3 4 5 A B A B A B A B Consider the following IPv6 in IPv6 encapsulation (each box represents an IPv6 header, but the picture shows only only src and dst address fields): +------------------+------------------+------------------+------------------ | src = 1, dst = A | src = A, dst = B | src = B, dst = A | dst = B, src = A +------------------+------------------+------------------+------------------ How is that different from your example with the source route ? Yakov. P.S. Note that all the encapsulation headers may be inserted at the source of the packet. ------------------------------------------------------------------------------ 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 Mon Aug 29 07:24:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26178; Mon, 29 Aug 94 07:24:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26172; Mon, 29 Aug 94 07:23:59 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11087; Mon, 29 Aug 94 07:21:11 PDT Received: from ftp.com by Sun.COM (sun-barr.Sun.COM) id AA29166; Mon, 29 Aug 94 07:20:53 PDT Received: from ftp.com by ftp.com ; Mon, 29 Aug 1994 10:20:52 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 29 Aug 1994 10:20:52 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA08207; Mon, 29 Aug 94 10:18:10 EDT Date: Mon, 29 Aug 94 10:18:10 EDT Message-Id: <9408291418.AA08207@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing From: kasten@ftp.com (Frank Kastenholz) Content-Length: 666 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Am I missing something here or are we all trying to get security 'on the cheap' (for instance, the comment that went by that roughly was "securing 'important' packets may be enough"). It seems to me that this is sort of like asking for a car that causes absolutely 0 environmental damage, cigarettes that don't cause cancer, and butter that has no fat in it. If security is important to you, either as a client attempting to access some service, or a server providing a service then you will use security. Real security. Full security. Doing security by half-measures will simply mean that there are more holes for the bad guys to attack. -- Frank Kastenholz ------------------------------------------------------------------------------ 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 Mon Aug 29 07:56:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26225; Mon, 29 Aug 94 07:56:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26219; Mon, 29 Aug 94 07:56:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13802; Mon, 29 Aug 94 07:53:40 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA03905; Mon, 29 Aug 94 07:53:23 PDT Message-Id: <9408291453.AA03905@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0537; Mon, 29 Aug 94 10:53:09 EDT Date: Mon, 29 Aug 94 10:51:38 EDT From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: source routing & authentication Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Mon, 29 Aug 1994 08:53:53 -0500 Folks, If we exclude the situation where a host, when received a packet with the source route is *required* to reverse the source route when sending in the opposite direction, and allow any router along the path to insert "source route" header, then it seems that from a semantic point of view pure tunneling (IPv6 in IPv6) represents a proper subset of "source routing". If that is correct, then how does the discussion about authentication of "source routed" packets apply to the use of encapsulation (IPv6 in IPv6) ? Yakov. P.S. It seems that the term "source route" may be a bit confusing, as it implies that only the "source" of a packet may specify the "source route". It is not clear why only the source should have such capabilities -- in fact it is possible to construct examples where it would be useful if a router will do this. So, perhaps we should replace the term "source route" with something else, like "Explicit Routing" ? Any other suggestions ??? ------------------------------------------------------------------------------ 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 Mon Aug 29 08:07:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26241; Mon, 29 Aug 94 08:07:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26235; Mon, 29 Aug 94 08:07:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14869; Mon, 29 Aug 94 08:04:34 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA05732; Mon, 29 Aug 94 08:04:10 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA03122; Mon, 29 Aug 94 07:50:58 -0700 Received: by xirtlu.zk3.dec.com; id AA19961; Mon, 29 Aug 1994 10:50:53 -0400 Message-Id: <9408291450.AA19961@xirtlu.zk3.dec.com> To: Craig Metz Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) source routing & authentication In-Reply-To: Your message of "Mon, 29 Aug 94 01:37:09 EDT." Date: Mon, 29 Aug 94 10:50:47 -0400 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, On end users. This is just a knob. And knobs will be more of a need as networking evolves. Clearly when you order your software and hardware you can also order your knobs. Leave the needs of end users to the vendors not the IETF. Flows.... I agree. But what application do you know of today that uses Flows. Where has it been tested. How will flows be generated. This all needs much work and like autoconfiguration has some research to it before we "know" it works. Take any thing you will use a flow for (almost) and I can give a customer that solution today with a source route. /jim ------------------------------------------------------------------------------ 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 Mon Aug 29 09:08:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26274; Mon, 29 Aug 94 09:08:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26268; Mon, 29 Aug 94 09:08:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20857; Mon, 29 Aug 94 09:05:28 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA16531; Mon, 29 Aug 94 09:05:09 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA20659; Mon, 29 Aug 1994 17:17:44 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA15938; Mon, 29 Aug 1994 17:16:45 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408291516.AA15938@dxcoms.cern.ch> Subject: (IPng) I-D on NSAP recommendations To: ipng@sunroof.Eng.Sun.COM (ip6) Date: Mon, 29 Aug 1994 17:16:44 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 15476 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Has been submitted today as an Internet Draft - Brian and Jim. --------- Internet Draft B. Carpenter August 31, 1994 J. Bound Recommendations for OSI NSAP usage in IP6 Abstract draft-ietf-ip6-nsap-map-00.txt This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IP6, should redesign a native IP6 addressing plan to meet their needs. However, in the event that network implementors prefer to keep their OSI addressing plan intact, this document defines a mapping of OSI NSAP addresses into IP6 addresses. This mapping is restricted by the 16 byte size of IP6 addresses. This document also defines a mapping of IP6 addresses within the OSI address format, should this be required for any reason. Expires February 28, 1995 [Page 1] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 Table of Contents: Status of this Memo.............................................3 1. General recommendations......................................4 2. NSAPA mapping into a 16-byte IP6 address for ICD and DCC.....6 3. NSAPA mapping into a 16-byte IP6 address for other formats...7 4. Restrictions in the NSAPA mappings...........................8 5. Annex: 16-byte IP6 addresses inside a 20-octet NSAPA.........9 Acknowledgements...............................................10 References.....................................................10 Authors' Addresses.............................................10 Expires February 28, 1995 [Page 2] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Expires February 28, 1995 [Page 3] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 1. General recommendations This document is principally addressed to network implementors who have already planned or deployed an OSI NSAP addressing plan for the usage of OSI CLNP [IS8473] according to the OSI network layer addressing plan [IS8348]. It recommends how they should adapt their addressing plan for use with IP6 [IP6]. The majority of CLNP addressing plans use either the Digital Country Code (DCC) or the International Code Designator (ICD) formats defined in [IS8348]. A particular example of this is the US Government OSI Profile Version 2 (GOSIP) addressing plan [RFC1629]. Most of the present document refers to these address plans, which are essentially binary byte-sequence plans. Brief reference is made to decimal digit-sequence plans as used for ISDN and X.25. The general recommendation is that implementors SHOULD design native IP6 addressing plans according to [Rekhter], but doing so as a natural re-mapping of their CLNP addressing plans. While it is impossible to give a general recipe for this, CLNP addresses in DCC or ICD format can normally be split into two parts: the high order part relating to the network service provider and the low order part relating to the user network topology and host computers. For example, in US GOSIP the high order part is the AFI, ICD, DFI, AA and RD fields, together occupying 9 bytes. The low order part is the Area and ID fields, together occupying 8 bytes. (The selector byte and the two reserved bytes are not part of the addressing plan.) Thus, for US GOSIP, the high-order part SHOULD be replaced by the provider part of an IP6 provider-based addressing plan. An 8-byte provider prefix is recommended for this case and [Rekhter] MUST be followed in planning such a replacement. The low order part SHOULD then be mapped directly in the low-order half of the IP6 address space, and user site address plans are unchanged. A 6-byte ID field mapped from US GOSIP will be acceptable for IP6 autoconfiguration [Katz]. Analogous rules SHOULD be applied to other addressing plans similar to US GOSIP. Some organizations may decide for various reasons not to follow the above recommendation and may wish to use their existing OSI NSAP addressing plan unchanged for IP6. It should be noted that such a decision has serious implications for routing, since it means that routing between such organizations and the rest of the Internet can only occur at inter-domain level using IDRP. An organization using both native IP6 addresses and NSAP addresses for IP6 would be obliged to run two independent routing systems interconnected by IDRP. Nevertheless, to cover this eventuality, the present document defines a way to map a subset of the NSAP address space into the IP6 address space. The mapping is algorithmic and reversible within this subset of the NSAP address space. Certain other uses of this algorithmic mapping could be envisaged. It could be used as an intermediate addressing plan for a network making a transition from CLNP to IP6. It could be used in a header translation scheme for dynamic translation between IP6 and CLNP. It could be used to allow CLNP and IP6 traffic to share the same Expires February 28, 1995 [Page 4] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 routing architecture within an organization (Ships in the Day). It could possibly be used in an encapsulation scheme. It could be used to leave the CLNP domain to traverse the Internet IP6 domain and then enter back into another CLNP domain. All these uses are DEPRECATED but if any of them are implemented, or any other use of mapping, then the mapping defined below MUST be used. Expires February 28, 1995 [Page 5] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 2. NSAPA mapping into a 16-byte IP6 address for ICD and DCC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0-3 |0 0 0 0 0 0 1|G| AFcode| IDI (last 3 digits) |Prefix(octet 0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | Prefix (octets 1 through 4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | Area (octets 0 and 1) | ID (octets 0 and 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| ID (octets 2 through 5) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The G bit is 1 for a group address, 0 for an individual address. Its applicability to support multicast is for further study, and this bit may be withdrawn. The AFcode nibble is encoded as follows 0000-1001 AFI value is 47 (ICD) (0-9 decimal) AFcode is first BCD digit of the ICD IDI is last three BCD digits of the ICD 1111 AFI value is 39 (DCC) (hex. F) IDI is the three BCD digits of the DCC The longest CLNP routing prefixes known to be in active use today are 5 octets (subdivided into AA and RD fields in US GOSIP version 2). Thus the semantics of existing 20-octet NSAPAs can be fully mapped. DECnet/OSI (R) address semantics are also fully mapped. The NSEL octet is not included. It is of no use for TCP and UDP traffic, but would be needed if a future revision of CLNP used the same format. In this case it could be encoded as an end-to-end IP6 option [IP6]. A network using such addresses could route using suitably adapted implementations of ES-IS, IS-IS and IDRP. It is expected that hosts using such addresses could be auto-configured using [Katz]. Expires February 28, 1995 [Page 6] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 3. NSAPA mapping into a 16-byte IP6 address for other formats 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0-3 |0 0 0 0 0 0 1|G| AFcode| Start of IDI (N digits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| End of DSP (29-N digits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The G bit is reserved and must be set to 0. The AFcode nibble is encoded as follows 1010 AFI value is 37 or 53 (X.121 binary) (hex. A) IDI is the 14 BCD digits of X.121 address DSP is up to 15 BCD digits 1011 AFI value is 45 or 59 (E.164 binary) (hex. B) IDI is the 15 BCD digits of E.164 address DSP is up to 14 BCD digits 1100-1110 Reserved, not to be used. (hex. C, D, E) The padding rules defined in [IS8348] are MODIFIED since only BCD digits are used. All pads to IDI and DSP digit strings consist of trailing ones (hex. F nibbles). Expires February 28, 1995 [Page 7] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 4. Restrictions in the NSAPA mappings Restrictions compared to [IS8348] are: 1. ICD and DCC format addresses using more bytes than the US GOSIP case cannot be mapped. For the US GOSIP case, the DFI byte (DSP Format Identifier) is not mapped and is deemed to be 80 hexadecimal. 2. F.69 (Telex), E.163 (telephone) and Local formats cannot be mapped. It is not widely expected that IP6 will need to run with a Telex or POTS addressing plan. IP6 has a native method of supporting Local addressing plans. 3. The DSP lengths for X.121 and E.164 are shorter than allowed in [IS8348], where they are 24 and 23 digits respectively. 4. Only the binary encodings of [IS8348] are supported. Expires February 28, 1995 [Page 8] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 5. Annex: 16-byte IP6 addresses inside a 20-octet NSAPA If it is required, for whatever reason, to embed an IP6 address inside a 20-octet NSAP address, then the following format MUST be used. Use of this embedding is not specifically recommended, nor is it deprecated. A possible goal would be to allow CLNP packets that encapsulate IP6 packets to be routed in a CLNP network using the IP6 address architecture. Several leading bytes of the IP6 address could be used as a CLNP routing prefix. However, in general routing between CLNP end-systems using this address format and those using another format would require use of IDRP. The first three octets are an IDP meaning "this NSAPA embeds a 16 byte IP6 address" and the last octet is a dummy selector. It is considered unwise to overload the selector octet. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0-3 | AFI = 47 | ICD = ISoc (TBD) | IP6 (byte 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | IP6 (bytes 1-4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | IP6 (bytes 5-8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| IP6 (bytes 9-12) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16-19| IP6 (bytes 13-15) | NSEL = dummy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires February 28, 1995 [Page 9] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 Acknowledgements Richard Collella, Jack Houldsworth, Cyndi Jung, Yakov Rekhter, and many other members of the former TUBA and new IP6 working groups of the IETF. References [IS8473] Data communications protocol for providing the connectionless-mode network service, ISO/IEC 8473, 19??. [IS8348] Annex A, Network Layer Addressing, and Annex B, Rationale for the material in Annex A, of ISO/IEC 8348, 1993 (identical to CCITT Recommendation X.213, 1992). [IP6] The IP6 base documents [RFC1629] The one that explains GOSIPv2 addressing [Rekhter] Forthcoming IP6 address allocation documents. [Katz] Forthcoming IP6 autoconfig document. Authors' Addresses Brian E. Carpenter Group Leader, Communications Systems Phone: +41 22 767-4967 Computing and Networks Division Fax: +41 22 767-7155 CERN Telex: 419000 cer ch European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch 1211 Geneva 23, Switzerland Jim Bound Member Technical Staff Phone: (603) 881-0400 Network Operating Systems Fax: (603) 881-0120 Digital Equipment Corporation Email: bound@zk3.dec.com 110 Spitbrook Road, ZKO3-3/U14 Nashua, NH 03062 Expires February 28, 1995 [Page 10] ------------------------------------------------------------------------------ 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 Mon Aug 29 09:13:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26290; Mon, 29 Aug 94 09:13:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26284; Mon, 29 Aug 94 09:13:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AB21228; Mon, 29 Aug 94 09:10:12 PDT Received: from netcom5.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA17428; Mon, 29 Aug 94 09:09:49 PDT Received: by netcom5.netcom.com (8.6.8.1/Netcom) id JAA16495; Mon, 29 Aug 1994 09:09:57 -0700 Date: Mon, 29 Aug 1994 09:09:57 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199408291609.JAA16495@netcom5.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) source routing & authentication Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The kind of security provided by the IPv6 Authentication Header >cannot work well unless virtually all hosts on the Internet support it. >Timeless examples have shown that most users don't know and/or care enough >to make their systems conform with standards specifications. Most users >will install their software and then do as little configuration is necessary While this may be true I guess we need to ask the question, what is authentication protecting? Just like what are seatbelts protecting? Probably the same thing. Nobody can force me to wear seatbelts, so its my choice of whether or not to take the chance. Authentication is the same. The incentive to wearing seatbelts is to avoid a fine that one may receive. The incentive for learning/using authentication is the ability to communicate with others at sites that require it. We should be defining the protocols so that a service can be provided, but we should not be in the legislation business, for then we have stepped out of bounds. > The painful, but probably correct, solution to performance problems >with the Authentication Header is to have hardware or coprocessor assistance >with the secure hash (be it MD5, or whatever else you might use). Since this >is not a very good solution for existing systems, a very high level of >optimization including well-written assembler code is necessary. If you are >unwilling to do this, then you shouldn't be complaining about performance. This isn't a very good solution for all future systems as well. Price points you know. >>Also source routing is very valuable and it must be part of IP6. Mobile IP has had some of the smae arguements as we are now hearing for source routing. In mobile IP it is a must to have authentication, but there are work arounds to avoid using it. This seems silly, since authentication is a should so lets face the problem correctly instead of creating non-interoperable systems. Lets try and do source route correctly. > -Craig ------------------------------------------------------------------------------ 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 Mon Aug 29 09:45:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26347; Mon, 29 Aug 94 09:45:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26341; Mon, 29 Aug 94 09:45:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AB24354; Mon, 29 Aug 94 09:42:36 PDT Received: from anl.gov (dns2.anl.gov) by Sun.COM (sun-barr.Sun.COM) id AA23892; Mon, 29 Aug 94 09:42:19 PDT Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA05325; Mon, 29 Aug 94 11:42:17 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:ipng@sunroof.Eng.Sun.COM id AA07298; Mon, 29 Aug 94 11:42:15 -0500 Date: Mon, 29 Aug 94 11:42:15 -0500 Message-Id: <9408291642.AA07298@benedick.ctd.anl.gov> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPNG Capabilities Cc: kgk@hookup.net From: "Richard Carlson" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >kgk@hookup.net (Keith G Knightson) Writes: >Also, it would remove any further arguments or requirements for about a >common single protocol. CLNP could, if the OSI folks desire, be enhanced to >be functionally equivalent without impacting on the control of IPNG >developments themselves. Clearly protocol mapping would still be required >in gateways, but this is child's play compared to address mapping. I see a >big advantage to this scenario in the sense that this would extend the >scope and reach of the INTERNET into the OSI world. This would make the >INTERNET a truly global and supreme entity. Keith; Well this little statement "protocol mapping...[is] ...child's play compared to address mapping" really triggered something in me. It's kind of like saying "I dropped the atomic bomb and it went off" (Harry Harrison). Protocol mapping is a *HORRENDOUS* idea and it 10^N times more difficult than address mapping. A protocol contains an entire set of specifications to describe the contents of a it's payload. The address field inside this protocol is just one parameter. What do you do when different protocols have different fields, or the fields mean different things. You will lose information when you map one protocol to another. The problem I see with your entire proposal it that you think we should make IPng and CLNP interchangable. Why? Ask yourself "who uses them". The answer is the transport layer (TCP, TP4, ...). Why not think of some way to make TCP run over IPng or CLNP? This is what you will get if TCP were changed to use an EID instead of an IP address in it's pseudoheader. TCP wouldn't care how the data was moved over the network, just that it got from source to destination reliabely. The network layer shouldn't care what the transport layer is, anymore than it cares if the physical layer is a T1/E! or Ethernet wire. The point is to let the market (users) decide what protocol(s) to run. There may be political or technological reasons to choose one network protocol over another, but why should the user application/transport layer care? We don't need to converge IPng and CLNP, we need to free TCP (and TP4) from being required to use a protocol that only supports a specific type of address. This would make convergence a non-issue and we could then get on with the job of building networks that will work and scale effeciently. Rich Carlson ------------------ Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 ------------------------------------------------------------------------------ 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 Mon Aug 29 11:32:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26652; Mon, 29 Aug 94 11:32:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25985; Mon, 29 Aug 94 05:32:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05084; Mon, 29 Aug 94 05:29:55 PDT Received: from inesc.inesc.pt by Sun.COM (sun-barr.Sun.COM) id AA16528; Mon, 29 Aug 94 05:29:25 PDT Received: from avila.inesc.pt ([146.193.248.1]) by inesc.inesc.pt with SMTP; id AA26848 (5.67a+/SunOS4.1.3); Mon, 29 Aug 1994 13:33:49 +0200 Received: by avila.inesc.pt (4.1/SunOS4.1.2) id AA26269; Mon, 29 Aug 94 13:37:54 +0200 From: prc@avila.inesc.pt (Pedro Ramalho Carlos) Message-Id: <9408291137.AA26269@avila.inesc.pt> Subject: [long and technically pointless] Re: (IPng) WHAT ELSE -- IPNG AND MADNESS To: alan@datacraft.oz.au Date: Mon, 29 Aug 1994 13:37:53 +0200 (MET DST) Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <"940825 13:33:09"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> from "/G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au" at Aug 25, 94 04:55:14 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dear Alan You said: > Gentlefolk. > [...] > > On the other hand large scale system designers will steer toward carrier/ > ISO standards approach to global networking because of the preferred > engineering approach, the twenty year lifetime of solutions, the horsepower ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Since OSI is approaching this age, I think it is time that the "engineering approach" you mention be once again used to define the OSI for the next 20 years. I propose that most of the "people-concerned-with-the-limited-length-of -IPv6-addresses" start at some convenient Sub-Committee of ITU, or whatever, this OSIv2 effort. ( I think it was /mtr [sorry if it wasn't you] that once said the real danger was that OSI's "engineering approach" would pervade the IETF. He proposed that we should therefore promote the OSI++ effort so that the people involved in OSIv1 could continue there "effort" OUTSIDE the IETF. As the signal/noise ratio (my message included) of this list proves mtr was right...) Please take this discussion off to some other forum. I volunteer to setup a mailing list for OSIv2 if that's the only way to stop this thread. ---IPNGers STOP HERE NOTE: The rest of the message is really worthless technically (and otherwise :-). So ipng-ers, don't spend precious time reading it. ---- [...] > provided by the carriers and media industries combined and the ablity to > adminster the radio/ satellite spectrum, addressing schemes and international > public services.. ...which do not involve computers! You're right off course.;-) > > Obviously I have little desire to see this fragmentation but given the choice > I will direct my energies to the longer term stable, global IT environments > rather than the fast a furious, self defeating approach to IT.. I think the problem is that the fragmentation comes from the completely different engineering approaches followed. These don't seem to have changed so I see no point in convergence (unless we really want IPX to be the internetworking framework of the future) > Addressing::The burning question. ouch! > > On the addressing issue the debate should be supported by recognising that > we all use the telephone numbering schemes with comfort because they are a > unique across the planet.. They are formally assigned.. by the ITU and ^^^^^^^^^^^^^^^^^^^^^^^^^^ The same happens with IPv4 addresses, so what's your point? It's just not the ITU, it's cheaper and a LOT FASTER! > carriers / regulatory bodies within the respective countries... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ...also known as monopolies and bureaucrats in most of the world... :-) > Now hopefully we all see the benefit of this and do realise that even in a > deregulated environment, that the network numbering schemes for international > working must be global, unique and administered by recognised authorities.. > otherwise global chaos will result. Yes, totally agreed. IANA, InterNic, Ripe, et al. are fine with me. And reachable by email too.:-) > > In the Internet case where TCP/IP started life as an interconnectivity tool > for LANs, the addressing was "just a funny number". ie It had local > significance only. Haha :-) You have to go back and look a little bit further back. There were no LAN's when TCP/IP was designed... (perhaps with the exception of some labs in Palo Alto and Maynard?) > > Applied globally though..a limited number form obvious problems will creep > in.. scale, allocation, duplication, routing algorithms, etc, etc.. > > Given a fundamental rule of mine is "the first action of any network design > is to determine its naming and addressing scheme " simply because getting it > wrong means digging it up (and switching the network off).. the internet in > my eyes has a serious problem. Ie how will it manage this upgrade and more > importantly how will it be done and who is going to pay? The point is that 99% of Internet users have yet to hear of an IPv4 address. They use domainnames, and these are a lot more flexible than NSAPS... If we let IPv6 people work I hope the other 1% will have an easy time upgrading. > The point here is there will be a massive cost to change the IP equipment on > this planet.. Is there any guarentee that IPv6 will work or be recognised by > aviation, transport, government systems, mobile systems, ships, aircraft.. > probably not. > Why? because the consensus mode and working code approach to development > cannot be applied to the administrative and commercial aspects of > multi/international commercial operations.. One cannot design a carriers or > major industries technical and operational interfaces with other > carriers/organisations in a few RFCs on a week end! No, you need reliable, cost-effective, running code to do it. And if you can technically connect each other with efficient and workable solutions that fit the end-users needs, the administrative and commercial aspects can be settled... If I ever upgrade to IPv6 it's because my users and their application needs make it worthwhile, not because my local carrier wants me to. (For background history on carrier confusion on this, look at ISDN; for forward looking at this wait for ATM - aka Another Terrible Mistake :-) > THe IETF seems to believe that because it can "design a 16 byte" address for > the whole planet, it will automatically get the support of the IT industry > and regulatory bodies to propagate this around the world.. Some router > vendors will naturally support this because there is money in "connectivity" > tools but the bottom line stuff is why would any supplier put in a network > into an international operation such as defence, govt, avaiation, etc where > there is a major risk of the network having large scale problems because of > issues with regulatory matters, assorted addressing schemes, routing > algorithms, interworking and dealing with international switched carrier > services.. There sure will. But then again, they can just lease some circuits and put PPP over them and forget about the "switched carrier services", can't you? It seems to be the trend by the way in most of the aforementioned networks, and IPv4 is present (along with IPX, and other proprietary stuff). Only CLNP seems to have lost momentum all over... And the circuit could just as well be supported on some ATM fabric if it is economical enough... ...and the whole of the other problems you mention are independent of having 16 or 20 byte addresses, BTW. > Is the scenario going to be as the Internet becomes a commercial network > operator, that it will have to upgrade its management (say to X.700, TMN, > carrier billing systems, service level agreements , etc, etc and possibly use > X.500 directory systems.. etc.. just because its the only global directory > standard on the block) and that it (the Internet) should come under the > regulatory requirements of a country .. ie does the IETF as a commercial > network operator have to comply with the regulatory issues of a country as > per Telecom, OPtus, etc. The IETF is not the IRTF (internet Regulatory Task Force). Leave this to the IP services providers to workout. They have and they will. > And THEN dont forget the mighty SNPM... > Simple -- Network Management Protocol > Simple Network -- Management Protocol > Simple Network Management - Protocol > > I am never sure of which one it is.. I tend to think that names are not important here. Working technology to satisfy perceived needs are. SNMP has made some things in NM easier. X.7xx has not. > In my previous comments I mentioned that SNMP is associated with a flat > information model.. Whereas CMIP is associated with an Object model.. > And Objects have names (global names in global networks).. as per X.500 > naming.. > > Now given that SNMP was designed for interfaces on connectionless networks > and CMIP was designed so that it can deal with a switched connection oriented > environment with objects (which get created and destroyed) that can represent > circuits.. How do the vendors plan to manage switched B-ISDN and ATM in a > large scale environment with SNMP! Particularly when the large scale > evironment will be controlled by the carriers -- (X.700/CMIP and TMN). SNMPvX has some problems, but this is not one of them. The Internet is the largest packet network in the world and it is managed with ping, traceroute, SNMP and other similar task oriented tools and it works. And I still remember the time when the "SNMP platforms" were classified by the OSI community as LAN toys as compared with the pre-TMN tools from the large switch vendors. Can you take a look and see how many of these large switch vendors haven't changed or commited to change to the same code used by the SNMP toys?... [note: this is not a plug for HP :-)] (BTW: I always loved the "scale argument" then. It basically ran: "Carrier networks are so much larger that LANs and Internetworks. There are literally millions of devices to be managed." Without some major insight, I suppose that this refers to the "terminal equipment", aka as telephone sets. I wonder how much a CMIP upgrade for my handset will cost?) OK. I agree that SNMP is a bit like using Assembly language to run networks. But, on the other hand X.7xx and M.3xxx is like using a word processor to do the same... ;-) > Well I see that if the Internet wants to go to ATM and B-ISDN - This uses > carrier numbering plans..and NSAPs. The management system (just because of I use 4-byte IP addresses over all kind of addresses today, including ISDN's E.164, SMDS, etc. It won't be different for ATM. There's a thing called ARP, around the Internet these days. IPv6 will not become poorer than IPv4 in that respect, I'm sure. > the carrier / switched focus) will orient itself to X.700 and X.500 because > of the object methodology and global naming.. I love this words. What do they buy you in the end? I know of a lot of global naming schemes in the Internet (DNS, URL's, AFS) What else is new? Object methodology reminds me of software development and Yourdon (have you read his comments on the object methodology used in the information modelling of the OSI work -see his "Object Oriented Analysis, 2nd Edition"? Perhaps you'll be convince that this "object" label can be put on top of almost anything) > There seems little point in having a network which has internationally > defined management and directory system technologies that use global naming, > which runs over internationaly defined carrier services with international > addressing schemes but in the middle an internetworking protocol that uses a > bag of funny numbers which have no official tie to the geography of the > planet or the authorities that allocate names and addresses.. I have yet to see those "internationaly defined carrier services" in practice. Are you talking of the international X.25 network? Or perhaps the global X.400 MTA network? Or are you talking about private networks built on top of leased circuits? Funny numbers? Yup. Although NSAPS are probably the "John Cleese" of funny numbers. (Not to mention X.400 O/R [Bob Hope], X.500 DN's [Herman Jose], et.al) > In closing > > In the new internet.. which I assume will be commercial, managed, secure and > have accounting tools and be using elements of B-ISDN, X.700, E.164 > addressing, NSAPs, X.500 and be in a "deregulated" carrier environment, there > will many issues. So why does an "commercial, managed, secure and hav[ing] accounting tools" internet have to use B-ISDN, X.700 and E.164, NSAPS, etc? Are they inerently more secure, accountable, manageable, commercial? Why? Where? How? WHEN? > > What is the IETFs view of this? > Simply because if the IETF cannot provide any objective answers oe guidance > on these, the IT industry and the User community should know.. > > There is no point in believing one can produce world standards based on > "working code" if one has no accountability or credibility.. I guess we all know about the accountability and credibility of the United Nations in most of the other fields. Why should we trust it more on Internetworking technologies? It's funny that most of these arguments tend to have a closing like this and since most of the people on the list are in the US the "international" argument tends to be preached over and over against them. This is simply not true! The rate of growth in both the Internet, Internet based technology and user awareneness of it seems to be as large here in Portugal as everywhere else. And the opposite goes for ISO internetworking related technologies. cheers, and sorry for this too long message (I promise I will not contribute further to this thread) --- pedro ramalho carlos email: prc@inesc.pt INESC tel: +351-1-3100050 Av. Duque de Avila, 23 fax: +351-1-3100008 1017 Lisboa Codex - PORTUGAL PS: Alan, please don't take this personally, but I'm full of the whole OSI argument, and your "well known" arguments have hit the no-silence threshold. ------------------------------------------------------------------------------ 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 Mon Aug 29 12:03:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26733; Mon, 29 Aug 94 12:03:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26727; Mon, 29 Aug 94 12:03:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09695; Mon, 29 Aug 94 12:00:12 PDT Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA25360; Mon, 29 Aug 94 11:59:48 PDT Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id OAA05818; Mon, 29 Aug 1994 14:59:45 -0400 Message-Id: <199408291859.OAA05818@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) source routing & authentication In-Reply-To: Your message of "Mon, 29 Aug 1994 09:09:57 EDT." <199408291609.JAA16495@netcom5.netcom.com> From: Valdis.Kletnieks@vt.edu Date: Mon, 29 Aug 1994 14:59:45 +22306356 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Mon, 29 Aug 1994 09:09:57 EDT, you said: > Probably the same thing. Nobody can force me to wear seatbelts, so its > my choice of whether or not to take the chance. Authentication is the > same. The incentive to wearing seatbelts is to avoid a fine that one > may receive. The incentive for learning/using authentication is the > ability to communicate with others at sites that require it. Umm.. the penalty of not wearing seatbelts is *not* having to pay a fine, it's having to extract your head from the other side of the windshield when you hit something. The logic of mandating end-to-end security is the same as the logic of mandating seat belts - to prevent problems that impact others. End-to-end security should be a "required by default, requires special action to disable", rather than a "here it is if you want to". I'm tired of picking up the roadkill on the Infobahn left over when people are allowed to practice unsafe computing by default... Valdis Kletnieks Computer Systems Engineer Virginia Tech ------------------------------------------------------------------------------ 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 Mon Aug 29 12:19:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26763; Mon, 29 Aug 94 12:19:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26757; Mon, 29 Aug 94 12:19:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11543; Mon, 29 Aug 94 12:16:23 PDT Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA29491; Mon, 29 Aug 94 12:16:04 PDT Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id PAA27190; Mon, 29 Aug 1994 15:15:59 -0400 Date: Mon, 29 Aug 1994 15:15:59 -0400 From: Vadim Antonov Message-Id: <199408291915.PAA27190@titan.sprintlink.net> To: avg@sprint.net, ipng@sunroof.Eng.Sun.COM, yakov@watson.ibm.com Subject: Re: (IPng) security & source routing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Consider the following IPv6 in IPv6 encapsulation (each box represents >an IPv6 header, but the picture shows only only src and dst address fields): > +------------------+------------------+------------------+------------------ > | src = 1, dst = A | src = A, dst = B | src = B, dst = A | dst = B, src = A > +------------------+------------------+------------------+------------------ >How is that different from your example with the source route ? This require boxes to de-encapsulate. I would definitely have de-encapsulation disabled on all transit boxes! IMHO, encapsulation should work only if specifically enabled for particular source-destination pair; i.e. much like current cisco tunnels. Nobody ever tried source-based routing on large wide-area networks and it is very unclear (at least to me) if network allowing it can ever be made manageable. Unmanageable network is useless by definition (at least people who do transport services for living will *never* knowingly bet their business on good behaviour of everybody in the whole Internet). --vadim ------------------------------------------------------------------------------ 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 Mon Aug 29 17:55:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27160; Mon, 29 Aug 94 17:55:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27154; Mon, 29 Aug 94 17:55:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11067; Mon, 29 Aug 94 17:52:38 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA06255; Mon, 29 Aug 94 17:52:20 PDT To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) security knobs Date: Tue, 30 Aug 94 1:49:01 GMT From: Ran Atkinson Message-Id: <9408300149.aa08336@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, As a customer, I think knobs are great. The default settings should be on safety not "wide open to vandals". Sun learned this sometime between SunOS 4.1.3 and Solaris 2.3. Customers, not the IETF or IESG, drove that change. Vendors who plan to be around for long have to make business decisions and IETF/IESG mandates that are not sensible in business terms will simply be ignored in the real world. Seriously, we need words like "MUST" for the benefit of firms who slavishly adhere to the exact words of the standard and don't think about customer needs. Not adhering to an Internet spec is legal as long as one doesn't _claim_ to fully adhere to that spec. I want the security specs to make "reasonable" requirements, but security completely turned off by default is not reasonable. Default fully on with a knob to turn security off is reasonable from a security perspective but has negative performance impacts. There is some middle ground that is reasonable to most folks. Its more productive to try to find that middle ground, don't you think ? Best Regards, Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ 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 Mon Aug 29 18:34:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27219; Mon, 29 Aug 94 18:34:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27213; Mon, 29 Aug 94 18:34:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13702; Mon, 29 Aug 94 18:31:35 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA21974; Mon, 29 Aug 94 16:28:41 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 30 Aug 1994 09:24:46 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Tue, 30 Aug 1994 09:27:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 30 Aug 1994 09:24:06 +1000 Date: Tue, 30 Aug 1994 09:24:06 +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 Aug 30 09:24:05 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 052409300894 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <052409300894*/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) security & source routing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM True, but I will note that its difficult to enforce such a policy except by stopping all unauthenticated source routed packets. Nonsense. The service tells the receiving host stack what its policy is. If authenticated source routes are required, then the packets are not delivered to the service. If unauthenticated source routes are permitted, then the data is delivered to the service. Is there an assumption here that the host software/system has to play the game? If the system is "got at" or poorly implemented, then the authentification headers could be ignored or bypassed. Is this being put in place to protect the host or the service? If it is the host, then its their problem but if it the service then it probably wont be water tight. Jeff ------------------------------------------------------------------------------ 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 Mon Aug 29 21:15:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27354; Mon, 29 Aug 94 21:15:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27348; Mon, 29 Aug 94 21:15:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19703; Mon, 29 Aug 94 21:12:25 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA26296; Mon, 29 Aug 94 21:11:56 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA08101; Mon, 29 Aug 94 21:01:17 -0700 Received: by xirtlu.zk3.dec.com; id AA06443; Tue, 30 Aug 1994 00:01:08 -0400 Message-Id: <9408300401.AA06443@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security knobs In-Reply-To: Your message of "Tue, 30 Aug 94 01:49:01 GMT." <9408300149.aa08336@sundance.itd.nrl.navy.mil> Date: Tue, 30 Aug 94 00:01:02 -0400 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, Hey my middle name is RISK but sometimes MIDDLEGROUND is OK though I hate mediocrity. But yes I am open to the middleground for sure. Part of that middleground are people who have no need for security in the fashion designed in IP6 at present. Some would not want IP6 without security so we have a real dilemna. Don't we. I appreciate the knowledge gained which you reference for Sun. We at Digital have much knowledge about customers and security too. At the end of the day when push came to shove and it was not a GOVERNMENT customer and they saw the performance or admin set up (the KEY MANAGEMENT STRATEGY) they said bag it and turn it off or worse yet "I am not paying for that". This Ran is reality not every customer in the world will pay for security. Please not lets get into the customer discussion for everyone you tell me that wants it I will tell you one that doesn't at extreme cost. And this will digress to a technical debate for the little rascals. But how about this: I build an IP6 product on a host. I conform to all security. When you get your system at the boot prompt it states: Do you want IP6 security configured on your system (y or n) [y]: _ The default is "y" but at the prompt they can enter "n". Now what I do is not load all the binaries and compress all unnecessary kernel routines etc (in the case of an embeded system) and other kernel config trickery. I have a compliant system that is not running with security. This gives me as a vendor an option for my customers. This customer can run rlogin without IP6 security even though its address-based and use what rlogin uses today. But this is only 1/10th of t discussion we need to have. But it is a start so folks shoudl not think this is the only issue it is only the first issue I assure you. But agreement on this would be nice soon. /jim ------------------------------------------------------------------------------ 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 Mon Aug 29 22:43:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27409; Mon, 29 Aug 94 22:43:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27403; Mon, 29 Aug 94 22:43:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22013; Mon, 29 Aug 94 22:40:38 PDT Received: from holonet.net (giskard.holonet.net) by Sun.COM (sun-barr.Sun.COM) id AA03512; Mon, 29 Aug 94 22:40:21 PDT Received: from DialupEudora (aheflich@localhost) by holonet.net with SMTP id WAA18365; Mon, 29 Aug 1994 22:38:50 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Aug 1994 22:39:17 -0700 To: ipng@sunroof.Eng.Sun.COM From: aheflich@fc.mcnet.com (Alan Heflich) Subject: Re: (IPng) security knobs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I appreciate the knowledge gained which you reference for Sun. We at >Digital have much knowledge about customers and security too. At the >end of the day when push came to shove and it was not a GOVERNMENT >customer and they saw the performance or admin set up (the KEY >MANAGEMENT STRATEGY) they said bag it and turn it off or worse yet "I am no= t >paying for that". This Ran is reality not every customer in the world >will pay for security. Please not lets get into the customer discussion >for everyone you tell me that wants it I will tell you one that doesn't >at extreme cost. And this will digress to a technical debate for the >little rascals Jim I am glad your proposal (not copied above) left the security as part of the= install and the default. When I see how easy it is to make a counterfeit= FROM address it makes me want securtiy in the form of authentication. In= fact my FROM address is NOT the send address. Eudora, my mailer software,= lets you specify the RETURN ADDRESS. I let IETF mail flow into this= address. Personal mail goes to the FROM address. Eudora does not have a= Reply To: address. As EDI and other electronic on net transactions come about, security will be= a MUST. I agree with RAN that it should be specified as a 'MUST' for all= companies providing Ipv6. Otherwise companies may make a decision just= based on price (really 8-D) and make a decision which they will later regre= t. =3DAlan MetaCity Network ------------------------------------------------------------------------------ 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 Mon Aug 29 23:15:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27492; Mon, 29 Aug 94 23:15:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27486; Mon, 29 Aug 94 23:15:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22633; Mon, 29 Aug 94 23:12:47 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA07033; Mon, 29 Aug 94 23:12:29 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23128; Tue, 30 Aug 1994 08:12:27 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28100; Tue, 30 Aug 1994 08:12:25 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408300612.AA28100@dxcoms.cern.ch> Subject: Re: (IPng) security knobs To: ipng@sunroof.Eng.Sun.COM Date: Tue, 30 Aug 1994 08:12:25 +0200 (MET DST) In-Reply-To: <9408300149.aa08336@sundance.itd.nrl.navy.mil> from "Ran Atkinson" at Aug 30, 94 01:49:01 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 218 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Customer speaking: I want to be able to impose a site security policy. That means that if a user on my site says "No" when the config asks about security, that "No" must be over-ridden by a site-wide "Yes". Brian ------------------------------------------------------------------------------ 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 Tue Aug 30 00:06:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27628; Tue, 30 Aug 94 00:06:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27622; Tue, 30 Aug 94 00:05:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23779; Tue, 30 Aug 94 00:03:07 PDT Received: from netcom15.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA13653; Tue, 30 Aug 94 00:02:47 PDT Received: by netcom15.netcom.com (8.6.8.1/Netcom) id AAA06852; Tue, 30 Aug 1994 00:03:11 -0700 Date: Tue, 30 Aug 1994 00:03:11 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199408300703.AAA06852@netcom15.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security knobs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I want to be able to impose a site security policy. That means >that if a user on my site says "No" when the config asks about >security, that "No" must be over-ridden by a site-wide "Yes". I would assume this would be the default because this user most likely would not be able to communicate with the other sites! Thus, the user would either reconfigure or communicate with themselves. >Brian rich ------------------------------------------------------------------------------ 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 Tue Aug 30 00:19:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27666; Tue, 30 Aug 94 00:19:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27660; Tue, 30 Aug 94 00:19:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24425; Tue, 30 Aug 94 00:16:20 PDT Received: from netcom15.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA15389; Tue, 30 Aug 94 00:16:03 PDT Received: by netcom15.netcom.com (8.6.8.1/Netcom) id AAA09040; Tue, 30 Aug 1994 00:16:30 -0700 Date: Tue, 30 Aug 1994 00:16:30 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199408300716.AAA09040@netcom15.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security knobs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >As EDI and other electronic on net transactions come about, security will be= >a MUST. I agree with RAN that it should be specified as a 'MUST' for all= >companies providing Ipv6. Otherwise companies may make a decision just= >based on price (really 8-D) and make a decision which they will later regre= t. I guess the real question is what does MUST mean? We MUST implement? We MUST have turned on? Any spec that says I must suffer in cost and performance for a feature, notice the word is feature, is completely wrong. It might be better for the spec to say its a MUST but provide mechanisms (or wording) that allows me to not incur the burden, ie: Jim's idea of the install line question. The one line of your note that I really disagree with, and the one that seems to be prevalent lately, is the one stating that companies may make a decision which they will later regret. The IETF is not the babysitters of the world. We should not be designing as if we are. However, these kinds of statements almost imply that the IETF is taking on the burden of making sure companies do not make bad decisions. I wish the IETF were around when I bought my car, they could have told me it was a bad choice and shown me the light. The penalty for a bad decision is to learn and then do it again, at some expense, of course. Hopefully, if the IETF does its job, people will be more informed before buying so they will have the parameters to make the right choice. Thus, the IETF should not try and make the choices for me as part of all designs, but should spend some effort in educating people so THEY can make there own choices. Folks are becoming more and more network wise and this trend will continue so hopefully more and more companies will be able to make the right choice. And with some help from there vendors and/or the IETF the ability to choose will become even easier! >=3DAlan rich ------------------------------------------------------------------------------ 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 Tue Aug 30 01:02:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27783; Tue, 30 Aug 94 01:02:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27777; Tue, 30 Aug 94 01:02:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25537; Tue, 30 Aug 94 00:59:28 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA19430; Tue, 30 Aug 94 00:59:12 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA00846; Tue, 30 Aug 1994 00:59:11 -0700 Date: Tue, 30 Aug 1994 00:59:11 -0700 From: Tony Li Message-Id: <199408300759.AAA00846@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Perry E. Metzger"'s message of Mon, 29 Aug 1994 08:27:07 -0400 <9408291227.AA10462@snark.imsi.com> Subject: (IPng) security & source routing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Summary reply: - I have no objections to full-blow security (intelligently applied) being the default. - I have no objections to security being implemented in something other than the endhost. - I would object if you mandate that there not be a knob to disable security. - I don't understand why someone would object to decapsulation on a transit box. Or any of Vadim's other comments for that matter. - I think it's regrettable that IPv6 didn't at least do variable length addresses so this entire NSAP issue could go away, but the matter IS decided, for better or worse. Time to learn to live with it. In any case, please stop sending mail. Tony ------------------------------------------------------------------------------ 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 Tue Aug 30 02:10:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27994; Tue, 30 Aug 94 02:10:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27988; Tue, 30 Aug 94 02:10:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00565; Tue, 30 Aug 94 02:07:41 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA26565; Tue, 30 Aug 94 02:07:23 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) IPNG Capabilities To: ipng@sunroof.Eng.Sun.COM Date: Tue, 30 Aug 1994 10:04:02 +0200 (BST) Cc: kgk@hookup.net In-Reply-To: <9408291642.AA07298@benedick.ctd.anl.gov> from "Richard Carlson" at Aug 29, 94 11:42:15 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1379 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The point is to let the market (users) decide what protocol(s) to run. There > may be political or technological reasons to choose one network protocol over > another, but why should the user application/transport layer care? We don't > need to converge IPng and CLNP, we need to free TCP (and TP4) from being > required to use a protocol that only supports a specific type of address. > This would make convergence a non-issue and we could then get on with the > job of building networks that will work and scale effeciently. The basic theory is fine. The final statement is wonderfully naiive. Suppose I tell a remote host to connect to 'X', and 'X' is a different addressing system. I of course didnt find out because it was transparently concealed. I'm now on a total lose with an address format not understood. Run CLNP over IPng or for that matter run CLNP+small header that precisely maps to IPng - that is in effect an efficient carrier of IPng over CLNP. The fact that IP can be run over everything from serial ports to ATM has a lot to do with why it is a success - as does the fact they all interwork properly with basically one bottom protocol layer and a certain amount of handwaving and labelling the mac layers as SEPs (Somebody Elses Problems). If true IPng goes in and out of any link it doesn't matter whether its OSI, ethernet or hand signals. Alan ------------------------------------------------------------------------------ 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 Tue Aug 30 09:18:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28999; Tue, 30 Aug 94 09:18:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28993; Tue, 30 Aug 94 09:18:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16683; Tue, 30 Aug 94 09:15:43 PDT Received: from LABS-N.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA15260; Tue, 30 Aug 94 09:15:26 PDT Message-Id: <9408301615.AA15260@Sun.COM> Date: Tue, 30 Aug 94 12:13:28 EDT From: Steven Winnett To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Reserved Bytes of NSAP Address Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Attached is a message I sent to Jim Bound re his Internet draft for OSI NSAP usage for IP6. I know there are many on this list who don'`t want to reopen this topic, but nevertheless I for one would like to know whether we should just leave this issue hanging. I would assume that those who are using the reserved octets have some good reason for doing so, and that these are probably being used as an extension of the high-order part of the address (to use the terminology of the Internet draft). It might be useful to hear who *is* using these bytes, and for what purposes. Then it can be determined whether they need to be fitted into the mapping scheme. Steve Winnett Bolt, Beranek & Newman Cambridge, MA, USA >>I have a question with regard to your very interesting >>Internet draft you just published. What happens if the >>2 reserved bytes are being used? Jack Houldsworth sent >>a message a few days ago to ipng which stated that in >>UK (vs. US) GOSIP *all* 20 bytes are specified by the >>CCTA (Central Computer Technical Authority). Where >>would these go in your mapping scheme? >Well it just won't work. They will have to renumber might be thE only >answer. Unless we can dream up a BCD scheme for the translator. > >/jim ------------------------------------------------------------------------------ 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 Tue Aug 30 09:38:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29072; Tue, 30 Aug 94 09:38:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29066; Tue, 30 Aug 94 09:38:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18616; Tue, 30 Aug 94 09:35:20 PDT Received: from anl.gov (dns2.anl.gov) by Sun.COM (sun-barr.Sun.COM) id AA18742; Tue, 30 Aug 94 09:35:00 PDT Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA16081; Tue, 30 Aug 94 11:34:57 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:ipng@sunroof.Eng.Sun.COM id AA07884; Tue, 30 Aug 94 11:34:56 -0500 Date: Tue, 30 Aug 94 11:34:56 -0500 Message-Id: <9408301634.AA07884@benedick.ctd.anl.gov> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products From: "Richard Carlson" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Vadim Antonov writes: >Well, i read the paper and although i agree with the goal i completely >disagree with the proposed solution (also, the problems witch TAs are >supposed to solve in reality look quite different -- for example, >growth of routing tables in not the problem per se given intelligent >planning on part of router vendors; routing flap is THE problem). Vadim; The problem TAs are suppose to solve is the limits to growth of the Internet. The problem with how to scale the existing routeing protocols to a very large cloud is just one of the problems that must be faced. It is by no means the only problem. I veiw routeing as a function of the network layer protocol, the fact that TAs don't adress this is because TAs are transport layer things. They aren't used to route packets over the network. >> In order to get from IPv4 to IP6 I need to change the networking code >>in all my workstations, servers, and routers. Since not all of them can >>change at once, I will wind up with a mix of both. >Yes. So what? Is it wise to write a kluge for transition period into >canons? There are other ways to get it done without adding new entities >for network administrators to have nightmares about. What "kluge"? My proposal is to change the very foundation that TCP/IP is built upon. The point I was trying to make is that there is no "transition period". When IP 6 is deployed, the Internet will run both IP6 *AND* IPv4 forever more. The term "transition period" implies there is a change from IPv4 to IP6 and at some time IPv4 will go away. I don't think IPv4 will ever die, so you I want a long term solution that allow IPv4 and IP6 to coexist. >There is a simple and trivial idea on how to make TCP to be *completely* >unaware of the transport locators. The idea is to kill the notion of >"one port -- many TCP connections" and replace it with "one port -- one >connection". In other words, make the semantics of the network identical >to the semantics of the socket interface. The quick fix required is >introduction of TCP option "Connection Accepted At" with the value of >the new destination transport locator (including port). I have read this mail message several times and I'm afraid that I don't see anything simple or trivial in it. .-) Let me describe what I think you said. If this is wrong, please let me know. Suppose I have a company "xyc.com" with hosts "a", "b", and "c". I build my network and somehow announce to the word that "xyz.com" exists and it can be reached at addresss ii:jj:kk. (You must announce this one address so remote nodes will know where to send service requests). All other addresses are "hidden" such that only the "xyz.com" server needs to know what they are. Operation is as follows 1) a remote node requests service from the xyz.com domain (i.e. telnet xyz.com). 2) the xyz.com server receives the request, decides it can honor it and returns an service "socket" (address.port). 3) the remote node receives the reply and opens a connection using the returned "socket" info. Is this correct? If so then I see a number of problems * how is the address of xyz.com announced? (DNS ?) * how does this proposal reduce the administrative burden on the local site? The DNS table still has to be kept up to date so the server xyz.com can find the real machines. Only the remote sites don't need to know the real addresses (no more DNS xfers?) * how do I reach a specific local node? If "A" is a small cluster and "C" is a cray and both support incoming telnet sessions, how do I tell xyz.com that I need to use the cray because I'm running a global weather simulation. * you rely on 2 new TCP options to make this work. How do unmodified remote nodes get access to your site? What happens when the remote node crashed because it didn't understand the option? (It could be very dangerous to rely on undocumented TCP options with all the different TCP implementations out there). >Actually, there is a clever idea (by Noel Chiappa, i believe) of >how to make all IPv4 applications to work with big addresses w/o >*ANY* modifications in application code. The idea is following: Well Noel might be able to come up with a way to map pseudo IPv4 addresses into IP6 addressses, but I don't think it will be easy to implement. I manage a large complex multi-protocol network. There are thousands of MAC's and PC's and hundreds of Unix workstations/servers and VAXes. The most common questions I get are 1) what is the IP address of the DNS server and 2) what is the IP address of my default gateway. We are giving out IP numbers instead of names. You have to, how else can you get started if you need DNS to lookup the DNS address? .-) The point is applications aren't the only things that look at IP addresses. Like it or not, 90+% of the users on the Internet have seen an address and think you can interchange names and addresses. What happens to Noels plan when the user complains that the node he could get to yesterday is unreachable today and you have to explain that the address he is using was only a random number and he shouldn't be using it. I would be leery of using the term "*ANY*". I would bet there are a lot of developers out there and at least one of them has built an application that would need to be modified. .-) >> I can clearly see how using EID's would make integrating my prototype >>ATM and Fibre Channel networks into my existing IP networks easier. > >And i can clearly see how *not* integrating it will make it even easier. How? If you mean forget about them, then yes it is simple .-) I have a new experimental facility coming online in a year or 2 that will generate LARGE amounts of data (35+ detectors capable of 18 MBytes/sec) which users want to ship to a processor, crunch the data, generate a video image, and ship the image out to a workstation. I *need* ATM or FCS. There is no other technology on the horizon that will support these kinds of data rates. >Let's weight pros and cons of both approaches. I will defend my >approach, ok? ;-) Well you go on to list several pros of your proposal, but no cons (aren't there any? .-) Clearly, I'm not fully convinced yet. .-) Before we start arguing, let's make sure I understand your proposal. Regards; Rich Carlson ------------------- Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 ------------------------------------------------------------------------------ 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 Tue Aug 30 10:03:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29157; Tue, 30 Aug 94 10:03:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28388; Tue, 30 Aug 94 05:34:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05146; Tue, 30 Aug 94 05:31:11 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA12388; Tue, 30 Aug 94 05:30:54 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11050; Tue, 30 Aug 1994 14:30:48 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA07926; Tue, 30 Aug 1994 14:30:45 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9408301230.AA07926@dxcoms.cern.ch> Subject: Re: (IPng) IPNG Capabilities To: ipng@sunroof.Eng.Sun.COM Date: Tue, 30 Aug 1994 14:30:44 +0200 (MET DST) In-Reply-To: from "Alan Cox" at Aug 30, 94 10:04:02 am X-Mailer: ELM [version 2.4 PL22] 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 Please, folks, move further discussion about CLNP or address size OFF the IP6 list and onto the big-internet list. This will help those of us who do automatic input filtering. That's big-internet@munnari.oz.au for the list, and big-internet-request@munnari.oz.au for [un]subscribe requests. ------------------------------------------------------------------------------ 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 Tue Aug 30 16:31:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29706; Tue, 30 Aug 94 16:31:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29700; Tue, 30 Aug 94 16:31:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27902; Tue, 30 Aug 94 16:28:24 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA17637; Tue, 30 Aug 94 16:27:44 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 31 Aug 1994 09:23:02 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 31 Aug 1994 09:26:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 31 Aug 1994 09:03:13 +1000 Date: Wed, 31 Aug 1994 09:03:13 +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 Aug 31 09:03:12 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 120309310894 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <120309310894*/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) security knobs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>As EDI and other electronic on net transactions come about, security will be= >>a MUST. I agree with RAN that it should be specified as a 'MUST' for all= >>companies providing Ipv6. Otherwise companies may make a decision just= >>based on price (really 8-D) and make a decision which they will later regre= >>t. >I guess the real question is what does MUST mean? We MUST implement? >We MUST have turned on? Any spec that says I must suffer in cost and >performance for a feature, notice the word is feature, is completely >wrong. It might be better for the spec to say its a MUST but provide >mechanisms (or wording) that allows me to not incur the burden, ie: >Jim's idea of the install line question. Is the question here more that the API and the architecture must be specified if the feature is not installed so that security modules can just be snapped in later? In that case the third party people could enter the security market and keep the competiition going. Jeff ------------------------------------------------------------------------------ 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 Tue Aug 30 19:12:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00436; Tue, 30 Aug 94 19:12:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00430; Tue, 30 Aug 94 19:12:12 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14472; Tue, 30 Aug 94 19:09:21 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA12890; Tue, 30 Aug 94 19:08:57 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA00888; Tue, 30 Aug 94 19:04:02 -0700 Received: by xirtlu.zk3.dec.com; id AA02735; Tue, 30 Aug 1994 22:03:56 -0400 Message-Id: <9408310203.AA02735@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security knobs In-Reply-To: Your message of "Mon, 29 Aug 94 22:39:17 PDT." Date: Tue, 30 Aug 94 22:03:49 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, Whereever Ran or whoever is going to put MUST I and hope others will want to see other words that permit customers to configure without the IP6 security option. I clearly will be very interested and look carefully at the wording. In fact I think such wording belongs in the IP6 architecture draft whatever it is to be. Which Ran did not write so we need to take this to Steve, Ross, and Bob the Chairs and get off this thread too folks, we can deal with it when it gets written IMHO. /jim ------------------------------------------------------------------------------ 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 Tue Aug 30 19:21:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00474; Tue, 30 Aug 94 19:21:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00468; Tue, 30 Aug 94 19:21:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15027; Tue, 30 Aug 94 19:19:02 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA13954; Tue, 30 Aug 94 19:18:26 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA01098; Tue, 30 Aug 94 19:11:40 -0700 Received: by xirtlu.zk3.dec.com; id AA02784; Tue, 30 Aug 1994 22:11:33 -0400 Message-Id: <9408310211.AA02784@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security knobs In-Reply-To: Your message of "Tue, 30 Aug 94 00:16:30 PDT." <199408300716.AAA09040@netcom15.netcom.com> Date: Tue, 30 Aug 94 22:11:27 -0400 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. Can we move to an engineering discussion of security in host kernel or router implementation to understand the costs? Or is this premature? My expert is gone on leave for a bit and will be back after the implementors meeting unfortuneately but he left me his code and thoughts on how to design this in a UNIX kernel anyway. Again maybe this is premature? /jim ------------------------------------------------------------------------------ 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 Tue Aug 30 19:39:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00556; Tue, 30 Aug 94 19:39:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00550; Tue, 30 Aug 94 19:39:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15939; Tue, 30 Aug 94 19:36:54 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AB15762; Tue, 30 Aug 94 19:36:21 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA01526; Tue, 30 Aug 94 19:25:45 -0700 Received: by xirtlu.zk3.dec.com; id AA02919; Tue, 30 Aug 1994 22:25:35 -0400 Message-Id: <9408310225.AA02919@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPNG Capabilities In-Reply-To: Your message of "Tue, 30 Aug 94 10:04:02 +0200." Date: Tue, 30 Aug 94 22:25:29 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tecnical Commentary: >> The point is to let the market (users) decide what protocol(s) to run. There >> may be political or technological reasons to choose one network protocol over >> another, but why should the user application/transport layer care? We don't >> need to converge IPng and CLNP, we need to free TCP (and TP4) from being >> required to use a protocol that only supports a specific type of address. >> This would make convergence a non-issue and we could then get on with the >> job of building networks that will work and scale effeciently. Not that I agree with this is the way to do it technically (there are varying schools of computer science thought on this), but the above is completely technically accruate. >The basic theory is fine. The final statement is wonderfully naiive. Suppose >I tell a remote host to connect to 'X', and 'X' is a different addressing >system. I of course didnt find out because it was transparently concealed. I'm >now on a total lose with an address format not understood. Run CLNP over IPng >or for that matter run CLNP+small header that precisely maps to IPng - that is >in effect an efficient carrier of IPng over CLNP. The fact that IP can be run >over everything from serial ports to ATM has a lot to do with why it is a >success - as does the fact they all interwork properly with basically one bottom >protocol layer and a certain amount of handwaving and labelling the mac layers >as SEPs (Somebody Elses Problems). If true IPng goes in and out of any link it >doesn't matter whether its OSI, ethernet or hand signals. THis is not technically correct in total. Running network layers over other network layers means "encapsulation" or if something else is mean't clary is needed for me to envision this at least in a host kernel? Using the premise that IPv4 runs over all (as the last entry in the validity table of the premises) does not make valid the previous premise that IPng over CLNP is a valid technical feat that can be accomplished in a network. /jim ------------------------------------------------------------------------------ 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 Tue Aug 30 19:48:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00594; Tue, 30 Aug 94 19:48:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00588; Tue, 30 Aug 94 19:48:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16403; Tue, 30 Aug 94 19:45:44 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA16673; Tue, 30 Aug 94 19:45:08 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA01911; Tue, 30 Aug 94 19:36:36 -0700 Received: by xirtlu.zk3.dec.com; id AA02992; Tue, 30 Aug 1994 22:36:24 -0400 Message-Id: <9408310236.AA02992@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Reserved Bytes of NSAP Address In-Reply-To: Your message of "Tue, 30 Aug 94 12:13:28 EDT." <9408301615.AA15260@Sun.COM> Date: Tue, 30 Aug 94 22:36:18 -0400 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, In the future your more than welcome to send me private mail. But I doubt I will respond unless your asking as a customer. I have a real problem with someone asking me a question privately and then re-posting my response to an IETF Working Group without even asking me. Clearly I will respond to you on this list but I see no need to communicate with you privately again, as I said unless your asking as a customer. To the Working Group: What I said is the way it is. If folks have used the reserved bytes I guess they just have to re-do their address plans. Unless someone has a better idea for that case per IP6 and NSAP mapping. I am looking at the compression now but the scheme I came up with would be a kludge. /jim ------------------------------------------------------------------------------ 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 Tue Aug 30 19:57:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00633; Tue, 30 Aug 94 19:57:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00627; Tue, 30 Aug 94 19:57:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16816; Tue, 30 Aug 94 19:54:20 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA17681; Tue, 30 Aug 94 19:53:54 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA02210; Tue, 30 Aug 94 19:47:18 -0700 Received: by xirtlu.zk3.dec.com; id AA03096; Tue, 30 Aug 1994 22:47:06 -0400 Message-Id: <9408310247.AA03096@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) millions of OSI products In-Reply-To: Your message of "Tue, 30 Aug 94 11:34:56 CDT." <9408301634.AA07884@benedick.ctd.anl.gov> Date: Tue, 30 Aug 94 22:47:00 -0400 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 to completely agree with Richard Carlson as I listen his arguments are all valid and also the points about implementing are complete axioms. P.S. Also Richard's paper on TAs is a very fine piece of computer science software engineering work and for those who have not read it, its not a kludge. You also won't see vague words like "nightmare" and "entity" in his paper which are words I find annoying in a technical debate and try as I can to avoid myself. P.S.S. Richard I think your paper on TAs is relevant to any implementor building IP6 transport layer, may I suggest you send that paper out to this IPng dist list. /jim ------------------------------------------------------------------------------ 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 Tue Aug 30 22:45:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00719; Tue, 30 Aug 94 22:45:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00713; Tue, 30 Aug 94 22:45:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21762; Tue, 30 Aug 94 22:42:12 PDT Received: from netcom2.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA04216; Tue, 30 Aug 94 22:41:55 PDT Received: by netcom2.netcom.com (8.6.8.1/Netcom) id WAA07937; Tue, 30 Aug 1994 22:42:21 -0700 Date: Tue, 30 Aug 1994 22:42:21 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199408310542.WAA07937@netcom2.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Interim meeting Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I will be going to the interim meeting. When will hotel and other info be avialable? thanks rich ------------------------------------------------------------------------------ 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 Wed Aug 31 00:57:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01272; Wed, 31 Aug 94 00:57:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01266; Wed, 31 Aug 94 00:56:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24551; Wed, 31 Aug 94 00:54:05 PDT Received: from holonet.net (orac.holonet.net) by Sun.COM (sun-barr.Sun.COM) id AA17836; Wed, 31 Aug 94 00:53:42 PDT Received: from DialupEudora (aheflich@localhost) by holonet.net with SMTP id AAA24184; Wed, 31 Aug 1994 00:51:20 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Aug 1994 00:51:46 -0700 To: ipng@sunroof.Eng.Sun.COM From: aheflich@fc.mcnet.com (Alan Heflich) Subject: Re: (IPng) security knobs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >The one line of your note that I really disagree with, and the one >that seems to be prevalent lately, is the one stating that companies >may make a decision which they will later regret. The IETF is not the >babysitters of the world. { removed to save space} Hopefully, if the IETF does its job, people >will be more informed before buying so they will have the parameters >to make the right choice. Thus, the IETF should not try and make the >choices for me as part of all designs, but should spend some effort in >educating people so THEY can make there own choices. Folks are >becoming more and more network wise and this trend will continue so >hopefully more and more companies will be able to make the right >choice. And with some help from there vendors and/or the IETF >the ability to choose will become even easier! Richard It looks like you agree with me here. If the IETF does its job and puts security as a firm requirement then the customer base WILL be so educated. GOSIP (do not confuse this with OSI) has already done the groundwork in determining layers 1 through 4 (protocol layers) security determination in the appendix of the GOSIP 2 material It is worth looking at for those who think it will be a checkbook buster. It definitely will not be. With all the easy attacks possible in simple editing of the FROM line, authentication is a leading security need. As for Education, it has a long way to go, especially with the new companies entering the internet market. Some do not even know the word internet. We have to introduce them to it by using 'Information Superhighway' This is NO joke. < Alan Heflich + MetaCity Network + Phoenix Arizona USA > ------------------------------------------------------------------------------ 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 Wed Aug 31 02:01:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01363; Wed, 31 Aug 94 02:01:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01357; Wed, 31 Aug 94 02:01:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29090; Wed, 31 Aug 94 01:58:19 PDT Received: from bunyip.cc.uq.oz.au by Sun.COM (sun-barr.Sun.COM) id AA22345; Wed, 31 Aug 94 01:57:59 PDT Received: from clix.aarnet.edu.au by bunyip.cc.uq.oz.au with SMTP (PP); Wed, 31 Aug 1994 18:57:45 +1000 X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 31 Aug 1994 18:53:58 +1000 X400-Received: by /PRMD=AUSGOVDEFENCENET/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 31 Aug 1994 18:50:21 +1000 Date: Wed, 31 Aug 1994 18:50:21 +1000 X400-Originator: Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au X400-Recipients: IPNG@SUNROOF.ENG.SUN.COM X400-Mts-Identifier: [/PRMD=AUSGOVDEFENCENET/ADMD=TELEMEMO/C=AU/;40A 940831184547] X400-Content-Type: P2-1984 (2) Content-Identifier: 40A 940831184547 From: Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au Message-Id: <"40A 940831184547*"@MHS> To: IPNG@SUNROOF.Eng.Sun.COM (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: (IPng) security & source routing -Reply Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Summary reply: >- I have no objections to full-blow security (intelligently applied) .>being the default. -> I have no objections to security being implemented in something >other than the endhost. >- I would object if you mandate that there not be a knob to disable >security. >- I don't understand why someone would object to decapsulation on a >transit box. Or any of Vadim's other comments for that matter. >- I think it's regrettable that IPv6 didn't at least do variable >length addresses so this entire NSAP issue could go away, but the >matter IS decided, for better or worse. Time to learn to live with >it. In any case, please stop sending mail. BUT how can it go away, you still have to handle the NSAP issue somehow! AND you can't just throw away 4 Bytes that easily either. Some POOR BARSTARD is going to use it as has aready been cited and they are legally entitled to do. So, is it going to be massive tables in routers now! RATHER than transparency! Kim ------------------------------------------------------------------------------ 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 Wed Aug 31 02:07:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01429; Wed, 31 Aug 94 02:07:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01423; Wed, 31 Aug 94 02:07:07 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29363; Wed, 31 Aug 94 02:04:16 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA22877; Wed, 31 Aug 94 02:03:58 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) IPNG Capabilities To: ipng@sunroof.Eng.Sun.COM Date: Wed, 31 Aug 1994 10:01:03 +0200 (BST) In-Reply-To: <9408310225.AA02919@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Aug 30, 94 10:25:29 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1068 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > THis is not technically correct in total. Running network layers over > other network layers means "encapsulation" or if something else is > mean't clary is needed for me to envision this at least in a host > kernel? Using the premise that IPv4 runs over all (as the last entry in > the validity table of the premises) does not make valid the previous > premise that IPng over CLNP is a valid technical feat that can be > accomplished in a network. CLNP delivers blocks of data from A to B within its own internal addressing system. In that there is enough to send IPv4 or the current draft IPng over a CLNP network. Thus the issue is no more complex than running IPng over ethernet (which indeed also delivers blocks of data from A to B within its own internal addressing system). The other point I was trying to make was that it is sometimes more efficient to 'cheat' on the encapsulation and not duplicate fields you can reconstruct the other end. If IPng and CLNP both have a length you can use the one and reconstruct the IPng header the other end. Alan ------------------------------------------------------------------------------ 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 Wed Aug 31 02:13:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01469; Wed, 31 Aug 94 02:13:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01463; Wed, 31 Aug 94 02:13:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29494; Wed, 31 Aug 94 02:10:21 PDT Received: from bunyip.cc.uq.oz.au by Sun.COM (sun-barr.Sun.COM) id AA23328; Wed, 31 Aug 94 02:09:59 PDT Received: from clix.aarnet.edu.au by bunyip.cc.uq.oz.au with SMTP (PP); Wed, 31 Aug 1994 19:09:55 +1000 X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 31 Aug 1994 19:05:58 +1000 X400-Received: by /PRMD=AUSGOVDEFENCENET/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 31 Aug 1994 19:03:40 +1000 Date: Wed, 31 Aug 1994 19:03:40 +1000 X400-Originator: Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au X400-Recipients: IPNG@SUNROOF.ENG.SUN.COM X400-Mts-Identifier: [/PRMD=AUSGOVDEFENCENET/ADMD=TELEMEMO/C=AU/;40A 940831190037] X400-Content-Type: P2-1984 (2) Content-Identifier: 40A 940831190037 From: Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au Message-Id: <"40A 940831190037*"@MHS> To: IPNG@SUNROOF.Eng.Sun.COM (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: Re: (IPng) IPNG Capabilities -Reply Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >kgk@hookup.net (Keith G Knightson) Writes: >Also, it would remove any further arguments or requirements for about a >common single protocol. CLNP could, if the OSI folks desire, be enhanced to >be functionally equivalent without impacting on the control of IPNG >developments themselves. Clearly protocol mapping would still be required >in gateways, but this is child's play compared to address mapping. I see a >big advantage to this scenario in the sense that this would extend the >scope and reach of the INTERNET into the OSI world. This would make the >INTERNET a truly global and supreme entity. >Keith; >Well this little statement "protocol mapping...[is] ...child's play compared >to address mapping" really triggered something in me. It's kind of like >saying "I dropped the atomic bomb and it went off" (Harry Harrison). >Protocol mapping is a *HORRENDOUS* idea and it 10^N times more difficult than >address mapping. A protocol contains an entire set of specifications to >describe the contents of a it's payload. The address field inside this >protocol is just one parameter. What do you do when different protocols >have different fields, or the fields mean different things. You will lose i>nformation when you map one protocol to another. >he problem I see with your entire proposal it that you think we should >ake IPng and CLNP interchangable. Why? Ask yourself "who uses them". >he answer is the transport layer (TCP, TP4, ...). Why not think of some >ay to make TCP run over IPng or CLNP? This is what you will get if TCP >ere changed to use an EID instead of an IP address in it's pseudoheader. >CP wouldn't care how the data was moved over the network, just that it >ot from source to destination reliabely. The network layer shouldn't care >hat the transport layer is, anymore than it cares if the physical layer > >a T1/E! or Ethernet wire. >he point is to let the market (users) decide what protocol(s) to run. There >may be political or technological reasons to choose one network protocol over >another, but why should the user application/transport layer care? We don't >need to converge IPng and CLNP, we need to free TCP (and TP4) from being >required to use a protocol that only supports a specific type of address. >This would make convergence a non-issue and we could then get on with the >job of building networks that will work and scale effeciently. **************************************************** This is the first bit of commomsense I have heard for some time. The ability to provide a global network requires that there is a common sub-network independent address framework. This is independent from the length 16 or 20 question (or at least should be). NSAP address or any other addresses MUST be technology or application independent, a basic architectureal concideration. The question is howis this ging to be done under IPv6? Tthe Network Layer handles the independent and dependent addressing not the Transport Layer? Where is the foreign format transistion (IPv6, NSAP etc.) handled and how? You have to flag it some how. At some point there is requirement to map an address into the other format so that the communications can occur and that usually means tables and overheads. This becomes more difficult when the address lengths are not equivalent. How do you propose to do it? Regards Kim Fenley X.400 address: G=KIM;S=FENLEY;OU=CM-DIMP;OU=ADITCS; O=HQADF;P=AUSGOVDEFENCENET;A=TELEMEMO;C=AU Internet address: Kim.Fenley@aditcs.cm-dimp.hqadf.defencenet.gov.au **************************************************** ------------------------------------------------------------------------------ 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 Wed Aug 31 02:14:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01481; Wed, 31 Aug 94 02:14:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01475; Wed, 31 Aug 94 02:14:37 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29521; Wed, 31 Aug 94 02:11:47 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA23451; Wed, 31 Aug 94 02:11:30 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id CAA08221; Wed, 31 Aug 1994 02:11:29 -0700 Date: Wed, 31 Aug 1994 02:11:29 -0700 From: Tony Li Message-Id: <199408310911.CAA08221@lager.cisco.com> To: ipng@SUNROOF.Eng.Sun.COM In-Reply-To: Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au's message of Wed, 31 Aug 1994 18:50:21 +1000 <"40A 940831184547*"@MHS> Subject: (IPng) security & source routing -Reply Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >- I think it's regrettable that IPv6 didn't at least do variable >length addresses so this entire NSAP issue could go away, but the >matter IS decided, for better or worse. Time to learn to live with >it. In any case, please stop sending mail. BUT how can it go away, It could go away because you could simply embed an NSAP in a sufficiently large IPv6 address. Away you go... When you convert to native IPv6 addresses, you get to use shorter addresses, so your performance goes up. AND you can't just throw away 4 Bytes that easily either. Some POOR BARSTARD is going to use it as has aready been cited and they are legally entitled to do. So, is it going to be massive tables in routers now! RATHER than transparency! Please read the rest of that paragraph again. No, I don't like how the IPv6 decision turned out either, but this is life. Ya win some, ya lose some. Tony ------------------------------------------------------------------------------ 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 Wed Aug 31 02:37:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01501; Wed, 31 Aug 94 02:37:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01495; Wed, 31 Aug 94 02:37:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00107; Wed, 31 Aug 94 02:34:20 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA24761; Wed, 31 Aug 94 02:34:01 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) IPNG Capabilities -Reply To: ipng@sunroof.Eng.Sun.COM Date: Wed, 31 Aug 1994 10:31:09 +0200 (BST) In-Reply-To: <"40A 940831190037*"@MHS> from "Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au" at Aug 31, 94 07:03:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2083 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The question is howis this ging to be done under IPv6? Tthe Network Layer handles the independent > and dependent addressing not the Transport Layer? Where is the foreign > format transistion (IPv6, NSAP etc.) handled and how? You have to flag it > some how. At some point there is requirement to map an address into the > other format so that the communications can occur and that usually means > tables and overheads. This becomes more difficult when the address lengths > are not equivalent. Damn, you mean I can't use ethernet with IPv4. Mapping larger to smaller isn't a difficult algorithmic problem now is it. I've always assumed that it would look something like [Assuming something sensible is done in using bits for routing] First few bits of IPng address are our country/area for routing Next few bits are our major provider Next few bits have been allocated to mean 'us' Cunningly we have only given our users say 8 addresses each as standard. We have also allocated our numbers sensibly so all we do now is shift right 3 and the rest we cleverly allocated to be the underlying address be it X.25 or whatever. In an environment with a giant unified telecommunications body this is fairly easy (it may need a few iterations of rules but not many). In a highly fragmented market then your problem is more likely to occur. The same algorithm can of course be reversed. Mapping smaller to larger is even easier of course : An example of IPng making it easier is amateur radio. Currently there is a requirement that the 'callsign' of the sender/receiver are present in the data (RI people like to know who's intefering with what etc..). With IPv4 ARP is used to map these long addresses onto small ones. With IPv6 it ought to be possible to get a net for amateur radio (currently its class A IPv4 44.x) that has enough bits to uniquely map between the callsign (46 bits or so including subid) and an IPng address. No arp, no mapping barring a few bit shifts. BTW: Is anyone working on an RFC for IPng over AX.25 (Amateur radio) yet ? Alan ------------------------------------------------------------------------------ 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 Wed Aug 31 05:12:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01539; Wed, 31 Aug 94 05:12:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01533; Wed, 31 Aug 94 05:11:59 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02349; Wed, 31 Aug 94 05:09:09 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA08840; Wed, 31 Aug 94 05:08:49 PDT Received: from relay.imsi.com by wintermute.imsi.com id IAA24350 for ; Wed, 31 Aug 1994 08:08:36 -0400 Received: from snark.imsi.com by relay.imsi.com id IAA21618 for ; Wed, 31 Aug 1994 08:08:36 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA14873; Wed, 31 Aug 94 08:08:35 EDT Message-Id: <9408311208.AA14873@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security knobs In-Reply-To: Your message of "Tue, 30 Aug 1994 22:11:27 EDT." <9408310211.AA02784@xirtlu.zk3.dec.com> X-Reposting-Policy: redistribute only with permission Date: Wed, 31 Aug 1994 08:08:34 -0400 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: > Folks. Can we move to an engineering discussion of security in host > kernel or router implementation to understand the costs? Or is this > premature? Its not premature, but the security stuff is really being discussed in the IPSEC mailing list. Ran has just gone on vacation to my knowledge, so I'll happily parrot any information people want about our discussions on IPSEC. Perry ------------------------------------------------------------------------------ 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 Wed Aug 31 09:06:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01952; Wed, 31 Aug 94 09:06:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01940; Wed, 31 Aug 94 09:06:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12406; Wed, 31 Aug 94 09:03:27 PDT Received: from drax.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA11478; Wed, 31 Aug 94 09:03:01 PDT Received: from drax.isi.edu by drax.isi.edu (5.65c/5.61+local-16) id ; Wed, 31 Aug 1994 09:02:48 -0700 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Reserved Bytes of NSAP Address In-Reply-To: Your message of "Tue, 30 Aug 1994 22:36:18 EDT." <9408310236.AA02992@xirtlu.zk3.dec.com> Date: Wed, 31 Aug 94 09:02:48 PDT Message-Id: <24774.778348968@drax.isi.edu> From: Craig Milo Rogers Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >What I said is the way it is. If folks have used the reserved bytes I >guess they just have to re-do their address plans. Unless someone has a >better idea for that case per IP6 and NSAP mapping. I am looking at the >compression now but the scheme I came up with would be a kludge. I have a better idea. Drop the NSAP-to-IP6 direct mapping, and use an ARP-like scheme. That way, it doesn't matter how the NSAP is structured. I submitted a DNS-based proposal to this mailing list earlier, but I haven't received much feedback: 1) suggestions that I should generalize the mapping to handle general tunneling. 2) suggestions that I should submit the proposal as an Internet Draft. Of course, I'll be happy to remail my proposal who may have missed it. Craig Milo Rogers ------------------------------------------------------------------------------ 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 Wed Aug 31 15:13:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02572; Wed, 31 Aug 94 15:13:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02566; Wed, 31 Aug 94 15:12:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15693; Wed, 31 Aug 94 15:10:07 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA02495; Wed, 31 Aug 94 15:09:50 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA18159; Wed, 31 Aug 94 15:02:04 -0700 Received: by xirtlu.zk3.dec.com; id AA28023; Wed, 31 Aug 1994 18:02:02 -0400 Message-Id: <9408312202.AA28023@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security knobs In-Reply-To: Your message of "Wed, 31 Aug 94 08:08:34 EDT." <9408311208.AA14873@snark.imsi.com> Date: Wed, 31 Aug 94 18:01:56 -0400 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 and Ran, This is a good idea to have a liaison to IPSEC. I think for starters we will need to specify something in the API spec to generate security on transmit. I can tell on receive when we process the IP6 header and then extended headers, unless of course a bit tells me that security is turned off then do I drop the packet? This brings up an issue similar to PMTU and TCP Delayed ACK. Let me explain using past knowledge on technical designs and choices made. With PMTU it could be that the default is Don't Fragment (not an issue in IP6 I know its always on except at maybe datalink code), but an application may set or not set the DF bit. The question for an implementor is if it is set by default by the system when and under what conditions can it not be set. With PMTU this was pretty straight forward from the spec (Deering/Mogul) at least in my mind. For security the same problem arises but its more complex because it involves the other end of a connection. We need to discuss this in detail as to what the rules are for default and then the other cases. This will permit us doing the IP6 API spec to make a guess at how it should be at least for the first draft? I am all ears on this one. The second point on delayed ACK is that this is a very good thing to put in TCP, unless the Server is an X, or some other interactive application who is completely legitimate in sending 1 byte of data. Hence, the application can set TCP_NODELAY option. Same needed for security too. Well I hope this gets us started and if we can keep it at the technical level it should be an interesting and worthwhile discussion. In fact I hope to learn something. I think its fair to separate out requirements for the Internet (per se) and all others (not using the Internet). We also need to realize at the end of the day the vendors need to be interoperable so agreement here might be a worthwhile discussion too. /jim ------------------------------------------------------------------------------ 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 Wed Aug 31 15:36:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02655; Wed, 31 Aug 94 15:36:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02649; Wed, 31 Aug 94 15:36:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17201; Wed, 31 Aug 94 15:33:23 PDT Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA07086; Wed, 31 Aug 94 15:33:05 PDT Received: from pobox (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA26066; Wed, 31 Aug 94 18:28:49 EDT Received: from cabernet.wellfleet by pobox (4.1/SMI-4.1) id AA12753; Wed, 31 Aug 94 18:27:19 EDT Date: Wed, 31 Aug 94 18:27:19 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9408312227.AA12753@pobox> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) security & source routing -Reply Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > BUT how can it go away, you still have to handle the NSAP issue somehow! > AND you can't just throw away 4 Bytes that easily either. Some POOR BARSTARD > is going to use it as has aready been cited and they are legally entitled to do. > So, is it going to be massive tables in routers now! RATHER than transparency! Kim The problem goes away because you use a transition scheme that doesn't require mapping NSAPs into IPv6 addresses. There are two things that seem strange to me about this entire "NSAP in an IPv6 address" debate: 1. The decision to use 16 byte addresses for IPv6 has been made, and is finished. There is no value in re-considering old decisions ad nauseum. Thus, lets take this as a decision and go with it. (This part is my personal opinion, and is also my interpretation of the consensus of the working group). 2. There has been no clear requirement for why we need to map NSAPs into IPv6 addresses. Brian Carpenter has pointed out the advantage of not having to redo address allocation schemes. However, this can be handled by local schemes. We don't need to use the same scheme everywhere, even though a default scheme that works in most cases is useful (thus Brian's proposal offers a reasonable "default" mapping). I haven't seen any other purpose (although some folks seem to implicitly have something else in mind). There is a valid concern about transition from existing OSI infrastructures (either using CLNP or X.25) to an "OSI application over IPv6" infrastructure. I think that this is a worthwhile effort. However, if this is the goal, then let's specifically discuss this goal, and come up with a way to accomplish this gracefully. I don't believe that this requires mapping NSAPs into IPv6 addresses (although I do see a need for embedding IPv6 addresses into data structures which were meant to include NSAPs -- fortunately this is easy). We should also consider whether a separate group should take on the task of developing a transition scheme from OSI over (CLNP or X.25) to OSI over IPv6. This is a good topic for a BOF at the next IETF. Given that my co-chair is out of town, I will suggest this directly to the IPng Area Directors. Ross ------------------------------------------------------------------------------ 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 Wed Aug 31 16:08:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02714; Wed, 31 Aug 94 16:08:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02708; Wed, 31 Aug 94 16:08:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19888; Wed, 31 Aug 94 16:05:19 PDT Received: from drax.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA12346; Wed, 31 Aug 94 16:05:01 PDT Received: from drax.isi.edu by drax.isi.edu (5.65c/5.61+local-16) id ; Wed, 31 Aug 1994 16:05:00 -0700 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) On NSAP/IP6 Translation In-Reply-To: Your message of "Mon, 29 Aug 1994 10:05:06 +0200." <9408290805.AA05336@dxcoms.cern.ch> Date: Wed, 31 Aug 94 16:04:59 PDT Message-Id: <9752.778374299@drax.isi.edu> From: Craig Milo Rogers Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Can you specify the functional requirement that your proposal >addresses (your problem statement already assumes that >somebody wants to solve that problem)? This is a hard one, since I doubt that I can look at any ISO document and find a functional requirement for interoperation with IP6. There might be an IETF document, though... I guess I'd state the functional requirements as: 1) a requirement to reduce the cost of NSAP-based (CLNP) communication by using the same communication facilities as IP6-based traffic 1) implemented by carrying NSAP-based packets on top of IP6 packets 2) a requirement to interoperate between NSAP-based hosts and IP6-based hosts 1) implemented by protocol translation in gateways (FTAM into FTP and/or NFS, for example) 3) a requirement that whatever is implemented should be easy to install and maintain 1) implemented by using existing services (DNS) and automatic procedures (automatic IP address assignment) wherever possible >Can you generalise your proposal to support any kind of >"tunnel X through the Internet" problem? Manual configuration >of tunnels is a real drag. That's an interesting suggestion. I'll ask the Tunnel people at ISI what sort of configuration problems they have. Would you email me a more detailed description of the problems you've encountered? On the other hand, if I make the proposal too complex, with too many selectors and prefixes and whatever, it'll be too complex to implement. Perhaps there can be a specific set of NSAP-to-IP6 and IP6-to-NSAP mapping tables in the DNS, and a framework for deploying other mapoping tables for similar applications? (My apologies for the delay in replying to this message.) Craig Milo Rogers ------------------------------------------------------------------------------ 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 Wed Aug 31 23:11:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03162; Wed, 31 Aug 94 23:11:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03156; Wed, 31 Aug 94 23:11:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08496; Wed, 31 Aug 94 23:08:57 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA24682; Wed, 31 Aug 94 23:08:40 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18432; Thu, 1 Sep 1994 08:08:37 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA29561; Thu, 1 Sep 1994 08:08:36 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409010608.AA29561@dxcoms.cern.ch> Subject: (IPng) To: ipng@sunroof.Eng.Sun.COM (ip6) Date: Thu, 1 Sep 1994 08:08:36 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 514 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Apparently-To: ipng-dist (I tried to send this to the list a couple of days ago, but majordomo ate it up because I included a magic word. I can't tell you what the magic word is, because then majordomo would eat it again :-) > Please, folks, move further discussion about CLNP > or address size OFF the IP6 list and onto the big-internet > list. This will help those of us who do automatic input > filtering. > > That's big-internet@munnari.oz.au for the list, and > big-internet-request@munnari.oz.au to get on the list. > Brian ------------------------------------------------------------------------------ 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 Wed Aug 31 23:17:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03186; Wed, 31 Aug 94 23:17:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03180; Wed, 31 Aug 94 23:17:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08632; Wed, 31 Aug 94 23:14:12 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA25208; Wed, 31 Aug 94 23:13:50 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA26081; Thu, 1 Sep 1994 16:13:23 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA01359; Thu, 1 Sep 94 16:08:26 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT01215; Thu, 01 Sep 1994 16:08:21 EST Date: 22 Aug 94 11:40:31 +1000 To: mo@uunet.uu.net Cc: /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, kgk@nic.ott.hookup.net, ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPNG AND "FUNNY NUMBERS".. Ua-Content-Id: 940822 08:52:36 P1-Recipient: mo@uunet.uu.net, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, kgk@nic.ott.hookup.net, ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940822 08:52:36 006 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940822114031+1000 deferred 940822114031+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940825094811+1000 deferred 940825094811+1000 action Relayed Message-Id: <"940822 08:52:36"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Mike .. thanks for the response re the 16 byte decision... I like a good debate so I hope I do not offend.. The Kings and Votes bit with the working code option.. " Concensus and Working Code" ... This is fine if one is building simple interconnectivity tools because one can prove the working code in the "garage".. However, when one is building global infrastructures that carriers will spend $BBB on over decades, that insular process does not work... Specifically with global communications.. one MUST HAVE Global addressing agreed by the regions and countries in question.. The ITU are under treaty to do this with the UN.. Next .. the "working code" .. Any junior student would have realised that one cannot build a global network without global addressing and to me global addressing MUST relate to countries..and be agreed by those countries. Obviously the IETF believe they can re map the entire planet with funny numbers all by themselves, on their own and with "working code" all from their backyard.. (As I assume "working code" means "tested code". Do you have a replica of the earths communications infrastructure to test IPv6 on?.... HO HO HO..) Next.. the "working code" is across the whole planet and is failing because of scale.. Scale is directly related to addressing...I might add your working code is a nothing more than an ugly duck if one wants to design scalable global networks.. Perhaps you should talk to people who have to build national / govt networks with a "handful of "funny numbers".. Its a crappy approach to building a network that will crash into a wall ... A good business investment.. I dont think..!! That is why governments are going GOSIP.. (because of the agreed and recognised global naming and addressing carried by ISO/ITU "protocols").. And like it or not the whole TCP/IP world has got to be reconfigured.. "Working Code?" I see some people are now referring to the problem as "bigger than the bubonic plague"... Working Code...!!! Next.. The carriers .. You may be aware of these guys... These guys provide international standards, they define and build international networks with international addressing schemes which embrace NSAPs.. these systems will be supported by X.500 directory systems, X.700 management systems and provide as an application, global X.400 messaging systems .. All these technologies have GLOBAL NAMES AND ADDRESSES... This process (which gets promoted as too slow and does not work) also produces "working code" and believe it or not supports the Internets "Working Code"... Code which is now failing...on a global scale!!!! At some point in time and across the whole planet the Internet.. whatever form it is in, will have to map to NSAPs and carrier defined addressing schemes.. Again the IETF seem to want to make this process (and the equipment that does this) more complex than necessary... Why? Are NSAPs that Bad... After all they are defined in AN INTERNATIONAL STANDARD... After all the Internet will still RELY ON THEM to support the "working code" they produce.. I find this "working code" and consensus stuff statements mind numbing.. I assume it is borne out of very limited understanding of the global infrastructures and the standards that are necessary to provide the whole planet with communications.. Not just a set of interconnectivity tools for workstations on LANs.. Perhaps the IETF would like to publish the number related to all the lines of code that provide FTP, Telnet, SMTP, SNMP and TCP/IP, etc.. And the carriers produce a list of the code quantities in PSTN, ISDN, FAX, X.400, X.500, X.700, X.25, Frame Relay, Transport and Session, Mobiles, MPEG, PDH, SDH, etc standards.. and the code lines for Billing Systems, Administration Systems, Inventory and Asset Management, Customer Support, Help Desks, Management of International Charging, Bilateral Agreements and Service Level Agreements.. All of which is needed to run scalable, standard, secure, reliable, cost effective, owned -- GLOBAL communications.. As this planet moves to intelligent networking (as defined by the carriers), international mobiles, Audio/Video mobile devices that MUST have global numbering and User Ids.. what significance will a "funny numbers" approach to data networking have? (Yes .. data networking only!) Do you honestly believe that the IETF will replace the carriers, suspend the deployment of global infrastructures (with international addressing), stop the ITU /ISO standardisation process, undo all the work on GOSIP, undo all the OSI products that have been developed and erase the progress of OSI from this planet with a 16 byte internetwoking protocol defined "by consensus".. Do you honestly believe that the IETF will develop standards for security, billing, fault management (note that SNMP is hitting the wall as well), etc, etc, etc .. and administer, with the same global capability, a network which is DIFFERENT to that as implemented carriers!!! YOU MUST BE JOKING!!!!! AS the broadcasting and telecommunications industries combine across this planet and deploy domestic and mobile multimedia services there will be little room for "defacto" standards that only relate to data.. One cannot have a defacto set of Broadcasting standards.. One cannot have an "International Networking" standard for anything in today's world .. wait for it.. without an agreed international address form.. The IETF can either decide to do something sensible and align itself to global numbering schemes (because it cannot ignore them) or expect that when the whole planet goes through the bubonic plague of TCP/IP reconfiguration it will yet again chose a numbering scheme which is administered by the US.. Who is kidding who here? Some organisations are seeing that TRUE Global Standards are the way.. Why on earth would the large corporates, security agencies, governments and carriers of this world go to "an interest group" to get .. yet again.. another set of funny numbers.. which have no relationship to the planet's geography or formal IT administration for its IT infrastucture? And please dont say because you have already done that.. Every one who has to reconfigure his total TCP/IP network now knows the magic of the "working code"!!!!. .Once bitten .. twice shy? Regards Alan PS On your point about NSAPs and "with few exceptions -- they are political with no regard for routing" .. The few exceptions ........ The few exceptions are of course the fields that provide routing .. which is nearly all the NSAP...ICD/DCC, Auth, RD,Loc/Area,System ID and Nsel I think its about time your "marketing man" who comes up with such statements about OSI is dead, OSI is a dream and TCP/IP is living it, kings and votes, working code and "few exceptions re routing" should review them. PPS It is a wonder that with all the lawyers in the US that some one has not cottoned on to the misconception that TCP/IP has been promoted as a Global networking technology and isnt.. ------------------------------------------------------------------------------ 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 Wed Aug 31 23:20:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03199; Wed, 31 Aug 94 23:20:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03193; Wed, 31 Aug 94 23:19:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08702; Wed, 31 Aug 94 23:17:04 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA25368; Wed, 31 Aug 94 23:16:27 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA26140; Thu, 1 Sep 1994 16:15:28 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA01332; Thu, 1 Sep 94 16:07:08 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT01215; Thu, 01 Sep 1994 16:07:06 EST Date: 18 Aug 94 09:24:42 +1000 To: /S=bruce-steer/O=saa/P=sa/A=telememo/C=au/@x400gw.datacraft.com.au, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, /G=kim/S=fenley/OU2=cm-dimp/OU=aditcs/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@x400gw.datacraft.com.au, ipng@sunroof.Eng.Sun.COM Subject: (IPng) RE THOUGHTS ON IPNG - THE ATTACHMENT Ua-Content-Id: 940818 09:28:42 P1-Recipient: /S=bruce-steer/O=saa/P=sa/A=telememo/C=au/@x400gw.datacraft.com.au, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, /G=kim/S=fenley/OU2=cm-dimp/OU=aditcs/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@x400gw.datacraft.com.au, ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940818 09:28:42 016 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940818092442+1000 deferred 940818092442+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940825094809+1000 deferred 940825094809+1000 action Relayed Message-Id: <"940818 09:28:42"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM re attachment-- woops! TCP/IP and OSI Harmonisation - an Update Alan Lloyd Manager - Strategic Development Datacraft Limited Victoria 3136 Australia Introduction The TCP-IP and OSI articles in the previous month's Australian Communications have provided some of the extreme views about this issue. Some of the comments centred around the Federal Internetworking Requirements Panel (FIRP) report from the US which was released for comment earlier this year. I provided some serious criticism of this report. The other major issue in the debate was the US ownership and administration of the IP address and its limited four byte form. Since this debate started, both sides of the argument have been well aired and now that the dust is settling, there is a strong desire emerging for the harmonisation of global networking and internetworking. This is taking a number of forms. Note, the information provided is still "working information" and therefore details may change. The FIRP Report Since its original release and input, the report h as been updated considerably and includes some significant new points. These are : i) it now recognises NOSIP (the NATO GOSIP) and the fact that the Aviation industry is using OSI. ii) it also recognises that the ITU is a treaty organisation under the auspices of the United Nations for delivering global standards (and addressing) and is recognised by the carriers and standards bodies in member countries. iii) it recommends that one addressing standard should be sought for global interoperation and that international community and governments will only seek addressing schemes as administered by national or internationally recognised bodies. These points are significant because once a common addressing scheme is sought, then the protocol choice becomes self evident. The Standards Process From a standards body perspective, the liaison between the Internet Engineering Task Force (IETF) and ISO-SC6, who deal with OSI networking standards, is also making considerable progress. There is a Memorandum of Underst anding between the two organisations and ISO will be referencing RFCs in its own standards . The IETF will be providing input and its RFCs into the ISO standardisation process. ISO for its part will not slow the standardisation process for RFCs - which could have been caused by lenghty procedures. Both groups will participate in the development of commonly desired standards. Protocol Harmonisation With respect to IP harmonisation and evolution, the three options proposed for IP Next Generation (IPNG) which are SIPP, CATNAP and TUBA will be blended to form a consolidated SIPP as the basis for IPNG. CLNP the ISO version of IP will be upgraded with enhancements for its Broadcast and its Quality of Service functions and aligned with IPNG. So from a connectionless internetworking service level, IPNG and CLNP should become equivalent. The network addressing issue is still under finalisation at the time of writing and the choice for the new IPNG is believed to be a sixteen byte address field instead of its old four byte field. The unfortunate fact is that ISO's NSAPs are twenty bytes so they will not quite fit. But this issue is still under review and hopefully NSAPs will be incorporated into IPNG. It should be noted that as IP (and the Internet) incorporate ISDN, B-ISDN and ATM technologies for switched broadband then Q.2931 (ex Q.931/B) network signalling schemes will have to be supported. Q.2931 supports E.164 numbering plans (that as used by the telephone system ) and NSAPs. So ITU numbering plans and NSAPs certainly should have a place in the new protocol (and the Internet). This support could be similar to the mechanisms used by X.25 where NSAPs are carried as facilities or optional address forms. So from a technical perspective the harmonisation process between TCP/IP and OSI (CLNP and NSAPs) is really starting. Network Operations From an operational perspective the harmonisation issue will still require some considerable effort. Although there are announcements that IPNG should be backward compatible, it is difficult to see how one can rapidly upgrade an operational network that spans many countries and organisations with software that permits the old addressed components to interwork with the new addressed components. Changing addressing schemes in the past (in simple devices like routers, ie not intelligent PABX systems) have usually meant a network switch off situation. Certainly there will be many devices out there that will need upgrading even if it is just to make them robust to receiving protocol with different versions of IP let alone process the new and longer address forms. The management of this upgrade, if one is running a commercial service on such a network will be fundamental. Addressing Implications Another aspect of this harmonisation is that of the long term direction with addressing. This has been raised in my previous articles. ITU/ISO NSAPs not only provide an internationally administered addressing scheme but within these addressing schemes there is internationally recognised routin g and administration hierarchies. ie. Routing levels for Aircraft, Ships, Transport systems and network devices can be assigned uniformly across the world and from a registration perspective, Countries, Governments and corporates can be assigned uniformly for the address administration in line with the routing hierarchies. Therefore the OSI NSAP should not be seen just as "twenty bytes", but a formal approach to global network interoperation and address administration. IPNG will naturally remove the addressing restriction of the current IP but the issue of allocation and structure will have to be resolved. Again having two totally different schemes here (one based on (eg) CIDR and numbers and the other based on internationally recognised routing and administration hierarchies) will cause large scale interworking problems. At the end of the day, both will have to interoperate so products will now have to be sought that permit the IP - IPNG and the OSI protocols and their addresses to harmonise. Design Metho dology One aspect of network addressing that is fundamental and does escape many people is that the addressing scheme used for a network dictates its design methodology. eg. with a conventional SNA network one designs the network with PUs and LUs and the network is styled on the "host centric" approach - although with APPN, LUs are distributed. With TCP/IP one designs a distributed network with a set of numbers (and subnet masks) which one configures across the system - hopefully a notion of geography is introduced into the format and allocation of these addresses. However, the notion of logical addressing (eg tactical units, ships or aircraft) or dynamically extensible subnets are usually not considered in this type of (data only) network. Again protocols which dynamically allocate IP addresses are being provided, but what are the scaling issues here? With NSAPs and carrier global numbering plans (and X.400 addresses and X.500 names) the network design by definition fits the network directly into the globa l routing and addressing hierarchy. Also because NSAP addresses have internationally recognised logical and geographic routing hierarchies, the network design certainly in my opinion is more natural and globally scalable. Hence OSI and NSAPs is about global networking. Although this harmonisation with OSI/CLNP and IPNG is only related at the network level other areas of technology will be addressed in the future. eg TCP and RFC1006 brought some transport service harmonisation with OSI applications. Because of similarities, ISOs Transport service will align and probably TCP will become the standard Transport service - as it is very similar to some of the ISO Transport layer functions. Other areas of harmonisation include compatibility between X.400 and MIME, X.500 support of the Internet and IPS and possibly SNMP will evolve to CMIP. This last case although may some way off formally, I believe will happen simply because SNMP was designed for LANs and connectionless networks, therefore with SNMP all one real ly manages is interfaces, status and statistics as flat management data. With connection oriented networks such as wide area B-ISDN and ATM, full object methodology will have to be used in the system design and the managed objects used will require naming components in the protocol (as per CMIP) to access them. Therefore the internetworking migration / harmonisation process for management will be to migrate the network protocols to IPNG/CLNP and as the new network services are established over switched broadband, the move from SNMP to CMIP will occur. This CMIP direction is already being supported by the major management platform vendors with the introduction of CMIP and GDMO facilities (as their core platform architectures). User's Position For the user, the IT industry will be providing the tools and gateways for this TCP/IP - OSI networking evolution and harmonisation, therefore the networking issues will be that as in the past. ie ensuring that the IT system design and operational plans incorporate the new technologies as appropriate and that the support for this process is provided by the equipment / service supplier. Certainly the support for NSAPs in both the End Systems and the Networking Equipment is essential. So this should be part of the stated procurement requirements. In closing it is pleasing the TCP/IP - OSI harmonisation process is occurring in a positive manner. The important factor is that both technologies are now fully recognised for what they are. Certainly both technologies and their harmonisation process is important to the planning of our commercial and government IT systems and also to our academic IT networks and the country's IT educational programs. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com