From mak@aads.net Thu Jun 30 23:51:44 1994 Return-Path: mak@aads.net Received: from aads.net (aads.com [198.111.96.42]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id XAA28593 for ; Thu, 30 Jun 1994 23:52:19 -0400 Received: from localhost (mak@localhost) by aads.net (8.6.5/aads1.1) id XAA27279; Thu, 30 Jun 1994 23:51:44 -0400 From: Mark Knopper Message-Id: <199407010351.XAA27279@aads.net> Subject: Re: BigTen packet format To: deering@parc.xerox.com (Steve Deering) Date: Thu, 30 Jun 1994 23:51:44 -0400 (EDT) Cc: sob@hsdndev.harvard.edu, ipng@cmf.nrl.navy.mil In-Reply-To: <94Jun29.154740pdt.12171@skylark.parc.xerox.com> from "Steve Deering" at Jun 29, 94 03:47:28 pm Reply-To: mak@aads.net X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1091 Steve and Scott, Steve is correct that this BigTen packet format has some additional features from the discussion and "consensus" from the Chicago meeting. I will forward a list of features that this format has. Steve, do you think these features represent an improvement from the actual Big Ten meeting? I believe the intent was to improve it and to resolve some potential problems. Mark > > > Here is a writeup we received of the packet format that was talked about > > at the end of the BigTen meeting. > > No it's not. In the format we discussed at the end of the BigTen meeting, > the Flow field was not optional, a 32-bit reserved field preceded the Flow > field, the Length field was 24 bits wide, the one-byte fields in the > second 32-bit word of the header were in a different order, and the > Flag values were not defined. The addresses did not have a Strict/Loose > indicator or a Locator Family field; they had only a 2-bit Len field > preceded by one Reserved bit. This document describes something other > than what we discussed at the meeting. > > Steve > > > From mak@aads.net Thu Jun 30 23:55:44 1994 Return-Path: mak@aads.net Received: from aads.net (aads.com [198.111.96.42]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id XAA28610 for ; Thu, 30 Jun 1994 23:55:45 -0400 Received: from localhost (mak@localhost) by aads.net (8.6.5/aads1.1) id XAA27310 for ipng@cmf.nrl.navy.mil; Thu, 30 Jun 1994 23:55:44 -0400 From: Mark Knopper Message-Id: <199407010355.XAA27310@aads.net> Subject: BigTen features To: ipng@cmf.nrl.navy.mil Date: Thu, 30 Jun 1994 23:55:44 -0400 (EDT) Reply-To: mak@aads.net X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1137 Hi. Here is a list of the major differences between the BigTen packet format and the SIPP packet format. Mark > > The major differences between SIPP and BigTen packet format fall > into the set of the following orthogonal categories: > > 1. Total length of a packet is increased from 2^16 to 2^20. > > 2. The Flow is longer (32 bits) and optional (since it isn't clear > that every packet has to use flow). > > 3. The source route has significantly enhanced functionality -- > strict vs loose on a per source route element basis, > control over packet handling when source route fails. > > 4. Error notification controlled by source. > > 5. Variable length addresses in multiple of 8 octets. > > 6. Introduction of an End-to-end Option header -- this allows to > consolidate all the optional information pertinent only to > the end-points (e.g. fragmentation) within a single header. > It also allows protocol expandability with respect to the information > that end-points may use (via introduction of new end-to-end options). > > 7. There are 4 spare bits reserved in the header -- SIPP has none. > > From mak@aads.net Fri Jul 1 01:02:47 1994 Return-Path: mak@aads.net Received: from aads.net (aads.com [198.111.96.42]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id BAA28881 for ; Fri, 1 Jul 1994 01:02:59 -0400 Received: from localhost (mak@localhost) by aads.net (8.6.5/aads1.1) id BAA27836; Fri, 1 Jul 1994 01:02:47 -0400 From: Mark Knopper Message-Id: <199407010502.BAA27836@aads.net> Subject: Re: 16 Byte To: sob@hsdndev.harvard.edu (Scott Bradner) Date: Fri, 1 Jul 1994 01:02:47 -0400 (EDT) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <9406281913.AA20507@hsdndev.harvard.edu> from "Scott Bradner" at Jun 28, 94 03:13:43 pm Reply-To: mak@aads.net X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 801 Scott, Should be variable of course (in line with Steve Bellovin's thinking). --Mark > > > Peter suggested that we do a straw poll of the directorate about 16 byte > fixed length addresses being acceptable for IPng (in the context of > the revised SIPP proposal and ones own understanding of the 'real world' > both technical and political.) That seems like a good idea so here it is > > Scott & Allison > > too much ok should be variable > J. Allard > Steve Bellovin > Jim Bound > Ross Callon > Brian Carpenter > Dave Clark > John Curran > Steve Deering > Dino Farinacci > Eric Fleischman > Paul Frances > Mark Knopper > Greg Minshall > > From brian@dxcoms.cern.ch Fri Jul 1 08:10:21 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA29102 for ; Fri, 1 Jul 1994 02:10:56 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA28297; Fri, 1 Jul 1994 08:10:23 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA16135; Fri, 1 Jul 1994 08:10:22 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407010610.AA16135@dxcoms.cern.ch> Subject: EIDs are research To: ipng@cmf.nrl.navy.mil Date: Fri, 1 Jul 1994 08:10:21 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 249 IPng people, I would like to assert that after many moons, I have concluded that EIDs are still research. As such I don't see how to mandate them for IPng. Do people think that Flow IDs/LLIDs are still research? If so, we are in trouble. Brian From brian@dxcoms.cern.ch Fri Jul 1 08:21:26 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA29134 for ; Fri, 1 Jul 1994 02:22:01 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA29702; Fri, 1 Jul 1994 08:21:28 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA16353; Fri, 1 Jul 1994 08:21:26 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407010621.AA16353@dxcoms.cern.ch> Subject: Re: BigTen features To: mak@aads.net Date: Fri, 1 Jul 1994 08:21:26 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <199407010355.XAA27310@aads.net> from "Mark Knopper" at Jun 30, 94 11:55:44 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1606 Mark, We are not doing design in the Directorate these days. But since you raise it: > > The major differences between SIPP and BigTen packet format fall > > into the set of the following orthogonal categories: > > > > 1. Total length of a packet is increased from 2^16 to 2^20. This is a virtue. I object to the small size of SIPP packets for ultra-high-speed LANs (I am thinking of Fibre Channel). Of course, it is irrelevant when going through routers. > > > > 2. The Flow is longer (32 bits) and optional (since it isn't clear > > that every packet has to use flow). As I said a moment ago, are we sure that Flow/LLID is fully understood? Is 32 bits too small, too big, just right? > > > > 3. The source route has significantly enhanced functionality -- > > strict vs loose on a per source route element basis, > > control over packet handling when source route fails. > > > > 4. Error notification controlled by source. > > > > 5. Variable length addresses in multiple of 8 octets. As I said a couple of days ago, overkill! Did anybody like my SIPP-16 plus NSAPA-32 suggestion? > > > > 6. Introduction of an End-to-end Option header -- this allows to > > consolidate all the optional information pertinent only to > > the end-points (e.g. fragmentation) within a single header. > > It also allows protocol expandability with respect to the information > > that end-points may use (via introduction of new end-to-end options). > > > > 7. There are 4 spare bits reserved in the header -- SIPP has none. Is this a virtue? Do we ever really retro-fit features? Brian From jallard@microsoft.com Fri Jul 1 09:59:39 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA01838 for ; Fri, 1 Jul 1994 13:05:27 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA23341; Fri, 1 Jul 94 09:07:20 -0700 Message-Id: <9407011607.AA23341@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Fri, 01 Jul 94 09:07:20 PDT X-Msmail-Message-Id: 36ACC08D X-Msmail-Conversation-Id: 36ACC08D X-Msmail-Fixed-Font: 0001 From: "James 'J' Allard" To: mak@aads.net, sob@hsdndev.harvard.edu Date: Fri, 1 Jul 94 09:59:39 TZ Subject: Re: 16 Byte Cc: ipng@cmf.nrl.navy.mil | > Peter suggested that we do a straw poll of the directorate about 16 byte | > fixed length addresses being acceptable for IPng (in the context of | > the revised SIPP proposal and ones own understanding of the 'real world' | > both technical and political.) That seems like a good idea so here it is | > | > too much ok should be variable | > J. Allard x personally, i was a little surprised that the 16-byte "consensus" was reached on big-internet and not on ipng. from my notes of the chicago meeting, i was not convinced that the directorate found 16-byte fixed to be sufficient. i think it's the same dog with bigger fleas. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From deering@parc.xerox.com Fri Jul 1 10:24:15 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA01986 for ; Fri, 1 Jul 1994 13:25:13 -0400 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14421(9)>; Fri, 1 Jul 1994 10:24:25 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 1 Jul 1994 10:24:18 -0700 To: ipng@cmf.nrl.navy.mil Cc: deering@parc.xerox.com Subject: Re: bigten notes In-reply-to: sob's message of Tue, 28 Jun 94 14:21:27 -0800. <9406282121.AA27823@hsdndev.harvard.edu> Date: Fri, 1 Jul 1994 10:24:15 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul1.102418pdt.12171@skylark.parc.xerox.com> Allison & Scott, Here are some corrections to those parts of the bigten minutes attributed to me: > Eric: The Boeing problem. 64 bits is more than enough if you can find > what you want. 2 class AUs, 28 class BUs plus class CUs, all being used > by Boeing. > > Steve D: provider based addresses. I don't remember what I said, but just "provider based addresses" doesn't seem to mean anything. Suggest you delete that line. > Consensus: 64 bit fixed addresses do not work. We need to have > extended addresses with delineated fields. I don't recall any such consensus. I think there *was* consensus that SIPP extended addressing using the Route Header was unworkable, and, of course, that 64-bit addresses are too small *if* you want to do address autoconfiguration with 48-bit IEEE 802 numbers. > Deering: this is Kleinrock and Camun from 1970. "Camun" should be "Kamoun". > Current SIPP header proposal: > > Fixed header > 16 byte source addresss > Sequence (optional) of source route elements - these could be > shortened. Use 1-bit to indicate whether 8 or 16 bits. Or need to > select 8, 16, 24 or 32. or 0, 8, 16, 24. > 16 byte dest addresses This was *not* a SIPP header proposal. It was a report on the header design discussed after the Thursday evening session broke up. This is clear from later in the minutes: > Steve Deering: could be happy with this. Providers should > apply discipline in their bit allocation. This is not SIPP, we wonUt > relable this SIPP. SIPP is 128 fixed address. Steve may not want to > write this protocol spec. In the above, change "relable" to "re-label". And I wish all you Macintosh users would learn to disable the function that turns quotes and apostrophes into "curly" versions of the same, so that "won't" won't come out as "wonUt" when transferred to Unix. > Transport identifier which is not tied to the network layer: consensus > position. Huh? I though we punted on that; certainly there was no consensus. Steve From sob@hsdndev.harvard.edu Fri Jul 1 13:37:41 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA02091 for ; Fri, 1 Jul 1994 13:37:51 -0400 Date: Fri, 1 Jul 94 13:37:41 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407011737.AA26397@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: so far Ross is out of town & I managed to forget Lixia & Rob the 1st time, Lixia fought through the slight but since Rob's mail was bouncing this will be the 1st time he sees this. Scott Peter suggested that we do a straw poll of the directorate about 16 byte fixed length addresses being acceptable for IPng (in the context of the revised SIPP proposal and ones own understanding of the 'real world' both technical and political.) That seems like a good idea so here it is too much ok should be variable J. Allard X Steve Bellovin X Jim Bound X Ross Callon Brian Carpenter X Add NSAPA option Dave Clark John Curran X X Steve Deering (X) X Dino Farinacci X X Eric Fleischman X X Paul Frances X Mark Knopper X Greg Minshall X X Rob Ullmann Lixia Zhang X add option for var From ericf@atc.boeing.com Fri Jul 1 10:59:42 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA02247 for ; Fri, 1 Jul 1994 13:57:30 -0400 Received: by atc.boeing.com (5.57) id AA26557; Fri, 1 Jul 94 10:59:42 -0700 Date: Fri, 1 Jul 94 10:59:42 -0700 From: Eric Fleischman Message-Id: <9407011759.AA26557@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: straw poll Dear Area Co-chairs, What is the current status for the straw poll of the Directorate of 8 byte vs 16 byte vs variable length addresses? --Eric From ericf@atc.boeing.com Fri Jul 1 11:23:42 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA02388 for ; Fri, 1 Jul 1994 14:21:30 -0400 Received: by atc.boeing.com (5.57) id AA01042; Fri, 1 Jul 94 11:23:42 -0700 Date: Fri, 1 Jul 94 11:23:42 -0700 From: Eric Fleischman Message-Id: <9407011823.AA01042@atc.boeing.com> To: deering@parc.xerox.com, ipng@cmf.nrl.navy.mil Subject: Re: bigten notes Cc: ericf > Eric: The Boeing problem. 64 bits is more than enough if you can find > what you want. 2 class AUs, 28 class BUs plus class CUs, all being used > by Boeing. > Allison & Scott, I didn't say that 64 bit addresses are more than enough. I recall saying that it is NOT enough space for our internal administrative needs to provide the internal aggregation of our possible medium term-sized networks and that it (in my opinion) will not scale to meet the needs of the Internet community. Concerning Boeing's current addressing usage, we have only 28 or so class Bs and 150 or so class Cs -- all (with one exception) very densely populated. We are toying with deploying a local class A as well and will probably do so later this year for a new major protocol family deployment of ours which is now being migrated over TCP/IP (CATIA/GAM) and thus now needs IP addresses. However, to understand our medium term needs the knowledge of our current address usage is misleading: We are planning to migrate our SNA network (which is bigger than our 80,000 device TCP/IP network) over TCP/IP via MPTN and TN3270 in the short term. We are migrating other proprietary networks over TCP/IP. In short, IPv4 is our convergence network today. All this will really change our IP address usage in the short term even if our toasternet/wireless needs do not materialize as we expect. I really don't have the time to read through the BIG 10 minutes and correct all of the misstatements about what I purportedly said. I am concerned, however, how frequently I was misquoted and how the arguments which others made against what I was saying appeared in the minutes as statements which I allegedly made. The bottom line is that I consistently said -- and say to this day -- that SIPP-8 is broken and will not work as designed. Furthermore, any fixed length addressing schema of less than 16 bytes for IPng will NOT have my stamp of approval -- for whatever that is worth -- and that my personal preference is for variable length addresses -- but preferably not to the extraordinary upper length bounds of the BIG 10 "compromise". (I fail to see EVER needing addresses longer than 24 or 32 bytes -- especially for a system supporting loose source routing as a potential way to "lengthen" too-short addresses.) Sincerely yours, --Eric Fleischman From mankin@radegond.cmf.nrl.navy.mil Sat Jul 2 23:38:19 1994 Return-Path: mankin@radegond.cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id XAA07955 for ; Sat, 2 Jul 1994 23:38:22 -0400 Received: from localhost (mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id XAA08770 for ; Sat, 2 Jul 1994 23:38:20 -0400 Message-Id: <199407030338.XAA08770@radegond.cmf.nrl.navy.mil> X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: ipng@radegond.cmf.nrl.navy.mil Subject: Directorate update Date: Sat, 02 Jul 94 23:38:19 -0400 From: Allison J Mankin Hi, all, We will have a telechat (it will have to be a bit short because Scott and I have a meeting at 1) on July 11. Agenda: the presentation outline we'll be sending you before Monday/state of the consensus on several major issues. We will have another telechat on July 18, of full length, and at that time we will rehearse the actual presentation to you. We are trying to call everyone individually as within the coming week too, to be sure that all the communication channels are open. The telechats will both begin at 11:30 EDT/8:30 PDT as usual (if you can remember so far back). Also, this is very important: please resend, now to the list, those of your written proposal reviews that you still like. We would like to have a compendium of review of the three proposals. Please put REVIEW: XYZ where XYZ is the subject, e.g. TUBA, SIPP, CATNIP, general, general transition in your subject line. Scott and I used all the reviews we got, and of course, we had the very valuable review round-robin on the first day of Big Ten. We'd like to see them go into the archived records too! Thanks. Allison and Scott From brian@dxcoms.cern.ch Sun Jul 3 10:26:10 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id EAA08614 for ; Sun, 3 Jul 1994 04:26:46 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24827; Sun, 3 Jul 1994 10:26:11 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA23964; Sun, 3 Jul 1994 10:26:10 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407030826.AA23964@dxcoms.cern.ch> Subject: one size fits all (fwd) To: ipng@cmf.nrl.navy.mil Date: Sun, 3 Jul 1994 10:26:10 +0200 (MET DST) Cc: yakov@watson.ibm.com Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5218 Directorate, cc. Yakov I've been having a private exchange with Yakov and it's reached a point where I would like to share it with the Directorate. It doesn't change my position in the straw poll on address size, but it may put a slight spin on it. I regard this as background, rather than as starting a design discussion (which we're not supposed to do on this list). I've cut & pasted two or three messages and deleted the rude bits :-) Yakov is in the Cc field. Yakov:> 1. Why do you need 32 octets to embed NSAP ? Seems like 24 (if you > insist on multiple of 8) should be sufficient. Brian:> That's true and it occurred to me too. I would certainly accept 24. Yakov:> 2. You said that SAF and OAF routing is independent. I don't quite > understand the implications of these. For example, does this mean that a > router is not required to support OAF ? Brian:> I meant to say that there would indeed be two independent, co-existing > A&R architectures. Of course you could run the SIN versus Unified > argument again. Yes, my thinking was that 'router requirements' > would say that SAF is a MUST and OAF is a MAY. In other words, service > providers must offer SAF and may offer OAF. > > Yakov:>3. If you are asking for 16 byt addressing plan for the Internet, > >>then why wouldn't you just use the subset of the BigTen addressing > >>plan (since BigTen includes both 8 and 16 bytes addresses). > > Brian:>Yes, I think I could go for that or something very like it. It is > >certainly better than the Paul Francis SIP(P) unicast plan. > Yakov:> It would certainly help if you'll express this in public (or at least > within the IPng AD). > Yakov:>4. You mentioned that Big10 is an overkill. I would appreciate > >>further comments on this. Specifically on the topic of 8, 16, 24 > >>and 32 bytes long addresses. I would agree though, that 56 bytes in Big10 > >>is an overkill. For that matter 32 may be as well -- if I have my choice > >>I would have just 8, 16 and 24. > Brian:>Much more reasonable ! If we have to have variable size this is > >a good compromise. If you define a provider code for the 24 byte case > >meaning "NSAPA" you can even embed my OAF. When I start thinking about > >addresses > 32 bytes I go into Bill Simpson mode. I think I could define > >my position as [8] 16 24|32. I mean: I don't really think 8 is necessary, > >but it does not harm. I think 16 is vital, and a format long enough > >to embed NSAPA is necessary. > Yakov:> Why wouldn't you propose to the IPng AD to change Big10 packet format > to have only 2 bits for the address length ? That would effectively > limit the choices to 8, 16, 24 and 32. Granted that 32 may not be > that useful, but there is no harm since you wouldn't carry 32 bytes > addresses in any case any time soon. You'll get 16 bytes for systems > that need stateless autoconfiguration, 8 bytes for cluster addresses > and for systems that don't need stateless autoconfiguration, and > you'll get 24 bytes for straightforward NSAPA embedding. > 8 bytes may also be quite useful if it carries only the "locator" > information and put EIDs as end-to-end options (into the End-to-end > options header of BigTen). > Brian: The Directorate doesn't do design, right? > > Yakov on source routing: [It is difficult] > to make any intelligent judgement on whether source routing capabilities > in any of the IPng (SIPP, TUBA, CATNIP) are sufficient to meet routing > requirements of IPng. I assume you saw message from Noel evaluating > SIPP Routing header in the context of Nimrod. I posted a similar > message evaluating SIPP Routing header in the context of Unified. > Both Noel's and mine conclusions are *exactly* the same -- the > SIPP Routing header is pretty useless, SIPP doesn't have enough > routing functionality. That really concerns me A LOT. > Brian:> I am just not an expert in source routing. As you may have gathered > from a side remark in my SAF/OAF mail, Dave Clark made a major > point in Boston that we do not know if the hierarchical addressing/ > source routing model really satisfies all routing requirements. > Clearly he talks to Noel from time to time. I can't judge but > I respect you, Noel and Dave enough to share your concern. I suspect > that Scott and Allison have realised there is a problem too, and I > will bear it in mind if they circulate a draft of their Toronto > statement to the Directorate. Yakov:> It is not enough to realise that there is a problem. It is important > to figure out how to fix this problem. The handwaiving from SIPP > folks saying that SIPP routing header is good enough, like > in the following piece of e-mail from Christian: > > "the SIPP loose "source route" are precisely there to > provide an escape and a path of evolution. We may not know > the details yet, but all works on flexible routing > (nimrod, sdrp, idpr, route segments) points towards > this type of solution." > > in my view is totally unacceptable. You either have the required functionality > or you don't. And SIPP doesn't have the required functionality, but has > the stuff (routing header) that is *already* acknowledged to be > pretty useless !!! > Brian:>Have a good holiday weekend. From sob@hsdndev.harvard.edu Sun Jul 3 07:52:09 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA08910 for ; Sun, 3 Jul 1994 07:52:21 -0400 Date: Sun, 3 Jul 94 07:52:09 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407031152.AA10729@hsdndev.harvard.edu> To: Brian.Carpenter@cern.ch Subject: Re: one size fits all (fwd) Cc: ipng@cmf.nrl.navy.mil, yakov@watson.ibm.com > The handwaiving from SIPP > folks saying that SIPP routing header is good enough Steve & I talked about this in Prague, we both think that the whole source route issue needs more discussion on the mailing list. We agreed that Steve would start a discussion along the lines of what he did with addresses on the SIPP list after we have a context to put it in. i.e. after we publish the notes from teh bigten meeting. Everyone should get any final comments in on those notes so we can get this and other things under way. Scott From yakov@watson.ibm.com Sun Jul 3 08:49:10 1994 Return-Path: yakov@watson.ibm.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA09017 for ; Sun, 3 Jul 1994 08:49:10 -0400 From: yakov@watson.ibm.com Message-Id: <199407031249.IAA09017@picard.cmf.nrl.navy.mil> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9207; Sun, 03 Jul 94 08:49:10 EDT Date: Sun, 3 Jul 94 08:49:10 EDT To: sob@hsdndev.harvard.edu, Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: one size fits all (fwd) Ref: Your note of Sun, 3 Jul 94 07:52:09 -0400 Scott, >Steve would start a discussion along the lines of what he did >with addresses on the SIPP list... That is a fine idea, *except* that the discussion should be carried in the big-internet list -- the issue of source route capabilities is more than just SIPP issue -- it is the IPng issue. Yakov. From bound@zk3.dec.com Sun Jul 3 09:06:23 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA09077 for ; Sun, 3 Jul 1994 09:10:39 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA26712; Sun, 3 Jul 94 06:06:40 -0700 Received: by xirtlu.zk3.dec.com; id AA25150; Sun, 3 Jul 1994 09:06:29 -0400 Message-Id: <9407031306.AA25150@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Cc: yakov@watson.ibm.com, peter@goshawk.lanl.gov, Bob.Hinden@eng.sun.com, dcrocker@Mordor.Stanford.EDU, bound@zk3.dec.com Subject: RFC 1627 : Issues about RFC 1597 Date: Sun, 03 Jul 94 09:06:23 -0400 X-Mts: smtp If most of you don't know I have always stated I don't care if RFC 1597 exists as long as no tells me I have to implement 1597. I also am now hearing folks represent 1597 in discussions like its a standard or a done deal in the IETF. Well please read RFC 1627 too if you have read RFC 1597. I am still neutral on 1597, but I do believe 1627 has produced a good counter argument, and also suggests we do not have consensus for 1597 in the IETF, which I agree with fyi. It also sends up some red flares which I just have to look at on this issue regarding IPng and a more important reason to read it than to diffuse 1597. /jim Network Working Group E. Lear Request for Comments: 1627 Silicon Graphics, Inc. Category: Informational E. Fair Apple Computer, Inc. D. Crocker Silicon Graphics, Inc. T. Kessler Sun Microsystems, Inc. July 1994 Network 10 Considered Harmful (Some Practices Shouldn't be Codified) Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. SUMMARY Re-use of Internet addresses for private IP networks is the topic of the recent RFC 1597 [1]. It reserves a set of IP network numbers, for (re-)use by any number of organizations, so long as those networks are not routed outside any single, private IP network. RFC 1597 departs from the basic architectural rule that IP addresses must be globally unique, and it does so without having had the benefit of the usual, public review and approval by the IETF or IAB. This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored. INTRODUCTION Growth in use of Internet technology and in attachments to the Internet have taken us to the point that we now are in danger of running out of unassigned IP network numbers. Initially, numbers were formally assigned only when a network was about to be attached to the Internet. This caused difficulties when initial use of IP substantially preceded the decision and permission to attach to the Internet. In particular, re-numbering was painful. The lesson that we learned was that every IP address ought to be globally unique, independent of its attachment to the Internet. This makes it possible for any two network entities to communicate, no matter where either might be located. This model is the result of a decades-long evolution, through which the community realized how painful it can be to convert a network of computers to use an assigned number after Lear, Fair, Crocker & Kessler [Page 1] RFC 1627 Network 10 Considered Harmful July 1994 using random or default addresses found on computers just out of the box. RFC 1597 abrogates this model without benefit of general IETF community discussion and consensus, leaving policy and operational questions unasked and unanswered. KEEP OUR EYES ON THE PRIZE: AN ARCHITECTURAL GOAL AND VIOLATION A common -- if not universal -- ideal for the future of IP is for every system to be globally accessible, given the proper security mechanisms. Whether such systems comprise toasters, light switches, utility power poles, field medical equipment, or the classic examples of "computers", our current model of assignment is to ensure that they can interoperate. In order for such a model to work there must exist a globally unique addressing system. A common complaint throughout the community is that the existing security in host software does not allow for every (or even many) hosts in a corporate environment to have direct IP access. When this problem is addressed through proper privacy and authentication standards, non-unique IP addresses will become a bottleneck to easy deployment if the recommendations in RFC 1597 are followed. The IP version 4 (IPv4) address space will be exhausted. The question is simply: when? If we assert that all IP addresses must be unique globally, connected or not, then we will run out of IP address space soon. If we assert that only IP addresses used on the world-wide Internet need to be globally unique, then we will run out of IP address space later. It is absolutely key to keep the Internet community's attention focused on the efforts toward IP next generation (IPng), so that we may transcend the limitations of IPv4. RFC 1597 produces apparent relief from IPv4 address space exhaustion by masking those networks that are not connecting to the Internet, today. However, this apparent relief will likely produce two results: complacency on the large part of the community that does not take the long term view, and a very sudden IP address space exhaustion at some later date. Prior to IPng deployment, it is important to preserve all the semantics that make both the Internet and Internet technology so very valuable for interoperability. Apple Computer, IBM, and Motorola could not collaborate as easily as they have to produce the PowerPC without uniquely assigned IP addresses. The same can be said of the Silicon Graphics merger with MIPS. There are many, many more examples Lear, Fair, Crocker & Kessler [Page 2] RFC 1627 Network 10 Considered Harmful July 1994 that can be cited. It should be noted that a scheme similar to RFC 1597 can be implemented at the time that we actually run out of assignable IPv4 address space; it simply requires that those organizations which have been assigned addresses but are not yet connected to the Internet return their addresses to IANA. It is important that the IAB (and IANA as its agent) reassert their ownership of the IP address space now, to preclude challenges to this type of reassignment. OPERATIONAL ISSUES RFC 1597 Implementations Methods are needed to ensure that the remaining addresses are allocated and used frugally. Due to the current problems, Internet service providers have made it increasingly difficult for organizations to acquire public IP network numbers. Private networks have always had the option of using addresses not assigned to them by appropriate authorities. We do not know how many such networks exist, because by their nature they do not interact with the global Internet. By using a random address, a company must take some care to ensure it is able to route to the properly registered owner of that network. RFC 1597 proposes to solve the routing problem by assigning numbers that will never be used outside of private environments. Using such standard numbers introduces a potential for clashes in another way. If two private networks follow RFC 1597 and then later wish to communicate with each other, one will have to renumber. The same problem occurs if a private network wishes to become public. The likely cost of renumbering is linear to the number of hosts on a network. Thus, a large company with 10,000 hosts on a network could incur considerable expense if it either merged with another company or joined the Internet in such a way as to allow all hosts to directly access the outside network. The probability of address clashes occurring over time approach 100% with RFC 1597. Picking a random network number reduces the chances of having to renumber hosts, but introduces the routing problems described above. Best of all, retrieving assigned numbers from the appropriate authority in the first place eliminates both existing and potential address conflicts at the cost of using a part of the address space. Apple Computer once believed that none of its internal systems would ever speak IP directly to the outside world, and as such, network operations picked IP class A network 90 out of thin air to use. Lear, Fair, Crocker & Kessler [Page 3] RFC 1627 Network 10 Considered Harmful July 1994 Apple is only now recovering from this error, having renumbered some 5,000 hosts to provide them with "desktop" Internet access. Unless the Internet community reaffirms its commitment to a globally unique address space, we condemn many thousands of organizations to similar pain when they too attempt to answer the call of the global Internet. Another timely example of problems caused by RFC 1597 is Sun's use of Internet multicasting. Sun selectively relays specific multicast conferences. This has the effect of making many hosts at Sun visible to the Internet, even though they are not addressable via IP unicast routing. If they had non-global addresses this would not work at all. It is not possible to predict which machines need global addresses in advance. Silicon Graphics has a similar configuration, as is likely for others, as well. Some might argue that assigning numbers to use for private networks will prevent accidental leaks from occurring through some sort of convention a'la Martian packets. While the proposal attempts to create a standard for "private" address use, there is absolutely no way to ensure that other addresses are not also used. Hence, the "standard" becomes nothing but a misleading heuristic. In fact, it is essential that routers to the global Internet advertise networks based only on explicit permission, rather than refusing to advertise others based on implicit prohibition, as supported by the policy formally created in RFC 1597. Security Issues Administrators will have a hard time spotting unauthorized networks, when their network has been breached (either intentionally or unintentionally) because the other networks might have the same numbers as those normally in the routing tables. More over, an inadvertent connection could possibly have a double whammy effect of partitioning two operational networks. It is worth emphasizing that IP providers should filter out all but authorized networks. Such a practice would not only prevent accidents but also enhance the security of the Internet by reducing the potential number of points of attack. Internet multicasting adds a new dimension to security. In some cases it may possible to allow multicasting through firewalls that completely restrict unicast routing. Otherwise unconnected networks might well need unique addresses, as illustrated in the example above. Lear, Fair, Crocker & Kessler [Page 4] RFC 1627 Network 10 Considered Harmful July 1994 Problems with Examples RFC 1597 gives several examples of IP networks that need not have globally unique address spaces. Each of those cases is plausible, but that does not make it legitimate to ENCOURAGE non-uniqueness of the addresses. In fact, it is equally plausible that globally unique IP addresses will be required, for every one of the scenarios described in RFC 1597: - Airport displays are public information and multicasting beyond the airport might be useful. - An organization's machines which, today, do not need global connectivity might need it tomorrow. Further, merging organizations creates havoc when the addresses collide. - Current use of firewalls is an artifact of limitations in the technology. Let's fix the problem, not the symptom. - Inter-organization private links do not generate benefit from being any more correct in guessing which machines want to interact than is true for general Internet access. This is another point that warrants repetition: the belief that administrators can predict which machines will need Internet access is quite simply wrong. We need to reduce or eliminate the penalties associated with that error, in order to encourage as much Internet connectivity as operational policies and technical security permit. RFC 1597 works very much against this goal. Problems With "Advantages" And More Disadvantages RFC 1597 claims that Classless Inter-Domain Routing (CIDR) will require enterprises to renumber their networks. In the general case, this will only involve those networks that are routed outside of enterprises. Since RFC 1597 addresses private enterprise networks, this argument does not apply. The authors mention that DCHP-based tools [2] might help network number transition. However, it is observed that by and large such tools are currently only "potential" in nature. Additionally, with the onslaught of ISDN, slip, and PPP in host implementations, the potential for a workstation to become a router inadvertently has never been greater. Use of a common set of addresses for private networks virtually assures administrators of having their networks partitioned, if they do not take care to carefully control modem connections. Lear, Fair, Crocker & Kessler [Page 5] RFC 1627 Network 10 Considered Harmful July 1994 Finally, RFC 1597 implies that it may be simple to change a host's IP address. For a variety of reasons this may not be the case, and it is not the norm today. For example, a host may be well known within a network. It may have long standing services such as NFS, which would cause problems for clients were its address changed. A host may have software licenses locked by IP address. Thus, migrating a host from private to global addressing may prove difficult. At the very least, one should be careful about addressing well known hosts. POLICY ISSUES IANA Has Overstepped Their Mandate For many years, IANA has followed an assignment policy based on the expectation of Internet connectivity for ALL assignees. As such it serves to encourage interconnectivity. IANA assignment of the network numbers listed in RFC 1597 serves to formally authorize behavior contrary to this accepted practice. Further, this change was effected without benefit of community review and approval. RFC 1597 specifies a new operational requirement explicitly: network service providers must filter the IANA assigned network numbers listed in RFC 1597 from their routing tables. This address space allocation is permanently removed from being used on the Internet. As we read RFC 1601 [3], this action is not within the purview of IANA, which should only be assigning numbers within the current standards and axioms that underlie the Internet. IP network numbers are assigned uniquely under the assumption that they will be used on the Internet at some future date. Such assignments violate that axiom, and constitute an architectural change to the Internet. RFC 1602 [4] and RFC 1310 [5] also contain identical wording to this effect in the section that describes IANA. While RFC 1597 contains a view worthy of public debate, it is not ready for formal authorization. Hence, we strongly encourage IANA to withdraw its IP address assignments documented by RFC 1597 forthwith. The IAB should review the address assignment policies and procedures that compose IANA's mandate, and reaffirm the commitment to a globally unique IP address space. COMMENTS AND CONCLUSIONS The Internet technology and service is predicated on a global address space. Members of the Internet community have already experienced and understood the problems and pains associated with uncoordinated private network number assignments. In effect the proposal attempts Lear, Fair, Crocker & Kessler [Page 6] RFC 1627 Network 10 Considered Harmful July 1994 to codify uncoordinated behavior and alter the accepted Internet addressing model. Hence, it needs to be considered much more thoroughly. RFC 1597 gives the illusion of remedying a problem, by creating formal structure to a long-standing informal practice. In fact, the structure distracts us from the need to solve these very real problems and does not even provide substantive aid in the near-term. In the past we have all dreaded the idea of having any part of the address space re-used. Numerous luminaries have both written and spoke at length, explaining why it is we want direct connections from one host to another. Before straying from the current architectural path, we as a community should revisit the reasoning behind the preaching of unique addressing. While RFC 1597 attempts to change this model, its costs and limitations for enterprises can be enormous, both in the short and long term. REFERENCES [1] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", T.J. Watson Research Center, IBM Corp., Chrysler Corp., RIPE NCC, RFC 1597, March 1994. [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, Bucknell University, October 1993. [3] Huitema, C., "Charter of the Internet Architecture Board (IAB)", RFC 1601, IAB, March 1994. [4] Internet Architecture Board, Internet Engineering Steering Group, "The Internet Standards Process -- Revision 2", IAB, IESG, RFC 1602, March 1994. [5] Internet Activities Board, "The Internet Standards Process", RFC 1310, IAB, March 1992. [6] Internet Activities Board, "Summary of Internet Architecture Discussion", Notes available from ISI, [ftp.isi.edu: pub/IAB/IABmins.jan91Arch.txt], IAB, January 1991. SECURITY CONSIDERATIONS See the section, "Security Issues". Lear, Fair, Crocker & Kessler [Page 7] RFC 1627 Network 10 Considered Harmful July 1994 AUTHORS' ADDRESSES Eliot Lear Silicon Graphics, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94043-1389 Phone: +1 415 390 2414 EMail: lear@sgi.com Erik Fair Apple Computer, Inc. 1 Infinite Loop Cupertino, CA 95014 Phone: +1 408 974 1779 EMail: fair@apple.com Dave Crocker Silicon Graphics, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94043-1389 Phone: +1 415 390 1804 EMail: dcrocker@sgi.com Thomas Kessler Sun Microsystems Inc. Mail Stop MTV05-44 2550 Garcia Ave. Mountain View, CA 94043 Phone: +1 415 336 3145 EMail: kessler@eng.sun.com Lear, Fair, Crocker & Kessler [Page 8] From bound@zk3.dec.com Sun Jul 3 09:18:47 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA09107 for ; Sun, 3 Jul 1994 09:20:04 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA27374; Sun, 3 Jul 94 06:19:03 -0700 Received: by xirtlu.zk3.dec.com; id AA25283; Sun, 3 Jul 1994 09:18:53 -0400 Message-Id: <9407031318.AA25283@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: sob@hsdndev.harvard.edu, Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: one size fits all (fwd) In-Reply-To: Your message of "Sun, 03 Jul 94 08:49:10 EDT." <199407031249.IAA09017@picard.cmf.nrl.navy.mil> Date: Sun, 03 Jul 94 09:18:47 -0400 X-Mts: smtp Yakov. ABSOLUTELY NOT. ABSOLUTELY NOT. The proposals on the table to solve this problem at this time is SIPP FIXED. I want the SIPP working group to work this problem without all the architects who dont build products, dont work with code, and don't do a hell of a lot but talk and discuss based on some experience they had in the past in any of the above categories. We have hands on folks willing to discuss this openly on SIPP list. These are people who have done more code with IPng than anyother WG in the IETF. I think Big-I is a waste of time these days and would not even read it if I were not on the Directorate and have to watch the traffic. More importantly this is a working group discussion and SIPP now has many of the key players from SIPP and TUBA on it now and willing to work together lets take advantage of that polarity. I suggest to Steve that if this must be done then lets run a simultaneous discussion on SIPP to get real implementors views. I also suggest to Steve that a header in the msg state we feel we have TUBA folks on the SIPP list and need their input too would be a good thing to do. Big-I is not a KING or QUEEN. Its not the final say and it certainly does not reflect very good tecHniccal discussion. I want to see technical discussion on how this is going to work not how it might work. p.s. Scott and Allison I object strongly to Yakovs idea of Big-I as a Directorate member. /jim From bound@zk3.dec.com Sun Jul 3 09:27:50 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA09132 for ; Sun, 3 Jul 1994 09:30:47 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA27879; Sun, 3 Jul 94 06:28:06 -0700 Received: by xirtlu.zk3.dec.com; id AA25664; Sun, 3 Jul 1994 09:27:56 -0400 Message-Id: <9407031327.AA25664@xirtlu.zk3.dec.com> To: craig@aland.bbn.com, kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: IPng Reqs : Ack Issue (CORRECTED DIST LIST) Date: Sun, 03 Jul 94 09:27:50 -0400 X-Mts: smtp Please only respond to this I made an alias error. A good reason why names are so important. /jim I don't think you wanted to send this to craig@zk3.dec.com I am Craig Peterson, and don't know who you intended this for. Craig. From: bound@zk3.dec.com Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Date: Sun, 03 Jul 94 08:50:04 -0400 Frank and Craig, Both of your names are on the front of 5/25 ...criteria-02.txt draft so I am sending this to both of you. I still think the document is good OK. BUT... Your acknowledgment list looks like you forgot about the IPng Directorate that helped you formulate and verify the entire set of requiremets and several our the Directorates white papers whose ideas are within your document in different words. Your notable mentions of IAB, Li, Chiappa, Postel, are nice but many of the ideas expressed in Directorate papers or by the mail discussions of us ourselves have contributed more to this document than the mentions above. I am very upset by this and feel its typical good ole boy IETF feed each other politics. In the future when I work with either of you I will be very cautious because when I work with someone I want to feel comfortable that my work and input will be acknowledged in addition to those who may be the good ole boys. Espescially when my ideas were used to help generate a document. I think key Directorate members worked real hard on your requirments with you and two of them produced white papers too: Brian Carpenter, Eric Fleischman, John Curran, Greg Minshall, Steve Deering, Steve Bellovin, and myself. Those connecting with you off line I cannot ascertain obviously but these are folks who worked extensive issues with you and in fact caused the final name of your doc Technical Criteria. A bit disappointed and it will affect me greatly in any future dealings we have in the IETF, unless you can send mail to me convincing me this was an oversight or something. Right now I think it was done on purpose and very bold, and I wanted you to know I know you did this. /jim ------- End of Forwarded Message From sob@hsdndev.harvard.edu Sun Jul 3 09:53:19 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA09191 for ; Sun, 3 Jul 1994 09:53:26 -0400 Date: Sun, 3 Jul 94 09:53:19 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407031353.AA26372@hsdndev.harvard.edu> To: Brian.Carpenter@cern.ch, yakov@watson.ibm.com Subject: Re: one size fits all (fwd) Cc: ipng@cmf.nrl.navy.mil yes, such a discussion should also be on the big-i list but it is quite reasonable for the sipp list to be part of the discussion. I've talked to quite a few people who are not on the big-i list because of what they see as a bad ratio between noise & substance, we would not like to miss the input from them. Scott From yakov@watson.ibm.com Sun Jul 3 09:59:07 1994 Return-Path: yakov@watson.ibm.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA09201 for ; Sun, 3 Jul 1994 09:59:07 -0400 From: yakov@watson.ibm.com Message-Id: <199407031359.JAA09201@picard.cmf.nrl.navy.mil> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9349; Sun, 03 Jul 94 09:59:07 EDT Date: Sun, 3 Jul 94 09:59:07 EDT To: bound@zk3.dec.com cc: sob@hsdndev.harvard.edu, ipng@cmf.nrl.navy.mil Subject: one size fits all (fwd) Ref: Your note of Sun, 03 Jul 94 09:18:47 -0400 Jim, >The proposals on the table to solve this problem at this time is >SIPP FIXED. It is a bit hard for me to understand what the above sentence means exactly. Could you elaborate a bit on this please. Thanks. Yakov. From jcurran@nic.near.net Sun Jul 3 10:12:09 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA09226 for ; Sun, 3 Jul 1994 10:13:21 -0400 Received: from platinum.near.net by nic.near.net id aa28282; 3 Jul 94 10:13 EDT To: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil, yakov@watson.ibm.com, peter@goshawk.lanl.gov, Bob.Hinden@eng.sun.com, dcrocker@mordor.stanford.edu Subject: Re: RFC 1627 : Issues about RFC 1597 In-reply-to: Your message of Sun, 03 Jul 1994 09:06:23 -0400. <9407031306.AA25150@xirtlu.zk3.dec.com> Date: Sun, 03 Jul 1994 10:12:09 -0400 From: John Curran Message-ID: <9407031013.aa28282@nic.near.net> -------- ] From: bound@zk3.dec.com ] Subject: RFC 1627 : Issues about RFC 1597 ] Date: Sun, 03 Jul 94 09:06:23 -0400 ] ... ] It also sends up some red flares which I just have to look at on this ] issue regarding IPng and a more important reason to read it than to ] diffuse 1597. Some of the policy questions raised in 1627 (regarding an informational doc affecting the manner of IANA address allocation) are quite real; it's always good to know there's a "IETF watchdog" group out there... On the other hand, 1627 advocates against formalizing an existing practice which is both necessary and desirable for some circumstances. The basic reasoning is that organizations don't understand the full ramifications of the use of "private" network addressing, and hence should not be encouraged to do so. This is meddling on behalf of the IETF into private organizations use of IP addresses by folks who think that they "know better". If the IETF formally tries to eliminate "private" network addressing, then industry will respond in force. /John From bound@zk3.dec.com Sun Jul 3 12:43:03 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA09492 for ; Sun, 3 Jul 1994 12:45:33 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA09204; Sun, 3 Jul 94 09:43:20 -0700 Received: by xirtlu.zk3.dec.com; id AA01042; Sun, 3 Jul 1994 12:43:09 -0400 Message-Id: <9407031643.AA01042@xirtlu.zk3.dec.com> To: John Curran Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil, yakov@watson.ibm.com, peter@goshawk.lanl.gov, Bob.Hinden@eng.sun.com, dcrocker@mordor.stanford.edu Subject: Re: RFC 1627 : Issues about RFC 1597 In-Reply-To: Your message of "Sun, 03 Jul 94 10:12:09 EDT." <9407031013.aa28282@nic.near.net> Date: Sun, 03 Jul 94 12:43:03 -0400 X-Mts: smtp John, ACK on private industry I agree with you 100% and why I am not anit-1597. My purpose was only to make sure we saw this in case warnings could at least be known with 1597. Thats all. Probably to much to ask but if there was a 1597-1627 draft that stated here are the warings but its your own trip and good luck. thanks /jim From bound@zk3.dec.com Sun Jul 3 12:52:21 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA09509 for ; Sun, 3 Jul 1994 12:55:26 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA09726; Sun, 3 Jul 94 09:52:37 -0700 Received: by xirtlu.zk3.dec.com; id AA01125; Sun, 3 Jul 1994 12:52:27 -0400 Message-Id: <9407031652.AA01125@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: bound@zk3.dec.com, sob@hsdndev.harvard.edu, ipng@cmf.nrl.navy.mil Subject: Re: one size fits all (fwd) In-Reply-To: Your message of "Sun, 03 Jul 94 09:59:07 EDT." <199407031359.JAA09201@picard.cmf.nrl.navy.mil> Date: Sun, 03 Jul 94 12:52:21 -0400 X-Mts: smtp Yakov, =>The proposals on the table to solve this problem at this time is =>SIPP FIXED. >It is a bit hard for me to understand what the above sentence means exactly. >Could you elaborate a bit on this please. I mean't we went through an exercise and found some consensus that we could use parts of SIPP with changes for routing and addressing which I hope is and does become an IPng Working Group. But saying it the way I did is probably not the best way to state it. I think Scott's right we need an IPng Working Group and an IPng mailing list too. I have been impressed with the recent SIPP list technical contributions from all factions on IPng lately, but its probably better to go to Big-I as I pondered it on my deck this sunny a.m. in New Hampshire. My concern is that on Big-I I just don't want to go down an architectural rat hole and felt we could avoid that on SIPP list. But, on second thought it might be best to go to Big-I and most of the folks are on there too. Maybe what I will do is sit back and take the rat-holer job and if it looks like a rat-hole just suggest its a rat hole. We just need to keep moving forward and not go backward I want to work on this stuff. Might be good to send mail to each WG list telling them we are going to discuss this on Big-I. /jim From dcrocker@Mordor.Stanford.EDU Sun Jul 3 09:52:41 1994 Return-Path: dcrocker@Mordor.Stanford.EDU Received: from Mordor.Stanford.EDU (Mordor.Stanford.EDU [36.53.0.155]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id MAA09503 for ; Sun, 3 Jul 1994 12:52:49 -0400 Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id JAA27011; Sun, 3 Jul 1994 09:52:41 -0700 Message-Id: <199407031652.JAA27011@Mordor.Stanford.EDU> To: John Curran cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil, yakov@watson.ibm.com, peter@goshawk.lanl.gov, Bob.Hinden@eng.sun.com cc: dcrocker@Mordor.Stanford.EDU Subject: Re: RFC 1627 : Issues about RFC 1597 Phone: +1 408 246 8253; fax: +1 408 249 6205 In-reply-to: Your message of Sun, 03 Jul 94 10:12:09 -0400. <9407031013.aa28282@nic.near.net> Date: Sun, 03 Jul 94 09:52:41 -0700 From: Dave Crocker X-Mts: smtp >From the Vegas BOF, I think there was some general agreement that we should attempt to develop a joint document. I'd guess that its tone and content should be along the lines that Jim B has used in describing his own view of the 1597 ideas. Not anti, but quite cautious. Dave From bound@zk3.dec.com Sun Jul 3 13:00:15 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA09542 for ; Sun, 3 Jul 1994 13:05:13 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA10167; Sun, 3 Jul 94 10:00:32 -0700 Received: by xirtlu.zk3.dec.com; id AA01236; Sun, 3 Jul 1994 13:00:21 -0400 Message-Id: <9407031700.AA01236@xirtlu.zk3.dec.com> To: Dave Crocker Cc: John Curran , bound@zk3.dec.com, ipng@cmf.nrl.navy.mil, yakov@watson.ibm.com, peter@goshawk.lanl.gov, Bob.Hinden@eng.sun.com Subject: Re: RFC 1627 : Issues about RFC 1597 In-Reply-To: Your message of "Sun, 03 Jul 94 09:52:41 PDT." <199407031652.JAA27011@Mordor.Stanford.EDU> Date: Sun, 03 Jul 94 13:00:15 -0400 X-Mts: smtp Dave, I am agreeing with you so much these past days I am going to go have a beer and do a logic check. /jim From dcrocker@Mordor.Stanford.EDU Sun Jul 3 10:24:50 1994 Return-Path: dcrocker@Mordor.Stanford.EDU Received: from Mordor.Stanford.EDU (Mordor.Stanford.EDU [36.53.0.155]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id NAA09577 for ; Sun, 3 Jul 1994 13:24:58 -0400 Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id KAA27106; Sun, 3 Jul 1994 10:24:50 -0700 Message-Id: <199407031724.KAA27106@Mordor.Stanford.EDU> To: bound@zk3.dec.com cc: John Curran , ipng@cmf.nrl.navy.mil, yakov@watson.ibm.com, peter@goshawk.lanl.gov, Bob.Hinden@eng.sun.com cc: dcrocker@Mordor.Stanford.EDU Subject: Re: RFC 1627 : Issues about RFC 1597 Phone: +1 408 246 8253; fax: +1 408 249 6205 In-reply-to: Your message of Sun, 03 Jul 94 13:00:15 -0400. <9407031700.AA01236@xirtlu.zk3.dec.com> Date: Sun, 03 Jul 94 10:24:50 -0700 From: Dave Crocker X-Mts: smtp Jim, ---- Included message: I am agreeing with you so much these past days I am going to go have a beer and do a logic check. Think of it as validating the legitimacy of our disagreements... d/ From mankin@radegond.cmf.nrl.navy.mil Sun Jul 3 15:16:32 1994 Forwarded: Tue, 05 Jul 94 08:31:45 -0400 Forwarded: "sob@harvard.edu " Return-Path: mankin@radegond.cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id PAA09823 for ; Sun, 3 Jul 1994 15:16:35 -0400 Received: from localhost (mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id PAA09794 for ; Sun, 3 Jul 1994 15:16:32 -0400 Message-Id: <199407031916.PAA09794@radegond.cmf.nrl.navy.mil> X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: ipng@radegond.cmf.nrl.navy.mil Subject: Mail to Each WG List Date: Sun, 03 Jul 94 15:16:32 -0400 From: Allison J Mankin Jim, Yes, we're about to do just that. I'm still tinkering a little because of the late date, but Scott and I are fairly happy with the message below: ----------------- To: big-internet, tuba, sipp, catnip, ietf Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Hi, This message is an attempt to gauge the extent of consensus on one of the IPng issues. Steve Deering's message "Chicago Meeting -- Possible Changes to SIPP" to the SIPP list a while back elicited quite a bit of discussion on various lists (both SIPP and big-internet and in other venues) about the length of "address" required for an IPng. We have also had considerable discussion within the directorate. At this time it would appear to us that there is considerable consensus that a fixed length, topologically structured, hierarchical address 16 bytes in length is reasonable for an IPng (that is meets the needs of the very very large-scale Internet). We understand that we are being a bit vague in using the term "address" in light of the question we asked last week. For the purposes of this request, please assume that the transport level and internet level names are the same. Some view that 16 bytes is larger than would be required for any imaginable Internet structure in the future and that an 8 byte address is all that is required. There seems to be a stronger, but still minority, view that, for various reasons, a variable length address, one that could be smaller or larger than 16 bytes, would meet the needs better for the future of the Internet. Much of the discussion on the lists has revolved around the relative efficiency of processing fixed and variable length addresses. We would like to assess the consensus just on lengths for the future. We want to make sure that we have understood consensus on meeting the needs of the very very large Internet. Therefore, this message is to ask people what present or future rationale they see for one of: 16 byte fixed length address longer than 16 byte fixed length address now longer than 16 byte fixed length address next time we change anything 8 byte fixed length address. We hope to guage, in particular, what, if any, the consensus is about the routing power, topological flexibility and manageability of the length of the address. At this point the consensus on the big-internet list seems quite clear. This is a good time to bring forward remaining issues about the IPng address length requirements. Of course, we also welcome messages that support our perceived consensus. Thank you, Scott & Allison From yakov@watson.ibm.com Sun Jul 3 15:35:12 1994 Return-Path: yakov@watson.ibm.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA09871 for ; Sun, 3 Jul 1994 15:35:12 -0400 From: yakov@watson.ibm.com Message-Id: <199407031935.PAA09871@picard.cmf.nrl.navy.mil> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0205; Sun, 03 Jul 94 15:35:13 EDT Date: Sun, 3 Jul 94 15:35:12 EDT To: bound@zk3.dec.com cc: sob@hsdndev.harvard.edu, ipng@cmf.nrl.navy.mil Subject: one size fits all (fwd) Ref: Your note of Sun, 03 Jul 94 12:52:21 -0400 Jim, >My concern is that on Big-I I just don't want to go down an >architectural rat hole. I understand your concern. However, IMHO the design of IPng *has* to reflect *both* architectural *and* implementation *and* end-user *and* network operators concerns. Yakov. From bound@zk3.dec.com Mon Jul 4 00:21:38 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA10999 for ; Mon, 4 Jul 1994 00:25:41 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA20795; Sun, 3 Jul 94 21:21:54 -0700 Received: by xirtlu.zk3.dec.com; id AA07026; Mon, 4 Jul 1994 00:21:44 -0400 Message-Id: <9407040421.AA07026@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: bound@zk3.dec.com, sob@hsdndev.harvard.edu, ipng@cmf.nrl.navy.mil Subject: Re: one size fits all (fwd) In-Reply-To: Your message of "Sun, 03 Jul 94 15:35:12 EDT." <9407031935.AA22602@decvax.dec.com> Date: Mon, 04 Jul 94 00:21:38 -0400 X-Mts: smtp Yakov, >I understand your concern. However, IMHO the design of IPng *has* to >reflect *both* architectural *and* implementation *and* end-user >*and* network operators concerns. Agreed and good point. /jim From brian@dxcoms.cern.ch Mon Jul 4 08:10:10 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA11239 for ; Mon, 4 Jul 1994 02:11:33 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11945; Mon, 4 Jul 1994 08:10:12 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA07491; Mon, 4 Jul 1994 08:10:10 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407040610.AA07491@dxcoms.cern.ch> Subject: Re: RFC 1627 : Issues about RFC 1597 To: bound@zk3.dec.com Date: Mon, 4 Jul 1994 08:10:10 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil, yakov@watson.ibm.com, peter@goshawk.lanl.gov, Bob.Hinden@eng.sun.com, dcrocker@Mordor.Stanford.EDU In-Reply-To: <9407031306.AA25150@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jul 3, 94 09:06:23 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 505 Folks, I don't think IPng should get into this specific controversy. What we should think about is whether IPng will adequately support the migration of private IPv4 nets onto the general Internet. It is irrelevant whether the private addresses are RFC 1597 addresses or "illegal" ones; in either case they are ambiguous. The interesting question is whether the IPng addressing plan allows them to be made globally unique by adding a prefix (good), or whether the users have to renumber (bad). Brian From brian@dxcoms.cern.ch Mon Jul 4 08:15:29 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA11264 for ; Mon, 4 Jul 1994 02:16:36 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA12154; Mon, 4 Jul 1994 08:15:31 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA07685; Mon, 4 Jul 1994 08:15:30 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407040615.AA07685@dxcoms.cern.ch> Subject: Re: Mail to Each WG List To: mankin@cmf.nrl.navy.mil (Allison J Mankin) Date: Mon, 4 Jul 1994 08:15:29 +0200 (MET DST) Cc: ipng@radegond.cmf.nrl.navy.mil In-Reply-To: <199407031916.PAA09794@radegond.cmf.nrl.navy.mil> from "Allison J Mankin" at Jul 3, 94 03:16:32 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3043 Just two comments 1. Consensus is not necessarily truth. I haven't fully digested Dave Clark's warning in Chelmsford yet. 2. I think you should add the "16 byte mandatory, longer optional now" choice (sort of the Yakov/Brian idea). Brian >--------- Text sent by Allison J Mankin follows: > > Jim, > > Yes, we're about to do just that. I'm still > tinkering a little because of the late date, but > Scott and I are fairly happy with the message below: > > > > ----------------- > > To: big-internet, tuba, sipp, catnip, ietf > Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements > > Hi, > > This message is an attempt to gauge the extent of consensus on > one of the IPng issues. > > Steve Deering's message "Chicago Meeting -- Possible Changes > to SIPP" to the SIPP list a while back elicited quite a bit > of discussion on various lists (both SIPP and big-internet and > in other venues) about the length of "address" required for an IPng. > We have also had considerable discussion within the directorate. > > At this time it would appear to us that there is considerable consensus > that a fixed length, topologically structured, hierarchical > address 16 bytes in length is reasonable for an IPng (that is > meets the needs of the very very large-scale Internet). > We understand that we are being a bit vague in using the term "address" in > light of the question we asked last week. For the purposes of this > request, please assume that the transport level and internet level names > are the same. > > Some view that 16 bytes is larger than would be required > for any imaginable Internet structure in the future and that an > 8 byte address is all that is required. > > There seems to be a stronger, but still minority, view that, for various > reasons, a variable length address, one that could be smaller or larger > than 16 bytes, would meet the needs better for the future of the > Internet. > > Much of the discussion on the lists has revolved around the relative > efficiency of processing fixed and variable length addresses. We would > like to assess the consensus just on lengths for the future. We want to > make sure that we have understood consensus on meeting the needs > of the very very large Internet. Therefore, this message is to > ask people what present or future rationale they see for one of: > 16 byte fixed length address > longer than 16 byte fixed length address now > longer than 16 byte fixed length address next time we change > anything > 8 byte fixed length address. > > We hope to guage, in particular, what, if any, the consensus > is about the routing power, topological flexibility and manageability > of the length of the address. > > At this point the consensus on the big-internet list seems quite > clear. This is a good time to bring forward remaining issues > about the IPng address length requirements. Of course, we also > welcome messages that support our perceived consensus. > > Thank you, > > Scott & Allison > > > > From jallard@microsoft.com Tue Jul 5 10:21:52 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA18403 for ; Tue, 5 Jul 1994 13:27:51 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA17911; Tue, 5 Jul 94 09:29:49 -0700 Message-Id: <9407051629.AA17911@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 05 Jul 94 09:29:49 PDT X-Msmail-Message-Id: DE117E2A X-Msmail-Conversation-Id: DE117E2A From: "James 'J' Allard" To: ipng@radegond.cmf.nrl.navy.mil, ipng-request@cmf.nrl.navy.mil Date: Tue, 5 Jul 94 10:21:52 TZ Subject: RE: IPng Outline from Scott and Allison | o - a new IPng working group be formed is this an umbrella group for the ipng effort, or is this a road group? | o - the working group take as its base documents | the forthcoming SIPP draft ( SIPP with 16 byte addresses) | SST outline i'd like the sst outline to be cleaned up prior to the bofs in toronto. | o - a new IPng autoconfiguration working group be formed | base document - draft from Sue Thompson & Dave Katz i haven't seen this new document, does it exsit yet? | o - an IPng Architect be named (Dave Clark) | job description: asking the exhaustive | questions, connecting all the points, | offering the broadest perspective, | but not making* architectural decisions, | that is the work of the wgs and the ietf. pls call this something other than "architect". what are the specific deliverables of this position? this description is alarmingly vague. | o - specific efforts be undertaken to facilitate the creation of | transition plans from other environments, including IPX | and CLNP. | (where the addresses are globally unique and allocated | along the lines of network topology) who owns this action item? | o - existing working groups not forced to shut down | what we said at start of process they should be. we need all of the players on the same team, otherwise we've failed. i'd specifically recommend disbanding all ipng wg's. | We think that there is general consensus about a 16 byte fixed length | hierarchical, autoconfigurable address. Will probe community. | If consensus not demonstrated then recommend a BOF in Toronto | to address the issue - Dave Clark as BOF chair we've probed the community and need to put a stake in the ground with this. the directorate needs to make a *recommendation* here, handwaving is unacceptable. there are two positions: 1) since we can address all of the electrons in the universe, it must be enough. 2) hierarchical routing, network marriages, and inefficient allocation all break the foundation of 1's argument. i see the split to be damn close to 50/50. we can ask the world, and it probably won't tilt beyond 40/60 in either direction. both sides should agree to disagree. i dont know what the final directorate poll results were, but i'd bet they're some where in this neighborhood. that said, i can't possibly see why we'd recommend something that 40% of the engineers believe "might" fail. although 16 bytes seems like enough to most of us right now, the performance argument is a crock. the tcp checksum is 3x the size of our send path in our stack. who cares abt a 10% overhead in header processing when it's only 25% of the common path? processor power is climbing through the roof. the biggest counter argument has been that multimedia apps need more bandwidth. yes, this is true. however, looking at mosaic on a 386/20 machine, we can cpu-saturate the system easily. the split? 85% mosaic, 15% tcp. what does that say? that the app itself is too cpu intensive to make the transport utilization an issue. if we doubled the performance of the transport, the app wouldn't be able to process it... i urge the directorate to recommend variable length addresses, profiled for 16 bytes today with an escape hatch tomorrow. we can all fastpath the 16 byte case for now. | Major open issues specific to IPng source routes and eids are all very interesting, but the goddamn thing doesn't work at all without some pretty extensive changes to dns (e.g., autoregistration, new record formats, etc..). how are we going to address this? in the ipng wg, the autoconfig wg? do we need another one? my hunch is that the dns issues are ~12 pages of documentation sorry to sound critical, but in trying to read this outline as "an outsider" to the process, it doesn't appear very strong. it feels very cya-ish. i think we really need to make some strong recommendations, get everyone on the same page, and start the engineering effort full tilt. we can't keep asking questions to which we know there are no single answers. we need to offer answers to the hard questions. From jallard@microsoft.com Tue Jul 5 11:10:34 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA18851; Tue, 5 Jul 1994 14:18:41 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA21180; Tue, 5 Jul 94 10:20:35 -0700 Message-Id: <9407051720.AA21180@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 05 Jul 94 10:20:35 PDT X-Msmail-Message-Id: 9BAAB5A0 X-Msmail-Conversation-Id: 9BAAB5A0 X-Msmail-Fixed-Font: 0001 From: "James 'J' Allard" To: Brian.Carpenter@cern.ch, ipng-request@cmf.nrl.navy.mil Date: Tue, 5 Jul 94 11:10:34 TZ Subject: Re: IPng Outline from Scott and Allison Cc: ipng@radegond.cmf.nrl.navy.mil, mankin@cmf.nrl.navy.mil | But no one on the Directorate or in the IETF has proven that 16bytes are | not sufficient for 30 years of product generations and the Internet. | The majority of Directorate members have stated OK to 16bytes. you're absolutely correct, there is no concrete proof that 16 bytes is not sufficient today. engineering for the future requires speculation, not just evidence. if i look at the fixed-width arguments, i'd say that we could easily prove that 4- or 6-bytes is enough. why 16 then? evidence is useful for a postemortem of ipv4, which quite seriously i'm surprised hasn't done at length. i personally attribute the ipv4 problems to classfull addressing, fixed width, poor allocation, lack of aggregation in general. i *can* prove that variable length is a superset of fixed length, and can, should it prove necessary extend the lifetime of ipng in the future by some factor (unless we hose things some other way). variable length seems like the way to go. let me share an analogy that you're probably familiar with to some degree (i'm no expert in this area, but i believe that these #s/dates are roughly accurate). ip address width tv tuner width ---------------- -------------- ipv4: 4 bytes 1975: 13 channels ipng: 16 bytes 1985: 36 channels 1991: 110 channels in the 70's, more than 13 channels seemed unthinkable. in '85, the cable industry had stolen frequencies in broadcast use to get it up to ~30 channels. today, everyone's tv addresses 110. was there proof that we'd exceed 100 channels? nope. can you upgrade the firmware in my $1500 tv today to save me from having to buy a new tv tommorow? nope. what happens when i can get more than 110 channels? upgrade. oh, did anyone think in 1991 that tv's would "talk back" to their headends? nope. we're going to all have to upgrade again. the cable industry has had to steal frequencies more than once and tell mfgs how to upgrade their systems. consumers have had to upgrade their systems to get the extra channels. why? because there was no proof that it was necessary, and they didn't take the time to spec out what the "unthinkable" future might look like so that mfgs could adapt. while i'm on the tv subject... a tv "package" used include a tuner, an antenna, a monitor, a speaker, and a remote control. since these bozo's didn't get it together, my $1500 tv "package" offers simply a monitor at the cost of the whole package. i need to get a set top box to get the tuning, i get cable instead of an antenna, i use my stereo system instead of the built-in 1.5" speakers, and i need a universal remote to control the audio and the tuning since its separate from my tv unit and the tv remote isn't programmable. why my tv remote can't control a vcr (which some very large percentage of all new tv buyers have) fails me. who gets screwed? end-users. who took the easy path? the tv engineers. had the speculated more, and relied less on evidence, i'd really get $1500 of value from my tv today. instead i throw 15% of it's value away and pay someone else more $$$ to bandaid it. many of our customers systems' have 5+ year old software running on them somewhere. we're going to be adding a whole new slew of technologies to do automatic updates of drivers, etc. to make the software upgrade process smoother. in our case the transition to ipng from ipv4 can be made almost entirely automatic on the hosts (which i speculate will be an order of magnitude more powerful than the existing pentium-level processors by the time the first user in production upgrades). my worry is that ipng to ipnng requires major infrastructural change. we can't have a flag day today because of the small, decentralized infrastructure that we have today. imagine when and if 16 isn't enough what kind of trouble we'll be in. let's not do this.. if we do, someone else will walk in and bandaid our mistakes, just like the set top box, cable tv and universal remote companies did. i am keeping a printed copy of this message in my safe deposit box. i warn you that my urge to pull it out and say "i told you so" if and when things break will be unsurpassed. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From iesg-request@ietf.cnri.reston.va.us Tue Jul 5 08:26:28 1994 Return-Path: iesg-request@ietf.cnri.reston.va.us Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA14547 for ; Tue, 5 Jul 1994 02:29:44 -0400 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12997; 5 Jul 94 2:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12993; 5 Jul 94 2:26 EDT Received: from dxmint.cern.ch by CNRI.Reston.VA.US id aa17307; 5 Jul 94 2:26 EDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22673; Tue, 5 Jul 1994 08:26:30 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA01850; Tue, 5 Jul 1994 08:26:29 +0200 Sender: iesg-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9407050626.AA01850@dxcoms.cern.ch> Subject: Re: IPng Outline from Scott and Allison To: Allison J Mankin Date: Tue, 5 Jul 1994 08:26:28 +0200 (MET DST) Cc: iesg@CNRI.Reston.VA.US, ipng@radegond.cmf.nrl.navy.mil In-Reply-To: <199407050425.AAA11896@radegond.cmf.nrl.navy.mil> from "Allison J Mankin" at Jul 5, 94 00:25:13 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3054 Brian says: > o - a new IPng working group be formed SHOUT: YOU MUST FIND AT LEAST ONE NON-US RESIDENT!! YOU MUST!! (even louder: NOT ME!!!) > > o - a new IPng-specific transition working group be formed > base document - provided by IPNG wg based on SST This is TACIT, right? > o - a new EID working group be formed > using results of BOF in Toronto Unclear to me. Do you mean that EIDs are part of IPng? From everything I have seen, I concluded that they are a research topic. > > o - an IPng Architect be named (Dave Clark) > job description: asking the exhaustive > questions, connecting all the points, > offering the broadest perspective, > but not making* architectural decisions, > that is the work of the wgs and the ietf. Call this job "IPng Reviewer". I had to leave before you finished this discussion in Chelmsford, but I find the word "architect" highly unfortunate. In fact the job description makes it clear this is NOT the architect. > > o - IPng address allocation procedures be described in > a document at the earliest possible time > participation from the IAB and IESG > led by IEPG? > first distribution of 10% IPng address space > to regional authorities be within this year > Make it 12.5%, it's a lot easier in binary! > o - specific efforts be undertaken to facilitate the creation of > transition plans from other environments, including IPX > and CLNP. > (where the addresses are globally unique and allocated > along the lines of network topology) Too vague. I can't sell this in Europe. I *need* NSAPA embedding as a specifc goal or up-front option. > > o - existing working groups not forced to shut down > what we said at start of process Fudge. SIPP and CATNIP have no reasom to continue. Either TUBA should shut down, or should be renamed TUNA (TCP and UDP over NSAP Addresses) and viewed as a coexistence tool to leverage Internet applications over CLNP infrastructure. Most of the basic TUBA work matches this approach very well. The less developed parts of TUBA (flows, multicast,...) could be moved to "historic" status. If you don't want to encourage this, close it down. > > We think that there is general consensus about a 16 byte fixed length > hierarchical, autoconfigurable address. Will probe community. > If consensus not demonstrated then recommend a BOF in Toronto > to address the issue - Dave Clark as BOF chair I agree there is consensus that this is necessary. Is there consensus that it is sufficient? I don't think so, certainly not in the Directorate. Brian From huitema@mitsou.inria.fr Tue Jul 5 09:48:01 1994 Return-Path: huitema@mitsou.inria.fr Received: from mitsou.inria.fr (mitsou.inria.fr [138.96.24.84]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id DAA14674 for ; Tue, 5 Jul 1994 03:46:59 -0400 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA18103; Tue, 5 Jul 1994 09:48:02 +0200 Message-Id: <199407050748.AA18103@mitsou.inria.fr> To: Allison J Mankin Cc: iesg@CNRI.Reston.VA.US, ipng@radegond.cmf.nrl.navy.mil, iab@isi.edu Subject: Re: IPng Outline from Scott and Allison In-Reply-To: Your message of "Tue, 05 Jul 1994 00:25:13 EDT." <199407050425.AAA11896@radegond.cmf.nrl.navy.mil> Date: Tue, 05 Jul 1994 09:48:01 +0200 From: Christian Huitema => o - an IPng Architect be named (Dave Clark) => job description: asking the exhaustive => questions, connecting all the points, => offering the broadest perspective, => but not making* architectural decisions, => that is the work of the wgs and the ietf. Alison, Scott, I have a lot of respect for Dave, but I do believe that this "architectural review" is right in the charter of the IAB. If the Internet Architecture Board is not involved in reviewing the design of the next generation Internet protocol, what is it nominated for? If the only job is to discuss with Jack Houldsworth, we may as well quit en masse and dissolve the IAB! We cautiously refused to get involved in the decision process, because their may be some dispute and we had to play "fair judges". Once the decision is taken, there is no reason we should not revert to normal procedures. Which implies that architectural review is indeed the job of the IAB. Note that I am not willing to exclude anybody from the process. We may very well ask Dave to lead an external review panel, as Brian suggests. Christian Huitema From sob@hsdndev.harvard.edu Tue Jul 5 07:34:13 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA15204 for ; Tue, 5 Jul 1994 07:34:27 -0400 Date: Tue, 5 Jul 94 07:34:13 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407051134.AA16006@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: outline please be careful in responding to the outline that Allison sent out. Note that it went to the ipng directorate & to teh IESG. If you want your note to only go to the ipng list you need to take care in your reply. (do send to teh IESG if you want to though) Scott From jallard@microsoft.com Tue Jul 5 20:34:40 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA22436 for ; Tue, 5 Jul 1994 23:41:15 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA13586; Tue, 5 Jul 94 19:43:05 -0700 Message-Id: <9407060243.AA13586@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 05 Jul 94 19:43:05 PDT X-Msmail-Message-Id: 0F2772A6 X-Msmail-Conversation-Id: 0F2772A6 From: "James 'J' Allard" To: ericf@atc.boeing.com, ipng-request@cmf.nrl.navy.mil Date: Tue, 5 Jul 94 20:34:40 TZ Subject: Re: Concern Cc: bound@zk3.dec.com, ipng@radegond.cmf.nrl.navy.mil | First performance hits on variable addresses are not a 'crock'. it's not a crock, it's a non issue. 50 instructions on the send path is trivial given the horsepower of existing and future cpus. really, how many instructions is it if you fastpath 16-bytes and do the check. bet it's less than 50. | It could be a 'wash' if we go and fix other areas of the IP stack. the fact that you haven't optimized all of the areas of your implementation suggest a bogus argument. we've tuned the shit out of ours, we can't cut out 50 instructions. it's not a wash, its more instructions. i don't care though, it's worth it. i recommend you clean up what you can, and if you save 50 great, if you save 500, better, but it has nothing to do with the argument (other than to suggest a bogus argument since you didn't clean up your performance before this discussion came up. performance must not be **that** important). | I talked to Scott this weekend and told him I know of several engineers | and myself who are willing to put out a very direct RFC that states | exactly why variable addresses 'will' cause a performance loss. it won't cause a measurable performance loss on a non-saturated cpu system. where will it cause a loss? aggregate performance on a server w/ a ton of connections who is not media, or bus bound, but is cpu bound. it's not an end system issue, it's a server issue. again, i'm willing to take the hit. every administrator i know throws tons of $$$ at server metal and would gladly throw more. what they don't want to do is to touch the goddamn clients - it's too expensive. they touch the server everyday and have expertise there, they have idiots at the end systems. | The issue for variable addresses is cost too. Any cost needs to be | justified. No one has justified variable addresses except that it will | let us evolve even past 30 years which 16bytes in fact will support. i don't understand how 16 bytes will allow boeing, who buys macdonald douglas next year to merge their addressing hierarchies when one of them used all 16 bytes. next year, not 30 from now. give me 100% utilization of class a addresses, and i'll give you 30 years on ipv4 when considering the number of general purpose desktop computers around. | IPng will get broken before then for reasons that we don't know that | have nothing to do with the network layer address IMHO because we will | have a technology paradigm shift on routers, networking, or operating | systems. If this happens all the cost to implement variable addresses | would have been un-necessary. the cost of implementing variable length addressing relative to all of the new baggage which will come w/ ipng (rotuing protocols, server- less and serverful configuration, dns autoregistration, etc...) is again trivial. i'll freely write reference code and slap it in an rfc. this is bogus. the real cost is in education of administration, addressing, router configuration, etc.. educating the network administrators, or anyone that needs to know anything abt the address is where the cost is. the implementors are all smart enough to implement varlen addresses. most college sophomores are. | All the successful protocols of past SNA, DECnet, IPX, and yes IPv4 have | all been fixed length address. One protocol in the market is variable | length and its not successful for whatever the reason is and I know its | not because of CLNP, but its not successful, at least today. bullshit, no one ever said "thank god my network layer addresses are fixed". not implementors, not users, not administrators. it saved a tiny bit on the implementation side, a fair amount on the education side (e.g., an ip address looks like a.b.c.d), but that's abt it. hell, ask 100 ipx network administrators how long an ipx address is, 98 will say "duh". the reason ipx succeeded was because they didn't know, not because they did and they liked that they were fixed. ipv4 is screwed because people beyond implementors or core operational geeks know what the address looks like. hey, let's focus on fixing that. now *there's* a carrot for ipng. it's not like we're promising better performance with this thing. | Also mine, Steve Deering, Paul Franics and others have a strong desire | for Fixed Length addresses unless 16bytes are not enough. Some even | still believe 8 bytes are enough. i believe that i will have a network which will require 1 byte addresses. i don't want the overhead of 15 unecessary bytes on a link that supports 512 byte datagrams. that reduces my throughput by 3% between two end systems which aren't close to cpu bound, but are totally network bound. why can't i use smaller addresses on a flat, non-routed topology? i think 16 bytes are too many for most situations. | If some want to change their vote from 16 is OK to ONLY Variable I | guess its fair. But if another argument comes about again next Monday | will I come back from vacation and see its now 23.5 bytes fixed or | variable with SIPP extended addresses. We need to make a decision and | stick with it. the fixed-width "consensus" announced at the retreat surprised me, and i'm questioning it. i agree that we need a decision and we need to stick with it. i see both sides, but i know which implementation covers both requirements - variable. unfortunately, it doesn't cover your concern abt end-systemn performance. do you agree with the following statement: "variable length addresses the *needs* of the ipng community with the side affect of minor performance penalty" we can debate what "minor" is. i want to be clear that this is your only gripe. |Or we are going to look very foolish and not say | anything except we could not reach consensus on the Directorate. This | will be old news cause either could the IETF before the Directorate. | And we would have wasted a year of our life, our companies money, and | the IETFs time. agreed. we need to put a stick in the sand. | My understanding of 16bytes fixed is that was the compromise to reach a | decision and bascially SIPP did not win but SIPP has more momentum and can | be used as spring board to move forward with a compromise. This is how you | make product decisions that work and are successful or a business decision. i still dont know where 16 fixed came from. i left chicago thinking that everyone agreed var length based on 4 byte granularity was it, to a max of 56 bytes. what i then saw was a ton of big-i yammering and backpeddling from the people who sketched the header. i didn't see consensus, just more volume to the fixed/var debate. not a notable shift in position by anyone. | If 16bytes will not work then I for one will support variable addresses | as I cannot be part of any idea for fixed >16byte addresses. i think that's a great compromise :) | I do not think any single mail message on 1 day should change the | Directorates present strategy or we are in big trouble. But if it did | then let it be. But I hope this is not the case. The counter argument | is that we should not continue to incur costs for IPng until the time | when a feature is needed. And will be as eloquently stated as J's mail | as an opposing position if necessary. i've been repeating myself on this topic for sometime and hold true to my position. i don't understand the history behind the fixed 16 "strategy" which scott and allison communicated for the first time in boston, and didn't and still don't agree with it. i can see it now: "encapsulating 16-byte fixed-length ipng addresses in nsaps by peter ford" wait until people like boeing vote with their $$$ and build clnp infrastructures to get the routing and they need and tunneling of ipng because they want a unified infrastructure and hate fixed length addresses. now *that's* a performance hit. you'd be amazed at what kind of network performance corporations will sacrifice to obtain something they deem managable. listen to eric. he runs a real network that's built on your software. under most circumstances, i'd say, don't listen to me, i'll build and sell what eric tells me to sell... i'd say don't listen to tony, he'll do the same. unfortunately, both tony and i have dealt with our share of erics, and our share of boeings, and know that his position is not unique and will defend it. we're in this game to sell software, my employer invests in the ipng effort in hopes that it will produce an architecture that will meet our customers needs and reduce our ultimate costs. i personally don't give two hoots abt fixed vs. variable. if my customers tell me 16-fixed is fine, i'll shutup. they're not. so, me and tony can fix it ourselves independent of the effort, or the directorate can take our feedback. this is not a threat, it's a reality. we do what our customers tell us to do. we try to base few of our decisions on "what should be good for 30 years" when our source of revenue suggests differently, with or without proof. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From jallard@microsoft.com Tue Jul 5 20:34:40 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA22441 for ; Tue, 5 Jul 1994 23:41:25 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA13586; Tue, 5 Jul 94 19:43:05 -0700 Message-Id: <9407060243.AA13586@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 05 Jul 94 19:43:05 PDT X-Msmail-Message-Id: 0F2772A6 X-Msmail-Conversation-Id: 0F2772A6 From: "James 'J' Allard" To: ericf@atc.boeing.com, ipng-request@cmf.nrl.navy.mil Date: Tue, 5 Jul 94 20:34:40 TZ Subject: Re: Concern Cc: bound@zk3.dec.com, ipng@radegond.cmf.nrl.navy.mil | First performance hits on variable addresses are not a 'crock'. it's not a crock, it's a non issue. 50 instructions on the send path is trivial given the horsepower of existing and future cpus. really, how many instructions is it if you fastpath 16-bytes and do the check. bet it's less than 50. | It could be a 'wash' if we go and fix other areas of the IP stack. the fact that you haven't optimized all of the areas of your implementation suggest a bogus argument. we've tuned the shit out of ours, we can't cut out 50 instructions. it's not a wash, its more instructions. i don't care though, it's worth it. i recommend you clean up what you can, and if you save 50 great, if you save 500, better, but it has nothing to do with the argument (other than to suggest a bogus argument since you didn't clean up your performance before this discussion came up. performance must not be **that** important). | I talked to Scott this weekend and told him I know of several engineers | and myself who are willing to put out a very direct RFC that states | exactly why variable addresses 'will' cause a performance loss. it won't cause a measurable performance loss on a non-saturated cpu system. where will it cause a loss? aggregate performance on a server w/ a ton of connections who is not media, or bus bound, but is cpu bound. it's not an end system issue, it's a server issue. again, i'm willing to take the hit. every administrator i know throws tons of $$$ at server metal and would gladly throw more. what they don't want to do is to touch the goddamn clients - it's too expensive. they touch the server everyday and have expertise there, they have idiots at the end systems. | The issue for variable addresses is cost too. Any cost needs to be | justified. No one has justified variable addresses except that it will | let us evolve even past 30 years which 16bytes in fact will support. i don't understand how 16 bytes will allow boeing, who buys macdonald douglas next year to merge their addressing hierarchies when one of them used all 16 bytes. next year, not 30 from now. give me 100% utilization of class a addresses, and i'll give you 30 years on ipv4 when considering the number of general purpose desktop computers around. | IPng will get broken before then for reasons that we don't know that | have nothing to do with the network layer address IMHO because we will | have a technology paradigm shift on routers, networking, or operating | systems. If this happens all the cost to implement variable addresses | would have been un-necessary. the cost of implementing variable length addressing relative to all of the new baggage which will come w/ ipng (rotuing protocols, server- less and serverful configuration, dns autoregistration, etc...) is again trivial. i'll freely write reference code and slap it in an rfc. this is bogus. the real cost is in education of administration, addressing, router configuration, etc.. educating the network administrators, or anyone that needs to know anything abt the address is where the cost is. the implementors are all smart enough to implement varlen addresses. most college sophomores are. | All the successful protocols of past SNA, DECnet, IPX, and yes IPv4 have | all been fixed length address. One protocol in the market is variable | length and its not successful for whatever the reason is and I know its | not because of CLNP, but its not successful, at least today. bullshit, no one ever said "thank god my network layer addresses are fixed". not implementors, not users, not administrators. it saved a tiny bit on the implementation side, a fair amount on the education side (e.g., an ip address looks like a.b.c.d), but that's abt it. hell, ask 100 ipx network administrators how long an ipx address is, 98 will say "duh". the reason ipx succeeded was because they didn't know, not because they did and they liked that they were fixed. ipv4 is screwed because people beyond implementors or core operational geeks know what the address looks like. hey, let's focus on fixing that. now *there's* a carrot for ipng. it's not like we're promising better performance with this thing. | Also mine, Steve Deering, Paul Franics and others have a strong desire | for Fixed Length addresses unless 16bytes are not enough. Some even | still believe 8 bytes are enough. i believe that i will have a network which will require 1 byte addresses. i don't want the overhead of 15 unecessary bytes on a link that supports 512 byte datagrams. that reduces my throughput by 3% between two end systems which aren't close to cpu bound, but are totally network bound. why can't i use smaller addresses on a flat, non-routed topology? i think 16 bytes are too many for most situations. | If some want to change their vote from 16 is OK to ONLY Variable I | guess its fair. But if another argument comes about again next Monday | will I come back from vacation and see its now 23.5 bytes fixed or | variable with SIPP extended addresses. We need to make a decision and | stick with it. the fixed-width "consensus" announced at the retreat surprised me, and i'm questioning it. i agree that we need a decision and we need to stick with it. i see both sides, but i know which implementation covers both requirements - variable. unfortunately, it doesn't cover your concern abt end-systemn performance. do you agree with the following statement: "variable length addresses the *needs* of the ipng community with the side affect of minor performance penalty" we can debate what "minor" is. i want to be clear that this is your only gripe. |Or we are going to look very foolish and not say | anything except we could not reach consensus on the Directorate. This | will be old news cause either could the IETF before the Directorate. | And we would have wasted a year of our life, our companies money, and | the IETFs time. agreed. we need to put a stick in the sand. | My understanding of 16bytes fixed is that was the compromise to reach a | decision and bascially SIPP did not win but SIPP has more momentum and can | be used as spring board to move forward with a compromise. This is how you | make product decisions that work and are successful or a business decision. i still dont know where 16 fixed came from. i left chicago thinking that everyone agreed var length based on 4 byte granularity was it, to a max of 56 bytes. what i then saw was a ton of big-i yammering and backpeddling from the people who sketched the header. i didn't see consensus, just more volume to the fixed/var debate. not a notable shift in position by anyone. | If 16bytes will not work then I for one will support variable addresses | as I cannot be part of any idea for fixed >16byte addresses. i think that's a great compromise :) | I do not think any single mail message on 1 day should change the | Directorates present strategy or we are in big trouble. But if it did | then let it be. But I hope this is not the case. The counter argument | is that we should not continue to incur costs for IPng until the time | when a feature is needed. And will be as eloquently stated as J's mail | as an opposing position if necessary. i've been repeating myself on this topic for sometime and hold true to my position. i don't understand the history behind the fixed 16 "strategy" which scott and allison communicated for the first time in boston, and didn't and still don't agree with it. i can see it now: "encapsulating 16-byte fixed-length ipng addresses in nsaps by peter ford" wait until people like boeing vote with their $$$ and build clnp infrastructures to get the routing and they need and tunneling of ipng because they want a unified infrastructure and hate fixed length addresses. now *that's* a performance hit. you'd be amazed at what kind of network performance corporations will sacrifice to obtain something they deem managable. listen to eric. he runs a real network that's built on your software. under most circumstances, i'd say, don't listen to me, i'll build and sell what eric tells me to sell... i'd say don't listen to tony, he'll do the same. unfortunately, both tony and i have dealt with our share of erics, and our share of boeings, and know that his position is not unique and will defend it. we're in this game to sell software, my employer invests in the ipng effort in hopes that it will produce an architecture that will meet our customers needs and reduce our ultimate costs. i personally don't give two hoots abt fixed vs. variable. if my customers tell me 16-fixed is fine, i'll shutup. they're not. so, me and tony can fix it ourselves independent of the effort, or the directorate can take our feedback. this is not a threat, it's a reality. we do what our customers tell us to do. we try to base few of our decisions on "what should be good for 30 years" when our source of revenue suggests differently, with or without proof. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From Greg_Minshall@Novell.COM Tue Jul 5 07:56:40 1994 Replied: Tue, 12 Jul 94 01:56:14 -0400 Replied: "Greg Minshall " Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA17059 for ; Tue, 5 Jul 1994 11:01:28 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA26881; Tue, 5 Jul 94 09:00:38 MDT Received: from [130.57.64.146] by WC.Novell.COM (4.1/SMI-4.1) id AA16368; Tue, 5 Jul 94 07:56:41 PDT Date: Tue, 5 Jul 94 07:56:40 PDT Message-Id: <9407051456.AA16368@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Allison J Mankin From: Greg Minshall Subject: Re: IPng Outline from Scott and Allison Cc: ipng@radegond.cmf.nrl.navy.mil Allison and Scott, (On the other hand, the danger of Steve and Bob continuing to lead the IPng group is that *they*, and the community, may get the wrong message; so, yes, it is a problem.) Note that even if this is not an issue, the *question* will be an issue: is this a team, or a World Wrestling Federation lineup? > o - a new IPng-specific transition working group be formed > base document - provided by IPNG wg based on SST I agree with Brian that this is either TACIT, or there should be some explicit reason why not. It is possible that adding Bob G. (or Erik N.?) to the TACIT chair-ship would make sense. > o - a new EID working group be formed > using results of BOF in Toronto Again, like Brian, i (biased as i am) feel that EID is still "out there". I think the IPng directors/directorate would be doing "good" to say this "in no uncertain terms". > o - an IPng Architect be named (Dave Clark) > job description: asking the exhaustive > questions, connecting all the points, > offering the broadest perspective, > but not making* architectural decisions, > that is the work of the wgs and the ietf. Good. > o - specific efforts be undertaken to establish an IPng security > framework as the standard practice > authentication header is very important > default case encryption is very important Where is the key distribution mechanism? I *agree* that this is important. However, i'm not sure how much content there is to the statement you are making (given how far we are away from a fully functioning system). Something that says "here's approximately what is going to plug in to make a real security system, and here are the facilities in IPng to facilitate a real security system" (or, here's where the facilities in IPng will be, and the task at hand is to firm up what and where). > o - IPng address allocation procedures be described in > a document at the earliest possible time > participation from the IAB and IESG > led by IEPG? > first distribution of 10% IPng address space > to regional authorities be within this year OK. The main objection i have to your entire outline is that, to me, Toronto is the convergence of all the tributaries into one river. But, we still have to break all the way through to the ocean. Remember my list of warts? There is still a lot of work to be done. Now, at least, we are all pursuing that work within one river. I said the other day "3 years". Maybe i'm being a bit pessimistic, but i doubt very. I think that if the sense "it's in the can, and just needs the final edit" is given, we are making a mistake. I think, basically, that the thrust of the decision is that we've decided on the *culture* of IPng (header format, address format[s]). Now, we need to figure out the details (i think all the questions of TTL, max packet size, etc., are going to come up again, NOW within the context of IPng; i'm not *wild* about this idea, but i think it is just going to happen). So, i think you need to, in the presentation, make vague guesses about when we will be at various stages of the project (first cut spec, first prototypes, last cut spec, "ship code", prevalence of code in the installed base, etc.). And, you need to tie your projections into the ALE numbers, so we (and the world!) can see the new oxygen will arrive before, or after, the old stuff has totally run out. *If* there is an initial allocation, it should be clearly defined to be for prototyping, experimentation, and interoperation activities only. > o - existing working groups not forced to shut down > what we said at start of process I agree with Brian. CATNIP and SIPP should be excused, with thanks. TUBA is no longer of the IPng area, but certainly has a role as "how to make the CLNP internet better". Penultimately, i think you need to lay out, in some detail, how IPng impacts other areas of the IETF. When and where is the RIPng going to happen? OSPFng? Should mobile-ip stop and refocus on IPng? Finally, there needs to be *some* discussion of APIs, in particular sockets (i think if someone "does" sockets, Winsock, being already better organized, will just fall out). You need to take a position, clarity ("I dreamed i saw Ray Noorda last night, in charge as you and me; says i, but Ray, what should we decide? Clarity, says he, clarity, says he..." - i always have odd dreams on the e. coast). Greg From rcallon@pobox.wellfleet.com Tue Jul 5 11:10:24 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (lobster.wellfleet.com [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA17259 for ; Tue, 5 Jul 1994 11:15:42 -0400 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA15218; Tue, 5 Jul 94 11:12:55 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA26531; Tue, 5 Jul 94 11:10:24 EDT Date: Tue, 5 Jul 94 11:10:24 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9407051510.AA26531@pobox.wellfleet> To: ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Subject: Re: so far Ross is out of town & I managed to forget Lixia & Rob the 1st time, Lixia fought through the slight but since Rob's mail was bouncing this will be the 1st time he sees this. Scott Peter suggested that we do a straw poll of the directorate about 16 byte fixed length addresses being acceptable for IPng (in the context of the revised SIPP proposal and ones own understanding of the 'real world' both technical and political.) That seems like a good idea so here it is too much ok should be variable Ross Callon X Well I am back now (although a bit buried until Thursday with other things). I think that 16 byte fixed length addresses are fine. Ross From ericf@atc.boeing.com Tue Jul 5 08:21:28 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA17285 for ; Tue, 5 Jul 1994 11:19:23 -0400 Received: by atc.boeing.com (5.57) id AA24694; Tue, 5 Jul 94 08:21:28 -0700 Date: Tue, 5 Jul 94 08:21:28 -0700 From: Eric Fleischman Message-Id: <9407051521.AA24694@atc.boeing.com> To: ipng@radegond.cmf.nrl.navy.mil, mankin@cmf.nrl.navy.mil Subject: Re: Mail to Each WG List Dear Allison and Scott, I am concerned about your proposed posting about address length. This has already been debated on the lists to which you intend to send your message. What I expect to see if you send this query is the strong, outspoken ravings of a small minority with an occasional put from others. It is my belief that the TECHNICAL input on this topic has already been expressed. All this new query will accomplish is to restart the "Goebels 'if you shout anything long enough they will believe it'" type of rantings of which I for one have grown quite weary. Certainly I don't expect to post anything since I have already said my piece. Ditto for many, many others. Thus, if you wish to illicet technical imput from this query then it has already happened. If you wish to illicet a rough feeling of consensus then it has already happened. Thus, all you can expect to achieve is to reopen the topic to minority ranters. --Eric Fleischman From ericf@atc.boeing.com Tue Jul 5 08:38:07 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA17396 for ; Tue, 5 Jul 1994 11:36:30 -0400 Received: by atc.boeing.com (5.57) id AA26352; Tue, 5 Jul 94 08:38:07 -0700 Date: Tue, 5 Jul 94 08:38:07 -0700 From: Eric Fleischman Message-Id: <9407051538.AA26352@atc.boeing.com> To: bound@zk3.dec.com, jcurran@nic.near.net Subject: Re: RFC 1627 : Issues about RFC 1597 Cc: Bob.Hinden@eng.sun.com, dcrocker@Mordor.Stanford.EDU, ipng@cmf.nrl.navy.mil, peter@goshawk.lanl.gov, yakov@watson.ibm.com >use of IP addresses by folks who think that they "know better". If the >IETF formally tries to eliminate "private" network addressing, then industry >will respond in force. Dear John, I confess that I am a bit murky in my thinking today (probably too many fireworks last night). However, I don't understand what you meant when you said that "industry will respond in force". What I think we have been seeing is that Industry wants local addresses for IPv4 for a variety of reasons. What the RFC does is to begin to constrain which network numbers are used for that purpose so that we hopefully will eventually have fewer instances of Company X using Company Y's addresses as their local addresses. Regardless of what the anti-local address segment of our community wants, Industry will continue to use local addresses to satisfy their itches which those who "know better" have not been able to satisfy. However, what does "force" have to do with it? There is nothing the IETF can really do to stop Industry from addressing their private nets as they see fit -- unless and until those nets are connected to the Internet and only then within those networks which are known to "the outside world". --Eric From bound@zk3.dec.com Tue Jul 5 11:46:29 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA17503 for ; Tue, 5 Jul 1994 11:53:16 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA06179; Tue, 5 Jul 94 08:46:48 -0700 Received: by xirtlu.zk3.dec.com; id AA27939; Tue, 5 Jul 1994 11:46:35 -0400 Message-Id: <9407051546.AA27939@xirtlu.zk3.dec.com> To: Eric Fleischman Cc: ipng@radegond.cmf.nrl.navy.mil, mankin@cmf.nrl.navy.mil Subject: Re: Mail to Each WG List In-Reply-To: Your message of "Tue, 05 Jul 94 08:21:28 PDT." <9407051521.AA24694@atc.boeing.com> Date: Tue, 05 Jul 94 11:46:29 -0400 X-Mts: smtp Allison and Scott, >Thus, if you wish to illicet technical imput from this query then it has >already happened. If you wish to illicet a rough feeling of consensus >then it has already happened. Thus, all you can expect to achieve is to >reopen the topic to minority ranters. In the bowels of my stomach this past weekend I have to say I agree with Eric. Sorry but I really really do. I think this has been discussed. /jim From ericf@atc.boeing.com Tue Jul 5 08:56:32 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA17517 for ; Tue, 5 Jul 1994 11:54:32 -0400 Received: by atc.boeing.com (5.57) id AA28716; Tue, 5 Jul 94 08:56:32 -0700 Date: Tue, 5 Jul 94 08:56:32 -0700 From: Eric Fleischman Message-Id: <9407051556.AA28716@atc.boeing.com> To: bound@zk3.dec.com, yakov@watson.ibm.com Subject: Re: one size fits all (fwd) Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu >We have hands on folks willing to discuss this openly on SIPP list. These >are people who have done more code with IPng than anyother WG in the >IETF. Dear Jim, I think that your comment above was probably written in haste. I doubt if you really meant to say that SIPP WG did more IPng code than the TUBA WG. If so, then I must express surprise. It has been my impression that BOTH WGs had done extensive amounts of implementation of their specs. It is not clear at all to me which WG has done MORE work on code, but it is clear to me which WG LIST has had the better discussions the past half a year (or longer; i.e., SIPP), which was the key point you were making. I understand what you are saying about the imporance of learning practical lessons by hands-on coding and experimentation. However, I also am concerned that IPng must be solved on many dimensions as per Yakov's comments. We really need all of our communities to come to a consensus, and this implies including the architects within the consensus too. I state this because no IPng WG is likely to do experimentation with a large enough body to find the type of problems which seem to constantly bite us as we try to deploy technologies like this. As Dave Crocker has been wont to say: it is scale which worries me. On the other hand, if we permit your function to operate then my function is saved all kinds of grief. Key point: we're all in this together. Bottom line: I am very grateful for your excellent work on IPng and don't want you to be hindered. Thank you for your efforts. Sincerely yours, --Eric Fleischman From Bob.Hinden@Eng.Sun.COM Tue Jul 5 09:03:36 1994 Return-Path: Bob.Hinden@Eng.Sun.COM Received: from Sun.COM (Sun.COM [192.9.9.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA17570 for ; Tue, 5 Jul 1994 12:05:18 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA12339; Tue, 5 Jul 94 09:03:41 PDT Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1/SMI-4.1) id AA00394; Tue, 5 Jul 94 09:04:31 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA24412; Tue, 5 Jul 1994 09:03:36 -0700 Date: Tue, 5 Jul 1994 09:03:36 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9407051603.AA24412@jurassic.Eng.Sun.COM> To: Eric Fleischman Cc: bound@zk3.dec.com, jcurran@nic.near.net, Bob.Hinden@Eng.Sun.COM, dcrocker@Mordor.Stanford.EDU, ipng@cmf.nrl.navy.mil, peter@goshawk.lanl.gov, yakov@watson.ibm.com In-Reply-To: <9407051538.AA26352@atc.boeing.com> Subject: Re: RFC 1627 : Issues about RFC 1597 Eric, > Regardless of what the anti-local address segment of our community wants, > Industry will continue to use local addresses to satisfy their itches which > those who "know better" have not been able to satisfy. However, what does > "force" have to do with it? There is nothing the IETF can really do to stop > Industry from addressing their private nets as they see fit -- unless and > until those nets are connected to the Internet and only then within those > networks which are known to "the outside world". Some parts of industry have discovered the hard way that while local use addresses are easier to obtain in the short term, when organizations change/merger/etc it can become extremely expensive to renumber a large organization. To me this is a short term vs. long term issue. The good news here is that I think IPng will provide automatic generation of local and global addresses (via embedded MAC addresses and global prefix discovery) that will make this an non-issue in the future. This should go in the "carrot" column for IPng. Bob From iesg-request@ietf.cnri.reston.va.us Tue Jul 5 12:43:40 1994 Return-Path: iesg-request@ietf.cnri.reston.va.us Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA18068 for ; Tue, 5 Jul 1994 12:50:10 -0400 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05111; 5 Jul 94 12:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05107; 5 Jul 94 12:49 EDT Received: from inet-gw-3.pa.dec.com by CNRI.Reston.VA.US id aa13425; 5 Jul 94 12:49 EDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA10278; Tue, 5 Jul 94 09:44:02 -0700 Received: by xirtlu.zk3.dec.com; id AA28964; Tue, 5 Jul 1994 12:43:46 -0400 Message-Id: <9407051643.AA28964@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: Allison J Mankin , iesg@CNRI.Reston.VA.US, ipng@radegond.cmf.nrl.navy.mil Subject: Re: IPng Outline from Scott and Allison In-Reply-To: Your message of "Tue, 05 Jul 94 08:26:28 +0200." <9407050626.AA01850@dxcoms.cern.ch> Date: Tue, 05 Jul 94 12:43:40 -0400 Sender: iesg-request@IETF.CNRI.Reston.VA.US From: bound@zk3.dec.com X-Mts: smtp => => o - a new IPng-specific transition working group be formed => base document - provided by IPNG wg based on SST >This is TACIT, right? I think this is a good idea. Asking Bob Gilligan to be part of this as another co-chair with Atul and Geoff would be a good idea IMHO. => o - a new EID working group be formed => using results of BOF in Toronto >Unclear to me. Do you mean that EIDs are part of IPng? From everything >I have seen, I concluded that they are a research topic. As one who has been beating this into the ground I agree with Brian that consensus seems to be EIDs are not defined and really a research topic. Hence, I give in and accept this Directorate consensus. But on both the SIPP and Big-I lists this has been a discussion where most seem to want to move forward with EIDs from my reading. The issues are: - It changes the essential IP network layer model (EIDs and Locators). - Internet scalability would be very hard to verify with present data. - Unclear what / how Multicast is used (by me anyway). - Unknown affect to anyones Transition strategy for 'paying customers' or the 'Internet' who will migrate to IPng. - It could delay the start of building product-integrated (as opposed to just prototypes, which also could be delayed) implementations for IPng. There will be a BOF on this at Toronto and a draft shortly for discussion fyi, which is separate from NIMROD. => o - specific efforts be undertaken to facilitate the creation of => transition plans from other environments, including IPX => and CLNP. => (where the addresses are globally unique and allocated => along the lines of network topology) >Too vague. I can't sell this in Europe. I *need* NSAPA embedding as >a specifc goal or up-front option. This is still not part of the formal list of IPng requirements, but clearly a real world requirement. But it should not be done at the cost of making IPng less than it could be technically or architecturally. For IPX it fits well in 16bytes for NSAPs its not as easy and we need an algorithmic mapping for 16bytes that spans different NSAP uses today. This also could be opening up pandoras box, with the only real answer encapsulaltion within IPng. I also think a clear defined statement of what convergence means is required (or transition): - Does this mean my host must now look at a format bit to determine if I received a packet other than IPv4 or IPng? Or just that hosts that want to receive non-IETF defined packets 'MAY' do so if they want to? One of the caveats when my company decided to pay the expenses and let me work full time on IPng and with the IETF was that if the IETF selected more than one protocol for IPng I would have to walk away from the Directorate. I don't think that is happening but I also don't want to see that happen indirectly either, not only for my company for all compaines that build IPv4 and soon IPng products. If 'paying customers' (as opposed to standards bodies, agencies, or whoever) want us to transition their other network protocols to IPng (besides IPv4) I am sure we will do it. - Is this only for the routing hierarchy so non-IETF defined packets can be used on the Internet? I think a strategy that supports non-IETF protocols to traverse and use the Internet is a prudent design objective for IPng. But, I am unclear by what means to reach that objective and what are the requirements. This would be a lot of work to figure out and we must ask ourselves should it hold up making some basic technical decisions about IPng so implementors can start building running code for IPng that is at least in wet-conrete form for the header and address. => => o - existing working groups not forced to shut down => what we said at start of process >Fudge. SIPP and CATNIP have no reasom to continue. Either TUBA should >shut down, or should be renamed TUNA (TCP and UDP over NSAP >Addresses) and viewed as a coexistence tool to leverage Internet >applications over CLNP infrastructure. Most of the basic TUBA work >matches this approach very well. The less developed parts of TUBA >(flows, multicast,...) could be moved to "historic" status. If you >don't want to encourage this, close it down. I think all working groups today should go away and there be just one IPng set of working groups. Regarding TUBA continuing to work on CLNP for the Internet with IPng (and IPv4 for that matter) should happen, but not under the auspices of IPng. Many of us believe that if CLNP is not the IPng selection then any major changes to the CLNP packet needs to be analyzed very closely for market reasons. There has been a significant investment in CLNP without a significant return on investment. Leaving TUBA as part of IPng could send the wrong message to the market and to non-IETF standards bodies. This is a critical decision for IPng and the IESG. => => We think that there is general consensus about a 16 byte fixed length => hierarchical, autoconfigurable address. Will probe community. => If consensus not demonstrated then recommend a BOF in Toronto => to address the issue - Dave Clark as BOF chair >I agree there is consensus that this is necessary. Is there consensus that >it is sufficient? I don't think so, certainly not in the Directorate. But no one on the Directorate or in the IETF has proven that 16bytes are not sufficient for 30 years of product generations and the Internet. The majority of Directorate members have stated OK to 16bytes. /jim From ericf@atc.boeing.com Tue Jul 5 09:43:46 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA18001 for ; Tue, 5 Jul 1994 12:41:43 -0400 Received: by atc.boeing.com (5.57) id AA04983; Tue, 5 Jul 94 09:43:46 -0700 Date: Tue, 5 Jul 94 09:43:46 -0700 From: Eric Fleischman Message-Id: <9407051643.AA04983@atc.boeing.com> To: ipng@radegond.cmf.nrl.navy.mil, mankin@cmf.nrl.navy.mil Subject: Re: Directorate update Dear Scott and Allison, I spent a great deal of time on my initial review which I submitted within the pre-Big 10 timeframe as requested. Of course, I have modified my perspective with new info since then, but not significantly. I don't have time to update my review. So I want my initial review to stand with the original date. Thanks much. --Eric Fleischman From mankin@cmf.nrl.navy.mil Tue Jul 5 13:22:03 1994 Return-Path: mankin@cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id NAA18383 for ; Tue, 5 Jul 1994 13:22:06 -0400 Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id NAA12803 for ipng; Tue, 5 Jul 1994 13:22:03 -0400 Date: Tue, 5 Jul 1994 13:22:03 -0400 From: Allison J Mankin Message-Id: <199407051722.NAA12803@radegond.cmf.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil Subject: AGAIN, about responding to the OUTLINE Be aware and only send to the IESG cc if you want to include the IESG in your comments in realtime Allison From bound@zk3.dec.com Tue Jul 5 13:42:24 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA18595 for ; Tue, 5 Jul 1994 13:52:54 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA14672; Tue, 5 Jul 94 10:42:45 -0700 Received: by xirtlu.zk3.dec.com; id AA29998; Tue, 5 Jul 1994 13:42:30 -0400 Message-Id: <9407051742.AA29998@xirtlu.zk3.dec.com> To: Eric Fleischman Cc: bound@zk3.dec.com, yakov@watson.ibm.com, Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Subject: Re: one size fits all (fwd) In-Reply-To: Your message of "Tue, 05 Jul 94 08:56:32 PDT." <9407051556.AA28716@atc.boeing.com> Date: Tue, 05 Jul 94 13:42:24 -0400 X-Mts: smtp Eric, My comment assumed most working on CLNP have just used existing OSI stacks as in our case DECnet/OSI. All we did was add a transport interface, alter the sockets structures, and fake out an API for Telnet and FTP (which we just stopped). Core parts of IPng using CLNP are in a very infant stage to even begin investing in changing the lower layers of TUBA based on the state of IPng we feel will change from IPv4 whether TUBA had been selected or not such as: - Multicast - Autoconfiguration (doing more than OSI does toay) - Encapsulation (no clear specs from TUBA on how to do this) - APIs (no API defined but we built one anyway) - Flow ID affect on the host kernel. - Path MTU affect on the host kernel. - Checksum removal at the network layer. - New Internet Fragmentation / Reassembly Model. - BIND Autoregistration (I know its nto a requirement but important) - Source Routing affect on the host. With SIPP we have really experimented with a new model for IPng and it required a lot more code to do those experiements. I agree with you it states nothing for scalability, but has taught us a great deal about many of the core IPng hot buttons such as new address format, source routing, autoconfiguration, systems discovery, transition, and interfacing to the applications environment. TUBA has not produced the kinds of specifications or mail list discussions to foster a 'can do' implementation momentum at least in our work. We essentially built the DNS records and tested against the NIST Telnet implementation, we have had to do much more testing with SIPP. Telnet with TUBA just proves its possible to accept an IPng packet into an application, and for me thats not enough. The momentum of the working group did not cause us to do more. Also we never saw a response to Radia Perlmans request for an answer or to Peter Fords memo about taking over CLNP in the IETF and knowing we actually had to change CLNP as is today. I would say from our historical perspective we lost a bit of faith at that point in time. Much of this is because of the assumption that because an OSI stack exists that means TUBA would be easier to build. This is wrong and what folks need to understand. If you recall my Host internet draft with all the parts on a Host IPng will affect its quite staggering. Those parts need tecHnical investigation at the host kernel level (a very difficult and complex place to do software engineering) and having an OSI stack does not alleviate much of that burden, unless you believe that the Internet and customers can completely transition with a dual stack without any API updates, encapsulation, performance enhancements in the kernel to name just a few. SIPP has caused us as engineers to re-ivestigate the IPv4 model and architecture in host kernels. TUBA has not done that simply because it was not really discussed and too many assumptions were made about the existing OSI stack. I can't give you an exact reason other than what I stated, but this is not just me but my team. I hope this clarifies the comment as it was not stated to belittle or to offend any efforts by TUBA. I agree with you about the need for cosensus with the architects. But architecture needs to be tested before final decisions to build products are made or failure could be a real possiblility for the products you will get at Boeing as an example. The way I have been approaching this work is to actually look at the code for the existing architecture and then project the ideas for a new architecture into a Host paradigm. This has been predominantly a BSD paradigm but we are looking at DOS, Linix, BSDi-Net/2, VMS, OSF/1, SunOS, NT, Mach, and UNIX Microkernel work too. We have several source pools for IPng not just OSF/1 which is our predominant OS advanced development OS. SIPP host kernel public domain code is also more abundant too. Don't get me wrong we put a good 4 man months of code into to TUBA it was just more extensive for SIPP who had a lot more specs to work with and mail list technical discussion to cause the creative juices to flow in us as engineers to keep investigating IPng ideas for a host. We even built a SIPP route cache analyzer based on some concerns John Curran has about ICMP messages and shutting them off if necessary and what the affect could be (John - talk to Alex Conta about this ICMP issue in Toronto if you get a chance). For SIPP we have build a protocol engine. Yes we have an OSI protocol engine, but not one for IPng. The TUBA effort for some reason did not entice the work to build a CLNP-Protocol engine for IPng. The sad part is that we have now stopped all prototype work and are taking this breather to review the specs more closely and continue to learn the affect of changing the host paradigm for IPng and the code base points of transition to a very fine level of granularity. I also have been semi-successful to set up a firewall based on our IP product for SIPP for Internet testing. I also understand you need to go to a high level to get things started architecturally and not hang out at the bits and bytes. For what its worth I was and am doing this with EIDs and Locators and using my colleagues as a logic check peroidically. I will add I felt I got beat to death on the Directorate about EIDs mostly because of the detail issues, being who I am and where I am coming from I have no problem with this and was not personally offended. I am glad you appreciate my work it has been and will continue to be a lot of work. I also think you should know that 'all' your mail (and Brian's) was carefully read by any engineer working on this prototype to help us keep a reality check on the work and also to stimulate us to think like folks who are really going to use this stuff to name just two reasons we have read yours and Brian's mail as part of our development strategy. FYI ... I now have our Internal network folks who manage our very large IP network looking at IPng as operators. They have all ready told me they want 'security' and BIND 'autoregistration' at our end. Above I mentioned the word Team. I view us (Directorate) as a Team. The only time I will never go along with any team is if they ask me to stuff too much feces in my throat for political reasons. I can only do that in very small chunks. So far we have not had to deal with it hardly at all, which is good and I appreciate Scott and Allison trying to keep it at a minimum. I fear this convergence issue and consensus at present could change that but I hope not. I hope we do the right technical thing for IPv4 and IPng first and then worry about the rest of the world is my bias. But I will support the Teams technical strategy and input where I can. I hope this helps you understand better my previous mail and why I said what I did. /jim From iesg-request@ietf.cnri.reston.va.us Tue Jul 5 13:52:15 1994 Return-Path: iesg-request@ietf.cnri.reston.va.us Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA18589 for ; Tue, 5 Jul 1994 13:52:41 -0400 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05911; 5 Jul 94 13:52 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05907; 5 Jul 94 13:51 EDT Received: from watson.ibm.com by CNRI.Reston.VA.US id aa15133; 5 Jul 94 13:51 EDT Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3181; Tue, 05 Jul 94 13:52:15 EDT Date: Tue, 5 Jul 94 13:52:15 EDT Sender: iesg-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com To: bound@zk3.dec.com cc: ipng@radegond.cmf.nrl.navy.mil, iesg@CNRI.Reston.VA.US Subject: IPng outline... Message-ID: <9407051351.aa15133@CNRI.Reston.VA.US> Jim, >The majority of Directorate members have stated OK to 16 bytes. Two questions: 1. Did they state OK to 16 bytes unicast addresses (provided that there is no distiction between "locator" and EID), or 16 bytes multicast addresses, or 16 bytes cluster addresses, or all of the above ? 2. Did they state OK to 16 bytes unicast "locators", if there would be a distinction between "locators" and EIDs ? Yakov. From bound@zk3.dec.com Tue Jul 5 14:35:30 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA19118 for ; Tue, 5 Jul 1994 14:52:32 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA18533; Tue, 5 Jul 94 11:35:54 -0700 Received: by xirtlu.zk3.dec.com; id AA01631; Tue, 5 Jul 1994 14:35:37 -0400 Message-Id: <9407051835.AA01631@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: bound@zk3.dec.com, ipng@radegond.cmf.nrl.navy.mil, iesg@cnri.reston.va.us Subject: Re: IPng outline... In-Reply-To: Your message of "Tue, 05 Jul 94 13:52:15 EDT." <199407051752.NAA18586@picard.cmf.nrl.navy.mil> Date: Tue, 05 Jul 94 14:35:30 -0400 X-Mts: smtp Yakov, Scott and Allison can send you the proposed question which did not have anything about EIDs and Locators in them. My reading is that I am the only Directorate member that thought EIDs and Locators should be part of the IPng decision, which means taking the risks and changing the present IP routing model. I give up being that kind of minority, to the wisdom of my colleagues, who have articulated well that this work is in research mode and is even hard to discuss technically, or to understand the scalability using such a paradigm on the Internet. If we had decided to use EIDs and Locators for IPng now there is no way IPng could be at a point in Toronto to state to the world we are ready to begin implementing IPng. It does cause a technical hick-up and a new variable to be figured out in the IPng equation. This may not be acceptable to the IETF or the market. I don't have an answer to that question. I will say if we don't have some answers at Toronto the implementors are going to walk away from IPng for the time being and I think is not good at all. We will loose the momentum of the implementors from CATNIP, TUBA, and SIPP. The implementors should leave Toronto from a single focused IPng Working Group with at least a header spec and address to tweek their code base. Having TUBA, SIPP, and CATNIP meet in Toronto individaully is using up at least 15 man hours where all the brains could be in the same IPng working group. But the logistics and admin work to figure this out now would be horrific and probably cause a nervous breakdown for those trying to organize this. /jim From craig@aland.bbn.com Tue Jul 5 14:09:59 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA20958 for ; Tue, 5 Jul 1994 17:10:29 -0400 Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA01801 for ipng@cmf.nrl.navy.mil; Tue, 5 Jul 94 17:10:10 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id OAA02041; Tue, 5 Jul 1994 14:10:01 -0700 Message-Id: <199407052110.OAA02041@aland.bbn.com> To: bound@zk3.dec.com Cc: craig@aland.bbn.com, kasten@ftp.com, ipng@cmf.nrl.navy.mil Subject: Re: IPng Reqs : Ack Issue (CORRECTED DIST LIST) In-Reply-To: Your message of Sun, 03 Jul 94 09:27:50 -0400. <9407031327.AA25664@xirtlu.zk3.dec.com> From: Craig Partridge Date: Tue, 05 Jul 94 14:09:59 -0700 Sender: craig@aland.bbn.com Hi Jim: I apologize for the acknowledgements goof. I'll take full responsibility since I was the last person to read the draft. We just failed to update the ACKs from earlier drafts. It was absolutely an error. Frank and I try very hard to give credit where credit is due and certainly the directorate deserves plenty of it. There's time to fix this before the draft becomes an RFC and we will. (In fact, we might consider issuing a slightly revised draft in the next week or so -- we apparently bungled in some of our attempts to answer Ran Atkinson's concerns about security -- this now gives us two goofs to fix). Frank -- do you have a few hours in the next two weeks? (I'm actually in my office for two consecutive weeks this month -- first time since April and it may not happen again until November). Craig PS: I don't believe in the old boy stuff -- good folks deserve credit regardless of when they join the net. From ericf@atc.boeing.com Tue Jul 5 14:13:35 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA20971 for ; Tue, 5 Jul 1994 17:11:29 -0400 Received: by atc.boeing.com (5.57) id AA17626; Tue, 5 Jul 94 14:13:35 -0700 Date: Tue, 5 Jul 94 14:13:35 -0700 From: Eric Fleischman Message-Id: <9407052113.AA17626@atc.boeing.com> To: ipng@radegond.cmf.nrl.navy.mil Subject: Concern Cc: ericf Dear Scott and Allison, I feel very much "out of the loop" and poorly informed partially due to my missing the retreat. However, This feeling has been heightened by recent Directorate member statements which surprised me greatly, particularly Steve Bellovin's very strong comments effectively "demanding" variable length addressing, Brian Carpenter's many recent comments about NSAP- mapping requirements for IPng and a desire for variable length extensions to the addresses, and J Allard's comments below. In each case the strength of their statements took me by surprise and made me think that my own fondness for variable length addressing was perhaps THE consensus position of the IPng Directorate after all and thus are still a viable possibility to recommend for our community as a whole. I was also surprised to read things in your recent proposed recommendations which made me think that you are recommending "SIPP as defined with 16 byte Addresses is our selection" rather than the SIPP-*based* solution which had technical elements from the other WGs which I would have prefered. Also, you have now apparently bound SST into your decision when you had consistently stated that transition was to be decoupled from the IPng selection. Needless to say, all this makes me feel VERY uncomfortable. I suspect that other Directorate members may be feeling somewhat similarly and thus would be grateful if we could all discuss this more fully at the next Teleconference. In any case, I very much want Steve Bellovin's, Brian Carpenter's and ESPECIALLY J Allard's comments below to be addressed by the IPng Directorate. In my mind, it seems to me that you have received STRONG PUSH-BACK against your proposed recommendations by these three individuals. Furthermore, I find strong resonance within myself for important aspects their arguments. Certainly, I wish to publically state that I fully support Brian Carpenter's two statements regarding the requirement for NSAPA mappings and the need for variable length extensions to the 16 byte addresses. I believe that the consensus position within the IPng Directorate is in favor of variable length addresses. I suggest a new poll be conducted to verify this statement and that your decision be ammended to reflect our actual consensus position. Let's poll the following text: "Do you favor an IPng addressing approach which defines an initial fixed-length 16 byte address deployment within a variable length addressing schema. The maximum address size shall be 32 bytes long with 8 byte address granularities." I realize that you must expeditiously make a decision. However, I urge you to please not make a decision until these Directorate members' concerns have been adequately addressed. I am particularly concerned that J Allard's comments are diametrically opposed to what I thought the end-system vendor perspective on fixed-vs-variable length addresses was. After all, the ES vendors are the ONLY community which did not PREFER variable length addresses (that I am aware of, at least). If the arguments which we have heard from them are bogus (as J Allard seems to imply) then this indeed is of the upmost importance for your ultimate decision. Or perhaps maybe J has not considered the viewpoint of the "intelligent adapter" makers? In any case, I am concerned that J's posting is at such variance from his community's viewpoint. At the very least it makes me conclude that your IPng Outline currently has less internal IPng Directorate support than I would have expected. Sincerely yours, --Eric Fleischman >From: "James 'J' Allard" >To: ipng@radegond.cmf.nrl.navy.mil, ipng-request@cmf.nrl.navy.mil >Subject: RE: IPng Outline from Scott and Allison ... >that said, i can't possibly see why we'd recommend something that >40% of the engineers believe "might" fail. although 16 bytes >seems like enough to most of us right now, the performance >argument is a crock. the tcp checksum is 3x the size of our send >path in our stack. who cares abt a 10% overhead in header >processing when it's only 25% of the common path? processor >power is climbing through the roof. the biggest counter argument >has been that multimedia apps need more bandwidth. yes, this >is true. however, looking at mosaic on a 386/20 machine, we can >cpu-saturate the system easily. the split? 85% mosaic, 15% >tcp. what does that say? that the app itself is too cpu intensive >to make the transport utilization an issue. if we doubled the >performance of the transport, the app wouldn't be able to >process it... > >i urge the directorate to recommend variable length addresses, >profiled for 16 bytes today with an escape hatch tomorrow. we >can all fastpath the 16 byte case for now. From bound@zk3.dec.com Tue Jul 5 18:05:29 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA21301 for ; Tue, 5 Jul 1994 18:17:13 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA28683; Tue, 5 Jul 94 15:05:57 -0700 Received: by xirtlu.zk3.dec.com; id AA06805; Tue, 5 Jul 1994 18:05:35 -0400 Message-Id: <9407052205.AA06805@xirtlu.zk3.dec.com> To: Craig Partridge Cc: bound@zk3.dec.com, kasten@ftp.com, ipng@cmf.nrl.navy.mil Subject: Re: IPng Reqs : Ack Issue (CORRECTED DIST LIST) In-Reply-To: Your message of "Tue, 05 Jul 94 14:09:59 PDT." <199407052110.OAA02041@aland.bbn.com> Date: Tue, 05 Jul 94 18:05:29 -0400 X-Mts: smtp Craig, Thanks. That was a very hard msg for me to hit the send key on as I do have respect for you and Frank as folks who seem to have a good perspective and did a good job on the IPng requirements. Sorry about the good ole boy stuff that was emotion from other stuff in the IETF that has nothing to do with this work and I am sorry now I let it get the better of me in that mail. I am really looking forward to taking vacation and just not seeing mail for awhile. I had no idea how much mail went on in the IETF and how much reading it takes to keep up with all of it. Two engineers where I work told me I should teach an internal seminar regarding my strategy to keep up with IPng mail lists and other work too. I told them you just give up your hobbies, devote your life to the company and the IETF, and stay single or have a very understanding family. Its not that bad but with in that proximity. Another reason I think we need an IPng decision is that folks cannot keep up this pace, we need a milestone reached to restore our faith and to recharge our energy cells that we are moving forward. take care and thanks again, /jim From bound@zk3.dec.com Tue Jul 5 18:40:47 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA21594 for ; Tue, 5 Jul 1994 19:02:58 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA00176; Tue, 5 Jul 94 15:41:06 -0700 Received: by xirtlu.zk3.dec.com; id AA07175; Tue, 5 Jul 1994 18:40:53 -0400 Message-Id: <9407052240.AA07175@xirtlu.zk3.dec.com> To: Eric Fleischman Cc: ipng@radegond.cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: Concern In-Reply-To: Your message of "Tue, 05 Jul 94 14:13:35 PDT." <9407052113.AA17626@atc.boeing.com> Date: Tue, 05 Jul 94 18:40:47 -0400 X-Mts: smtp Eric, Well I was not going to respond to J's mail but I guess I have to now. First performance hits on variable addresses are not a 'crock'. It could be a 'wash' if we go and fix other areas of the IP stack. I talked to Scott this weekend and told him I know of several engineers and myself who are willing to put out a very direct RFC that states exactly why variable addresses 'will' cause a performance loss. This document will do nothing to help consensus and its better it not be done for right now. OK I agree. The issue for variable addresses is cost too. Any cost needs to be justified. No one has justified variable addresses except that it will let us evolve even past 30 years which 16bytes in fact will support. IPng will get broken before then for reasons that we don't know that have nothing to do with the network layer address IMHO because we will have a technology paradigm shift on routers, networking, or operating systems. If this happens all the cost to implement variable addresses would have been un-necessary. This argument is as valid as stating that variable addresses will take us into the future of Deep Space Nine and 16bytes won't. No 16bytes will not last for infinity and we cannot probably identify the asymtope its limit will approach, but many of us believe it will last us 30 years which is OK for a networking protocol. All the successful protocols of past SNA, DECnet, IPX, and yes IPv4 have all been fixed length address. One protocol in the market is variable length and its not successful for whatever the reason is and I know its not because of CLNP, but its not successful, at least today. Also CLNP is really 20bytes fixed in any set of requirements and its variable within the 20 bytes. So even its authors used a bounded strategy for CLNP for real implementations. Also mine, Steve Deering, Paul Franics and others have a strong desire for Fixed Length addresses unless 16bytes are not enough. Some even still believe 8 bytes are enough. If some want to change their vote from 16 is OK to ONLY Variable I guess its fair. But if another argument comes about again next Monday will I come back from vacation and see its now 23.5 bytes fixed or variable with SIPP extended addresses. We need to make a decision and stick with it. Or we are going to look very foolish and not say anything except we could not reach consensus on the Directorate. This will be old news cause either could the IETF before the Directorate. And we would have wasted a year of our life, our companies money, and the IETFs time. My understanding of 16bytes fixed is that was the compromise to reach a decision and bascially SIPP did not win but SIPP has more momentum and can be used as spring board to move forward with a compromise. This is how you make product decisions that work and are successful or a business decision. Now to make it politically correct we will call this new effort the IPng Working Group. This is what I thought was going down and I also think it will work. If 16bytes will not work then I for one will support variable addresses as I cannot be part of any idea for fixed >16byte addresses. I was trying to come up with a better compromise before the Chicago retreat. That was fixed length 8byte identifiers and variable length routing sequence mabye as a source route. Yes I believe 8bytes is plenty to do autoconfiguration and provide globally unique addresses for any private network and the Internet. Plus it will work very well for Mobile and Renumbering addresses in sites as that seems to be a general concern. And yes it can be supported by DNS too. on and on and on. But that will break other stuff right and needs much more work. I do not think any single mail message on 1 day should change the Directorates present strategy or we are in big trouble. But if it did then let it be. But I hope this is not the case. The counter argument is that we should not continue to incur costs for IPng until the time when a feature is needed. And will be as eloquently stated as J's mail as an opposing position if necessary. /jim From iesg-request@ietf.cnri.reston.va.us Wed Jul 6 00:04:09 1994 Return-Path: iesg-request@ietf.cnri.reston.va.us Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA22584 for ; Wed, 6 Jul 1994 00:08:02 -0400 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20261; 6 Jul 94 0:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20257; 6 Jul 94 0:03 EDT Received: from aads.com by CNRI.Reston.VA.US id aa10411; 6 Jul 94 0:03 EDT Received: from localhost (mak@localhost) by aads.net (8.6.5/aads1.1) id AAA08595; Wed, 6 Jul 1994 00:04:10 -0400 Sender: iesg-request@IETF.CNRI.Reston.VA.US From: Mark Knopper Message-Id: <199407060404.AAA08595@aads.net> Subject: Re: IPng Outline from Scott and Allison To: Allison J Mankin Date: Wed, 6 Jul 1994 00:04:09 -0400 (EDT) Cc: iesg@CNRI.Reston.VA.US, ipng@radegond.cmf.nrl.navy.mil In-Reply-To: <199407050425.AAA11896@radegond.cmf.nrl.navy.mil> from "Allison J Mankin" at Jul 5, 94 00:25:13 am Reply-To: mak@aads.net X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4099 I would like to see what the reactions were to the Big Ten protocol draft that has been circulated on this list, before we say that we are starting from the SIPP spec. I understand this is being released as an Internet Draft this week. I was not able to attend the second Ipng retreat but I am still confused about what happened to eliminate the consensus that we had rather strongly at the Big Ten meeting. I am not sure that I see how there is consensus on the 16 byte fixed length address. The "poll" among the IPng directorate was close to 50/50. J. Allard's note pretty much expressed my view on this. The process outlined here is very good, creating an IPng working group to further develop and refine the single IPng protocol. Presumably the major open issues list will appear on the charter of this working group? Mark > > For your review, as we discussed, an outline of the > current state of the Toronto recommendations on IPng > > ------- > A Direction for IPNG (Outline) > > IPng ADs will recommend that: > > o - a new IPng working group be formed > short-term milestones for the proposed standards for IPng > (by next IETF) > major points to resolve in last bullet below > IPng BOF meeting twice in Toronto > > o - the working group take as its base documents > the forthcoming SIPP draft ( SIPP with 16 byte addresses) > SST outline > > o - all references to SIPP (other than in acknowledgment sections) > replaced by IPng > > o - a new IPng-specific transition working group be formed > base document - provided by IPNG wg based on SST > > o - a new IPng autoconfiguration working group be formed > base document - draft from Sue Thompson & Dave Katz > > o - a new EID working group be formed > using results of BOF in Toronto > > o - an IPng Architect be named (Dave Clark) > job description: asking the exhaustive > questions, connecting all the points, > offering the broadest perspective, > but not making* architectural decisions, > that is the work of the wgs and the ietf. > > o - specific efforts be undertaken to establish an IPng security > framework as the standard practice > authentication header is very important > default case encryption is very important > > o - IPng address allocation procedures be described in > a document at the earliest possible time > participation from the IAB and IESG > led by IEPG? > first distribution of 10% IPng address space > to regional authorities be within this year > > o - specific efforts be undertaken to facilitate the creation of > transition plans from other environments, including IPX > and CLNP. > (where the addresses are globally unique and allocated > along the lines of network topology) > > o - existing working groups not forced to shut down > what we said at start of process > > We think that there is general consensus about a 16 byte fixed length > hierarchical, autoconfigurable address. Will probe community. > If consensus not demonstrated then recommend a BOF in Toronto > to address the issue - Dave Clark as BOF chair > > Major open issues specific to IPng > address format > routing structure > source route design > where, element content and length > source route syntax and mechanisms > end system identifier extensibility > > From brian@dxcoms.cern.ch Wed Jul 6 08:05:34 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA22946 for ; Wed, 6 Jul 1994 02:06:08 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA20684; Wed, 6 Jul 1994 08:05:36 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28845; Wed, 6 Jul 1994 08:05:35 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407060605.AA28845@dxcoms.cern.ch> Subject: what Greg was saying... To: ipng@cmf.nrl.navy.mil Date: Wed, 6 Jul 1994 08:05:34 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1378 Directorate, Isn't this what Greg was trying to get at in Boston? I.E. why having both 0:0 and 0:1 prefixes is broken? Brian >--------- Text sent by William Allen Simpson follows: > From sipp-request@sunroof2.eng.sun.com Wed Jul 6 03:48:33 1994 > X-Delivered: at request of brian on dxcoms.cern.ch > Date: Wed, 6 Jul 94 01:04:18 GMT > From: "William Allen Simpson" > Message-Id: <2778.bill.simpson@um.cc.umich.edu> > To: sipp@sunroof.eng.sun.com > Reply-To: bsimpson@morningstar.com > Subject: Re: SIPP-only to IPv4-only > Sender: sipp-request@sunroof.eng.sun.com > > > From: Bob.Gilligan@eng.sun.com (Bob Gilligan) > > Consider the following topology: > > > > > > SIPP-only ------ Translator ------ IPv4-only > > host H1 T1 host H2 > > > > <---- <---- > > SIPP Packets IPv4 Packets > > > Stop! > > The IPv4 host cannot talk to a SIPP-only host. There will be no A DNS > records. The IPv4 host won't know the SIPP-only host is there. > > The SIPP-only host cannot talk to an IPv4 host. There will be no > AA/ASeq DNS records. The SIPP-only host won't know the IPv4 host is there. > > A host which understands how to talk to IPv4 has a different TCP > checksum calculation, and therefore is an IPv4 host. > > Why are you making this harder than it already is? > > Bill.Simpson@um.cc.umich.edu > From francis@cactus.slab.ntt.jp Wed Jul 6 08:06:08 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id TAA21610 for ; Tue, 5 Jul 1994 19:10:23 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.4); Wed, 6 Jul 1994 08:06:08 +0900 Received: by slab.ntt.jp (8.6.9/core-slab.s5+) id IAA14736; Wed, 6 Jul 1994 08:06:07 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA27363; Wed, 6 Jul 94 08:06:08 JST Date: Wed, 6 Jul 94 08:06:08 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9407052306.AA27363@cactus.slab.ntt.jp> To: bound@zk3.dec.com, yakov@watson.ibm.com Subject: Re: IPng outline... Cc: iesg@cnri.reston.va.us, ipng@radegond.cmf.nrl.navy.mil > > 1. Did they state OK to 16 bytes unicast addresses (provided that > there is no distiction between "locator" and EID), or 16 bytes > multicast addresses, or 16 bytes cluster addresses, or all of the > above ? > > 2. Did they state OK to 16 bytes unicast "locators", if there would > be a distinction between "locators" and EIDs ? > My "OK" was for a single 16-byte address space where the unicast, multicast, and cluster addresses are all taken from that space, and where the same address space serves both to identify and to locate. PF From iesg-request@ietf.cnri.reston.va.us Wed Jul 6 08:06:08 1994 Return-Path: iesg-request@ietf.cnri.reston.va.us Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA21686 for ; Tue, 5 Jul 1994 19:26:38 -0400 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11299; 5 Jul 94 19:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11295; 5 Jul 94 19:09 EDT Received: from mail.ntt.jp by CNRI.Reston.VA.US id aa05762; 5 Jul 94 19:09 EDT Received: by mail.ntt.jp (8.6.8/COREMAIL.4); Wed, 6 Jul 1994 08:06:08 +0900 Received: by slab.ntt.jp (8.6.9/core-slab.s5+) id IAA14736; Wed, 6 Jul 1994 08:06:07 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA27363; Wed, 6 Jul 94 08:06:08 JST Date: Wed, 6 Jul 94 08:06:08 JST Sender: iesg-request@IETF.CNRI.Reston.VA.US From: Paul Francis Message-Id: <9407052306.AA27363@cactus.slab.ntt.jp> To: bound@zk3.dec.com, yakov@watson.ibm.com Subject: Re: IPng outline... Cc: iesg@CNRI.Reston.VA.US, ipng@radegond.cmf.nrl.navy.mil > > 1. Did they state OK to 16 bytes unicast addresses (provided that > there is no distiction between "locator" and EID), or 16 bytes > multicast addresses, or 16 bytes cluster addresses, or all of the > above ? > > 2. Did they state OK to 16 bytes unicast "locators", if there would > be a distinction between "locators" and EIDs ? > My "OK" was for a single 16-byte address space where the unicast, multicast, and cluster addresses are all taken from that space, and where the same address space serves both to identify and to locate. PF From brian@dxcoms.cern.ch Wed Jul 6 08:11:47 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA22973 for ; Wed, 6 Jul 1994 02:12:20 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22293; Wed, 6 Jul 1994 08:11:48 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28951; Wed, 6 Jul 1994 08:11:47 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407060611.AA28951@dxcoms.cern.ch> Subject: Re: IPng Outline from Scott and Allison To: ipng@cmf.nrl.navy.mil Date: Wed, 6 Jul 1994 08:11:47 +0200 (MET DST) In-Reply-To: <9407051643.AA28964@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jul 5, 94 12:43:40 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2457 Jim, > > => > => o - a new IPng-specific transition working group be formed > => base document - provided by IPNG wg based on SST > > >This is TACIT, right? > > I think this is a good idea. Asking Bob Gilligan to be part of this > as another co-chair with Atul and Geoff would be a good idea IMHO. Well, I will be running a Eurpopean candidate for this. ... > => o - specific efforts be undertaken to facilitate the creation of > => transition plans from other environments, including IPX > => and CLNP. > => (where the addresses are globally unique and allocated > => along the lines of network topology) > > >Too vague. I can't sell this in Europe. I *need* NSAPA embedding as > >a specifc goal or up-front option. > > This is still not part of the formal list of IPng requirements, but > clearly a real world requirement. But it should not be done at the cost > of making IPng less than it could be technically or architecturally. For > IPX it fits well in 16bytes for NSAPs its not as easy and we need an > algorithmic mapping for 16bytes that spans different NSAP uses today. > This also could be opening up pandoras box, with the only real answer > encapsulaltion within IPng. I can only repeat: Too vague. I can't sell this in Europe. I *need* NSAPA embedding as a specifc goal or up-front option. ... > => > => o - existing working groups not forced to shut down > => what we said at start of process > > >Fudge. SIPP and CATNIP have no reasom to continue. Either TUBA should > >shut down, or should be renamed TUNA (TCP and UDP over NSAP > >Addresses) and viewed as a coexistence tool to leverage Internet > >applications over CLNP infrastructure. Most of the basic TUBA work > >matches this approach very well. The less developed parts of TUBA > >(flows, multicast,...) could be moved to "historic" status. If you > >don't want to encourage this, close it down. > > I think all working groups today should go away and there be just one IPng > set of working groups. Regarding TUBA continuing to work on CLNP for the > Internet with IPng (and IPv4 for that matter) should happen, but not under > the auspices of IPng. I agree entirely. That is the reason for changing the name from TUBA. It is just a "TCP and UDP over foo" activity. It doesn't even *have* to be in the IETF. Brian From brian@dxcoms.cern.ch Wed Jul 6 08:14:34 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA22992 for ; Wed, 6 Jul 1994 02:15:08 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22454; Wed, 6 Jul 1994 08:14:35 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28988; Wed, 6 Jul 1994 08:14:34 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407060614.AA28988@dxcoms.cern.ch> Subject: Can you re-post the straw poll result? To: ipng@cmf.nrl.navy.mil Date: Wed, 6 Jul 1994 08:14:34 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 842 Scott and Allison, > => > => We think that there is general consensus about a 16 byte fixed length > => hierarchical, autoconfigurable address. Will probe community. > => If consensus not demonstrated then recommend a BOF in Toronto > => to address the issue - Dave Clark as BOF chair > > >I agree there is consensus that this is necessary. Is there consensus that > >it is sufficient? I don't think so, certainly not in the Directorate. > > But no one on the Directorate or in the IETF has proven that 16bytes are > not sufficient for 30 years of product generations and the Internet. > The majority of Directorate members have stated OK to 16bytes. > > /jim > Can you post the final version of the straw poll results please? (I realise the Directorate doesn't get to vote for the whole IETF :-) Brian From jallard@microsoft.com Wed Jul 6 13:22:36 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA28287 for ; Wed, 6 Jul 1994 16:31:37 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA10139; Wed, 6 Jul 94 12:32:36 -0700 Message-Id: <9407061932.AA10139@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Wed, 06 Jul 94 12:32:35 PDT X-Msmail-Message-Id: 34BE3528 X-Msmail-Conversation-Id: 34BE3528 From: "James 'J' Allard" To: bound@zk3.dec.com Date: Wed, 6 Jul 94 13:22:36 TZ Subject: Re: Concern Cc: ericf@atc.boeing.com, ipng@radegond.cmf.nrl.navy.mil, ipng-request@cmf.nrl.navy.mil | | It could be a 'wash' if we go and fix other areas of the IP stack. | | >the fact that you haven't optimized all of the areas of your | >implementation suggest a bogus argument. we've tuned | | First SLOW DOWN on your assumptions that 'we have not optiimized our IP | implemntation" in fact we have and can saturate an Ethernet or FDDI for | both TCP and UDP. Don't make those kind of public comments to a list | its not cool. my intention was not to attack a specific vendor's implementation and the basis of my statement was your comment "fix other areas of the ip stack". apologies all over the place if this was misinterpreted. | It is an end system issue and I don't agree with your assessment of end | system users or the market (but we know that already). The performance | issue will take place at every network connection on a client or server. | On a server it will be more noticable. we can agree to disagree here i think. yes it's going to burn some cycles on end systems, but considering the instruction count necessary to do anything useful. | This is nonsense. No customer will use all 16bytes if used correctly and | I am not even going to give this argument the courteousy of an answer. | Now this is bogus. i predict that most large networks (e.g., 50,000 systems or more) will use a minimum of 8 in their addressing schemes. you're right, it's not likely that people will use all 16 out of the door, but they'll start with a bunch. today microsoft has 2 class a's, a number of class b's (i think 6) and a ton of class c's. the history reflects the growth of our network. we have only 45,000 nodes, but we've bought other companies, merging existing networks, and have grown our global network a great deal. if you walked through our history with a 16-byte address, we'd probably have started with 6 and been up to about 14 today. given my discussions with is managers from fortune 1000, non-technical corporations, we're not atypical here. | bullshit. You have it all wrong that those protocols were designed by | accident. Better performance is one of my goals, but your right no | promises. i never said that they were designed by accident, i said that real end-users don't care if it's fixed or variable. | Performance is not the issue to stop variable addresses its the cost. Not | just for the kernel but the total cost. There is a cost at the app level | too we have not even analyzed yet. where's the cost at the app? the next version of windows sockets will take a name and turn it into a system handle. the app has zero need to know the network layer address, as it should be. this is the case for real applications. granted ping, traceroute and nslookup will need to know, but they're typically implemented by the xport team anyway. i don't understand why a sql server or x client needs to know the actual network address. don't assume that all technology remains static and we just change the xport address structure, i think we need to make changes to sockets to make ipng a pill people will swallow. | >"variable length addresses the *needs* of the ipng community with the | >side affect of minor performance penalty" | | I would add "and additional costs". I am not sure about the community but | the statement is axiomatic for sure. Its really a question of cost I | think more than performance. what costs specifically? i see none of these as insurmountable, and at most, incremental. we need to educate, we need to write code, and we need to spec this stuff. whether it's fixed or variable is a small, small difference. | ACK on the employer. My customers want good IP in our products. I can do | this with fixed addresses or variable addresses. But I can do it cheaper | with fixed addresses which means it will cost my customer less money. And | it will last for 30 years of product generations. what cost do you customers have to cover? i can't believe that the engineering cost is worth measuring. given all of the changes and work that you'll need to invest in ipng, this can't be a significant burden that your customers are forced to carry. the cost to the customers is really in education, a challenge alltogether not addressed by ipng. | Also above are you alluding to a vendor consortia and who could figure | out an IPng archictecture better than all the bright people together in | the IETF? I hope no cause that would be real bullshit. no, this is not what i am suggestion. what i am saying is that as soon as (hopefully before) a customer runs into the 16-byte wall, i will be forced to hand them a fix. i want to do this as part of the ietf and this is my reason for authoring these painfully long notes detailing my concern for v.l. if we dont have variable length, and a customer (forget real internet addresses, forget on the internet, just big ip network) has a problem with the architecture, we'll fix it and ship it. example: dhcp with dns updates. the ietf and dns groups both told me to screw off 2+ years ago when i suggested that we do dynamic updates to dns as part of dnsv2. given my customers' demand for dhcp, and our vision of peer-networking where every system is some kind of server, this was important. it's not that they aren't very smart people, it's that they didn't want to solve the potential problem and didn't believe that dhcp would be successful or that this would become a real problem. so 1.5 years ago, when i needed to make a decision, we built a dynamic nameserver and we're shipping it with dhcp next month. we'll have dns-compatible query support on top of it before year end. we had to fix it, and couldn't wait since dhcp was useless without it. internally we have ovre 5,000 systems using dhcp and wins. i still want dynamic dns registrations to be supported universally and want winsv2 to be fully dynamic dns compliant, but, i had to react and ship a product that my customers were demanding in the meantime. i'm not suggesting that i'm smarter than anyone, i know that i'm not. i do know that we will build things in reaction to customer demand, and this demand will contrinue to drive our product development process well beyond standards body engineering excercises. funny that you mentioned decnet, sna, and ipx before (omitting appletalk though). these were all protocols that were invented not by standards bodies, but by corporations solving problems that standards bodies didn't have answers to. i suggest the same may be necessary should flat 16 fail in the future. that's all. |Or is this just | the case of wanting to take your ball and go home. And your customers | told you I want variable addresses? no, my customers are all wild-cowboy network administrators that do things based on simplicity and convenience, not the preservation of the worldwide ip addressing scheme. they have all had tons of addressing problems, most of them have run out on subnets, or globally based on poor mask selection, and everyone that's ever merged two networks has probably gone through a number of net engineers and thousands if not millions of dollars fixing these problems. my customers (in general, with some exceptions) are not educated enough to answer this question. i am drawing a probably conclusion given my experiences with them. eric is one of the few "customers" that actually has read ipng documents, under- stands the various architectures and has gone throught the excercise of mapping it into his environment. now if we have a really smart guy that's done a ton of homework saying "i probably need variable addresses someday, although 16-bytes seems like a ton", what conclusion can you draw from the other is shops that don't know what ipng is? 15 years ago, i wrote software on systems with 4k, then 16k of memory for a number of years. i didn't know what a megabyte was, the customers of my software didn't have harddisks, but 140k capacity floppy drives. every instruction counted. today i send this mail from a system with 32mb a 1280x1024 display and 3 gigs of disk (oh btw it's a laptop with a docking station, i use it on airplanes to check my email). if you asked me in a decade why anyone would need a 128Mb system on their desk, a multiprocessor server w/ 10 Gigs of storage for their $10M firm, or a 4million virtual processor machine for some physics research in a 3 star educational facility, i would have laughed. to predict that 30 years from now, we won't run into network merging problems, excessive disposable devices, and incredibly inefficient address assignment blows my mind. i don't want to waste everyone's time, i simply wanted to offer my opinion. no one has to agree with me, no one has to consider it. the market will decide. i'm just offering some insights which i consider everyday in the decisions we make internally with our systems design - and we design with 3 years in mind, not 30... enough said. sorry if my future messages were overly aggressive or suggested an attack on any one or more vendors. trying to just make points, not attacks. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From sob@hsdndev.harvard.edu Wed Jul 6 06:22:42 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id GAA23629 for ; Wed, 6 Jul 1994 06:22:49 -0400 Date: Wed, 6 Jul 94 06:22:42 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407061022.AA09482@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: as requested Peter suggested that we do a straw poll of the directorate about 16 byte fixed length addresses being acceptable for IPng (in the context of the revised SIPP proposal and ones own understanding of the 'real world' both technical and political.) That seems like a good idea so here it is too much ok should be variable J. Allard X Steve Bellovin X Jim Bound X Ross Callon X Brian Carpenter X Add NSAPA option Dave Clark John Curran X X Steve Deering (X) X Dino Farinacci X X Eric Fleischman X X Paul Frances X Mark Knopper X Greg Minshall X X Rob Ullmann Lixia Zhang X add option for var From jallard@microsoft.com Wed Jul 6 18:58:26 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id FAA00999 for ; Thu, 7 Jul 1994 05:33:27 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA03066; Thu, 7 Jul 94 01:35:27 -0700 Message-Id: <9407070835.AA03066@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Thu, 07 Jul 94 01:35:27 PDT X-Msmail-Message-Id: E7BBC750 X-Msmail-Conversation-Id: E7BBC750 From: "James 'J' Allard" To: ipng-request@cmf.nrl.navy.mil Date: Wed, 6 Jul 94 18:58:26 TZ Subject: Re: Concern very good wrap up. i was trying to spark real down and dirty discussion and trying to move beyond the realm of this p.c. position that we've been in. i sincerely apologize if you felt i was attacking you, dec, or anyone else in the directorate. i took a side, you took a side, most everyone else has stayed out. i hoped to see action from those less vocal. imho you have been the most significant contributor in the directorate, with eric running a close second. your perspectives and experience have been very valuable for me, although i fear they have not been adequately represented in the directorate's recommendations. i fear the same for eric. thx for your input and good thoughts. i appreciate your honesty and directness and hold a very high opinion of you and your contributions. thx for a lively and well supported discussion. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" ---------- | From: | To: James 'J' Allard | Cc: ; ; ; | | Subject: Re: Concern | Date: Wednesday, July 06, 1994 9:37PM | | Received: from picard.cmf.nrl.navy.mil by netmail.microsoft.com with SMTP (5.65/25-eef) | id AA24330; Wed, 6 Jul 94 18:48:33 -0700 | Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com | [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with | SMTP id VAA29698 for ; Wed, 6 | Jul 1994 21:43:54 -0400 | Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) | id AA11976; Wed, 6 Jul 94 18:37:21 -0700 | Received: by xirtlu.zk3.dec.com; id AA08879; Wed, 6 Jul 1994 21:37:16 -0400 | Message-Id: <9407070137.AA08879@xirtlu.zk3.dec.com> | In-Reply-To: Your message of "Wed, 06 Jul 94 13:22:36 +0700." | <9407061932.AA10139@netmail2.microsoft.com> | X-Mts: smtp | | Jim, | | All your statements are valid (I mean it). The problem is that we are | coming from completely different technical philosophies to solve this | problem, which causes us to be diametrically opposed. In addition we | are both very technical so no one can say its politics its honest to | goodness differences. I value difference and I hope the Area Directors | and the Directorate read very closely all your mail on this issue I know | it took a lot of time away from other work. I also see your point about | DHCP and Dynamic DNS and how they told you to screw off thats a very | good argument in context for variable addresses, because you were right | on that one for sure. | | The bottom line is I am sitting with Steve Deering, Paul Francis, and | Bob Hinden with my technical beliefs for the most part. I see no point | of further replies to this thread its time to make a decision. I will | build products as you no matter what the decision is for IPng. I am glad | the discussion has turned to variable vs fixed addresses which is better | than this group vs that group. That much is progress IMHO. I won't say | who you may be sitting with in similarities thats for you to say. But I | found the Big-10 Packet format not to my technical 'taste'. I assume that | will be another long technical discussion we will have soon and an important | one. But also Steve, Paul, and Bobs too will need discussion, which I | hope we get soon. | | My final offer of compromise at my end to the Directorate for variable | addresses technically is to support an 8byte fixed length address in the | main header that is globally unique in the Internet and a variable | address source route optional header if the packet has to leave the | private site (private site is dec.com, microsoft.com, etc..). Yes we | would need to set up and define the 8 byte address space for such a | purpose and no I do not ask that it be called an EID. See my mail on | Big-I in a moment regarding source routes in main headers, which I do | not think is a good idea. Source routing should be a second class | citizen. | | This is also my individual position not my companies. As I said I will | build products for IPng in my company no matter what IPng ends up to | be. Which is what we have said all along. But no one is yelling at me | for supporting 16bytes unless someone can show its not enough for 30 | years on the Internet. | | I guess-estimate the cost to move our 3 host kernels to variable | addresses and the re-training to be about $1.5 million. To me this is | significant. This would include the API to insulate the applications as | you suggested, which we mostly have figured out anyway from SIPP | extended addresses. I do admit I am very cost conscious and have always | been as an engineer for the past 20 years. I will also admit the | mistakes I have made was trying to save costs when I should have been | less frugal. But on this one I got to stand pat with the 16bytes with | my caveat of what will change my mind. | | p.s. WOW you have two class A addresses and I felt bad with 1 (we | have 50,000+ hosts and growing daily, plus I just started managing my | own subnet for our IPng Internet testing, I don't find it bad at all but | then again I just look at the code if I don't get it). | | Not offended at my end, | /jim | | | From laylesto@IETF.CNRI.Reston.VA.US Wed Jul 6 10:14:23 1994 Replied: Wed, 06 Jul 94 15:41:41 -0400 Replied: "Lois Keiper " Return-Path: laylesto@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA24810 for ; Wed, 6 Jul 1994 10:14:23 -0400 Date: Wed, 6 Jul 1994 10:14:23 -0400 Received: from [132.151.1.63] by IETF.CNRI.Reston.VA.US id aa03373; 6 Jul 94 10:12 EDT X-Sender: laylesto@ietf.cnri.reston.va.us Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@cmf.nrl.navy.mil From: Lois Keiper MMDF-Warning: Parse error in original version of preceding line at IETF.CNRI.Reston.VA.US Subject: Re: Ipng Teleconference July 11, 1994 Message-ID: <9407061012.aa03373@IETF.CNRI.Reston.VA.US> >>ANNOUNCEMENT: > >> >>The names marked with an asterisk are those who have confirmed participation >>for the IPng teleconference scheduled for July 11, 1994 at 11:30 - 1:30 >>EDT. Thank you. >> >> >> >> >> J. Allard 206-936-9031 >> Steve Bellovin 908-582-5886 >> Jim Bound 603-881-0400 >> Scott Bradner 617-495-3864 >> Ross Callon 508-436-3936 > Brian Carpenter +41 22 767 4967 >> Dave Clark 617-253-6003 > John Crowcroft +44 71 380 7296 >> Steve Coya 703-620-8990* >> John Curran 617-873-4398 >> Steve Deering 415-812-4839 >> Dino Farinacci 408-668-4696 >> Eric Fleischman 206-957-5334 >> Paul Francis +81 33 928 0408 > Frank Kastenholz 508-685-4000 >> Daniel Karrenberg +31 20 592 5065 >> Mark Knopper 313-741-5445 > Craig Partridge 415-812-4415 >> Allison Mankin 202-404-7030 >> Greg Minshall 510-975-4507 > Rob Ullmann 617-693-1315 >> Lixia Zhang 415-812-4415 >> >> >>If you need to be added to the teleconference call in progress, please call >>1-800-232-1234 or for the international participants, 516-424-3151. The call >>can be referenced by the confirmation number -ER21499 in the orginators name, >>Steve Coya. >> >>Thanks >> >> >>Lois >> >> >> > >Lois J. Keiper >IETF Secretariat Lois J. Keiper IETF Secretariat From ericf@atc.boeing.com Wed Jul 6 08:27:26 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA25463 for ; Wed, 6 Jul 1994 11:25:29 -0400 Received: by atc.boeing.com (5.57) id AA17049; Wed, 6 Jul 94 08:27:26 -0700 Date: Wed, 6 Jul 94 08:27:26 -0700 From: Eric Fleischman Message-Id: <9407061527.AA17049@atc.boeing.com> To: bound@zk3.dec.com, ericf@atc.boeing.com Subject: Re: Concern Cc: ipng@radegond.cmf.nrl.navy.mil Dear Jim, Thank you for your response. It is somewhat of a comfort to find that you at least are not vacillating on your positions. Would you please do me the favor of addressing for this list what you think of the following question?: "Do you favor an IPng addressing approach which defines an initial fixed-length 16 byte address deployment within a variable length addressing schema. The maximum address size shall be 32 bytes long with 8 byte address granularities." Would this approach preserve the undesirable variable length tenets against which you and other host vendors have been arguing or would it appear to your software as something resembling fixed length addresses? Question to the directorate: what do you think would happen if we define an address structure such as that described above but suggest to the host vendors that they may consider it as simply a fixed length 16 byte address and to the router vendors to treat it as a variable length address? This way, should it be needed we have a clear migration direction with a possible router-based supporting infrastructure. This, after all, is much like what was done within CLNP and seems to me to be a viable alternative. Sincerely yours, --Eric Fleischman From brian@dxcoms.cern.ch Wed Jul 6 18:27:16 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA25977 for ; Wed, 6 Jul 1994 12:27:51 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18347; Wed, 6 Jul 1994 18:27:18 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA17177; Wed, 6 Jul 1994 18:27:17 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407061627.AA17177@dxcoms.cern.ch> Subject: Re: Concern To: ipng@cmf.nrl.navy.mil Date: Wed, 6 Jul 1994 18:27:16 +0200 (MET DST) In-Reply-To: <9407061527.AA17049@atc.boeing.com> from "Eric Fleischman" at Jul 6, 94 08:27:26 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1566 Eric > "Do you favor an IPng addressing approach which defines an initial > fixed-length 16 byte address deployment within a variable length > addressing schema. The maximum address size shall be 32 bytes long > with 8 byte address granularities." > You didn't ask all of us, but I'd certainly accept this as long as there is an NSAPA encoding defined. (At this point I'd probably accept anything to end the debate :-) > Question to the directorate: what do you think would happen if we define > an address structure such as that described above but suggest to the > host vendors that they may consider it as simply a fixed length 16 byte > address and to the router vendors to treat it as a variable length address? > This way, should it be needed we have a clear migration direction with a > possible router-based supporting infrastructure. This, after all, is much > like what was done within CLNP and seems to me to be a viable alternative. > The trouble with this approach is that if initial IPng hosts are deployed only with 16-byte support, moving to larger addresses is in effect moving to IPngng. It would be a second transition. So it's theoretically OK, but practically meaningless, I fear. My SAF/OAF suggestion (16 byte mandatory, NSAPA optional) has the same problem, but with some chance that the option would be implemented up-front by some vendors. However, my general sense is that if we do decide for variable length, it has to be there from the start. If it is an add-on it will never actually get added on. Brian From lixia@parc.xerox.com Wed Jul 6 09:47:42 1994 Replied: Wed, 06 Jul 94 13:40:46 -0400 Replied: "Lixia Zhang " Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA26082 for ; Wed, 6 Jul 1994 12:48:50 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14623(3)>; Wed, 6 Jul 1994 09:47:53 PDT Received: by redwing.parc.xerox.com id <57153>; Wed, 6 Jul 1994 09:47:45 -0700 Date: Wed, 6 Jul 1994 09:47:42 PDT Sender: Lixia Zhang From: Lixia Zhang To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil Subject: Re: Big10 notes revisited In-Reply-To: Your message of Fri, 1 Jul 1994 12:15:13 -0700 Message-ID: > here is a pass of editing the big 10 notes to reflect the comments > I've received. Can you all take a quick look? We would like to > get these out soon. sorry for the delay. below are a few corrections > Lixia Xhang, xerox Lixia Zhang, Xerox PARC > ... > Lixia: Authentication and accounting at network level. Research > has not been done yet, but need is coming for these functions. Cost of > dual stack transition with TUBA is problem. Cost of TUBA's dual-stack ONLY transition plan is problematic; BOTH dual-stack and translations are needed. In addition, CATNIP has no transition plan, no routing design, and is not sufficiently specified to be evaluated. > ...... > Transport identifier which is not tied to the network layer: consensus > position. I do not recall that we reached such a consensus. > Lixia: Like separate group looking at EID issue, but we may > have different visions on where it may go. Would like to see single > IPng group finalizing protocol. Do not think variable length address > buys us anything. Growth to the right assumption is not valid. The > smaller your address is, the larger amount of address space you > reserve. Lixia: Support Ron A.'s suggestion of setting up a separate working group to look at EID issue, though we may have different visions on where it may go. Would like to see a single IPng group finalizing protocol. Do not think variable length address buys us anything if it only grows to the right, in which case the smaller your address is, the larger amount of address space you have consumed. > ..... > % (Eric Fleischmann). What additional functionality is brought with > each proposal. Too much additional risk over IPv4. Provider based > addressing is flawed and a bad thing. I don't recall exactly what Eric said, but if the above is correct, I'd like some elaboration regarding comments on provider based addressing. A final comment: I know nobody has time to do it, but how much I wish someone could combine the 3 notes into one single minutes! Lixia From lixia@parc.xerox.com Wed Jul 6 10:45:11 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA26593 for ; Wed, 6 Jul 1994 13:46:19 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14603(5)>; Wed, 6 Jul 1994 10:45:27 PDT Received: by redwing.parc.xerox.com id <57153>; Wed, 6 Jul 1994 10:45:19 -0700 Date: Wed, 6 Jul 1994 10:45:11 PDT Sender: Lixia Zhang From: Lixia Zhang To: Allison J Mankin Cc: ipng@radegond.cmf.nrl.navy.mil Subject: Re: Mail to Each WG List In-Reply-To: Your message of Sun, 3 Jul 1994 12:16:32 -0700 Message-ID: > ----------------- > > To: big-internet, tuba, sipp, catnip, ietf > Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements a few comments about this proposed msg > There seems to be a stronger, but still minority, view that, for various > reasons, a variable length address, one that could be smaller or larger > than 16 bytes, would meet the needs better for the future of the > Internet. as I said in an earlier msg, the question about addr length should not be asked or answered separately from the overall IPng consideration. There is a (brobably long) list of open issues regarding the impact of variable length addr on other parts of IPng (e.g. relation to EID?) 16-fixed byte addr is an extension to current IPv4 architecture, the game I think we confidently know how to play. Variable addr is probably NOT, as Deering repeatedly stated (that it'd be no longer SIPP if you put in var addr) > Much of the discussion on the lists has revolved around the relative > efficiency of processing fixed and variable length addresses. We would > like to assess the consensus just on lengths for the future. We want to > make sure that we have understood consensus on meeting the needs > of the very very large Internet. Therefore, this message is to > ask people what present or future rationale they see for one of: > 16 byte fixed length address > longer than 16 byte fixed length address now > longer than 16 byte fixed length address next time we change > anything > 8 byte fixed length address. > > We hope to guage, in particular, what, if any, the consensus > is about the routing power, topological flexibility and manageability > of the length of the address. > If the purpose here is to collect concensus, why not list variable length as a bullet too? > At this point the consensus on the big-internet list seems quite > clear. This is a good time to bring forward remaining issues > about the IPng address length requirements. Of course, we also > welcome messages that support our perceived consensus. I agree with Eric's comment that probably everyone who wants to say someting on the issue has done so. But if you want to use this msg as a way to inform/pre-warn the community about your recommendations, it may be worth doing, so that whoever want to shout again can do it now (instead of being shocked by your announcement at Toronto). But then I feel the wording need be changed per my above comments. Lixia From bound@zk3.dec.com Wed Jul 6 15:10:09 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA27596 for ; Wed, 6 Jul 1994 15:21:10 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA11808; Wed, 6 Jul 94 12:10:28 -0700 Received: by xirtlu.zk3.dec.com; id AA01634; Wed, 6 Jul 1994 15:10:15 -0400 Message-Id: <9407061910.AA01634@xirtlu.zk3.dec.com> To: "James 'J' Allard" Cc: ericf@atc.boeing.com, ipng-request@cmf.nrl.navy.mil, bound@zk3.dec.com, ipng@radegond.cmf.nrl.navy.mil Subject: Re: Concern In-Reply-To: Your message of "Tue, 05 Jul 94 20:34:40 +0700." <9407060243.AA13586@netmail2.microsoft.com> Date: Wed, 06 Jul 94 15:10:09 -0400 X-Mts: smtp | First performance hits on variable addresses are not a 'crock'. >it's not a crock, it's a non issue. 50 instructions on the send path is >trivial given the horsepower of existing and future cpus. really, how >many instructions is it if you fastpath 16-bytes and do the check. >bet it's less than 50. It is less than 50 based on two compilers. But thats not the performance hit. Its the searches in the cache, pcb's, and the ifnet data structures which are now all variable. I never stated it was an order of magnitude performance loss based on instructions even if not in the fast path. | It could be a 'wash' if we go and fix other areas of the IP stack. >the fact that you haven't optimized all of the areas of your >implementation suggest a bogus argument. we've tuned the shit >out of ours, we can't cut out 50 instructions. it's not a wash, its >more instructions. i don't care though, it's worth it. i recommend >you clean up what you can, and if you save 50 great, if you save >500, better, but it has nothing to do with the argument (other than >to suggest a bogus argument since you didn't clean up your >performance before this discussion came up. performance >must not be **that** important). First SLOW DOWN on your assumptions that 'we have not optiimized our IP implemntation" in fact we have and can saturate an Ethernet or FDDI for both TCP and UDP. Don't make those kind of public comments to a list its not cool. I said nothing about my implementation yet. And my arguments are not bogus and our performance is fine. Your way out of line here and I suggest you use a different tact for discussion. There are many public domain concepts for TCP/IP that are useful to all of us to generate code as we generate IETF specs for IP such as VJs work. I was refernecing for example the way searches are done and that they could be done more efficiently for IP in the Open Systems sense. Of course if you want to roll your own go for it. But, just changing the way searches are done in the public domain of IP would make up for any loss with variable addresses and it would be a wash. | I talked to Scott this weekend and told him I know of several engineers | and myself who are willing to put out a very direct RFC that states | exactly why variable addresses 'will' cause a performance loss. >it won't cause a measurable performance loss on a non-saturated >cpu system. where will it cause a loss? aggregate performance on >a server w/ a ton of connections who is not media, or bus bound, >but is cpu bound. it's not an end system issue, it's a server issue. >again, i'm willing to take the hit. every administrator i know throws >tons of $$$ at server metal and would gladly throw more. what they >don't want to do is to touch the goddamn clients - it's too expensive. >they touch the server everyday and have expertise there, they >have idiots at the end systems. It is an end system issue and I don't agree with your assessment of end system users or the market (but we know that already). The performance issue will take place at every network connection on a client or server. On a server it will be more noticable. | The issue for variable addresses is cost too. Any cost needs to be | justified. No one has justified variable addresses except that it will | let us evolve even past 30 years which 16bytes in fact will support. >i don't understand how 16 bytes will allow boeing, who buys >macdonald douglas next year to merge their addressing >hierarchies when one of them used all 16 bytes. next year, >not 30 from now. give me 100% utilization of class a addresses, >and i'll give you 30 years on ipv4 when considering the number >of general purpose desktop computers around. This is nonsense. No customer will use all 16bytes if used correctly and I am not even going to give this argument the courteousy of an answer. Now this is bogus. | IPng will get broken before then for reasons that we don't know that | have nothing to do with the network layer address IMHO because we will | have a technology paradigm shift on routers, networking, or operating | systems. If this happens all the cost to implement variable addresses | would have been un-necessary. >the cost of implementing variable length addressing relative to all of >the new baggage which will come w/ ipng (rotuing protocols, server- >less and serverful configuration, dns autoregistration, etc...) is again >trivial. i'll freely write reference code and slap it in an rfc. this is >bogus. the real cost is in education of administration, addressing, >router configuration, etc.. educating the network administrators, or >anyone that needs to know anything abt the address is where the >cost is. the implementors are all smart enough to implement >varlen addresses. most college sophomores are. Relative is an important word and has variance when used. I said any cost needs to be justified. I agree with you on the edu and admin costs and add transition to that education. As far as your comments about the implementors no one stated they could not do it that I have heard. I am not sure what your point was here and I think your comment about college sophmores is bullshit. | All the successful protocols of past SNA, DECnet, IPX, and yes IPv4 have | all been fixed length address. One protocol in the market is variable | length and its not successful for whatever the reason is and I know its | not because of CLNP, but its not successful, at least today. >bullshit, no one ever said "thank god my network layer addresses are >fixed". not implementors, not users, not administrators. it saved a tiny >bit on the implementation side, a fair amount on the education side >(e.g., an ip address looks like a.b.c.d), but that's abt it. hell, ask 100 >ipx network administrators how long an ipx address is, 98 will say >"duh". the reason ipx succeeded was because they didn't know, not >because they did and they liked that they were fixed. ipv4 is screwed >because people beyond implementors or core operational geeks >know what the address looks like. hey, let's focus on fixing that. now >*there's* a carrot for ipng. it's not like we're promising better performance >with this thing. bullshit. You have it all wrong that those protocols were designed by accident. Better performance is one of my goals, but your right no promises. | Also mine, Steve Deering, Paul Franics and others have a strong desire | for Fixed Length addresses unless 16bytes are not enough. Some even | still believe 8 bytes are enough. >i believe that i will have a network which will require 1 byte addresses. i >don't want the overhead of 15 unecessary bytes on a link that supports >512 byte datagrams. that reduces my throughput by 3% between two >end systems which aren't close to cpu bound, but are totally network >bound. why can't i use smaller addresses on a flat, non-routed >topology? i think 16 bytes are too many for most situations. 16bytes are an awful lot I agree I look it as the cost of compromise I guess. | If some want to change their vote from 16 is OK to ONLY Variable I | guess its fair. But if another argument comes about again next Monday | will I come back from vacation and see its now 23.5 bytes fixed or | variable with SIPP extended addresses. We need to make a decision and | stick with it. >the fixed-width "consensus" announced at the retreat surprised me, and >i'm questioning it. i agree that we need a decision and we need to stick >with it. i see both sides, but i know which implementation covers both >requirements - variable. unfortunately, it doesn't cover your concern >abt end-systemn performance. Performance is not the issue to stop variable addresses its the cost. Not just for the kernel but the total cost. There is a cost at the app level too we have not even analyzed yet. >do you agree with the following statement: >"variable length addresses the *needs* of the ipng community with the >side affect of minor performance penalty" I would add "and additional costs". I am not sure about the community but the statement is axiomatic for sure. Its really a question of cost I think more than performance. >we can debate what "minor" is. i want to be clear that this is your only >gripe. I think I answered that above and its not a gripe its a concern. >listen to eric. he runs a real network that's built on your software. >under most circumstances, i'd say, don't listen to me, i'll build and >sell what eric tells me to sell... i'd say don't listen to tony, he'll do >the same. unfortunately, both tony and i have dealt with our >share of erics, and our share of boeings, and know that his >position is not unique and will defend it. I always listen to Eric and we have a lot of our network products in Boeing. I don't need to hear this from you trust me. >we're in this game to sell software, my employer invests in the ipng >effort in hopes that it will produce an architecture that will meet our >customers needs and reduce our ultimate costs. i personally don't >give two hoots abt fixed vs. variable. if my customers tell me 16-fixed >is fine, i'll shutup. they're not. so, me and tony can fix it ourselves >independent of the effort, or the directorate can take our feedback. >this is not a threat, it's a reality. we do what our customers tell us >to do. we try to base few of our decisions on "what should be >good for 30 years" when our source of revenue suggests >differently, with or without proof. ACK on the employer. My customers want good IP in our products. I can do this with fixed addresses or variable addresses. But I can do it cheaper with fixed addresses which means it will cost my customer less money. And it will last for 30 years of product generations. Also above are you alluding to a vendor consortia and who could figure out an IPng archictecture better than all the bright people together in the IETF? I hope no cause that would be real bullshit. Or is this just the case of wanting to take your ball and go home. And your customers told you I want variable addresses? /jim From bound@zk3.dec.com Wed Jul 6 15:10:09 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA27588 for ; Wed, 6 Jul 1994 15:20:56 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA11808; Wed, 6 Jul 94 12:10:28 -0700 Received: by xirtlu.zk3.dec.com; id AA01634; Wed, 6 Jul 1994 15:10:15 -0400 Message-Id: <9407061910.AA01634@xirtlu.zk3.dec.com> To: "James 'J' Allard" Cc: ericf@atc.boeing.com, ipng-request@cmf.nrl.navy.mil, bound@zk3.dec.com, ipng@radegond.cmf.nrl.navy.mil Subject: Re: Concern In-Reply-To: Your message of "Tue, 05 Jul 94 20:34:40 +0700." <9407060243.AA13586@netmail2.microsoft.com> Date: Wed, 06 Jul 94 15:10:09 -0400 X-Mts: smtp | First performance hits on variable addresses are not a 'crock'. >it's not a crock, it's a non issue. 50 instructions on the send path is >trivial given the horsepower of existing and future cpus. really, how >many instructions is it if you fastpath 16-bytes and do the check. >bet it's less than 50. It is less than 50 based on two compilers. But thats not the performance hit. Its the searches in the cache, pcb's, and the ifnet data structures which are now all variable. I never stated it was an order of magnitude performance loss based on instructions even if not in the fast path. | It could be a 'wash' if we go and fix other areas of the IP stack. >the fact that you haven't optimized all of the areas of your >implementation suggest a bogus argument. we've tuned the shit >out of ours, we can't cut out 50 instructions. it's not a wash, its >more instructions. i don't care though, it's worth it. i recommend >you clean up what you can, and if you save 50 great, if you save >500, better, but it has nothing to do with the argument (other than >to suggest a bogus argument since you didn't clean up your >performance before this discussion came up. performance >must not be **that** important). First SLOW DOWN on your assumptions that 'we have not optiimized our IP implemntation" in fact we have and can saturate an Ethernet or FDDI for both TCP and UDP. Don't make those kind of public comments to a list its not cool. I said nothing about my implementation yet. And my arguments are not bogus and our performance is fine. Your way out of line here and I suggest you use a different tact for discussion. There are many public domain concepts for TCP/IP that are useful to all of us to generate code as we generate IETF specs for IP such as VJs work. I was refernecing for example the way searches are done and that they could be done more efficiently for IP in the Open Systems sense. Of course if you want to roll your own go for it. But, just changing the way searches are done in the public domain of IP would make up for any loss with variable addresses and it would be a wash. | I talked to Scott this weekend and told him I know of several engineers | and myself who are willing to put out a very direct RFC that states | exactly why variable addresses 'will' cause a performance loss. >it won't cause a measurable performance loss on a non-saturated >cpu system. where will it cause a loss? aggregate performance on >a server w/ a ton of connections who is not media, or bus bound, >but is cpu bound. it's not an end system issue, it's a server issue. >again, i'm willing to take the hit. every administrator i know throws >tons of $$$ at server metal and would gladly throw more. what they >don't want to do is to touch the goddamn clients - it's too expensive. >they touch the server everyday and have expertise there, they >have idiots at the end systems. It is an end system issue and I don't agree with your assessment of end system users or the market (but we know that already). The performance issue will take place at every network connection on a client or server. On a server it will be more noticable. | The issue for variable addresses is cost too. Any cost needs to be | justified. No one has justified variable addresses except that it will | let us evolve even past 30 years which 16bytes in fact will support. >i don't understand how 16 bytes will allow boeing, who buys >macdonald douglas next year to merge their addressing >hierarchies when one of them used all 16 bytes. next year, >not 30 from now. give me 100% utilization of class a addresses, >and i'll give you 30 years on ipv4 when considering the number >of general purpose desktop computers around. This is nonsense. No customer will use all 16bytes if used correctly and I am not even going to give this argument the courteousy of an answer. Now this is bogus. | IPng will get broken before then for reasons that we don't know that | have nothing to do with the network layer address IMHO because we will | have a technology paradigm shift on routers, networking, or operating | systems. If this happens all the cost to implement variable addresses | would have been un-necessary. >the cost of implementing variable length addressing relative to all of >the new baggage which will come w/ ipng (rotuing protocols, server- >less and serverful configuration, dns autoregistration, etc...) is again >trivial. i'll freely write reference code and slap it in an rfc. this is >bogus. the real cost is in education of administration, addressing, >router configuration, etc.. educating the network administrators, or >anyone that needs to know anything abt the address is where the >cost is. the implementors are all smart enough to implement >varlen addresses. most college sophomores are. Relative is an important word and has variance when used. I said any cost needs to be justified. I agree with you on the edu and admin costs and add transition to that education. As far as your comments about the implementors no one stated they could not do it that I have heard. I am not sure what your point was here and I think your comment about college sophmores is bullshit. | All the successful protocols of past SNA, DECnet, IPX, and yes IPv4 have | all been fixed length address. One protocol in the market is variable | length and its not successful for whatever the reason is and I know its | not because of CLNP, but its not successful, at least today. >bullshit, no one ever said "thank god my network layer addresses are >fixed". not implementors, not users, not administrators. it saved a tiny >bit on the implementation side, a fair amount on the education side >(e.g., an ip address looks like a.b.c.d), but that's abt it. hell, ask 100 >ipx network administrators how long an ipx address is, 98 will say >"duh". the reason ipx succeeded was because they didn't know, not >because they did and they liked that they were fixed. ipv4 is screwed >because people beyond implementors or core operational geeks >know what the address looks like. hey, let's focus on fixing that. now >*there's* a carrot for ipng. it's not like we're promising better performance >with this thing. bullshit. You have it all wrong that those protocols were designed by accident. Better performance is one of my goals, but your right no promises. | Also mine, Steve Deering, Paul Franics and others have a strong desire | for Fixed Length addresses unless 16bytes are not enough. Some even | still believe 8 bytes are enough. >i believe that i will have a network which will require 1 byte addresses. i >don't want the overhead of 15 unecessary bytes on a link that supports >512 byte datagrams. that reduces my throughput by 3% between two >end systems which aren't close to cpu bound, but are totally network >bound. why can't i use smaller addresses on a flat, non-routed >topology? i think 16 bytes are too many for most situations. 16bytes are an awful lot I agree I look it as the cost of compromise I guess. | If some want to change their vote from 16 is OK to ONLY Variable I | guess its fair. But if another argument comes about again next Monday | will I come back from vacation and see its now 23.5 bytes fixed or | variable with SIPP extended addresses. We need to make a decision and | stick with it. >the fixed-width "consensus" announced at the retreat surprised me, and >i'm questioning it. i agree that we need a decision and we need to stick >with it. i see both sides, but i know which implementation covers both >requirements - variable. unfortunately, it doesn't cover your concern >abt end-systemn performance. Performance is not the issue to stop variable addresses its the cost. Not just for the kernel but the total cost. There is a cost at the app level too we have not even analyzed yet. >do you agree with the following statement: >"variable length addresses the *needs* of the ipng community with the >side affect of minor performance penalty" I would add "and additional costs". I am not sure about the community but the statement is axiomatic for sure. Its really a question of cost I think more than performance. >we can debate what "minor" is. i want to be clear that this is your only >gripe. I think I answered that above and its not a gripe its a concern. >listen to eric. he runs a real network that's built on your software. >under most circumstances, i'd say, don't listen to me, i'll build and >sell what eric tells me to sell... i'd say don't listen to tony, he'll do >the same. unfortunately, both tony and i have dealt with our >share of erics, and our share of boeings, and know that his >position is not unique and will defend it. I always listen to Eric and we have a lot of our network products in Boeing. I don't need to hear this from you trust me. >we're in this game to sell software, my employer invests in the ipng >effort in hopes that it will produce an architecture that will meet our >customers needs and reduce our ultimate costs. i personally don't >give two hoots abt fixed vs. variable. if my customers tell me 16-fixed >is fine, i'll shutup. they're not. so, me and tony can fix it ourselves >independent of the effort, or the directorate can take our feedback. >this is not a threat, it's a reality. we do what our customers tell us >to do. we try to base few of our decisions on "what should be >good for 30 years" when our source of revenue suggests >differently, with or without proof. ACK on the employer. My customers want good IP in our products. I can do this with fixed addresses or variable addresses. But I can do it cheaper with fixed addresses which means it will cost my customer less money. And it will last for 30 years of product generations. Also above are you alluding to a vendor consortia and who could figure out an IPng archictecture better than all the bright people together in the IETF? I hope no cause that would be real bullshit. Or is this just the case of wanting to take your ball and go home. And your customers told you I want variable addresses? /jim From bound@zk3.dec.com Wed Jul 6 15:46:00 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA27870 for ; Wed, 6 Jul 1994 15:54:28 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA13296; Wed, 6 Jul 94 12:46:11 -0700 Received: by xirtlu.zk3.dec.com; id AA02809; Wed, 6 Jul 1994 15:46:06 -0400 Message-Id: <9407061946.AA02809@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng Outline from Scott and Allison In-Reply-To: Your message of "Wed, 06 Jul 94 08:11:47 +0200." <9407060611.AA28951@dxcoms.cern.ch> Date: Wed, 06 Jul 94 15:46:00 -0400 X-Mts: smtp Brian, >Well, I will be running a Eurpopean candidate for this. Thats fine but I want expertise in there and would not want to sacrifice it for geography concerns. But I do think a European would be very good and you doing it would be good too as you have this expertise. If I had any input to this decision of course. => This is still not part of the formal list of IPng requirements, but => clearly a real world requirement. But it should not be done at the cost => of making IPng less than it could be technically or architecturally. For => IPX it fits well in 16bytes for NSAPs its not as easy and we need an => algorithmic mapping for 16bytes that spans different NSAP uses today. => This also could be opening up pandoras box, with the only real answer => encapsulaltion within IPng. >I can only repeat: > Too vague. I can't sell this in Europe. I *need* NSAPA embedding as > a specifc goal or up-front option. ... > => > => o - existing working groups not forced to shut down > => what we said at start of process OK I must respeat what is the specific technical requirement on End Systems and Routers. I will say what I don't want convergence to be. That my IP applications and transports have to understand anything about NSAPs. This is unacceptable. We need a clear set of requirements and what is needed in convergence. Or else this all sounds strictly political with no content for direction. What do NSAP folks want to do with the Internet. Do they want to have an CLNP application talk to another CLNP application on the other end of a regional network? I don't get it right now at all and maybe this is why its not in the IPng requirements. But I want to and have my own idea of what it should be but that is very biased as I work for the biggest vendor of a protocol that uses NSAPs with more CLNP on the street than anyone. Thats why sometimes I have to just sit back and laugh at some of the CLNP comments that are totally wrong. /jim From Greg_Minshall@Novell.COM Wed Jul 6 13:01:39 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA28074 for ; Wed, 6 Jul 1994 16:06:31 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA19753; Wed, 6 Jul 94 14:05:42 MDT Received: from [130.57.64.152] by WC.Novell.COM (4.1/SMI-4.1) id AA21021; Wed, 6 Jul 94 13:01:40 PDT Date: Wed, 6 Jul 94 13:01:39 PDT Message-Id: <9407062001.AA21021@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Lixia Zhang , Allison J Mankin From: Greg Minshall Subject: Re: Mail to Each WG List Cc: ipng@radegond.cmf.nrl.navy.mil Lixia, of Xerox PARC, >16-fixed byte addr is an extension to current IPv4 architecture, the >game I think we confidently know how to play. >Variable addr is probably NOT, as Deering repeatedly stated (that it'd >be no longer SIPP if you put in var addr) Let me just mention something driven peripherally off something Dave Clark said last Monday to the effect that there are *semantics* and there is *encoding*, and maybe its useful to separate the two. IF there is a fixed maximum address size (32 bits, say), and IF a known method for mapping < maximum sized addresses into maximum sized addresses (by appending zeroes, say), THEN we are *preserving* the current, well-understood, IPv4 fixed length address game (the semantics), but allowing different encodings (in headers only, maybe, or also in DNS, or also in MIBs, etc.). (If we do this, it might be a bit tricky, and therefore a mistake to even do it, to try to define how to represent the encoding in all the various possible places. In this sense, the infamous Deering might be right...) This might be useful (though i doubt DDC meant his remark to apply to this case). Greg From Greg_Minshall@Novell.COM Wed Jul 6 13:02:44 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA28097 for ; Wed, 6 Jul 1994 16:07:37 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA19765; Wed, 6 Jul 94 14:06:44 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB21025; Wed, 6 Jul 94 13:02:44 PDT Date: Wed, 6 Jul 94 13:02:44 PDT Message-Id: <9407062002.AB21025@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Brian.Carpenter@cern.ch From: Greg Minshall Subject: Re: Concern Cc: ipng@cmf.nrl.navy.mil Brian, >The trouble with this approach is that if initial IPng hosts are deployed >only with 16-byte support, moving to larger addresses is in effect moving >to IPngng. It would be a second transition. So it's theoretically OK, >but practically meaningless, I fear. The counter example is TTL. Most hosts used to ship with TTL == 16. Now, TTL == 64 or whatever is there. The routing system never changed. TTL == 16 hosts were motivated to upgrade to get better connectivity, but could stay at TTL == 16 if that was acceptable. (This example breaks down, of course, in that the effort to go from TTL == 16 to 64 is fairly trivial, one .h file, whereas the effort to go from 16-byte fixed to variable is, oh, a bit more complicated... :-) Greg From bound@zk3.dec.com Wed Jul 6 16:18:12 1994 Return-Path: bound@zk3.dec.com Received: from crl.dec.com (crl.dec.com [192.58.206.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA28986 for ; Wed, 6 Jul 1994 18:39:52 -0400 From: bound@zk3.dec.com Received: by crl.dec.com; id AA15902; Wed, 6 Jul 94 16:24:04 -0400 Received: by xirtlu.zk3.dec.com; id AA03852; Wed, 6 Jul 1994 16:18:18 -0400 Message-Id: <9407062018.AA03852@xirtlu.zk3.dec.com> To: Eric Fleischman Cc: bound@zk3.dec.com, ipng@radegond.cmf.nrl.navy.mil Subject: Re: Concern In-Reply-To: Your message of "Wed, 06 Jul 94 08:27:26 PDT." <9407061527.AA17049@atc.boeing.com> Date: Wed, 06 Jul 94 16:18:12 -0400 X-Mts: smtp Eric, >Thank you for your response. It is somewhat of a comfort to find that you >at least are not vacillating on your positions. Would you please do me >the favor of addressing for this list what you think of the following >question?: > "Do you favor an IPng addressing approach which defines an initial > fixed-length 16 byte address deployment within a variable length > addressing schema. The maximum address size shall be 32 bytes long > with 8 byte address granularities." >Would this approach preserve the undesirable variable length tenets against >which you and other host vendors have been arguing or would it appear >to your software as something resembling fixed length addresses? It would not appear to my software as fixed length addresses, because I would have to build the escape hatch into my kernel and the APIs while I am building the IPng architecture in my products. In addition this could be even more costly than just doing variable length addresses because you would have time explosions in the software engineering abstraction now for the design, which would affect all the code paths on a router or a host. I do think this idea has merit regarding source routes for sure. /jim From Greg_Minshall@Novell.COM Wed Jul 6 13:38:41 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA28368 for ; Wed, 6 Jul 1994 16:43:31 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA20571; Wed, 6 Jul 94 14:42:43 MDT Received: from [130.57.64.152] by WC.Novell.COM (4.1/SMI-4.1) id AA21171; Wed, 6 Jul 94 13:38:45 PDT Date: Wed, 6 Jul 94 13:38:41 PDT Message-Id: <9407062038.AA21171@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "James 'J' Allard" From: Greg Minshall Subject: Re: Concern Cc: ipng@radegond.cmf.nrl.navy.mil Jim, >i don't understand how 16 bytes will allow boeing, who buys >macdonald douglas next year to merge their addressing >hierarchies when one of them used all 16 bytes. next year, >not 30 from now. give me 100% utilization of class a addresses, >and i'll give you 30 years on ipv4 when considering the number >of general purpose desktop computers around. Pick a maximum sized (all the variable length people want some such). Say it is 32 bytes (seems a favorite). Let one of {Boeing, MD} use up all 32 bytes. Let one of them buy the other. Voi-splot! I don't think that is a good argument. (I think Brian C's argument of preserving a "provider"/"customer" split *may be* good, if only someone knew what a "provider" was and what a "customer" was...) > if my customers tell me 16-fixed >is fine, i'll shutup. they're not. so, me and tony can fix it ourselves >independent of the effort, or the directorate can take our feedback. Customers are interesting beasts. Over on the IETF "channel", there was a message from Craig Partridge and Dave Crocker suggesting (i think) that customers wanted CMIP over SNMP "way back then". Way back then, "customers" wanted CLNP, also. My point is that we all need to listen to customers, but evaluating what their statements *really* mean is an art. Greg From Greg_Minshall@Novell.COM Wed Jul 6 13:38:51 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA28370 for ; Wed, 6 Jul 1994 16:43:40 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA20574; Wed, 6 Jul 94 14:42:52 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB21171; Wed, 6 Jul 94 13:38:51 PDT Date: Wed, 6 Jul 94 13:38:51 PDT Message-Id: <9407062038.AB21171@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Brian.Carpenter@cern.ch From: Greg Minshall Subject: Re: what Greg was saying... Cc: ipng@cmf.nrl.navy.mil Brian, >Isn't this what Greg was trying to get at in Boston? >I.E. why having both 0:0 and 0:1 prefixes is broken? Yes and no. Bill Simpson's query is really to the question "should you allow IPng-only hosts (NG hosts, in my notation) to talk to IPv4-only hosts (V4 hosts)?". I think that is a valid question (and i've raised it). However, my point is that *even if* you decide to do that, i'm not convinced that 0:0 and 0:1 makes any sense. (I'm not convinced it *doesn't*, mind you; Bob Gilligan and i are still yacking about that. However, my intuition, nortoriously flawed, says it probably doesn't make any sense.) Greg From bound@zk3.dec.com Wed Jul 6 21:37:10 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA29694 for ; Wed, 6 Jul 1994 21:43:45 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/27May94) id AA11976; Wed, 6 Jul 94 18:37:21 -0700 Received: by xirtlu.zk3.dec.com; id AA08879; Wed, 6 Jul 1994 21:37:16 -0400 Message-Id: <9407070137.AA08879@xirtlu.zk3.dec.com> To: "James 'J' Allard" Cc: bound@zk3.dec.com, ericf@atc.boeing.com, ipng@radegond.cmf.nrl.navy.mil, ipng-request@cmf.nrl.navy.mil Subject: Re: Concern In-Reply-To: Your message of "Wed, 06 Jul 94 13:22:36 +0700." <9407061932.AA10139@netmail2.microsoft.com> Date: Wed, 06 Jul 94 21:37:10 -0400 X-Mts: smtp Jim, All your statements are valid (I mean it). The problem is that we are coming from completely different technical philosophies to solve this problem, which causes us to be diametrically opposed. In addition we are both very technical so no one can say its politics its honest to goodness differences. I value difference and I hope the Area Directors and the Directorate read very closely all your mail on this issue I know it took a lot of time away from other work. I also see your point about DHCP and Dynamic DNS and how they told you to screw off thats a very good argument in context for variable addresses, because you were right on that one for sure. The bottom line is I am sitting with Steve Deering, Paul Francis, and Bob Hinden with my technical beliefs for the most part. I see no point of further replies to this thread its time to make a decision. I will build products as you no matter what the decision is for IPng. I am glad the discussion has turned to variable vs fixed addresses which is better than this group vs that group. That much is progress IMHO. I won't say who you may be sitting with in similarities thats for you to say. But I found the Big-10 Packet format not to my technical 'taste'. I assume that will be another long technical discussion we will have soon and an important one. But also Steve, Paul, and Bobs too will need discussion, which I hope we get soon. My final offer of compromise at my end to the Directorate for variable addresses technically is to support an 8byte fixed length address in the main header that is globally unique in the Internet and a variable address source route optional header if the packet has to leave the private site (private site is dec.com, microsoft.com, etc..). Yes we would need to set up and define the 8 byte address space for such a purpose and no I do not ask that it be called an EID. See my mail on Big-I in a moment regarding source routes in main headers, which I do not think is a good idea. Source routing should be a second class citizen. This is also my individual position not my companies. As I said I will build products for IPng in my company no matter what IPng ends up to be. Which is what we have said all along. But no one is yelling at me for supporting 16bytes unless someone can show its not enough for 30 years on the Internet. I guess-estimate the cost to move our 3 host kernels to variable addresses and the re-training to be about $1.5 million. To me this is significant. This would include the API to insulate the applications as you suggested, which we mostly have figured out anyway from SIPP extended addresses. I do admit I am very cost conscious and have always been as an engineer for the past 20 years. I will also admit the mistakes I have made was trying to save costs when I should have been less frugal. But on this one I got to stand pat with the 16bytes with my caveat of what will change my mind. p.s. WOW you have two class A addresses and I felt bad with 1 (we have 50,000+ hosts and growing daily, plus I just started managing my own subnet for our IPng Internet testing, I don't find it bad at all but then again I just look at the code if I don't get it). Not offended at my end, /jim From brian@dxcoms.cern.ch Thu Jul 7 08:23:48 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA00606 for ; Thu, 7 Jul 1994 02:24:22 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA19457; Thu, 7 Jul 1994 08:23:49 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28019; Thu, 7 Jul 1994 08:23:48 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407070623.AA28019@dxcoms.cern.ch> Subject: Re: Concern To: ipng@cmf.nrl.navy.mil Date: Thu, 7 Jul 1994 08:23:48 +0200 (MET DST) In-Reply-To: <9407062038.AA21171@WC.Novell.COM> from "Greg Minshall" at Jul 6, 94 01:38:41 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1464 Greg, ... > Pick a maximum sized (all the variable length people want some such). Say > it is 32 bytes (seems a favorite). Let one of {Boeing, MD} use up all 32 > bytes. Let one of them buy the other. Voi-splot! I don't think that is a > good argument. > > (I think Brian C's argument of preserving a "provider"/"customer" split > *may be* good, if only someone knew what a "provider" was and what a > "customer" was...) > I think the point is that to be sure that route aggregation remains possible when companies merge (or divide), you need this split. If you don't have it, then a merged company has prefix 12345 for one division, and 76314127 for another division, and since they are different lengths they are very hard to renumber in order to aggregate. Similar things would happen if two service providers merge. It's true that service provision is recursive, so there may not be a unique definition of the provider/customer split. If you go very far down that road, you get to recursively defined address formats with extensibility at both ends, which is probably not where we want to be. Now here is a another red herring. It seems to me that a pre-CIDR IPv4 address is stateless (you know everything about it by inspection), whereas a CIDR address needs external state (the CIDR mask) before you can interpret it. Have we discussed whether IPng 16-byte addresses, or IPng variable length addresses, should be stateless? Does it matter? Brian From brian@dxcoms.cern.ch Thu Jul 7 08:45:30 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA00640 for ; Thu, 7 Jul 1994 02:46:04 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24506; Thu, 7 Jul 1994 08:45:32 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28689; Thu, 7 Jul 1994 08:45:31 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407070645.AA28689@dxcoms.cern.ch> Subject: CLNP, one more time To: ipng@cmf.nrl.navy.mil Date: Thu, 7 Jul 1994 08:45:30 +0200 (MET DST) In-Reply-To: <9407061946.AA02809@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jul 6, 94 03:46:00 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1763 Jim, Let's pretend that IPng includes my suggestion of NSAPA addressing as an _optional_ alternative to 16-byte. It implies that vendors could include a whole hunk of code starting "if format=NSAPA then..." in hosts and routers, and DNS servers I suppose. This is a cost and a pain, even if the code is inefficient and slow compared to the 16-byte case. But they could leverage off existing OSI code for routing. Also the API would probably not be defined (IETF doesn't do APIs). The alternative is that vendors could decide to return an ICMP message instead, if they get a packet with an NSAPA source address. This would be fairly cheap and easy to code. The market would decide, and I know what it would decide. Why propose it? I'm seeking a way to get IPng accepted universally, not only by we slobs who go to the IETF. It's PC, CYA, if you like but we have suffered (your company has suffered) a lot from the OSI disease and we need to end it somehow. If we come out and say "The IETF has rejected all pressure for convergence with OSI" this will play VERY BADLY over here. If we say "The IETF has incorporated an OSI addressing option in IP" it will play very well. We are choosing IPng on engineering grounds. I don't think that including an option that nobody will use, on PC grounds, is that bad though. You will never get a clear requirements statement for CLNP convergence, because all the people who might be able to write one are in the IETF camp anyway. My own requirements statement is very simple: I need to run DECnet over the Internet, without redesigning our private addressing plan. I believe we can do that inside a 16-byte address, if DEC does what it has to do. So actually I don't care at all about CLNP or NSAPAs as such. Brian From bound@zk3.dec.com Thu Jul 7 10:44:43 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA02437 for ; Thu, 7 Jul 1994 10:55:42 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA00724; Thu, 7 Jul 94 07:45:09 -0700 Received: by xirtlu.zk3.dec.com; id AA07426; Thu, 7 Jul 1994 10:44:49 -0400 Message-Id: <9407071444.AA07426@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: IPng Convergence (was Re: CLNP, one more time) In-Reply-To: Your message of "Thu, 07 Jul 94 08:45:30 +0200." <9407070645.AA28689@dxcoms.cern.ch> Date: Thu, 07 Jul 94 10:44:43 -0400 X-Mts: smtp Brian, I understand your mail very well. Also that its hard to define the requirements, but that does not mean we do not have to do that. Let me end my comments on this thread as I did with Jim Allard on variable addresses this way. I am open to technical discussion for that which is tasteful to the IETF community. First I agree with you that we need to end the OSI debate and that convergence could accomplish that and appease the political issues of the geographic CLNP camps. I think the Area Directors should stand up in front of the IETF or one/two of the Directorate members (like me and you) and tell them at the plenary we recommend doing this for IPng and for those reasons and be totally honest about our motives. Anything less than that is unfair to the IETF community like using back door approaches to get this in as part as IPng. Second we also need to do the same for other protocols IPX, DECnet, and SNA if we do it for CLNP. But these protocols are more widely implementd than CLNP by a long shot. Now for how to do this. First my opinion is that the most important one above in the market is IPX. This fits in 16bytes. The others either will maintain their existing infrastructure, encapsulate within IPng (as they do within IPv4), or just port to IPng. But the other option is to develop mappings for the other protocols into 16bytes. I will not and cannot support making IPng >16bytes for protoocols to be carried in the IPng network layer header. Even if we had variable addresses I could not support this idea. Its too much tax on TCP/IP protocol suite and I do not think we should ask all to pay that tax. I know we can figure out the mappings somehow OK. The other issue is what does this mean to a vendor building IPng. Here is what I think it should not mean: That at the host I now have to keep state and connections for multiple address formats and code to extrapolate and process variant packets. On a router they are just moving the packets on, but on a host you have to move that packet up to the application. If this is the strategy then we are telling the host vendors that we really are supporting multiple protocols by supporting multiple IPng network layer packets. If what I just said is mandatory in IPng per the Directorate then I have to walk away from the Directorate and make it publicly known. This is an order not an option for me I think. But if its an option then I can support that if the requirements are stated clearly and the technical ramifications, and then solutions are worked on in the IETF. I think this would be a working group all by itself with a lot of work. Here is what I think it should mean: First the above as an option. This permits us to let the market live with the answer for a year or so and see how noisy it gets for all the protocols. If its noisy enough and greenbacks are shown on the table (sorry for the U.S. term) then the smell of revenue will cause the vendors to solve the problem with this option in IPng. Now the hard part for all to swallow: I also believe once you put an NSAP, IPX, or whatever format in an IPng packet for covergence you now live and depend on the total IPng suite of protocols whatever those are to be. That means you may use OSPF instead of IS-IS or IPng-ICMP instead of ES-IS as examples. This makes the cost of handling convergence acceptable and any transition too. Let us not forget our main objective is to move IPv4 to IPng and that is our primary job here. Do not tell the vendors they have to support additional infrastructure below the transport and API. Use the IPng suite to be developed, not the ones of past. /jim From brian@dxcoms.cern.ch Thu Jul 7 16:55:37 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA02456 for ; Thu, 7 Jul 1994 10:57:12 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA19812; Thu, 7 Jul 1994 16:56:17 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA11933; Thu, 7 Jul 1994 16:55:38 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407071455.AA11933@dxcoms.cern.ch> Subject: CLNP, one more time (clarification) To: ipng@cmf.nrl.navy.mil Date: Thu, 7 Jul 1994 16:55:37 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2215 It's been pointed out that my earlier message might imply that the only reason for NSAPA support in IPng is PC. This was not my intention. However, I think Jack Houldsworth expressed it better than I did, in the message that Scott relayed on April 14, saying in part: As discussed in Seattle, the IT community requires a migration route from both IP and CLNP to IPng whatever the decision turns out to be and this should be taken into account in the decision process - at least in transition planning, at best when making the fundamental choice. If a migration route from CLNP to IPng exists, there is a chance of persuading ISO/IEC that IPng is a sensible common goal for the future network layer for OSI. There is also a chance that they could put in place migration from Transport Class 4 to TCP. Clearly, it would be suicidal for ISO to do either of these things if transition is not possible. Transition from CLNP to IPng could enrich the Internet Protocol Suite by adding OSI applications to the IPS portfolio in due course. Market forces would determine which OSI applications survived. Transition capability would convince the European GOSIP organisations, which are currently against including TCP/IP in mandatory procurement, that including TCP/IP is not a threat which will condemn them to permanent dual stacking and they may relent. With a route forward to IPng, all the CLNP LAN traffic, a lot of which currently runs over X.25, becomes potential internet traffic. The ideal solution is TUBA, which has a guaranteed transition route, but perhaps the key factor is the adoption of NSAP addressing. It is hard to see a clear migration route from CLNP without it. Is everyone aware that NSAPs are used by both ITU-T and ISO/IEC and cover data, telephone, TELEX etc. ... Regards Jack -- Brian From craig@aland.bbn.com Thu Jul 7 10:58:55 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA04148 for ; Thu, 7 Jul 1994 13:59:41 -0400 Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA28109 for ipng@cmf.nrl.navy.mil; Thu, 7 Jul 94 13:59:09 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA04541; Thu, 7 Jul 1994 10:58:56 -0700 Message-Id: <199407071758.KAA04541@aland.bbn.com> To: ipng@cmf.nrl.navy.mil Subject: another view on IPng From: Craig Partridge Date: Thu, 07 Jul 94 10:58:55 -0700 Sender: craig@aland.bbn.com Hi folks: In my spring reading and research course at Stanford I had my students write survey papers on a networking topic of their choice. One of them (Michael Graven) chose to write on IPng. I found it an interesting read and think you might too. Part of the interest is his technical comments and part is simply his perspective -- Michael's a user and one who hadn't been following IPng heavily until recently. Note that Michael's an AT&T employee on leave to get a graduate degree and that AT&T said it was OK to circulate this provided it didn't get into a journal or similarly permanent medium (which I suspect includes RFCs). Also, if you violently disagree with this paper, please yell at me not Michael -- I asked him if he'd be willing to see it posted (since I thought folks might find it useful). If there are things you like -- feel free to drop him a note. Thanks! Craig E-mail: craig@aland.bbn.com or craig@bbn.com ------- Forwarded Message Received: from Sunburn.Stanford.EDU by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA28888 for popbbn; Tue, 5 Jul 94 12:47:38 -0400 Received: from ozzy.homer.att.com (tip-mp2-ncs-16.Stanford.EDU) by Sunburn.Stanford.EDU with SMTP (5.67b/25-SUNBURN-eef) id AA21500; Tue, 5 Jul 1994 09:47:16 -0700 Received: by ozzy.homer.att.com (8.6.9) id JAA16798; Tue, 5 Jul 1994 09:47:10 -0700 From: Message-Id: <199407051647.JAA16798@ozzy.homer.att.com> Subject: IPng paper: nroff version To: craig@aland.bbn.com Date: Tue, 5 Jul 1994 09:47:10 -0700 (PDT) Reply-To: mjg@cs.Stanford.EDU (Michael J Graven) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 44118 Next-generation internetwork protocols: requirements and contenders Michael J. Graven mjg@cs.stanford.edu ABSTRACT Continued exponential growth in the IP Internet has acceler- ated efforts to develop a successor to IP version 4. Many replacement proposals have been advanced; with time, some have merged with others. Two of the proposals under active development, the ``Simple Internet Protocol Plus'' (SIPP) and ``TCP and UDP with Bigger Addresses'' (TUBA) have emerged as leading candidates to replace IP and become ``IP: The Next Generation'' (IPng). Issues relating to the intro- duction of IPng will be introduced, and the two draft proto- cols will be evaluated in light of those issues. 1. Introduction The explosive growth in computer internetworking in the last several years has precipitated a demand to upgrade the infrastructure upon which the tens of thousands of con- stituent networks depend. The ARPANET gave way to the NSFNET, which is giving way to an amalgam of regional and interregional carriers to better handle the needs of the networked community. Through the late 1980's and early 1990's, considerable effort was expended in upgrading the Internet's hardware architecture. The backbone networks were upgraded first from DS0 56k links to T-1 speed, then to T-3 speed by the end of 1992. It's becoming widely held that Asynchronous Transfer Mode (ATM) is the wave of the future and that soon the preferred architectures will be ATM and SONET, operating at gigabit speeds among millions of hosts. But these advances in data communications hardware haven't been matched by advances in protocols. IP version 4 (IPv4)[1] is still in use, largely unchanged since its orig- inal definition in 1980-81. Unfortunately, IP wasn't designed for the massive scaling seen in recent years. Cer- tain deficiencies in the original design, tolerable in a small network, have become intolerable. The IP Internet needs a new network protocol to carry it into the next twenty-five or more years. 2. Why a new IP? In February, 1994 alone, the InterNIC Registration Services Next-generation internetwork protocols Graven - 2 - assigned more than 14,700 networks and more than 800 domains.[2] Further, in January 1994 it was estimated there were 2.2 million hosts on the IP internet, up from 1.1 mil- lion in October 1992.[3] This explosive growth is accelerat- ing the demise of IP. IP suffers most from two design limitations: the address class encoding and the address sizes. Class encoding and past address block allocation schemes have caused backbone routing tables to grow dramatically, and router managers must continuously add memory to keep track of the ballooning tables. At the same time, IP's 32-bit address size is prov- ing to be too small, given the exponentially-increasing pop- ularity of networking. What's more, some features of IP have proven to be less use- ful than originally thought, and other features have arisen in the meantime that network programmers wish were supported in the network layer. 2.1 A routing nightmare Until the early 1990's, assignment of IP address blocks was relatively freewheeling; if an organization could show its need for a Class B address, it was likely to get one. Con- sequently, any two adjacent network numbers could belong to entities on different sides of the globe. This randomness can cause routing tables to grow with O(n), an undesirable state of affairs for large n. In 1993, Vint Cerf offered the following perspective: The somewhat embarrassing thing is that the net- work address space is under pressure now. The original design of 1973 and 1974 contemplated a total of 256 networks. There was only one LAN at PARC, and all the other networks were regional or nationwide networks. We didn't think there would be more than 256 research networks involved.[4] The introduction of Classless Inter-Domain Routing (CIDR)[5] and routing information protocols such as OSPF[6] and BGP-4[7] are an attempt to impose on network numbers a hier- archical order that mimics the hierarchy of connections among network providers and clients. Retroactively imposing such an ordering is viewed as a necessary condition for con- tinued scaling of the IP Internet in the short term. In the long term, however, even if CIDR becomes wildly popular, the Internet will eventually run out of addresses completely. 2.2 Address depletion At the current rate of consumption, various authors have predicted that IP's 32-bit address space will run out some- time between 1995 and ``the next century.'' The advent of Next-generation internetwork protocols Graven - 3 - intelligent home networks, ubiquitous personal communica- tors, and myriad other networked devices is increasing net- work address space consumption. When we consider the adage that ``data will expand to fill the available space,'' it becomes clear that a larger, extensible addressing scheme is required. Estimates place an upper bound on the number of global networks at around 1012, plus or minus a few orders of magnitude. 2.3 New features IP currently lacks features that have become popular rally- ing cries in the last few years. Among them are o support for flows, o enhanced security, o node self-configuration (``plug-and-play''), and o decentralized address administration. Supporting these features in a new protocol would speed its acceptance. 3. Requirements for a new IP Discussion of what IP: next generation (IPng) should and should not do has been continuing -- sometimes heatedly -- since the early 1990's. In December 1993, Scott Bradner and Allison Mankin issued a call for white papers (RFC 1550) regarding the transition to IPng.[8] Their solicitation elicited many proposals and requirements documents from a variety of system architects, network providers, users, etcetera. These desires can be grouped roughly into two parts: those that have narrow technical impact and those that affect the broader overall design and deployment of IPng. 3.1 Design and deployment considerations 3.1.1 Significant advantage: Boeing's Eric Fleischman notes in a response to RFC 1550 that users will be compelled to migrate to IPng only if there is a good return on the time invested to make the change. A new protocol needs one or more ``must-have'' applications that cannot run on the old protocols. He also observes that most corporations view networks as means to an end. To a corporate user, the net- work is unimportant: it's the applications that run on it that matter.[9] Next-generation internetwork protocols Graven - 4 - 3.1.2 Smooth migration: Similarly, Edward Britton and John Tavs of IBM expressed the large user's desire for easy (preferably transparent) cross-protocol interoperability and migration during a cutover. They also assert that the period of coexistence will likely be longer than most designers would like or expect.[10] 3.1.3 Policy-friendly: The IP protocol suite as designed by the ARPANET architects had narrow focus: it was intended to serve an experimental, best-effort datagram network for remote terminal access and resource sharing. IP today is being used far more broadly: for commerce, entertainment, and other uses. A consequence of its design scope has been a lack of native support for features like policy routing, security control, access control, service reservations and guarantees, and so on. A replacement protocol needs to address these shortcomings. 3.1.4 Multiprotocol support: The IP Internet has had such success serving as a host for other protocols that Britton and others have suggested that to succeed, IPng must provide equivalent or better functionality and must also be easily encapsulatable itself. 3.1.5 External motivations: Fleischman, in a discussion of users' reasons not to migrate to IPng, observes that many sites will not transition to a new protocol unless required to by upper management as part of an international standards or interoperability movement. The Internet user of 1994 is very different from the user of 1982, the time of the last protocol cutover. Today's network managers are less in academia and science than business, and business is driven by applications, not infrastructure. 3.2 Technical considerations Partridge and Kastenholz[11] outline a comprehensive list of technical requirements with which the IETF will evaluate IPng candidates, from the protocol designer's point of view. Other documents, by Britton, Taylor,[12] Vecchi,[13] Brazdziunas,[14] and Bellovin[15] consider narrower, often industry-specific, problems that IPng must address. 4. The contenders In the last few months, two contenders have emerged as the leading candidates for IPng. TUBA[16] and SIPP,[17] as a result of various protocol mergers and acquisitions over the last two years, are currently the primary alternatives to IP. The following feature-by-feature analysis of TUBA and SIPP Next-generation internetwork protocols Graven - 5 - addresses issues raised in the white papers and requirement documents mentioned in the previous section. Arguments in the requirement documents are heavily summarized; the inter- ested reader is referred to them and the big- internet@munnari.oz.au mailing list for further discussion. 4.1 General principles Kastenholz and Partridge express a desire for a ``lean'' network layer that offers the minimum capability necessary to function at layer three. Their reasoning is an applica- tion of the end-to-end argument:[18] the network layer do as little as possible and let higher and lower layers satisfy protocol and user demands. IPng should also be a ``long- lived'' protocol, sufficient to satisfy needs for at least the next twenty years, since users and vendors won't be willing to trade up their networking code often. SIPP's name implies one of its design goals in this area: it's designed to be a simple IP. The nominal SIPP header is lean: it's only a few bytes larger than the current IP header, while still encoding much larger addresses. The initial 64-bit address space ought to suffice for the near term, and extension facilities are defined if enlarging the space further becomes necessary. SIPP also has as a design feature the philosophy that the only system to do option processing should be the one addressed in the destination field; intermediate systems shouldn't need to look any fur- ther in the packet than the first few words. To this end, an arbitrary SIPP packet is composed of a payload encapsu- lated in n options, where the first option header contains as its payload the second option header plus its payload, which is composed of the third option header, and so on. Of course, if no options are needed, the simple case is that of a normal source/destination header and its associated pay- load, no more. The TUBA proposal addresses the leanness requirement by offering to fix the size of certain variable-length fields in the CLNP header, to aid fast routing and processing. This method, however, undercuts a primary scaling and life- time advantage of CLNP: its variable address length. In trying to be lean, TUBA seriously cripples itself. 4.2 Scaling It is estimated that the new protocol will eventually ser- vice between 109 and 1012 networks, or perhaps 1012 to 1015 end systems. Obviously, routing in such a large system requires a method that scales with O(<; Thu, 7 Jul 1994 16:47:33 -0400 Received: from ftp.com by ftp.com ; Thu, 7 Jul 1994 16:47:31 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 7 Jul 1994 16:47:31 -0400 Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA11245; Thu, 7 Jul 94 16:45:26 EDT Date: Thu, 7 Jul 94 16:45:26 EDT Message-Id: <9407072045.AA11245@mailserv-D.ftp.com> To: Brian.Carpenter@cern.ch Subject: Re: IPng Outline from Scott and Allison From: stev@ftp.com Cc: mankin@cmf.nrl.navy.mil, iesg@CNRI.Reston.VA.US, ipng@radegond.cmf.nrl.navy.mil Sender: stev@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Thu Jul 7 16:45:18 1994] Originating-Client: d-cell.ftp.com Content-Length: 3672 Brian says: > o - a new IPng working group be formed > (chairs not yet final) SHOUT: YOU MUST FIND AT LEAST ONE NON-US RESIDENT!! YOU MUST!! (even louder: NOT ME!!!) (*sigh*) being a WG chair is a considerable amount of work. there are few non-us residents running WG's because few volunteer. you cant force people to do these jobs, they do a lousy job if do. > o - an IPng Architect be named (Dave Clark) > job description: asking the exhaustive > questions, connecting all the points, > offering the broadest perspective, > but not making* architectural decisions, > that is the work of the wgs and the ietf. Call this job "IPng Reviewer". I had to leave before you finished this discussion in Chelmsford, but I find the word "architect" highly unfortunate. In fact the job description makes it clear this is NOT the architect. please leave the title alone. dave clark will do the "Right thing"(tm). > o - IPng address allocation procedures be described in > a document at the earliest possible time > participation from the IAB and IESG > led by IEPG? > first distribution of 10% IPng address space > to regional authorities be within this year > Make it 12.5%, it's a lot easier in binary! this is an amazing amount of a limited resource to be giving out, isnt it? > o - specific efforts be undertaken to facilitate the creation of > transition plans from other environments, including IPX > and CLNP. > (where the addresses are globally unique and allocated > along the lines of network topology) Too vague. I can't sell this in Europe. I *need* NSAPA embedding as a specifc goal or up-front option. this is probably a result of a conversation i had with scott when he called me to "divide and conquer" the IESG. these two groups had no names attached to them, but were still suggested as WGs. i noted that: 1) trying to fondle IPX without novell buyin was stupid. 2) trying to "convince" people to do these difficult jobs would be useless. as i noted above, unwilling chairs make bad WGs. 3) if the job needs to be done, people will come forward to do it. as a side note, i view the phrase "specific efforts be undertaken" as implying an "up front option". Fudge. SIPP and CATNIP have no reasom to continue. Either TUBA should shut down, or should be renamed TUNA (TCP and UDP over NSAP Addresses) and viewed as a coexistence tool to leverage Internet applications over CLNP infrastructure. Most of the basic TUBA work matches this approach very well. The less developed parts of TUBA (flows, multicast,...) could be moved to "historic" status. If you don't want to encourage this, close it down. this is interesting. i dont see much of a CLNP "infrastructure". but, i suppose this is an arguement for a time when we dont have something better to discuss . . . .:) I agree there is consensus that this is necessary. Is there consensus that it is sufficient? I don't think so, certainly not in the Directorate. Brian this echo's a note i saw from bound@dec. i suppose the position paper shoudl specify where the consensus is viewed as being . . . From rcallon@pobox.wellfleet.com Thu Jul 7 17:37:34 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (lobster.wellfleet.com [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA06547 for ; Thu, 7 Jul 1994 17:42:32 -0400 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA02470; Thu, 7 Jul 94 17:40:02 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA03237; Thu, 7 Jul 94 17:37:34 EDT Date: Thu, 7 Jul 94 17:37:34 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9407072137.AA03237@pobox.wellfleet> To: craig@aland.bbn.com, ipng@cmf.nrl.navy.mil Subject: Re: another view on IPng Also, if you violently disagree with this paper, please yell at me not Michael -- I asked him if he'd be willing to see it posted (since I thought folks might find it useful). If there are things you like -- feel free to drop him a note. Thanks! Craig; What if we violently disagree with only one part of the paper? I think that in the discussion of transition he completely missed the very serious problems that can be caused by translation. Some of us have seen these problems in real networks, and are very aware of how bad they can be. It is possible to solve these problems, but only if we are *VERY* careful about making sure that translation has *NO* semantic meaning, or we make sure that every semantic change, no matter how subtle, has fully understood effects and implications. I guess my main reaction to the paper was to feel very sad that the same very real problem, described over and over again by people who have seen the problems occur in real networks, does not necessarily cause smart people to actually listen. Ross From lixia@parc.xerox.com Thu Jul 7 16:28:45 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA07123 for ; Thu, 7 Jul 1994 19:29:46 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14657(2)>; Thu, 7 Jul 1994 16:29:02 PDT Received: by redwing.parc.xerox.com id <57153>; Thu, 7 Jul 1994 16:28:54 -0700 Date: Thu, 7 Jul 1994 16:28:45 PDT Sender: Lixia Zhang From: Lixia Zhang To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: Concern In-Reply-To: Your message of Wed, 6 Jul 1994 09:27:16 -0700 Message-ID: > My SAF/OAF suggestion (16 byte mandatory, NSAPA optional) has the same > problem, but with some chance that the option would be implemented > up-front by some vendors. Brian, Your msgs of the last few days push strongly for embedding NSAPA in IPng. However I do not recall this has ever been stated as a requirement previously. > However, my general sense is that if we do decide for variable length, > it has to be there from the start. If it is an add-on it will never > actually get added on. Really? I had thought differently. If it never gets added on, that's probably because no need to do so; it will be added when, and perhaps only when, the need rises. Lixia From lixia@parc.xerox.com Thu Jul 7 17:30:38 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA07349 for ; Thu, 7 Jul 1994 20:31:29 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14665(5)>; Thu, 7 Jul 1994 17:30:48 PDT Received: by redwing.parc.xerox.com id <57153>; Thu, 7 Jul 1994 17:30:43 -0700 Date: Thu, 7 Jul 1994 17:30:38 PDT Sender: Lixia Zhang From: Lixia Zhang To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: CLNP, one more time In-Reply-To: Your message of Wed, 6 Jul 1994 23:45:30 -0700 Message-ID: > You will never get a clear requirements statement for CLNP convergence, > because all the people who might be able to write one are in the > IETF camp anyway. My own requirements statement is very simple: > I need to run DECnet over the Internet, without redesigning our private > addressing plan. I believe we can do that inside a 16-byte address, > if DEC does what it has to do. So actually I don't care at all > about CLNP or NSAPAs as such. > > Brian ?? really? If this indeed the case, sorry I had got a wrong impression from your msgs of last couple of days. From brian@dxcoms.cern.ch Fri Jul 8 08:06:24 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA08630 for ; Fri, 8 Jul 1994 02:06:59 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA12305; Fri, 8 Jul 1994 08:06:26 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA24623; Fri, 8 Jul 1994 08:06:24 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407080606.AA24623@dxcoms.cern.ch> Subject: Re: Concern To: ipng@cmf.nrl.navy.mil Date: Fri, 8 Jul 1994 08:06:24 +0200 (MET DST) In-Reply-To: from "Lixia Zhang" at Jul 7, 94 04:28:45 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1234 Lixia, > > > My SAF/OAF suggestion (16 byte mandatory, NSAPA optional) has the same > > problem, but with some chance that the option would be implemented > > up-front by some vendors. > > Brian, > Your msgs of the last few days push strongly for embedding > NSAPA in IPng. However I do not recall this has ever been stated as a > requirement previously. > I would rather say that it has been stated often over the last 2 years, but ignored. It's not a message the IETF has wanted to hear. I have been thinking seriously in the last couple of weeks about how to present the IPng direction for European audiences, and my renewed comments about NSAPAs result from this. > > > However, my general sense is that if we do decide for variable length, > > it has to be there from the start. If it is an add-on it will never > > actually get added on. > > Really? I had thought differently. If it never gets added on, that's > probably because no need to do so; it will be added when, and > perhaps only when, the need rises. > Well yes, but it would be such a big change that it would actually initiate the IPngng discussion and a new transition; it is not a simple update like changing the TTL value (as in Greg's mail). Brian From iesg-request@ietf.cnri.reston.va.us Fri Jul 8 08:51:05 1994 Return-Path: iesg-request@ietf.cnri.reston.va.us Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA08772 for ; Fri, 8 Jul 1994 02:51:45 -0400 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18385; 8 Jul 94 2:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18381; 8 Jul 94 2:50 EDT Received: from dxmint.cern.ch by CNRI.Reston.VA.US id aa27680; 8 Jul 94 2:50 EDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24033; Fri, 8 Jul 1994 08:51:06 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA25825; Fri, 8 Jul 1994 08:51:05 +0200 Sender: iesg-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9407080651.AA25825@dxcoms.cern.ch> Subject: Re: IPng Outline from Scott and Allison To: ipng@cmf.nrl.navy.mil, iesg@CNRI.Reston.VA.US Date: Fri, 8 Jul 1994 08:51:05 +0200 (MET DST) In-Reply-To: <9407072045.AA11245@mailserv-D.ftp.com> from "stev@ftp.com" at Jul 7, 94 04:45:26 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5147 Stev , >--------- Text sent by stev@ftp.com follows: > > > Brian says: > > > o - a new IPng working group be formed > > (chairs not yet final) > > SHOUT: YOU MUST FIND AT LEAST ONE NON-US RESIDENT!! YOU MUST!! > > (even louder: NOT ME!!!) > > (*sigh*) being a WG chair is a considerable amount of work. there are > few non-us residents running WG's because few volunteer. you cant > force people to do these jobs, they do a lousy job if do. > Understood. But do you want to spend the next ten years selling less IPng in Europe, or worse seeing the Internet break? I am extremely concerned that IPng will be perceived like IP was, as some fiendish American attempt to get an unfair advantage over European industry. (Note the word "perceived" there.) This could have very negative effects indeed (why do you think we wasted so much time and money on OSI in research/education networks in Europe?). I believe that we have to work hard to get *real* international participation in the WGs. Certainly, a co-chair without motivation and spare time is useless. > > o - an IPng Architect be named (Dave Clark) > > job description: asking the exhaustive > > questions, connecting all the points, > > offering the broadest perspective, > > but not making* architectural decisions, > > that is the work of the wgs and the ietf. > > Call this job "IPng Reviewer". I had to leave before you finished > this discussion in Chelmsford, but I find the word "architect" > highly unfortunate. In fact the job description makes it clear > this is NOT the architect. > > please leave the title alone. dave clark will do the "Right thing"(tm). > Of course he will, whatever the job title is. > > o - IPng address allocation procedures be described in > > a document at the earliest possible time > > participation from the IAB and IESG > > led by IEPG? > > first distribution of 10% IPng address space > > to regional authorities be within this year > > > > Make it 12.5%, it's a lot easier in binary! > > this is an amazing amount of a limited resource to be giving out, isnt it? > OK, let's say 6.25% or 3.125% then! > > o - specific efforts be undertaken to facilitate the creation of > > transition plans from other environments, including IPX > > and CLNP. > > (where the addresses are globally unique and allocated > > along the lines of network topology) > > Too vague. I can't sell this in Europe. I *need* NSAPA embedding as > a specifc goal or up-front option. > > this is probably a result of a conversation i had with scott when he > called me to "divide and conquer" the IESG. these two groups had no > names attached to them, but were still suggested as WGs. i noted that: > > 1) trying to fondle IPX without novell buyin was stupid. > > 2) trying to "convince" people to do these difficult jobs would be useless. > as i noted above, unwilling chairs make bad WGs. > > 3) if the job needs to be done, people will come forward to do it. > > as a side note, i view the phrase "specific efforts be undertaken" as > implying an "up front option". > Yes. For me IPX is a practical issue (it will come if it's needed, and since it is needed, it will come). CLNP is what the French call a "false problem". My proposal is to add an NSAPA _option_ to IPng, knowing it would be inefficient, and suspecting that few vendors will implement it. (Let the market decide.) The reason for doing this "up front" is saleability of the proposal. > Fudge. SIPP and CATNIP have no reasom to continue. Either TUBA should > shut down, or should be renamed TUNA (TCP and UDP over NSAP > Addresses) and viewed as a coexistence tool to leverage Internet > applications over CLNP infrastructure. Most of the basic TUBA work > matches this approach very well. The less developed parts of TUBA > (flows, multicast,...) could be moved to "historic" status. If you > don't want to encourage this, close it down. > > this is interesting. i dont see much of a CLNP "infrastructure". but, > i suppose this is an arguement for a time when we dont have something > better to discuss . . . .:) > Oh yeah, it is just so that the TUBA people can do it if they want. Where's the harm? > > I agree there is consensus that this is necessary. Is there consensus that > it is sufficient? I don't think so, certainly not in the Directorate. > > Brian > > this echo's a note i saw from bound@dec. i suppose the position paper > shoudl specify where the consensus is viewed as being . . . > You saw Scott's posting of the straw poll, you can judge whether it's a consensus. Brian From brian@dxcoms.cern.ch Fri Jul 8 08:51:05 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA08769 for ; Fri, 8 Jul 1994 02:51:42 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24033; Fri, 8 Jul 1994 08:51:06 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA25825; Fri, 8 Jul 1994 08:51:05 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407080651.AA25825@dxcoms.cern.ch> Subject: Re: IPng Outline from Scott and Allison From lixia@parc.xerox.com Fri Jul 8 08:09:29 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA11671 for ; Fri, 8 Jul 1994 11:10:36 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14468(1)>; Fri, 8 Jul 1994 08:09:44 PDT Received: by redwing.parc.xerox.com id <57153>; Fri, 8 Jul 1994 08:09:39 -0700 Date: Fri, 8 Jul 1994 08:09:29 PDT Sender: Lixia Zhang From: Lixia Zhang To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: Concern In-Reply-To: Your message of Thu, 7 Jul 1994 23:06:24 -0700 Message-ID: > > Brian, > > Your msgs of the last few days push strongly for embedding > > NSAPA in IPng. However I do not recall this has ever been stated as a > > requirement previously. > > > I would rather say that it has been stated often over the last 2 years, > but ignored. It's not a message the IETF has wanted to hear. Here's my view: if it should be one of the requirements, then it should be stated in the requirement doc; if it cannot make there, then I do not consider it as a requirement. This whole IPng activity is under IETF umbrella. If one is questioning the basic judgment of IETF community, that'd be a very different issue. > I have been > thinking seriously in the last couple of weeks about how to present > the IPng direction for European audiences, and my renewed comments > about NSAPAs result from this. I certainly do not know European audience, so I'd really appreciate more voices from Europe on this concern (is Jon Crowcroft listening?) > > > However, my general sense is that if we do decide for variable length, > > > it has to be there from the start. If it is an add-on it will never > > > actually get added on. > > > > Really? I had thought differently. If it never gets added on, that's > > probably because no need to do so; it will be added when, and > > perhaps only when, the need rises. > > > Well yes, but it would be such a big change that it would actually > initiate the IPngng discussion and a new transition; it is not > a simple update like changing the TTL value (as in Greg's mail). I do not think the TTL value is a proper example here either. But on the other hand, once an address extension option is defined (presumbly together with transition strategy), could someone explain why changing it from optional to mandatory would have to initiate an IPngng discussion? From bound@zk3.dec.com Fri Jul 8 12:34:12 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA12528 for ; Fri, 8 Jul 1994 12:49:11 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA29289; Fri, 8 Jul 94 09:34:30 -0700 Received: by xirtlu.zk3.dec.com; id AA06325; Fri, 8 Jul 1994 12:34:18 -0400 Message-Id: <9407081634.AA06325@xirtlu.zk3.dec.com> To: Lixia Zhang Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: Concern In-Reply-To: Your message of "Fri, 08 Jul 94 08:09:29 PDT." Date: Fri, 08 Jul 94 12:34:12 -0400 X-Mts: smtp For what its worth as more input. I have to present to the European community and already am getting hate mail cause someone told two of my European customers Jim Bound said SIPP will replace DECnet. We are trying to chase down the source of this rumor and the customer will help us as this could have been very damaging to Digital and to my job. So its getting a bit intense I would say over the pond. The customers are fine and I have written personal letters with my field contacts in Europe and the customer understands whats up now. But I sure hope we can locate where that rumor started as its bad enough I would make a serious issue out of it from whereever it came. I think Brians mail is a real issue and we need to have a more International focus. But I need to understand how far are we to go based on what requirement to address the NSAP issue. Now if the IETF does nothing then I will present my own scenarios and have already started building them for my customer base. I would rather this be done by the IETF for Interoperability issues in a multivendor networking world. Right now I am assuming 16bytes. /jim From brian@dxcoms.cern.ch Fri Jul 8 18:41:38 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA12483 for ; Fri, 8 Jul 1994 12:42:14 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA13870; Fri, 8 Jul 1994 18:41:39 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA12828; Fri, 8 Jul 1994 18:41:38 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407081641.AA12828@dxcoms.cern.ch> Subject: Re: Concern To: ipng@cmf.nrl.navy.mil Date: Fri, 8 Jul 1994 18:41:38 +0200 (MET DST) In-Reply-To: from "Lixia Zhang" at Jul 8, 94 08:09:29 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1250 Lixia, > Here's my view: if it should be one of the requirements, then it > should be stated in the requirement doc; if it cannot make there, then > I do not consider it as a requirement. I thought we decided to take convergence requirements separately from the requirements doc? > > This whole IPng activity is under IETF umbrella. If one is > questioning the basic judgment of IETF community, that'd be a > very different issue. > When the IETF reaches consensus, I will accept it; but that doesn't stop me expressing what I think, does it? ... > > I certainly do not know European audience, so I'd really appreciate > more voices from Europe on this concern (is Jon Crowcroft listening?) > WADRT Jon, I am thinking about official Europe. They are definitely not on this list :-) (WADRT = with all due respect to) ... > I do not think the TTL value is a proper example here either. > But on the other hand, once an address extension option is defined > (presumbly together with transition strategy), could someone explain > why changing it from optional to mandatory would have to initiate an > IPngng discussion? > It wouldn't have to, it is just my feeling that it is likely to re-open the whole discussion. I could be wrong. Brian From mak@aads.net Fri Jul 8 13:36:14 1994 Return-Path: mak@aads.net Received: from aads.net (aads.com [198.111.96.42]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id NAA12903 for ; Fri, 8 Jul 1994 13:36:11 -0400 Received: from localhost (mak@localhost) by aads.net (8.6.5/aads1.1) id NAA19189 for ipng@cmf.nrl.navy.mil; Fri, 8 Jul 1994 13:36:14 -0400 From: Mark Knopper Message-Id: <199407081736.NAA19189@aads.net> Subject: BigTen to SIPP comparison To: ipng@cmf.nrl.navy.mil Date: Fri, 8 Jul 1994 13:36:14 -0400 (EDT) Reply-To: mak@aads.net X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7363 Hi. The following outlines the essential differences between the BigTen and SIPP packet formats. We should use this to understand what tradeoffs we are making and why. I think we need to be giving more feedback about our discussions on this issue to the wider community. Mark ------ Comparison between the BigTen and SIPP Packet Formats Yakov Rekhter, IBM Watson Peter Ford, Los Alamos National Laboratory Draft: 6 July, 1994 This is a preliminary attempt to document the differences between the BigTen and SIPP packet formats. We will attempt to document the rationale of the design decisions made in the BigTen packet format. It will be useful to collect the same rationale information for the SIPP design for the sake of analysis of the two protocols. It should be noted that BigTen and SIPP have many features in common. Both eliminate fragmentation as a primitive header function and both eliminate the header checksum found in IPv4. SIPP and BigTen use eight bit fields to encode protocol type and hop count field. Both proposals make use of an optional encapsulation header for security features such as authentication. Note that each design can further borrow from the other, for example both designs can use the protocol field to code other options following the initial packet header. Subsequent header processing is used by both SIPP and BigTen for extendability. 1. Address Format. SIPP uses fixed width, 16 byte, addresses. Any type of address (unicast, multicast, cluster, etc.) is coded in 16 bytes. High order bits of the address are used to encode the address type. Sixteen bytes is used to allow for host addresses that are autoconfigured in the same manner as IPX addresses, where the low order bytes code an end system identifier such an IEEE 802 MAC address. BigTen uses variable length addresses. BigTen addresses are multiples of 8 bytes to facilitate high speed processing and to preserve 64 bit alignment of address fields. The length of each address element is coded as part of the first byte. High order bits of the address are used to encode the address type. BigTen uses variable length addresses to accommodate a variety of types of addresses that are to be coded in address elements. Short encodings can be used yielding efficient resource utilization (e.g. bandwidth, storage for routing tables, memory access to data structures, etc.). Variable length encoding is cost effective over-engineering (e.g. insurance) that allows coding of long addresses where and when necessary. It is expected that globally unique unicast addresses will be coded as 16 bytes. Cluster addresses private unicast addresses, and "local use" unicast addresses (e.g. two systems living on the same wire or switch) can be coded in 8 bytes. Multicast addresses can be either 8 or 16 bytes. 2. Routing functionality. As the Internet evolves as a world-wide heterogeneous network with multiple service providers, the conventional hop-by-hop routing paradigm is not sufficient to address new requirements (see Unified, Nimrod). Both BigTen and SIPP advocate the use of source routing to augment hop by hop routing. SIPP will code source routes in an optional source routing header. A source route will be coded as a sequence of SIPP addresses, where a SIPP address will either be a cluster address or an unicast address. SIPP supports only loose source routing. The BigTen packet format explicitly codes source routes as part of the packet header. The source route is coded as a sequence of address elements in the header. Each element is either a cluster or a unicast address. The header has a field that points to the current active source routing element. BigTen supports both loose and strict source routing. Each address element carries an indication whether forwarding to the next element should be strict (share a common subnetwork) or loose. The BigTen packet format allows the source to specify packet handling in the case the source route can not be satisfied. The BigTen header allows the source to specify whether a router, that is not able to forward a packet as specified by the source route, should forward the packet based solely on the destination address, or whether the packet should be discarded. The source can mark a BigTen packet as to whether an error message should be sent back to the source in the event of source route failure. 3. Flow handling. SIPP has a flow-ID field of 24 bits. The field is always present in a SIPP header. A Flow ID is globally unique by catenating the SIPP source address with the contents of the flow ID field. The actual application of flow ids is currently subject to the outcome of the integrated services working group. BigTen has an optional flow-ID; a bit in the packet header specifies whether a 32 bit flow-ID is present. The actual application of flow ids is currently subject to the outcome of the integrated services working group. 4. Error notification Both SIPP and BigTen use ICMP style error reporting. As previously noted, the BigTen packet format permits the source to indicate whether error reporting is desired. If the source indicates that no error reporting is necessary, then the entity (e.g. router or end system) that detects an error does not send an error message back to the source. 5. Total length of a packet. The maximum packet length for a SIPP packet is 2^16. This conforms to the IPv4 packet length. The maximum allowed packet length with BigTen is 2^20. Increasing the maximum allowed packet length is important for improving the performance of applications requiring very high speed (Gbits to per second). There are TCP extensions developed to optimize TCP performance with high bandwidth delay products. Empirical data [4] shows a non-negligable improvement in TCP throughput as MTU changes from 32K to 64K (from 550 Mbits/sec to 631 Mbits/sec). 6. Spare bits in the header. All of the bits in the SIPP header are in use. Additional functionality will be coded as extension headers. The BigTen specification has 4 spare bits reserved for future use. Additional functionality can also be coded using options. 7.End to End Option Header BigTen defines an end to end option header that is used to encode options that are meaningful in the context of hosts. Routers will ignore this header. As illustration of this capability consider the following example: in the future you might want to pass the address of your own TCB to a peer so the peer can send it back to facilitate demultiplexing of reverse flow packets. This information will be carried as an option in the end to end option header where the type of option indicates that if the option is not "understood" the host must ignore it and continue processing the remainder of the packet. This allows upgrading of the protocol in a backward compatible manner. This appears to be a good way to satisfy future extension of IPng [1]. References: [1] Kastenholtz, F., Partridge, C., "Technical Criteria for Choosing IP:The Next Generation (IPng)", Internet Draft, draft-kastenholz-ipng-criteria-02.txt [2] Nicholson, A., Golio, J., Borman, D., Young, D., Roiger, W., "High Speed Networking at Cray Research", ACM CCR, Vol 21, No 1, January 1991 From bound@zk3.dec.com Fri Jul 8 14:23:19 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA13661 for ; Fri, 8 Jul 1994 14:33:08 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA03098; Fri, 8 Jul 94 11:23:34 -0700 Received: by xirtlu.zk3.dec.com; id AA08715; Fri, 8 Jul 1994 14:23:25 -0400 Message-Id: <9407081823.AA08715@xirtlu.zk3.dec.com> To: mak@aads.net Cc: ipng@cmf.nrl.navy.mil Subject: Re: BigTen to SIPP comparison In-Reply-To: Your message of "Fri, 08 Jul 94 13:36:14 EDT." <199407081736.NAA19189@aads.net> Date: Fri, 08 Jul 94 14:23:19 -0400 X-Mts: smtp Mark, This document will become null and void once Steve puts out the new SIPP draft based on 16bytes. So is this premature. I don't want to waste my time doing this twice. We have already done this internally so I will be interested if we agree with the technical content. p.s. Steve will we have a new SIPP doc shortly......... thanks /jim From bound@zk3.dec.com Fri Jul 8 14:24:59 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA13652 for ; Fri, 8 Jul 1994 14:31:39 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA03145; Fri, 8 Jul 94 11:25:10 -0700 Received: by xirtlu.zk3.dec.com; id AA08768; Fri, 8 Jul 1994 14:25:05 -0400 Message-Id: <9407081825.AA08768@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Big-10 Specs Date: Fri, 08 Jul 94 14:24:59 -0400 X-Mts: smtp Scott and Allison, Where does big-10 sit as a spec? Where does what Steve will do with 16byte SIPP sit as a spec? I think we will be asked this question and we need to asnwer this. I have already been asked and not sure what to say? thanks /jim From bound@zk3.dec.com Fri Jul 8 14:46:37 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA13897 for ; Fri, 8 Jul 1994 14:53:58 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA03808; Fri, 8 Jul 94 11:46:54 -0700 Received: by xirtlu.zk3.dec.com; id AA09480; Fri, 8 Jul 1994 14:46:43 -0400 Message-Id: <9407081846.AA09480@xirtlu.zk3.dec.com> To: bound@zk3.dec.com Cc: mak@aads.net, ipng@cmf.nrl.navy.mil Subject: Re: BigTen to SIPP comparison In-Reply-To: Your message of "Fri, 08 Jul 94 14:23:19 EDT." <9407081823.AA08715@xirtlu.zk3.dec.com> Date: Fri, 08 Jul 94 14:46:37 -0400 X-Mts: smtp Mark, Just in case when I said null and void I meant I only want to do the work toi compare the Big-10 spec agains one sipp doc. Not that >Big-10 would be null and void. /jim From bound@zk3.dec.com Fri Jul 8 16:55:46 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA15071 for ; Fri, 8 Jul 1994 17:04:53 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA08171; Fri, 8 Jul 94 13:56:01 -0700 Received: by xirtlu.zk3.dec.com; id AA13118; Fri, 8 Jul 1994 16:55:52 -0400 Message-Id: <9407082055.AA13118@xirtlu.zk3.dec.com> To: craig@aland.bbn.com Cc: ipng@cmf.nrl.navy.mil Subject: IPng Grad Student paper (Mike Graven) Date: Fri, 08 Jul 94 16:55:46 -0400 X-Mts: smtp Craig, I thought the paper was very good and useful. Please let Mike know. And thanks for sharing that with us. /jim From laylesto@IETF.CNRI.Reston.VA.US Fri Jul 8 16:18:55 1994 Return-Path: laylesto@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA14864 for ; Fri, 8 Jul 1994 16:45:14 -0400 Received: from [132.151.1.63] by IETF.CNRI.Reston.VA.US id aa09246; 8 Jul 94 16:13 EDT X-Sender: laylesto@ietf.cnri.reston.va.us Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Jul 1994 16:18:55 -0500 To: ipng@cmf.nrl.navy.mil From: Lois Keiper MMDF-Warning: Parse error in original version of preceding line at IETF.CNRI.Reston.VA.US Subject: IPng Teleconference, July 11 1994 Cc: laylestock@IETF.CNRI.Reston.VA.US Message-ID: <9407081613.aa09246@IETF.CNRI.Reston.VA.US> >UPDATE: > >The names marked with an asterisk are those who have confirmed participation >for the IPng teleconference scheduled for July 11, 1994 at 11:30 - 1:30 >EDT. *****It is very important that I receive your regret/RSVP so accurate >arrangements can be made with AT&T. It is most appreciated. Thank you. > > > > > J. Allard 206-936-9031 > Steve Bellovin 908-582-5886 > -Jim Bound REGRETS > Scott Bradner 617-495-3864 > Ross Callon 508-436-3936 *Brian Carpenter +41 22 767 4967* > Dave Clark 617-253-6003 John Crowcroft +44 71 380 7296 > *Steve Coya 703-620-8990* > John Curran 617-873-4398 > *Steve Deering 415-812-4839* > *Dino Farinacci 408-668-4696* > *Eric Fleischman 206-957-5334* > Paul Francis +81 33 928 0408 Frank Kastenholz 508-685-4000 > Daniel Karrenberg +31 20 592 5065 > Mark Knopper 313-741-5445 Craig Partridge 415-812-4415 > *Allison Mankin will call in* > *Greg Minshall 408-577-7511*(may call in) Rob Ullmann 617-693-1315 > *Lixia Zhang 415-812-4415* > > >If you need to be added to the teleconference call in progress, please call >1-800-232-1234 or for the international participants, 516-424-3151. The call >can be referenced by the confirmation number -ER21499 in the orginators name, >Steve Coya. > >Thanks > > >Lois > > > Lois J. Keiper IETF Secretariat From jcurran@nic.near.net Fri Jul 8 23:10:56 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA22099 for ; Fri, 8 Jul 1994 23:12:03 -0400 Received: from platinum.near.net by nic.near.net id aa06043; 8 Jul 94 23:12 EDT To: Lois Keiper cc: ipng@cmf.nrl.navy.mil, laylestock@ietf.cnri.reston.va.us Subject: Re: IPng Teleconference, July 11 1994 In-reply-to: Your message of Fri, 08 Jul 1994 16:18:55 -0500. <9407081613.aa09246@IETF.CNRI.Reston.VA.US> Date: Fri, 08 Jul 1994 23:10:56 -0400 From: John Curran Message-ID: <9407082312.aa06043@nic.near.net> -------- ] From: Lois Keiper ] Subject: IPng Teleconference, July 11 1994 ] Date: Fri, 8 Jul 1994 16:18:55 -0500 ] > ] >The names marked with an asterisk are those who have confirmed participation ] >for the IPng teleconference scheduled for July 11, 1994 at 11:30 - 1:30 ] >EDT. ] *****It is very important that I receive your regret/RSVP so accurate ] >arrangements can be made with AT&T. It is most appreciated. Thank you. Sorry folks; I will not be able to make this conference call. /John From yakov@watson.ibm.com Sun Jul 10 11:38:06 1994 Return-Path: yakov@watson.ibm.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA29733 for ; Sun, 10 Jul 1994 11:39:45 -0400 From: yakov@watson.ibm.com Message-Id: <199407101539.LAA29733@picard.cmf.nrl.navy.mil> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9113; Sun, 10 Jul 94 11:39:42 EDT Date: Sun, 10 Jul 94 11:38:06 EDT To: ipng@radegond.cmf.nrl.navy.mil Subject: NRENAISSANCE report and IPng Folks, I'd like to repost the following directly to the IPng Directorate. I would be interested to hear the Directorate's opinion on the relevance of the NRENAISSANCE commitee report to the IPng design, and if the report is viewed as relevant, then how the Directorate plans to deal with the issues brought by the report. Yakov. ****** The following is a COPY ***************************** Received: from murtoa.cs.mu.OZ.AU by watson.ibm.com (IBM VM SMTP V2R3) with TCP; Sun, 10 Jul 94 11:28:42 EDT Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA12049; Mon, 11 Jul 1994 01:26:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12003; Mon, 11 Jul 1994 01:06:39 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14430; Mon, 11 Jul 1994 01:06:35 +1000 (from yakov@watson.ibm.com) Message-Id: <9407101506.14430@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8985; Sun, 10 Jul 94 11:06:30 EDT Date: Sun, 10 Jul 94 11:05:06 EDT To: big-internet@munnari.oz.au, mankin@cmf.nrl.nay.mil, sob@harvard.edu Subject: IPng ADs Wish to Gauge Consensus on Address Length Requirements Ref: Your note of Thu, 7 Jul 1994 14:07:10 -0400 Folks, The following quote is from "Realizing the Information Future -- the Internet and Beyond" (NRENAISANNCE Committee Report): "The migration to a new address space will be a major upheaval that will affect users, network providers, and vendors. Unifying the various network communities, the Internet, the cable industry, and the telecommunications industry is an additional complex undertaking that will not happen unless there is a clear and explicit advantage. An effort to define a single overarching architecture is the only context in which this integration can be motivated. It will take careful consideration to plan and implement a scheme that properly resolves such major concerns as an appropriate addressing scheme, interim management actions, and migration plans. This implies that overarching architectural decisions for the NII, such as addressing, must be made in a context with an appropriate long-term vision and architectural overview. Wide-ranging discussion is needed on the requirements for next-generation integrated addressing, with the goal of determining what the scope of this coming address space should be. It is critical that the requirements be appropriately specified." Correct me if I am wrong, but I don't think that *today* we have "a single overarching architecture". Correct me if I am wrong, but I don't think that *today* we have "the requirements for next-generation integrated addressing". In absence of *both* the architecture *and* the requirements for next-generation intergrated addressing, the only way to define the IPng packet format *without* waiting for the architecture and the requirements is to make a guess. The guess needs to factor in the uncertainty about the architecture and the requirements. The guess suggested by Scott and Allison -- fixed length 16 bytes for all address types (unicast, cluster, multicast) that carries both EID and locator semantics seems to be too rigid and too constrained in view of the above. I think that a better (more flexible and less constrained) guess is the following: (a) Separate unicast EID from unicast locators, with unicast EID of fixed length and unicast locators of variable length (perhaps multiple of 8). (b) Cluster locators of variable length (perhaps multiple of 8). Yakov. P.S. Let me suggest that we'll pay a serious attention to the NRENAISSANCE committee report. The committee membership represents the top experts in networking (Leonard Kleinrock, Cynthia Braddon, Dave Clark, William Emery, Dave Farber, A.G. Fraser, Russell Hensley, Lawrence Landweber, Robert Lucky, Susan Nutter, Radia Perlman, Susanna Schweizer, Chales Taylor, Thomast West, Robert Kahn). From brian@dxcoms.cern.ch Sun Jul 10 19:04:17 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA29908 for ; Sun, 10 Jul 1994 13:04:51 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA13948; Sun, 10 Jul 1994 19:04:18 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA11126; Sun, 10 Jul 1994 19:04:17 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407101704.AA11126@dxcoms.cern.ch> Subject: Re: NRENAISSANCE report and IPng To: yakov@watson.ibm.com Date: Sun, 10 Jul 1994 19:04:17 +0200 (MET DST) Cc: ipng@radegond.cmf.nrl.navy.mil In-Reply-To: <199407101539.LAA29733@picard.cmf.nrl.navy.mil> from "yakov@watson.ibm.com" at Jul 10, 94 11:38:06 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 371 > > " Wide-ranging discussion is needed on the requirements for > next-generation integrated addressing, with the goal of > determining what the scope of this coming address space should > be. It is critical that the requirements be appropriately specified." > I bet that the charge to the committee that designed NSAPA format was much like this. Brian From bound@zk3.dec.com Mon Jul 11 01:22:39 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id BAA01926 for ; Mon, 11 Jul 1994 01:29:16 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA08846; Sun, 10 Jul 94 22:22:53 -0700 Received: by xirtlu.zk3.dec.com; id AA11840; Mon, 11 Jul 1994 01:22:45 -0400 Message-Id: <9407110522.AA11840@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: ipng@radegond.cmf.nrl.navy.mil Subject: Re: NRENAISSANCE report and IPng In-Reply-To: Your message of "Sun, 10 Jul 94 11:38:06 EDT." <199407101539.LAA29733@picard.cmf.nrl.navy.mil> Date: Mon, 11 Jul 94 01:22:39 -0400 X-Mts: smtp Yakov, I am sending this from White Mountains on PC from a Cabin then I am out of touch until July 18th. I guess you could say I am 'mobile' (like the song by the Who). >The following quote is from "Realizing the Information Future -- the >Internet and Beyond" (NRENAISANNCE Committee Report): >Correct me if I am wrong, but I don't think that *today* we have >"a single overarching architecture". We will with IPng its going down right now. >I think that a better (more flexible and less constrained) guess >is the following: > > (a) Separate unicast EID from unicast locators, with unicast EID of > fixed length and unicast locators of variable length (perhaps > multiple of 8). > (b) Cluster locators of variable length (perhaps multiple of 8). > I have been preaching (exactly) this since Februrary 94, but we would have to take the risk of breaking the IP model for scalability. See concerns by Dave Crocker and Bob Hinden in Big-I archives. Plus the Big-10 meeting you were at convinced me we don't know enough about EIDs and Locators right now to move this way right now. But this will be my I told you so card I will keep in my hip pocket. >P.S. Let me suggest that we'll pay a serious attention to the >NRENAISSANCE committee report. Well Craig Partidge sent us mail from one of his grad students that did an IPng recap and that was good input too. If you have not guessed I am not one to be impressed by credentials or names but rather what you are doing at that moment in time per the task at hand. So I consider this very valuable but I also consider valuable the conversations I have had with network systems managers, Jr Programmers, and some other individuals who are not even known by the world who work with IP every day. I am not saying its not important but a report does not and cannot alter my thinking after 1 year of hard work and working with the Directorate and many in the IETF to formulate my ideas and technical beliefs and finally the consensus I accept to begin the initial building blocks of IPng )---> 16bytes fixed. Of course after I hike 46 miles across the White Mountains and then ride my Harley Davidson through the Maine North Woods and down the New England Coast to come home and it being OK I only have a few pairs of underware and don't care if I don't take a bath I guess the above fits with my MO. And the above should make sense from where I sit. Whatever. Its pretty SIMPLE to me. Actually we do take showers at campgrounds when riding around. take care, /jim From brian@dxcoms.cern.ch Mon Jul 11 08:38:11 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA02071 for ; Mon, 11 Jul 1994 02:38:45 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA13384; Mon, 11 Jul 1994 08:38:13 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA20888; Mon, 11 Jul 1994 08:38:12 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407110638.AA20888@dxcoms.cern.ch> Subject: The discussion on big-i To: ipng@cmf.nrl.navy.mil Date: Mon, 11 Jul 1994 08:38:11 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 469 Directorate, I've been keeping a rough count of the people who have actually answered Scott & Allison's question. All the responses I have seen were on big-i, and I have ignored all messages that discussed the question rather than answering it. For what it's worth (not much, since only 13 people actually answered the question), what I noted was: 8 bytes are enough: 2 16 bytes fixed is fine: 6 variable is necessary: 4 need more than 16 bytes: 1 Brian From yakov@watson.ibm.com Mon Jul 11 08:42:02 1994 Return-Path: yakov@watson.ibm.com Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA03092 for ; Mon, 11 Jul 1994 08:44:19 -0400 From: yakov@watson.ibm.com Message-Id: <199407111244.IAA03092@picard.cmf.nrl.navy.mil> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3741; Mon, 11 Jul 94 08:44:16 EDT Date: Mon, 11 Jul 94 08:42:02 EDT To: bound@zk3.dec.com cc: ipng@radegond.cmf.nrl.navy.mil Subject: NRENAISSANCE report and IPng Ref: Your note of Mon, 11 Jul 94 01:22:39 -0400 Jim, >> I think that a better (more flexible and less constrained) guess >> is the following: >> >> (a) Separate unicast EID from unicast locators, with unicast EID of >> fixed length and unicast locators of variable length (perhaps >> multiple of 8). >> (b) Cluster locators of variable length (perhaps multiple of 8). > >I have been preaching (exactly) this since February 94... Could we agree that this is a *highly* desirable design objective ? >... but we would have to take the risk of breaking the IP model for >scalability. See concerns by Dave Crocker and Bob Hinden in Big-I >archives. I think that the issue of "breaking the IP model for scalability" deserves a careful analysis. May I suggest that perhaps a BOF at the IETF would be an appropriate way to make a progress on this issue. >Plus the Big-10 meeting you were at convinced me we don't know enough >about EIDs and Locators right now to move this way right now. The other side of your observation is that if we want to move right now, we better come up with a design that wouldn't "paint us in a corner" -- it should allow extensibility, especially in the area of addressing and routing (as these two functions are fundamental to the network layer). >I accept to begin the initial building blocks of IPng )--> 16 bytes >fixed. While it is ok to define "the initial building blocks" now, I would suggest that we better make this "initial building block" extensible *from the beginning*. Or otherwise, we have a good chance that the "initial building block" would at some point in the future turn into a stumbling block on the path of the evolution of the Internet. Yakov. From almes@ans.net Mon Jul 11 09:57:50 1994 Forwarded: Mon, 18 Jul 94 02:17:19 -0400 Forwarded: "sob@harvard.edu " Return-Path: almes@ans.net Received: from interlock.ans.net (interlock.ans.net [147.225.1.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA03696 for ; Mon, 11 Jul 1994 09:57:55 -0400 Received: by interlock.ans.net id AA43996 (InterLock SMTP Gateway 1.1 for mankin@cmf.nrl.navy.mil); Mon, 11 Jul 1994 09:57:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 11 Jul 1994 09:57:52 -0400 Date: Mon, 11 Jul 94 9:57:50 EDT From: Guy Almes Cc: almes@ans.net Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements In-Reply-To: Your message of Thu, 7 Jul 1994 14:07:30 -0400 To: IPng Area Directors Message-Id: Scott and Allison, First the short answer and then a (fairly short) rationale. I believe an 8-byte fixed-length address is the best option, but would also be happy with 16-byte fixed-length address as a compromise. Rationale: I note from the IPv4 CIDR effort that Internet engineers can work well to work within a fixed-length space, and that they can creatively make use of the variable-length prefix notion within a fixed-length total address size. There is thus *no global design for field sizes* within CIDR, and this is all for the good. I believe that, with some coordination and discipline we could do the same within a 8-byte fixed-length address for the indefinite future. I observe, however, that when the 16-byte fixed-length idea was floated widely after the Chicago meeting, many otherwise sane members of the community came forward with plans for using the larger address, not to support scaling or longevity issues, but to make working within it more convenient or for solving other problems that have nothing to do with primary ROAD issues. I don't mean to suggest that all proposals had this property, but the general pattern left me with the uncomfortable feeling that the extra 8 bytes would be spent on avoiding the need for Internet discipline and coordination, and that in the long run we'd be no further toward meeting our ROAD objectives. I therefore advocate 8-byte fixed-length in principle, with the understanding that this would require some discipline and coordination. If, having tried to work within this framework, the honest belief is that 16 bytes are needed, then I'd *readily* accept the larger address. In short, I support working within a large fixed-length address space with the understanding that discipline and coordination in the spirit of CIDR will be required for a healthy Internet in the future. I believe 8 bytes would suffice, but would go for 16 bytes if the consensus is that that would be needed *even with discipline and coordination*. I fear that variable-length addresses would make it too easy to quickly get into a world where 'taking the easy path' would tend to make these addresses quite large. I similarly fear that fixed-length addresses that are too large would lead to the theoretical gains being frittered away too easily. -- Guy From brian@dxcoms.cern.ch Wed Jul 13 09:01:30 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id DAA20386 for ; Wed, 13 Jul 1994 03:02:05 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA19779; Wed, 13 Jul 1994 09:01:50 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA20041; Wed, 13 Jul 1994 09:01:31 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407130701.AA20041@dxcoms.cern.ch> Subject: What to do? To: ipng@cmf.nrl.navy.mil Date: Wed, 13 Jul 1994 09:01:30 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 489 Directorate, It is fairly clear that the variable v. fixed debate will not reach a conclusion in the Toronto BOF. I am coming to the view that the best chance of consensus is Lixia's (if I remember correctly) proposal, i.e. 16 byte fixed recommended, 8-24-32 optional but not implemented. Whether or not to exercise the option could be an ongoing WG discussion for the next few decades. (Of course, an NSAPA format could be a sub-option, so everybody is happy in some sense.) Brian From jallard@microsoft.com Wed Jul 13 18:06:39 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA27720 for ; Wed, 13 Jul 1994 21:11:46 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA28722; Wed, 13 Jul 94 18:12:05 -0700 Message-Id: <9407140112.AA28722@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Wed, 13 Jul 94 18:12:05 PDT X-Msmail-Message-Id: 59FC9D6D X-Msmail-Conversation-Id: 59FC9D6D From: "James 'J' Allard" To: ipng-request@cmf.nrl.navy.mil Date: Wed, 13 Jul 94 18:06:39 TZ Subject: RE: Ipng Teleconference July Monday 18, 1994 | ******It is very important that I receive your regret/RSVP so accurate | arrangements can be made with AT&T. We are trying to avoid further delays | and improve communications. Thank you. sign me up. hey, what happened to the last name there? _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From smb@research.att.com Wed Jul 13 07:24:40 1994 Return-Path: smb@research.att.com Received: from research.att.com ([192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA21008 for ; Wed, 13 Jul 1994 07:25:41 -0400 From: smb@research.att.com Message-Id: <199407131125.HAA21008@picard.cmf.nrl.navy.mil> Received: by gryphon; Wed Jul 13 07:24:41 EDT 1994 To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: What to do? Date: Wed, 13 Jul 94 07:24:40 EDT Directorate, It is fairly clear that the variable v. fixed debate will not reach a conclusion in the Toronto BOF. The only chance is for Paul Francis's suggestion: that folks try to find something that just won't work with the other proposal. I am coming to the view that the best chance of consensus is Lixia's (if I remember correctly) proposal, i.e. 16 byte fixed recommended, 8-24-32 optional but not implemented. Whether or not to exercise the option could be an ongoing WG discussion for the next few decades. Although I support variable-length addresses, I don't think this will fly. As others have pointed out, the code is too likely to be buggy or even unimplemented, and we won't know till it's too late. I personally find this to be a much stronger argument against variable length addresses than the performance issue (though given my vote, which I'm not changing, I don't find it persuasive). From lixia@parc.xerox.com Wed Jul 13 06:50:29 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA21713 for ; Wed, 13 Jul 1994 09:51:39 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14438(1)>; Wed, 13 Jul 1994 06:50:48 PDT Received: by redwing.parc.xerox.com id <57153>; Wed, 13 Jul 1994 06:50:43 -0700 Date: Wed, 13 Jul 1994 06:50:29 PDT Sender: Lixia Zhang From: Lixia Zhang To: Brian.Carpenter@cern.ch Subject: Re: What to do? In-Reply-To: Your message of Wed, 13 Jul 1994 00:01:30 -0700 Cc: ipng@cmf.nrl.navy.mil Message-ID: > Directorate, > > It is fairly clear that the variable v. fixed debate will > not reach a conclusion in the Toronto BOF. You mean, *not everyone* will agree on one solution. (isn't that what "rough" means in Dave Clark's famous "rouhg consensus" quote? :-) > I am coming to the view that the best chance of consensus > is Lixia's (if I remember correctly) proposal, i.e. > 16 byte fixed recommended, 8-24-32 optional but > not implemented. Whether or not to exercise the option > could be an ongoing WG discussion for the next few decades. What I suggested is to *study* and add options. I more and more feel that, if we bother to go variable, the current 8-24-32 proposal does not go far enough, e.g. not extensible to the left, not possible for *unlimited* growth (as people have falsely believed, that if they go variable this time, they'd be done once and forever). I do not think adequate research has been done on the topic, so variable size is *not* ready for prime time yet (more fundamental open issues, not just implementation concern). From brian@dxcoms.cern.ch Wed Jul 13 17:37:59 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA22728 for ; Wed, 13 Jul 1994 11:38:37 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA26673; Wed, 13 Jul 1994 17:38:19 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA02467; Wed, 13 Jul 1994 17:38:00 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407131538.AA02467@dxcoms.cern.ch> Subject: Re: IPng ADs Wish to Gauge Consensus on Address Length Requirements To: ipng@cmf.nrl.navy.mil Date: Wed, 13 Jul 1994 17:37:59 +0200 (MET DST) In-Reply-To: <9407131525.AA01103@ginger.lcs.mit.edu> from "Noel Chiappa" at Jul 13, 94 11:25:01 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 804 (Brian) > Which prejudices me in favour of topologically meaningful, hierarchical > locators. Which will tend to be longer than the mathematical minimum. > (Noel) > Exactly... but do you believe that these are inherently variable length things, > which we are trying to represent in a fixed-length field? > I was trying to avoid that particular part of the debate. But yes, you are correct, if it matters. Which it doesn't, if the fixed length is long enough. (Steve D) > Nobody is arguing for anything other than topologically meaningful, > hierarchical locators. If you think that my arguments are based on > *not* having topologically meaningful, hierarchical locators, you > need to do a reset. > NO, I think the argument is about the minimum length to painlessly achieve them. Brian From scoya@CNRI.Reston.VA.US Wed Jul 13 17:38:28 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA26990 for ; Wed, 13 Jul 1994 18:41:13 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12633; 13 Jul 94 17:41 EDT To: ipng@cmf.nrl.navy.mil cc: lkeiper@CNRI.Reston.VA.US Subject: Telechats Date: Wed, 13 Jul 94 17:38:28 -0400 From: Steve Coya Message-ID: <9407131741.aa12633@IETF.CNRI.Reston.VA.US> Folks, Lois will be sending out the announcement for Monday's telechat in a few minutes. PLEASE let her know if you will or will not be participating, and whether or not you will be calling on or waiting for the call. If you're waiting for the call, please try to answer personally (as opposed to delegating to the answering machine). However, it is far more important to let us know if you will or won't be participating and, if you will, if you'll be calling in. Thanks. Steve From rcallon@pobox.wellfleet.com Wed Jul 13 18:57:09 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA27095 for ; Wed, 13 Jul 1994 19:02:26 -0400 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA20197; Wed, 13 Jul 94 18:59:30 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA10528; Wed, 13 Jul 94 18:57:09 EDT Date: Wed, 13 Jul 94 18:57:09 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9407132257.AA10528@pobox.wellfleet> To: ipng@cmf.nrl.navy.mil, laylesto@IETF.CNRI.Reston.VA.US Subject: Re: Ipng Teleconference July Monday 18, 1994 >> Ross Callon regrets I will be out of town, at the ATM Forum meeting in California. Ross From laylesto@IETF.CNRI.Reston.VA.US Wed Jul 13 18:11:25 1994 Return-Path: laylesto@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA26999 for ; Wed, 13 Jul 1994 18:41:40 -0400 Received: from [132.151.1.63] by IETF.CNRI.Reston.VA.US id aa12903; 13 Jul 94 18:06 EDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Jul 1994 18:11:25 -0500 To: ipng@cmf.nrl.navy.mil From: Lois Aylestock Subject: Ipng Teleconference July Monday 18, 1994 Cc: laylestock@IETF.CNRI.Reston.VA.US Message-ID: <9407131806.aa12903@IETF.CNRI.Reston.VA.US> > >>ANNOUNCEMENT > >> >>The names marked with an asterisk are those who have confirmed participation >>for the IPng teleconference scheduled for July 18, 1994 at 11:30 - 1:30 >>EDT. ******It is very important that I receive your regret/RSVP so accurate arrangements can be made with AT&T. We are trying to avoid further delays and improve communications. Thank you. >> >> >> >> >> J. Allard 206-936-9031 >> Steve Bellovin 908-582-5886 >> Jim Bound 603-881-0400 >> Scott Bradner 617-495-3864 >> Ross Callon 508-436-3936 > Brian Carpenter +41 22 767 4967 >> Dave Clark 617-253-6003 > *Steve Coya 703-620-8990* >> John Curran 617-873-4398 >> Steve Deering 415-812-4839 >> Dino Farinacci 408-226-6870 >> Eric Fleischman 206-957-5334 >> Paul Francis +81 33 928 0408 > Mark Knopper 313-741-5445 > Allison Mankin 202-404-7030 >> Greg Minshall 408-577-7511 > Rob Ullmann 617-693-1315 >> Lixia Zhang 415-812-4415 >> >> >>If you need to be added to the teleconference call in progress, please call >>1-800-232-1234 or for the international participants, 516-424-3151. The call >>can be referenced by the confirmation number -ER16042 in the orginators name, >>Steve Coya. >> >>Thanks >> >> >>Lois >> >> >> > >Lois J. Keiper >IETF Secretariat > > From brian@dxcoms.cern.ch Thu Jul 14 14:26:02 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA29773 for ; Thu, 14 Jul 1994 08:26:37 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA26818; Thu, 14 Jul 1994 14:26:23 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA01891; Thu, 14 Jul 1994 14:26:02 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407141226.AA01891@dxcoms.cern.ch> Subject: NSAPAs, inside and outside To: ipng@cmf.nrl.navy.mil Date: Thu, 14 Jul 1994 14:26:02 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2642 We don't do design in the Directorate, but I'm not brave enough to send this to big-i. Anybody able to review this? Brian 1. NSAPAs inside a 16-byte IPng address The first byte is an IANA-assigned code meaning "this IPng address embeds a 15-byte NSAPA". The alignment is a mess, but no worse than in a 20-byte NSAPA. 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 |NSAPA code TBD | AFI | IDI (ICD or DCC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | Prefix (3 octets) | Area (octet 0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | Area (octet 1)| ID (octets 0 through 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| ID (octets 3 through 5) | NSEL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The AFI will normally be 39 (DCC, digital country code) or 47 (ICD, international code designator). The longest prefixes in use today, to my knowledge, are 4 octets in NORDUNET (the Nordic academic network), so they would have to squeeze down to 3 octets. Are there any cases where a 3 octet prefix is unthinkable? 2. 16-byte IPng addresses inside a 20-octet NSAPA The first three octets are an IDP meaning "this NSAPA embeds a 16 byte IPng address" and the last octet is a dummy selector. Sorry about the alignment, but it seems very risky 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) | IPng (byte 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | IPng (bytes 1-4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | IPng (bytes 5-8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| IPng (bytes 9-12) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16-19| IPng (bytes 13-15) | NSEL = dummy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- From jallard@microsoft.com Thu Jul 14 16:49:04 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA06379 for ; Thu, 14 Jul 1994 19:54:30 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA13673; Thu, 14 Jul 94 16:54:55 -0700 Message-Id: <9407142354.AA13673@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Thu, 14 Jul 94 16:54:54 PDT X-Msmail-Message-Id: E1C10571 X-Msmail-Conversation-Id: E1C10571 From: "James 'J' Allard" To: ipng-request@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Date: Thu, 14 Jul 94 16:49:04 -0400 Subject: FW: summary of Big-Internet messages |Thanks very much to Bill Simpson who sent us this summary of the traffic |on the big-i list since we made our request. this seems heavily biased since peter ford, david piscitello, and myself were very public in our opinion with regard to v.l. and we're not mentioned in the survey. i think it's irresponsible to post something like this w/o confirmation of its accuracy from a source or two. i didn't bother to keep the postings, but i certainly know of the three i mention. which would change the perceived balance dramatically. i'm not sure what the motivation behind this summary was, but i question it's accuracy. gee, i wonder what camp bill is in? fixed 16- "concensus" is easy to find if that's what you're looking for. i'm not trying to whine, but using bill simpson as the judge and jury, especially given the blatently unprofessional nature of his postings in the past is bogus. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From jallard@microsoft.com Thu Jul 14 17:04:33 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA06465 for ; Thu, 14 Jul 1994 20:09:53 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA14440; Thu, 14 Jul 94 17:10:23 -0700 Message-Id: <9407150010.AA14440@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Thu, 14 Jul 94 17:10:22 PDT X-Msmail-Message-Id: C1A00C84 X-Msmail-Conversation-Id: C1A00C84 X-Msmail-Fixed-Font: 0001 From: "James 'J' Allard" To: ipng@cmf.nrl.navy.mil Date: Thu, 14 Jul 94 17:04:33 -0400 Subject: FW: summary of Big-Internet messages |Thanks very much to Bill Simpson who sent us this summary of the traffic |on the big-i list since we made our request. We thought that it would |be of interest and Bill agreed to let us send it out. for the record, i find this "survey" meaningless. there were at least 3 postings which (ironically) contradicted bill's personal position which were not reflected here. we cannot draw conclusions based on this perceived "consensus". i think all of you know how i feel and saw my personal posts to big-i. you will note i am not mentioned in the vl debate. imho this should have been validated by at least one believer in each of the camps before it was posted for accuracy if we were to draw any conclusions. of course if this is how we are going to make decisions, i'll start urging those which agree with me to post "me too" mail just so that their vote is counted. if we really wanted to be democratic, and bill simpson is so willing to help out, he could write a little app that people could telnet to and cast their vote based on email address. 1 vote per big-internet member or registered ietf attendee. hell, we could let people vote at checkin in toronto if we really wanted to know. (of course it would be a zoo at the registration lines w/ peter giving out tuba posters and deering w/ his sipp buttons :) if we got >50% response, i'd believe the numbers. given the number of people involved in the ietf, 12 people don't represent the majority in my book. we should be a little more scientific here, many people simply don't post their opinions. given the unprofessional and inflammatory nature of the responses, it is fairly obvious why this is. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From ericf@atc.boeing.com Thu Jul 14 17:57:38 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA06668 for ; Thu, 14 Jul 1994 20:55:23 -0400 Received: by atc.boeing.com (5.57) id AA18423; Thu, 14 Jul 94 17:57:38 -0700 Date: Thu, 14 Jul 94 17:57:38 -0700 From: Eric Fleischman Message-Id: <9407150057.AA18423@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: My response to Bill Simpson's Poll Dear Scott and the IPng Directorate, Even if Bill's polling is accurate and most people do indeed support 8 byte fixed addresses, his poll didn't summarize the extent of the feelings and evidence involved. That is, I wish to affirm that *I* am personally unable to support an 8 byte fixed addressing schema as defined by pre-compromise SIPP for IPng. As I said at the Big-10 and reiterated in my subsequent write-up's during the past few months, the "pre-compromise" version of SIPP is demonstrably broken and will not work as defined. In my mind, it is NOT a viable IPng alternative for that reason. I am unable to support such an IPng because to do so would be to support something that I *KNOW* to be broken. It simply will not work as defined. I state this as my strong personal conclusion and I also state this as Boeing's official spokesman to the IETF. While I recognize that there are many users with many perspectives and that Boeing's opinion is of perhaps little significance in the overall scheme of things, it is perhaps not hybris to state that such an 8 byte fixed address decision for IPng would cause IPng to be dead on arrival. Certainly, corporations who felt comfortable with OSI will not be likely to accept such an IPng. After all, the ability to weather unforeseen growth and the flexibility of CLNP's address space to support our private enterprise networks is a fundamental reason why CLNP was so popular with the corporate mindset -- and, of course, it's international acceptance. I believe that once vendors realize the strong feelings of certain segments of the Fortune 1000 on this matter, it will be doubtful if these vendors would subsequently devote too many resources on developing products to support this technology. Thus, such an IPng may never actually "arrive" at all. After all, a working IPng would be a "hard sell" to begin with. But a broken one? Let's not waste our time. Sincerely yours, --Eric Fleischman From ericf@atc.boeing.com Thu Jul 14 17:58:47 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA06677 for ; Thu, 14 Jul 1994 20:56:30 -0400 Received: by atc.boeing.com (5.57) id AA18450; Thu, 14 Jul 94 17:58:47 -0700 Date: Thu, 14 Jul 94 17:58:47 -0700 From: Eric Fleischman Message-Id: <9407150058.AA18450@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: My written BIG-10 position Network Working Group Eric Fleischman Request for Comments: draft Boeing Computer Services IPng Directorate Evaluation Opinion May 7, 1994 (modified July 12, 1994) An IPng Evaluation Table of contents 1.0 Bottom Line 2.0 My IPng "Hot Buttons" 3.0 Reasons for my Conclusion 3.1 CATNIP 3.2 TUBA 3.3 SIPP 4.0 Why I think SIPP's 8 byte Addresses Are Too Small 5.0 Anatomy of a Personal Bias -- or How I Got Here 1.0 Bottom Line. I believe that TUBA is the only possible alternative available today to be selected as the IPng if one is to base the selection upon the current "specifications" of the IPng alternatives. I state this because I believe that SIPP is demonstrably "broken as currently defined" and CATNIP lacks the necessary maturity/support to be a viable alternative. 2.0 My IPng "Hot Buttons" I have only a few personal "hot buttons" concerning IPng which need to be explicitly noted "up front" for the reader to understand my built-in biases and presuppositions: 1) IPng must work -- and work very well. 2) IPng must be simple, easy-to-use, scale-able, expandable and endure several decades. 3) IPng must have a large address space. I can not believe 8 bytes are adequate for the world-wide Internet in 2010. I prefer 16 bytes if we must have a "one size fits all" approach. I greatly prefer variable length addressing. 4) IPng must have enhanced functionality over IPv4 so that users will want to deploy it instead of IPv4 -- either that or it must have workable (non-broken) IPAE-like element so that users won't know that they have deployed it. 5) IPng must be able to serve as a convergence protocol upon which all datagram technologies may eventually converge. It should be "one protocol to bind them all." 6) IPng represents substantial (i.e., unbelievably high) potentially non-value added expense for large end users. There had better be an awfully good reason for us to deploy IPng -- and it had better endure for several decades if there is any hope for us to justify such a deployment via cost/benefit analysis. For this reason, IPng is a "hard sell" and our vendors had better plan on supporting IPv4 for some time to come -- unless IPng is bundled with "killer applications" or something very surprising happens to the market. 3.0 Reasons for My Conclusion As one goes down the list of IPng criteria requirements, all three alternatives really appear "pretty much of a wash". I found that my grading of the various options vis-a-vis the requirements was more a function of my own world view rather than a function of the requirements and alternatives themselves (i.e., the requirements-to-alternatives mapping was really not definitive and demonstrable except on personal-world view interpretations) -- except when it came to my still controversial business requirements. This exercise again reaffirmed to me that each of the proposals have very different underlying assumptions and world-views which makes comparing them somewhat like comparing apples and oranges. Thus, I found that it was very difficult to make any decision what-so-ever and that any decision was not based -- in the general case -- upon the type of evidence which I would have preferred. The following is a partial summary of how I ultimately concluded that TUBA was the best alternative. Fleischman, Expires December 1, 1994 [Page 1] draft-ipng-directorate-fleischman-review-00.txt May 1994 I concluded that it was not possible to assert that any one protocol definitely could support "hot new technologies" better than any other -- though, I expect that SIPP -- and perhaps CATNIP -- could probably do so cleaner than TUBA. But even that is contentious. And is the difference enough to matter? Probably not. That is, Paul Francis told me in Amsterdam that he thought that PIP would only improve on IPv4's performance by 20% -- I doubt if that is an adequate performance boost to "sell" the technology. Thus, concerning the single most important facet affecting the IPng decision (i.e., technologies compelling users to want to deploy the protocol) it was pretty much of a wash -- unless I have overlooked something somewhere. I believe that TUBA and CATNIP are the obvious convergence targets because they leverage off of protocols which are deployed and towards which many deployment plans exist. However, my trouble understanding CATNIP and the fact that CATNIP itself is not yet deployed makes me prefer to restate the previous sentence in terms of TUBA alone. My own personal sense of urgency concerning making the IPng decision comes from my belief that toasternet is going to appear soon. In fact, I believe that both CDPD and EPRI are toasternet vanguards. I am interested in the fact that both technologies chose OSI allegedly because they thought that CLNP was the only existing network layer technology which could scale to meet their needs. [Note: in EPRI's case I suspect a strong bias towards OSI was also a significant reason. Maybe this is also true with CDPD since it is coming from phone companies? I don't know, but I am suspicious.] This implies that other toasternets selected/deployed before IPng becomes deployable may similarly conclude that CLNP was the best option. This possibility implies that the TUBA alternative would provide for them the most minimal migration possible to connect to the new Internet infrastructure. Thus, TUBA seems to be the best choice for supporting the two "toasternet" applications which have appeared to date and may similarly naturally resonate with the other toasternets which may soon appear. Now to partially evaluate CATNIP, TUBA, and SIPP in order. ------------------ 3.1 CATNIP. I am concerned that I was not able to really understand how CATNIP will actually work. [This may be an indictment against my technical competence but I believe it shows that CATNIP is "rather" complex -- and I am a believer that complexity in protocols is not a positive attribute.] I believe that CATNIP has the "best vision" (according to my biases) in that it was explicitly seeking to join three important communities (IPv4, NetWare, CLNP). However, it does not have enough popular support to permit it to be selected as the IPng. "What type of reason is this?!?", you may ask. My answer: the Internet is run by rough consensus and working code and there are too few CATNIP advocates to form a basis for rough consensus -- and I know of no working code. In any case, the CATNIP working group sessions were always sparsely attended. Only a handful of people ever actually participated in the development of the CATNIP specifications. This doesn't mean that the spec isn't the greatest thing since sliced bread but it does mean that the CATNIP vision has not caught the fancy of more than a few of us. And while I recall that Rob Ullmann (under the auspices of Process Technology) was developing TP-IX Fleischman, Expires December 1, 1994 [Page 2] draft-ipng-directorate-fleischman-review-00.txt May 1994 code, I am not aware of any "running code" for CATNIP. Even worse, TP-IX was re-defined to CATNIP roughly a half a year ago meaning that the specification is not is mature as I would like for an IPng selection. All this leads me to say that it is my belief that CATNIP is inadequately mature with inadequate "proof of concept" (i.e., running code) to be selected as the IPng. Also, Paul Francis' comment below (if indeed accurate) points out that CATNIP can not perform everything claimed for it. This makes me wonder how else the reality would differ from the "marketing": > However, a CATNIP box *cannot* >translate between IP and C-NSAP (where C-NSAP is an NSAP address in CATNIP >form). This is because the NSAP address cannot (easily) be expressed in >only 32 bits, and therefore the IP host cannot "address" the C-NSAP host. ------------------ 3.2 TUBA. TUBA [and SIPP], on the other hand, has an impressive array of "running code" on a wide variety of platforms. TUBA is the most "mature" IPng option. It is by far the easiest option to "deploy" in the sense that the TUBA-network layer software (CLNP) is already supported by almost every router vendor and by many of the network service providers today. Of course, there is still a lot of host software work to be done by the host the vendors (and by us users) but there is no more to do in that domain than for any other alternative. Most importantly from my point-of-view: *I* have personal confidence that the TUBA option will work because I have practical experience using the OSI network layer upon which it is based. Thus, I believe that it has the lowest risk factor of all of the options since it based upon technology which has already "been made deployable" in production environments. That is, when technology is defined the vendors subsequently have to do a great amount of work to make it product-ready. This often takes years. Once it is product-ready then we large users must work out numerous the bugs and hidden "features" with our vendors in a time-consuming but necessary joint effort to "make it deployable" in our production environments. Our experience in Boeing is that it usually takes two years for us to make a stable product "become deployable" -- though some products never achieve this status. In any case, this overhead has already been endured by us --and many others-- for CLNP. On the other hand, I have NOT appreciated the attitude of the TUBA working group of late. Up through the Amsterdam IETF they were a dynamic group accomplishing an impressively large amount of work. Their demo in Amsterdam was extremely satisfying. However, since then they have done virtually nothing. They have essentially "quit". They either did not -- or belatedly -- addressed the IPng requirements. Their standard answer to the "new technology" requirement is "we'll design it once we know how to do so". Mind you, I believe that IS a VALID answer (i.e., don't design half-cocked) but I expect at least examples of what they might do based upon our current belief-structure. That is, even though we may not know how best to implement flows, but we do *believe* certain things about flows AS A COMMUNITY and these things should be addressed at least as possible options such as was done by PIP, SIP, CATNIP, and SIPP -- in fact, by every other group. Even more telling, at the Seattle IETF I concluded that the core members of the TUBA group had largely "burned out" and that the TUBA working group as a whole had ceased to function as a viable working group. Certainly, their meetings were long, unproductive, contentious, and without hope (at least *I* lost hope) that they would ever come to consensus on anything. Fleischman, Expires December 1, 1994 [Page 3] draft-ipng-directorate-fleischman-review-00.txt May 1994 Now back to technology: I believe that many of the basic CLNP ideas are excellent and that it is solid and mature technology. However, I find the following faults with CLNP: 1) I firmly believe in extensible addressing however the OSI NSAP structure of ISO 8348 Addendum 2 -- and the subsequent modification removing the preferred decimal encoding (Addendum 4?) -- has gone much too far. There is such a thing as "too much of a good thing" becoming a bad thing: Seven distinct basic format types (X.121, ISO DCC. F.69, E.163, E.164, ISO 6523-ICD, and Local) are defined with permitted variations in each of these themes. This extreme variability is counterproductive. I do not want to think of my end systems and my routers having to support such needless overhead. Fortunately, very few (if any) of the truly absurd possible permutations have actually been deployed or assigned. However, should TUBA become IPng then the IETF must restrict the permitted NSAP structures to a small subset of what is currently permitted by ISO if "sanity" and "aggregation" is to be achieved. 2) The N-Selector has been a perennial problem for CLNP. Radia Perlman's book has several pages devoted to this issue. It has been a gnawing source of confusion to us CLNP users as well. I object to the mentality which it represents that the network address should identify the transport protocol used. Not! Rather, I believe we should eliminate the N-Sel altogether and redefine the "Network Layer Protocol Identifier" [which currently either identifies the header as being ISO 8473 (i.e., CLNP) or "inactive" -- a waste of 8 bits!] as being the protocol identifier for the Transport Layer in a fashion parallel to "normal" protocols--or some similar alteration. Of course, this implies that TUBA is not starting out exactly as CLNP which harms my "Installed base" arguments and causes many problems. For this reason this bullet is untenable and must be rejected out of hand. At best, this possibility needs to be studied to be sure that the gain is worth the pain. However, this bullet shows my belief that if TUBA becomes the IPng, then the IPng will gradually evolve away from today's CLNP as part of the normal IETF process. [I hope and trust that any evolution will solely be done for justifiable reasons.] 3) If TUBA becomes the IPng then the IETF must own TUBA. The TUBA working group does not have concurrence on this important point today which is a large part of their current malaise. However, this ownership is mandatory. This implies that the IETF may modify TUBA even if ISO does not agree to the changes. Thus, we may eventually have two versions of TUBA: CLNP and IPng. This is bad for convergence but the protocol simply must be free to expand to support advanced technologies. If it can't support advanced technologies then it will calcify and die. 4) If TUBA becomes the IPng then the TUBA header must be defined to support mobility, security, and flows with a system at least as good as that defined by SIPP. Proposed approaches to do so will need to be agreed upon soon (this year). 5) As was the case with IPv4 and capitalized upon by SIP and SIPP, certain parts of the CLNP header are "archaic" and we don't know what to do with them. One must perhaps keep the size and orientation of the fixed part of the header (i.e., Clause 7.2 of ISO 8473) in tact (if we are to truly choose the TUBA option) but thought should be given towards redeeming the unused aspects. Again, the pain must be worth the gain and ultimately justifiable. Fleischman, Expires December 1, 1994 [Page 4] draft-ipng-directorate-fleischman-review-00.txt May 1994 Having given thought to these points over two days, I believe that bullets 2 and 5 should be stricken from the text: TUBA must start out exactly as CLNP -- or, rather, as a subset of CLNP. However, I am leaving the text in to emphasize the importance that the protocol must "live" and evolve to support new technologies and to emphatically state that the IETF must have the power and ability to modify IPng when needed. In stark contrast to the comparatively "ugly" header of CLNP, SIPP is an aesthetically beautiful protocol well tailored to compactly satisfy today's known network requirements. Similarly, Tony Li's TURNIP was an attempt to do for CLNP what SIPP did for IPv4. Because I believe that IPv4's addressing is broken, while CLNP's is not, my belief is that CLNP is a much better foundation for SIPP-izing a header than is IPv4. For this reason, I am very favorably disposed to TURNIP. I understand the "out with the old, in with the best" philosophy of SIPP and TURNIP and find that it is not without its appeal -- (though it is generally lacking in business sense). After all, it is not often we have the opportunity to redefine the network layer so why carry old baggage? [Well, there ARE valid reasons.] However, I prefer that IF we go this route that we would do so based on as firm a starting foundation as possible. To me, this implies CLNP and not IPv4. However, I believe that TURNIP is not a viable IPng option because it has no working group, no working code, is inadequately defined, and does not have a stable specification. ------------------ 3.3 SIPP. The SIPP working group is currently the most vibrant of the three working groups producing libraries of documentation, very creative possible technical enhancements, and many instances of "working code". In fact, there are tremendously many good things which one can and should say about SIPP. However, my reading of the current SIPP specifications leads me to conclude that SIPP is broken and thus demonstrably inadequate to be considered as an IPng candidate as it is currently written. For this reason, the many outstanding qualities of SIPP are really immaterial for this discussion simply because the IPng must be able to function to benefit from those good qualities. Before I begin my defense of this conclusion, I want to assert that Paul Francis and I have begun a dialog on this topic. He has assured me that my conclusions are inaccurate. (I hope he is correct.) However, since I can only judge SIPP by its specifications, I will stand by these observations until they are proven wrong. Which brings up another point: at what point does one know what SIPP actually is since it -- or at least its specifications -- seems to be constantly mutating and altering itself? The SIPP of today seems to be very different from the SIPP of January. Certainly, what the "SIPP inner core" talk about is frequently not contained within SIPP documents. This lack of solidity in itself is a very serious matter and shows lack of maturity which also (in my mind) implies higher risk. In any case, Paul wrote: >Date: Fri, 6 May 94 09:47:25 JST >From: francis@cactus.slab.ntt.jp (Paul Francis) > Fleischman, Expires December 1, 1994 [Page 5] draft-ipng-directorate-fleischman-review-00.txt May 1994 >SIPP addresses are every bit as flexible as NSAPs. There is technically >no reason that you can't have just what you ask for above. > >I believe the mistake that SIPP has made vis a vis addressing is that we >have been too limited in what we have written down as possible formats. >The limited-to-64-bits format in the SIPP address assignment spec does not >suit your purpose, as it does not give you an internal layer of hierarchy >above the subnet layer. > >The "local-use" address can work for your purposes, but we SIPP folks have >perhaps (apparently?) not clearly stated how to use a local-use address as the >lower part of an extended address. I think what is needed is a "this is >how your address will look" document, so that one doesn't have to read the >routing and addressing spec to understand their own address, agreed? I have read all of the many SIPP routing and addressing specifications (that I know of, at least). From this reading I concluded the following: I find the following faults with SIPP's addressing which makes me conclude that SIPP addressing (as defined) is "broken": 1) It seems that a basic assumption of SIPP was that the existing IPv4 addressing was adequate in all respects except scale. However, my perspective is that IPv4 addressing itself is fundamentally flawed in that it lacks adequate hierarchy to serve the purposes of large end users. I simply don't want an IPng which doesn't dramatically improve on the many addressing failings of IPv4. 2) SIPP's "extended addressing" is demonstrably broken: intermediate source routes using extended addressing are unable to be "turned around" as would happen in a normal reply with such an address in the path. Another "broken" issue (though not so obvious) is that SIPP addresses larger than 64 bits are indistinguishable from source routes by the SIPP specification. This means that such extended addresses are really "pseudo- source routes". This leaves the addresses open to all types of confusion and definitely indicate a "blurred" vision of what an address actually is. In any case, SIPP's addresses are not really expandable despite their claims to the contrary. Extensibility of addressing is a firm IPng requirement and a necessary component of the "convergence" requirement. 3) The Self-Defining addresses of SIPP will NOT scale for Boeing's internal network (i.e., they solely have a subnetwork-orientation). 4) 8 byte addresses are to small to meet the world-wide Internet's addressing needs. This third point is addressed in a separate section of the document below. In addition, at the final session of the SIPP working group in Seattle IETF it was demonstrated that IPAE was broken. The problem is that IPAE does not keep enough state information [i.e., C bit is not enough, IPAE needs at least another bit to identify SIPP-only hosts] so that ICMP messages can actually be delivered under certain conditions. I have not seen a solution to date to mend IPAE's broken-ness. More importantly, unless IPAE is fixed it must be rejected. Thus there is a very real possibility in my mind of a IPAE-less SIPP. Since IPAE was one of the big selling points of SIPP, this severely detracts from the total appeal of the proposal. Yet if something so fundamental in SIPP is demonstrably broken at this late stage of the specification, what does that say about the lurking dangers of a more esoteric nature which are waiting to bite future SIPP deployments? This is a serious concern indeed. Fleischman, Expires December 1, 1994 [Page 6] draft-ipng-directorate-fleischman-review-00.txt May 1994 Another aspect which worries me about SIPP is that source routing scares me for security reasons. The opportunities to "spoof" seem so abundant with that capability. I appreciated Paul Francis' dialog on this very point. However, I did not note whether a solution was postulated beyond relying on the authentication capabilities which Ran Atkinson and others have added to SIPP. But is this enough? I really don't know. Hackers are so very clever these days. I am worried. In my opinion, when PIP joined IPAE/SIP to become SIPP the result was a political masterpiece but the resulting proposal has proven to be anything but simple. In hindsight, I have come to view the PIP parts of SIPP as major weaknesses to the proposal since the source routing parts of SIPP do not appear to me to be as powerful as they were in PIP (they certainly are much less "clean" in their SIPP incarnation) and thus I suspect that they may not be used (which would be unfortunate). Finally, Tracy Mallory posted the following issue which reminds me of the complexities and risks associated with adopting a protocol which has not yet proven itself in "real-world" deployments: >Note that a late item on the requirements list is that IPng ought not >to make things harder for firewalls. The SIPP approach requires that >the entire header be scanned to perform protocol dependent filtering. >Whether this is "good" or "bad" needs further thought, but for >example, it makes the filtering of inbound TELNET or FTP open requests a >little harder than today. What am I saying? I am saying that even if one can conclusively demonstrate that each of these "problems" can quickly be resolved, the fact still remains that SIPP is not as mature as TUBA and the risks of adopting it are therefore higher. The future of the Internet is directly dependent upon the stability of its network layer. It is better to have a somewhat inefficient network layer than a broken one. Also, how can we really know that any new technology will work as advertised -- or even work at all (in scale in production environments) until it has been field tested "in a big way". This isn't a show stopper but it is a real concern to those who must make technology-related business decisions. -------------- 4.0 Why I think SIPP's 8 byte Addresses Are Too Small The following tenets concerning my view of Boeing's addressing needs cumulatively lead me to conclude that SIPP's 8 byte address space is inadequate for the world-wide Internet's needs. I believe that we require: 1) An ability to have five levels of internal addressing hierarchy within our vast international private network IN ADDITION TO whatever levels of addressing hierarchy are needed by the world-wide Internet infrastructure. 2) An ability to potentially address more than 1,000,000 internal IPng devices in the medium term. [Note, only a subset of these devices will probably be computers as we know them today. Already our doors, elevators, Fleischman, Expires December 1, 1994 [Page 7] draft-ipng-directorate-fleischman-review-00.txt May 1994 and security huts are IP addressed today. We also have several thousand wireless devices which are network attached today, including scads of trucks and other mobile vehicles such as forklifts. It is possible that a sizable percentage of our 120,000+ work force may eventually have PDA devices.] 3) A desire to use serverless autoaddressing, perhaps via a mechanism which is built off of IEEE addresses. [Certainly, I currently associate the use of IEEE addresses with serverless autoconfiguration. Serverless autoaddressing is desirable as a means to reduce the number of address servers which we have to deploy to support current TCP/IP autoaddressing schemes.] Note: this uses 6 bytes of the address. 3a) The requirement that devices addressed by serverless autoaddressing be either global or local AT OUR DISCRETION [as opposed to the current SIPP approach where IEEE-based addresses must be local only]. That is, these addresses must be fully functional addresses completely on a par with addresses assigned by any other means. 4) The requirement that all of our addressing be simple, consistent, and easy to understand. If it isn't, we'll screw it up. 5) The hope that if masking continues to be used for addressing, that it will be substantially easier to deal with than IPv4's masking. [It sure would be great if masking could go away altogether.] 6) The desire to not have to continue to be addressing "bit heads" where we spend far too much $$$ to squeeze out more addresses from our tiny address spaces. Addresses should be what is cheap rather than the human labor overhead of the current IPv4 system. In today's system human labor is "cheaper" than addresses -- unless one uses "local addresses". 7) Our requirement that IPng may potentially serve as a convergence protocol for IPX/SPX and CLNP as well as for IPv4. 8) The belief that 64 bits can not scale to service the long-term needs of the world-wide Internet due to the administrative inadequacies of that size space servicing so many providers, customers and levels of routing hierarchy, among other reasons. 9) The belief that 8 byte SIPP addresses are not really expandable to handle unforeseen future scalability and toasternet issues. That is, today's SIPP "extended addresses" are indistinguishable from source routes within the SIPP specification. This lack of distinction between source routes and extended addresses (two very different concepts) leaves the addresses open to many types of confusion -- including the inability of an intermediate source route using extended addressing to be "turned around" as mentioned above. I imagine there are some other points which I could also mention which, when added cumulatively together, leads to the conclusion that SIPP's 8 byte addresses are inadequate to meet the Internet's needs. In any case, the issues affecting the need for addressing [and routing] hierarchy are complex for large multi-national corporations with extensive Fleischman, Expires December 1, 1994 [Page 8] draft-ipng-directorate-fleischman-review-00.txt May 1994 world-wide business dealings. The directions of an addressing architecture are in many ways a reflection of ones underlying assumptions. One assumption of the following is that the corporation will have a single address space. This, of course, is not the only alternative. Indeed, alternatives exist at many levels but each have architectural implications. In any case, I believe that the following assumptions with the following characteristics must be permissible within IPng addressing architecture. For this reason I stated that it is my assumption that an IPng addressing requirement is that the following structure can be supported. The following text seeks to address why I believe that Boeing will probably need to have five levels of addressing hierarchy. It is my belief/hope that some of these layers can be integrated into a single layer in an effort to try to reduce the layers of hierarchy and the resulting addressing sparseness as much as possible. Thus, I suggested 5 layers of hierarchy when the actual number of potential layers is greater. Of course, things may be combined in different ways, but 5 layers seemed to me to be a reasonable number as a starting point for discussion. Potential layers: 1) Continent: Boeing currently uses the services of two aeronautical communications service providers (ARINC, SITA) as well as the services of several Value Added Networks (VANs) for much of our international communications. However, we have also established an extensive international private communications network of our own to numerous international sites. Our need for international communications are extensive. For example, we must be able to address virtually every airport at which any of our planes can land -- with the possible exception of some of the dirt strips in the jungles which may be infrequently serviced via portable satellite communications. We communicate with virtually every airline in the world and (potentially, I believe) the governments as well. We have literally hundreds of corporations which are our suppliers and business partners -- again widely distributed throughout the world. The many sites linked by Boeing's private international network use Boeing addresses. I am not aware of plans to migrate this private network to Internet-like services due to a variety of factors, including security. Thus, I anticipate the probable need to maintain these many private international links within our address space. 2) Major Region within a continent. See above paragraph for size and scope. 3) Cities within a region. For example, in the Puget Sound region in which I work we have maybe like 40 cities in this small region which have substantial Boeing sites and who knows how many cities with other sites of lesser stature. If you want to make "regions" non-geographically based (e.g., call our Portland, Oregon or Spokane, Washington or Moses Lake, Washington sites as part of Puget Sound) then the number is greater. 4) Campuses within a city. We can potentially have several sprawling campuses within a city and an indeterminate number of lesser sites and stand-alone buildings as well. 5) Buildings within a Campus. Some of our campuses are immense containing perhaps hundreds of buildings. 6) Networks and subnetworks within a building. Boeing has some immense buildings. In fact, the largest building in the world by volume is a Fleischman, Expires December 1, 1994 [Page 9] draft-ipng-directorate-fleischman-review-00.txt May 1994 Boeing building in Everett. Some of these buildings are mind-boggling big. One which comes to mind appears to me to stretch a few kilometers in length. It is simply unbelievable (to my small mind, at least). Note that I assume that the distinction between networks and subnetworks will go away. If not, then make this two potential layers. In any case, some of these buildings can consume a Class B and then go back for seconds. 7) Individual Hosts and devices within a subnetwork. -------------- 5.0 Anatomy of a Personal Bias -- or How I Got Here I joined the IETF community two years ago as Boeing's only official representative to this community. Boeing is almost exclusively funding my IETF participation in order to assist the IPng selection process in the hopes that whatever IPng is ultimately selected will be maximally beneficial to large end users. My mindset when I first joined the fray was that all protocols except TUBA define "Yet Another Protocol" (YAP) and thus were orthogonal to our corporate protocol convergence goals. TUBA also represents little or no changes to the router vendors and service providers and thus is the only alternative which can be speedily deployed within the core Internet infrastructure on a world-wide basis -- and correspondingly represents the minimum amount of work for the community as a whole (i.e., 50% of our community can already support TUBA leaving only work for the end-system vendors and we end users). Therefore, TUBA was clearly the best solution. QED. However, the SIP people helped me see that the OSI community may perhaps to converge to whatever IPng turns our to be -- partially due to aspects of Marshall Rose's "OSI is a Road Kill" reasoning and partially due to that community sincerely wanting convergence and an end the protocol wars. Thus, a non-TUBA solution is not necessarily an anti-convergence solution. Functionality and the ability to support new technologies were also very important and relevant factors as well. Also, the IPAE people sold me on the concept that if we end users didn't know that we had deployed IPng then that is the ideal IPng. I fully agree: If we users deploy IPng thinking we had deployed IPv4 then that is indeed the best of all IPngs. Therefore, because of IPAE I became interested in SIP. Then PIP got me all excited with promised new functionality and enhanced performance. I decided that enhanced performance/functionality was more important than convergence and ease of migration since our users have real needs which demand these new functionalities with heightened performance. However, Paul Francis burst my bubble at Amsterdam by telling me that PIP would deliver only 20% enhanced performance over IPv4 (albeit "much cleaner done") and that is by no means an adequate performance boost to justify switching protocols (in my mind, at least). Thus, I became disillusioned with PIP thinking that we didn't understand flows and the advanced PIP features well enough yet to use them to build viable protocols and products before IPng would be deployed. Thus, I concluded that the primary selling point of PIP was not dramatic enough to be able to sell it to us end users. I greatly appreciated the vision of both TP-IX and, especially, CATNIP. However, comments which I (and others) made during the working group Fleischman, Expires December 1, 1994 [Page 10] draft-ipng-directorate-fleischman-review-00.txt May 1994 meetings seemed to not be appreciated in some/many cases. Since some of my suggestions were thus "rejected", I formed the opinion that my input was not desired. I suspect that others may have formed similar opinions because only a few people contributed to it technically. In any case, I was left with the general feeling that despite its great ideas, it was pretty much of a one-man show. Also at the Amsterdam IETF I got excited about TUBA again because of their demo and the dynamism of the working group. I also didn't realize that Europe had deployed CLNP on any scale at all and being in Europe helped me to view CLNP with greater appreciation. Thus, convergence again became a deciding point for me -- though IPAE still did look promising. Shortly thereafter I figured out that the best IPng for us end users is no IPng at all: we could support the Internet's demands by putting application layer gateways on our firewalls and thus continue to support IPv4 "forever" --thus avoiding the pain and the cost of deploying IPng at all. Unless, of course, it had real functionality benefits which would entice our end users to demand that it become deployed. Also, since we users didn't HAVE to deploy IPng, we could hold out for a "convergence" solution should we ever choose to deploy IPng to ensure that IPng wouldn't be Yet Another Protocol (YAP). Then some of the TUBA people did what seemed-like-at-the-time a "sour grapes" stunt saying that SIP and primarily IPAE were broken and couldn't possibly work. I greatly respect these "nay-sayers" and actively tried to get them to articulate their points in an intelligible fashion. However, I just couldn't understand their reasoning. The effort did leave me with the overall feeling that nothing was working well enough to excite users. Thus, I supported Noel Chiappa's viewpoint that there were no viable IPng candidates and I began to wish that NIMROD would miraculously appear and save us from the "half-solutions". Then I encountered my first toasternet application (CDPD) and was surprised that they chose CLNP and OSI for their internal infrastructure allegedly because of a lack of a viable IPng. Thus, I finally realized that perfect or not, we need to decide on an IPng ASAP. It was obvious by then that SIPP was the most dynamic working group and that they were (in my opinion) doing the most creative and innovative work and thus would be the best working group for the community as a whole. Because of the continually strong opposition against IPAE by the some of the above mentioned "nay sayers" and the willingness of many of the non-SIPP people to compromise upon an IPAE-less SIPP, I became willing to sacrifice IPAE for political reasons [despite the fact that I and users in general would GREATLY value it] in order to form a community-wide consensus to answer the looming toasternet menace. That is, I *thought* that I was willing to do so until IPAE was actually demonstrated to be technically broken towards the end of the Seattle IETF. When that happened I became genuinely scared and began to doubt the quality of the entire SIPP approach (wondering how many other aspects of their core approach were also really broken) -- but I saw no alternative to SIPP at that time since I had concluded that the TUBA and CATNIP working groups were effectively "dead". Fleischman, Expires December 1, 1994 [Page 11] draft-ipng-directorate-fleischman-review-00.txt May 1994 Then I read Peter Ford's White Paper on TUBA and was reminded of all of the scholarship that had gone into CLNP and OSI routing. Despite the deadness of the TUBA working group, I had to admit that the TUBA proposal was a very good proposal. In fact, I found Peter's paper to be mighty convincing. Then during the past two weeks (while preparing to write this paper) I began to think about IPng addressing more seriously than ever before. From this exercise I concluded that the SIPP approach to addressing is broken. This was the straw which broke the camel's back: I don't care how dynamic the SIPP working group is and how dead the TUBA working group is. TUBA works. SIPP doesn't. TUBA is mature. SIPP isn't. TUBA is low risk. SIPP has *significantly* greater risk. End of story. While I am doubtlessly more "gray-scale" (as opposed to seeing everything in "black and white" terms) than the norm, my vacillation on this important matter merely shows that all of the IPng approaches have merit and that each approach has significant and important strengths and weaknesses. However, broken alternatives can NOT be the IPng. Fleischman, Expires December 1, 1994 [Page 12] From sob@hsdndev.harvard.edu Thu Jul 14 23:27:53 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA07257 for ; Thu, 14 Jul 1994 23:28:00 -0400 Date: Thu, 14 Jul 94 23:27:53 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407150327.AA08947@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: SNA in IPng As a result of a discussion about coding SNA addresses in IPng I've done some checking and have tracked down what SNA addresses look like: they are coded as alphanumeric EBCDIC characters (A-Z, 0-9, not starting with number) one 1-8 chacter NetID name & one 1-8 chacter NAUname normally they use 'human-readable' combinations structure as defined by IBM: NetID - characters 1-2 country code, e.g. US, UK characters 3-6 organization code, e.g. IBMS (1.7 million per country) characters 7-8 networks (up to 1296 per organization) NAUname - locally determined I guess you could call this information for background. Scott From smb@research.att.com Thu Jul 14 23:48:01 1994 Return-Path: smb@research.att.com Received: from research.att.com ([192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA07305 for ; Thu, 14 Jul 1994 23:49:25 -0400 From: smb@research.att.com Message-Id: <199407150349.XAA07305@picard.cmf.nrl.navy.mil> Received: by gryphon; Thu Jul 14 23:48:02 EDT 1994 To: sob@hsdndev.harvard.edu (Scott Bradner) cc: ipng@cmf.nrl.navy.mil Subject: Re: SNA in IPng Date: Thu, 14 Jul 94 23:48:01 EDT As a result of a discussion about coding SNA addresses in IPng I've do ne some checking and have tracked down what SNA addresses look like: they are coded as alphanumeric EBCDIC characters (A-Z, 0-9, not starting with number) one 1-8 chacter NetID name & one 1-8 chacter NAUname normally they use 'human-readable' combinations structure as defined by IBM: NetID - characters 1-2 country code, e.g. US, UK characters 3-6 organization code, e.g. IBMS (1.7 million per country) characters 7-8 networks (up to 1296 per organization) NAUname - locally determined I guess you could call this information for background. Scott Knowing IBM, the set of letters probably includes $#@. Anyway, that means 1521 possible country and network codes, and 2313441 organization codes. Even with a conservative packing, that's 7 bytes, which means that the whole shebang does fit in our presumed 16 byte space. From brian@dxcoms.cern.ch Fri Jul 15 08:22:02 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA07883 for ; Fri, 15 Jul 1994 02:22:36 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA20717; Fri, 15 Jul 1994 08:22:23 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA18800; Fri, 15 Jul 1994 08:22:03 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407150622.AA18800@dxcoms.cern.ch> Subject: Re: FW: summary of Big-Internet messages To: ipng@cmf.nrl.navy.mil Date: Fri, 15 Jul 1994 08:22:02 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 463 Directorate, I find Bill's assessment very different from a count I was keeping on a couple of scraps of paper; but he seems to have time to wade through reams of mail and find binary interpretations of imprecise waffle and IRTF theology. The people who actually answered the question as posed were quite definitely in a 2/3 majority for 16 bytes to end the discussion. J., how about "On the Internet, nobody cares how long your address is"? -- Brian From smb@research.att.com Fri Jul 15 09:29:45 1994 Return-Path: smb@research.att.com Received: from research.att.com (research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA09682 for ; Fri, 15 Jul 1994 09:34:08 -0400 From: smb@research.att.com Message-Id: <199407151334.JAA09682@picard.cmf.nrl.navy.mil> Received: by bigbird.zoo.att.com; Fri Jul 15 09:29:47 EDT 1994 To: ipng@cmf.nrl.navy.mil Subject: SIPP versus firewalls Date: Fri, 15 Jul 94 09:29:45 EDT I'm starting to get a bit uneasy about how to build firewalls, and in particular how to build packet filters, with IPng. A fair number of headers can be interposed between the SIPP header and the TCP header; while the actual performance hit may not be too bad, the semantics of evaluating the headers isn't clear. Here's the list of the ones I've heard mentioned so far; I've probably missed a few: Source routing Fragmentation Authentication Encryption If encryption is present, the notion of checking port numbers probably doesn't apply. But the other three can all occur in a single packet. No doubt new ones will be invented at some point in the future. What should a firewall filter do? One possibility is to loop through all headers, until one is found whose protocol id matches some filter rule (i.e., PROTO=TCP,PORT=25) or some such. But that demands that the firewall know of all possible option headers -- which might be necessary in any case, since if you don't know what an option is, you don't know if it's being used to violate your security policy -- or that they all share a common format including a header length. Another idea is to have a transport header offset pointer in the SIPP header; this is adjusted as necessary, or zeroed by things like the encryption layer. Or maybe firewalls should rely on the flowid, and use the flow setup packets to enable it. (But that would require that all packets carry firewall-level authentication headers.) Anyway -- I haven't thought this through thoroughly, and this list (as opposed to the SIPP working group) may not be the place to address it. But it does merit some thought. --Steve Bellovin From Greg_Minshall@Novell.COM Fri Jul 15 13:52:35 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA14405 for ; Fri, 15 Jul 1994 16:57:53 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA24025; Fri, 15 Jul 94 14:57:00 MDT Received: from [130.57.64.147] by WC.Novell.COM (4.1/SMI-4.1) id AA18358; Fri, 15 Jul 94 13:52:37 PDT Date: Fri, 15 Jul 94 13:52:35 PDT Message-Id: <9407152052.AA18358@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@cmf.nrl.navy.mil From: Greg Minshall Subject: FWD: baby omnibus >To: big-internet@munnari.oz.au >Subject: baby omnibus >Date: Fri, 15 Jul 1994 22:07:57 +1000 >From: Bob Smart > >Some of the good ideas from the IPng process: > >From SIP and IPAE: encapsulation for fast option processing. > >From AEIOU: address extension on the right not the left. > >From Christian Huitema: A distinct security layer between the network layer >and the transport layer. I was amazed that this got mentioned and forgotten. >There has been a lot of talk about security implications of the way the >network layer conveys information about the other end to the transport >layer. Sometimes it doesn't matter and sometimes we need cryptographic >security. A layer in there seemed like the right way to protect the network >and transport layers from having to deal with this area which doesn't >logically belong to either. > >From various places including PIP: separate transport end-point identifier >from network locators. And now that I realize that transport end-point >identification belongs in the security layer everything "feels" neater. >I don't mean that transport identification is necessarily in the security >layer part of the packet: the simplest security layer type will deduce >the transport identification from the network address as we do now. > > From Greg_Minshall@Novell.COM Fri Jul 15 14:44:34 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA15093 for ; Fri, 15 Jul 1994 17:49:44 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA25864; Fri, 15 Jul 94 15:48:58 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB18644; Fri, 15 Jul 94 14:44:34 PDT Date: Fri, 15 Jul 94 14:44:34 PDT Message-Id: <9407152144.AB18644@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: smb@research.att.com, ipng@cmf.nrl.navy.mil From: Greg Minshall Subject: Re: SIPP versus firewalls Steve, >One possibility is to loop through all headers, until one is found >whose protocol id matches some filter rule (i.e., PROTO=TCP,PORT=25) >or some such. But that demands that the firewall know of all possible >option headers -- which might be necessary in any case, since if you >don't know what an option is, you don't know if it's being used to >violate your security policy -- or that they all share a common format >including a header length. I think you *NEED* to do this. >Another idea is to have a transport header offset pointer in the SIPP >header; this is adjusted as necessary, or zeroed by things like the >encryption layer. What if it comes in with a forged offset pointer, but the target *host* doesn't check it (since the target host needs to unwind all the headers anyway)? What if it has a *bad* option, one you don't *want* in your site? I think the firewall needs to grok all the headers (and, thus, toss ones it doesn't grok). Greg From jallard@microsoft.com Sat Jul 16 16:02:41 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA04183; Sat, 16 Jul 1994 19:07:13 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA02272; Sat, 16 Jul 94 16:07:43 -0700 Message-Id: <9407162307.AA02272@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Sat, 16 Jul 94 16:07:43 PDT X-Msmail-Message-Id: 1553B4CE X-Msmail-Conversation-Id: 1553B4CE X-Msmail-Fixed-Font: 0001 From: "James 'J' Allard" To: ipng@cmf.nrl.navy.mil, ipng-request@cmf.nrl.navy.mil Date: Sat, 16 Jul 94 16:02:41 TZ Subject: RE: heads up | Well some one likes talking to the press. Both Allison & I got calls | from Network World reporters late last week. Someone had told them that | we were 'picking SIPP' as IPng. We tried to get them to hold on the | offer of full cooperation next week so they could publish the same | day as the announcement but they would not. We were (we think) able | to move things away from a 'SIPP won' picture to one that is closer | to what we would like to say. what *do* we want to say? you know the press will be all over the place on this once the monday announcement is made. my limited understanding of the proposed recommendation (what we discussed in toronto) is very sipp-heavy (no guys, i didn't talk to n.w.). i see very little coming from any of the alternate proposals, and i'm pretty close to the src. it's understandable that the press would distort the message a bit to make things easy-to-read. i don't mean to stir here, but given what was said at sun, i don't know what other conclusion you expect the press to draw. i got a call from computerworld, who, since i wouldn't say anything, is sending a reporter to monday's event. i would not be surprised that despite any and all efforts on monday to debunk the "sipp won" message, that computerworld prints "sipp won". in dealing with the press, i've learned that you have to select the 2-5 words that you want them to take verbatim, and that the rest of the article is up for grabs. if you repeat the phrase at least 6 times every 10 minutes, there's a 50% chance they'll print it w/o distortion. that said, i'd recommend the title of the first slide read something like: "IPng: A new Future Through Collaboration and Compromise" if you are really concerned abt the sipp-centricity of the articles, we really should pick the one or two soundbytes that we want people to walk away from, memorize them, and chant them in the halls of the ietf. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From <@www.bbn.com:jcurran@nic.near.net> Sat Jul 16 09:11:07 1994 Return-Path: <@www.bbn.com:jcurran@nic.near.net> Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA17875 for ; Sat, 16 Jul 1994 09:12:22 -0400 Received: from www.bbn.com by nic.near.net id aa09362; 16 Jul 94 9:12 EDT To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: NSAPAs, inside and outside In-reply-to: Your message of Thu, 14 Jul 1994 14:26:02 +0200. <9407141226.AA01891@dxcoms.cern.ch> Date: Sat, 16 Jul 1994 09:11:07 -0400 From: John Curran Message-ID: <9407160912.aa09362@nic.near.net> -------- ] From: Brian Carpenter CERN-CN ] Subject: NSAPAs, inside and outside ] Date: Thu, 14 Jul 1994 14:26:02 +0200 (MET DST) ] ] 1. NSAPAs inside a 16-byte IPng address ] ] The first byte is an IANA-assigned code meaning "this IPng address ] embeds a 15-byte NSAPA". The alignment is a mess, but no worse ] than in a 20-byte NSAPA. ] ] 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 |NSAPA code TBD | AFI | IDI (ICD or DCC) | ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ] 4-7 | Prefix (3 octets) | Area (octet 0)| ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ] 8-11 | Area (octet 1)| ID (octets 0 through 2) | ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ] 12-15| ID (octets 3 through 5) | NSEL | ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ] ] The AFI will normally be 39 (DCC, digital country code) or 47 ] (ICD, international code designator). The longest prefixes in use ] today, to my knowledge, are 4 octets in NORDUNET (the Nordic academic ] network), so they would have to squeeze down to 3 octets. ] Are there any cases where a 3 octet prefix is unthinkable? Would it be better to: 1) Use a smaller prefix for the NSAPA indicator. (e.g. 4 bits) 2) Encode a subset of AFI's into the remainder of the first octet. (e.g. first 8 for known-in-use AFI's, 8 for handling new ones) 3) Slide the IDI up one octet 4) Allow 4 octet prefixes While this would constrain the compatible AFI address space, it would prevent having to compress existing prefixes and would provide more "usable" space long-term (prefix space = useful, AFI space = functionally-challenged.) Another nit: if the perceived use of these recast addresses are to allow reuse of existing assignments for IPng, then the NSEL is superfluous, no? The only reason I can see for including the NSEL would be if there was an intent to revise CLNP to use this address format. Without variable length addressing in IPng, this appears to me to be a very, very unlikely event. /John From sob@hsdndev.harvard.edu Sat Jul 16 10:19:23 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA18029 for ; Sat, 16 Jul 1994 10:19:28 -0400 Date: Sat, 16 Jul 94 10:19:23 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407161419.AA07610@hsdndev.harvard.edu> To: jcurran@nic.near.net Subject: Re: NSAPAs, inside and outside Cc: ipng@cmf.nrl.navy.mil > 1) Use a smaller prefix for the NSAPA indicator. (e.g. 4 bits) don't this reduce the %age of the IPng address space for non-nsapa assignment? Scott From <@www.bbn.com:jcurran@nic.near.net> Sat Jul 16 11:31:31 1994 Return-Path: <@www.bbn.com:jcurran@nic.near.net> Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA18432 for ; Sat, 16 Jul 1994 11:32:38 -0400 Received: from www.bbn.com by nic.near.net id aa15408; 16 Jul 94 11:32 EDT To: Scott Bradner cc: ipng@cmf.nrl.navy.mil Subject: Re: NSAPAs, inside and outside In-reply-to: Your message of Sat, 16 Jul 1994 10:19:23 -0400. <9407161419.AA07610@hsdndev.harvard.edu> Date: Sat, 16 Jul 1994 11:31:31 -0400 From: John Curran Message-ID: <9407161132.aa15408@nic.near.net> -------- From: Scott Bradner Subject: Re: NSAPAs, inside and outside Date: Sat, 16 Jul 94 10:19:23 -0400 > 1) Use a smaller prefix for the NSAPA indicator. (e.g. 4 bits) don't this reduce the %age of the IPng address space for non-nsapa assignment? Certainly. Instead of taking 1/256 of the possible address space, you lose 1/16. If we get to within 1/16 of the IPng address space, we've failed anyway. /John From deering@parc.xerox.com Sun Jul 17 22:31:42 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id BAA25772 for ; Mon, 18 Jul 1994 01:32:41 -0400 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14631(5)>; Sun, 17 Jul 1994 22:31:57 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 17 Jul 1994 22:31:52 -0700 To: Lois Aylestock Cc: lkeiper@cnri.reston.va.us, scoya@cnri.reston.va.us, ipng@cmf.nrl.navy.mil Subject: Re: Ipng Teleconference July Monday 18, 1994 In-reply-to: laylesto's message of Wed, 13 Jul 94 16:11:25 -0800. <9407131806.aa12903@IETF.CNRI.Reston.VA.US> Date: Sun, 17 Jul 1994 22:31:42 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul17.223152pdt.12171@skylark.parc.xerox.com> CNRI folks: I just got a call from Ross Callon, and he said he will be able to participate in tomorrow's IPng teleconference. Please have the AT&T operator call him at his hotel in Los Angeles, (714) 553-0100, room 806, at the start time of 8:30 am Pacific. [By the way, are Lois Keiper and Lois Aylestock one and the same?] Steve From deering@parc.xerox.com Mon Jul 18 01:13:15 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id EAA26073 for ; Mon, 18 Jul 1994 04:14:11 -0400 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14723(1)>; Mon, 18 Jul 1994 01:13:27 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 18 Jul 1994 01:13:17 -0700 To: sipp@sunroff.eng.sun.com, ipng@cmf.nrl.navy.mil, big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: SIPP-16 draft Date: Mon, 18 Jul 1994 01:13:15 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul18.011317pdt.12171@skylark.parc.xerox.com> I have submitted a new version of the SIPP spec, with 16-byte addresses, as an Internet Draft. If you want to grab a copy before it shows up in the official directories, you can get it from: ftp://parcftp.xerox.com/pub/sipp/draft-ietf-sipp-spec-01.txt Besides the change of address size, a number of other changes were made, arising from the implementors' meeting in Seattle and subsequent events. Be sure to read through Appendix B to find out everything that changed since the last draft. Steve From sob@hsdndev.harvard.edu Mon Jul 18 07:44:17 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA26531 for ; Mon, 18 Jul 1994 07:44:23 -0400 Date: Mon, 18 Jul 94 07:44:17 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407181144.AA26181@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: rough Toronto outline Something must have gone wrong with Allison's mail system. She was working on a more complete version of this outline last night and was going to send it out when she was done. Right about now she should be on the train between DC & NYC where she is going to an ANSI meeting today. She (& Paul) will be joining us on the telechat from a room at ANSI. Sorry to send out this rather rough outline but its better than nothing (I hope :-) ) Scott (In case you wondered, this is a troff source file) ---- .im ../head.man .fe '''\fH\s+4 IPng-%\fP\s-4' @.ds Sc NS .ps 24 .vs 26 'rs .ce IP next generation (IPng) .ps 20 .ce Scott Bradner .ce Allison Mankin .bp .ps 24 .vs 26 History .ps 20 \(bu August 1993 temporary IETF area formed to consolidate IPng activity \(bu ADs from other areas on temporary assignment in addition to regular duties \(bu existing IPng working groups moved into area \(bu charge from the IETS chair to area .bp .ps 24 .vs 26 Charge from IESG chair .ps 20 \(bu establish directorate \(bu keep process public \(bu understand available timeframe recommend policy changes if warranted \(bu make a recommendation regarding the scope of IPng 'just' fix addresses or more \(bu develop clear and concise set of technical requirements \(bu develop a recommendation on which, if any, of current proposals should be next IP .bp .ps 24 .vs 26 Directorate .ps 20 J. Allard - Microsoft Steve Bellovin - AT&T Jim Bound - Digital Ross Callon - Wellfleet Brian Carpenter - CERN Dave Clark - MIT John Curran - NEARnet Steve Deering - Xerox Dino Farinacci - Cisco Paul Francis - NTT Eric Fleischmann - Boeing Mark Knopper - Ameratech Greg Minshall - Novell Rob Ullmann - Lotus Lixia Zhang - Xerox .bp .ps 24 .vs 26 Public Process .ps 20 \(bu big-internet mailing list used (big-internet-request@munnari.oz.au) \(bu internal directorate mailing list archive made public \(bu public reports \(bu open directorate meetings \(bu archive site hsdndev.harvard.edu anonymous ftp & gopher .bp .ps 24 .vs 26 Available Timeframe .ps 20 \(bu Address Lifetime Expectations (ALE) working group Frank Solensky, FTP Software Tony Li, Cisco Systems \(bu made prediction at Seattle IETF meeting 2008 \(+-3 \(bu assumes no paradigm shifts \(bu ADs endorse current address assigment policies \(bu ADs do not currently recommend address reclamation efforts may be warranted if large address request(s) received and if sub-Class A nets can be assigned .bp .ps 24 .vs 26 Scope of IPng .ps 20 \(bu we have adequate time in IPv4 address space \(bu can do more than 'just' fix addresses \(bu use requirements process to determine scope .bp .ps 24 .vs 26 IPng Technical Requirements .ps 20 \(bu IPng requirements working group (ngreq) Frank Kastenholz, FTP Software Jon Crowcroft, UCL uses big-internet mailing list \(bu draft requirements document based on Kastenholz/Partridge draft (draft-kastenholz-ipng-criteria-02.txt) criteria, discussion & time frame \(bu RFC1550 white papers .bp .ps 24 .vs 26 White Papers .ps 20 .vs 24 draft-adamson-ipng-radio-req-00.txt draft-bellovin-ipng-addr-per-host-00.txt draft-bellovin-ipng-sec-concerns-00.txt draft-bound-ipng-bsdhost-implement-00.txt draft-brazdziunas-ipng-atm-00.txt draft-britton-ipng-req-corp-netwrk-00.txt draft-brownlee-ipng-acct-req-00.txt draft-carpenter-ipng-whitepaper-00.txt draft-clark-ipng-multipro-interop-00.txt draft-curran-ipng-viability-00.txt draft-estrin-ipng-unified-routing-00.txt draft-fleischman-ipng-corp-view-00.txt draft-ghiselli-ipng-whitepaper-req-00.txt draft-green-ipng-navy-hpn-00.txt draft-heagerty-ipng-input-00.txt draft-simpson-ipng-mobility-00.txt draft-skelton-ipng-epri-00.txt draft-symington-ipng-model-00.txt draft-taylor-ipng-cdpd-viewpt-00.txt draft-vecchi-ipng-tvcable-viewpt-00.txt .ps 20 \(bu to become Informational RFCs .bp .ps 24 .vs 26 Proposal Whitepapers .ps 20 \(bu tuba draft-ford-ipng-tuba-whitepaper-00.txt \(bu sipp draft-ietf-sipp-whitepaper-00.txt \(bu catnip draft-mcgovern-ipng-catnip-wpaper-00.txt .bp .ps 24 .vs 26 IPng Criterias .ps 20 .vs 24 \(bu 10\u9\d networks, 10\u12\d end-systems \(bu topologically flexible \(bu high performance \(bu robust \(bu media independent \(bu datagram protocol \(bu autoconfiguration \(bu secure operation \(bu globally unique names \(bu support multicasting \(bu extensible \(bu service classes \(bu support mobile hosts \(bu tunneling \(bu straightforward transition plan .bp .ps 24 .vs 26 Nostradamus mode .ps 20 \(bu predicting the future is hard \(bu from "A Proposal for a Next Generation Internet Protocol" Ross Callon - December, 1987 detailed requirements seen for 1997 Internet doubling every year (720 assigned nets in '87) listed requirements: change should last for at least 10-15 years very high speed nets (microsecond forwarding time) plan for at least 100,000 nets, 10,000 ASs administrative diversity - addressing complexity effective general congestion control efficient source routing side note: "The expected arrival of ISDN will have a major impact on data communications in the 1990's and beyond." .bp .ps 24 .vs 26 Assumptions .ps 20 we see consensus on the following points \(bu we need to make a specific recommendation now \(bu basic requirements agreed to \(bu proceed with single IPng effort .bp .ps 24 .vs 26 Reviews of IPng Proposals .ps 20 xxx .bp .ps 24 .vs 26 Recommendations .ps 20 \(bu go forward with single IPng working group \(bu all base documents to be ready for proposed standard consideration by December \(bu minimual required IPng functionality must include autoconfiguration & security .bp .ps 24 .vs 26 IPng Working Group .ps 20 \(bu a new IPng working group be formed chairs: Deering, xxx, yyy short-term milestones for the proposed standards for IPng IPng BOF meeting twice in Toronto \(bu base IPng draft documents SIPP-16 SST .bp .ps 24 .vs 26 IPng Working Group, charter outline .ps 20 .bp .ps 24 .vs 26 Existing IPng Proposal Working Groups .ps 20 \(bu at start of process we said that we would not force shutdown of existing working groups when IPng recomendation made \(bu current IPng proposal working groups returned to Internet area \(bu can continue to work, but work will not be on IPng or expected to have specific influence on IPng \(bu can disband if chairs so choose .bp .ps 24 .vs 26 IPng Addresses .ps 20 \(bu 16 byte Internet address \(bu address formats determined by IPng working group \(bu assignment coordinated by the IANA .bp .ps 24 .vs 26 IPng Addresses, contd .ps 20 \(bu propose mapping algorythms from and to other environments \(bu where addresses are globally unique and assigned along network topology \(bu IPX, NSAPA, etc \(bu work with other organizations for development of such mappings .bp .ps 24 .vs 26 Autoconfiguration .ps 20 \(bu autoconfiguration a required feature of IPng \(bu an IPng autoconfiguration working group be formed chairs - Sue Thompson & Dave Katz \(bu base document draft from Sue Thompson & Dave Katz \(bu serverless & serverfull modes must be supported .bp .ps 24 .vs 26 Autoconfiguration WG charter .ps 20 .bp .ps 24 .vs 26 Transition .ps 20 \(bu two IPng transition efforts \(bu short term refine IPng-specific documents for proposed standard \(bu long term transition, coexistance & testing .bp .ps 24 .vs 26 Transition, short term .ps 20 \(bu new short lived working group - NGTRANS \(bu base document - final SST overview from IPng WG \(bu create series of standards track documents .bp .ps 24 .vs 26 NGTRANS charter .ps 20 .bp .ps 24 .vs 26 Transition, long term .ps 20 \(bu Transition and Coexistence Including Testing (tacit) WG Atul Bansal, Digital Geoff Huston, AARNet \(bu transition to IPng from multiple protocols \(bu understand economics of transition \(bu multiple protocol coexistence \(bu understanding testing requirements is vital Internet now viewed as a utility \(bu ongoing effort \(bu not just IPv4 -> IPng ???? -> IPng IPng -> IPgang .bp .ps 24 .vs 26 TACIT charter .ps 20 facets of issue \(bu transition from the currently deployed protocol to a new protocol \(bu heterogeneity and decentralization will need to be accommodated \(bu long period of coexistence between a protocol and the existing protocol \(bu the Internet must now be considered a utility rigorous testing needed as part of predeployment phase goals \(bu learn from other transition and deployment efforts \(bu detail problems areas in transition and coexistence \(bu recommendation of specific testing procedures \(bu recommendation of coexistence operations procedures with IPv4 \(bu recommendations for the smoothing of decentralized transition planning \(bu facillatate transition pland from other network technologies e.g. IPX, CLNP .bp .ps 24 .vs 26 IPng coordinator (inquisitor?) .ps 20 \(bu appoint an IPng directorate member to be specifically responsibe for ensuring that a consistant view of IPng is maintained across the working groups \(bu job description ask the exhaustive questions connecting all the points, offering the broadest perspective, but not making architectural decisions that is the work of the wgs and the ietf. .bp .ps 24 .vs 26 Security .ps 20 o - specific efforts be undertaken to establish an IPng security framework as the standard practice authentication header is very important default case encryption is very important .bp .ps 24 .vs 26 EIDs .ps 20 \(bu much discussion, little resolution too much at a research status \(bu do not think EID work will affect IPng header format \(bu sanctioned EID BOF in Toronto \(bu any follow on WG likley not in IPng area transport possible .bp .ps 24 .vs 26 Other Needed Work .ps 20 \(bu changing the size of the internetwork layer address effects many IETF standards \(bu new working groups must be formed in many areas to TCP From brian@dxcoms.cern.ch Mon Jul 18 14:10:51 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA26647 for ; Mon, 18 Jul 1994 08:11:29 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA25764; Mon, 18 Jul 1994 14:11:15 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA25994; Mon, 18 Jul 1994 14:10:52 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407181210.AA25994@dxcoms.cern.ch> Subject: Revised NSAPA mapping To: tuba@lanl.gov, ipng@cmf.nrl.navy.mil Date: Mon, 18 Jul 1994 14:10:51 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3374 [Acknowledgements for useful comments: Scott Bradner, John Curran, Bob Hinden, Yakov Rekhter. And for the main improvement: Cyndi Jung.] BTW, I haven't bothered to write down a mapping for NSAPAs inside the BigTen 24-byte address format, but it is clearly trivial. Brian 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. 2. 16-byte IPng addresses inside a 20-octet NSAPA The main goal of this embedding is to allow CLNP packets that encapsulate IPng packets to be routed in a CLNP network using the IPng address architecture. An arbitrary number of bytes of the IPng address can be used as a CLNP routing prefix. The first three octets are an IDP meaning "this NSAPA embeds a 16 byte IPng address" and the last octet is a dummy selector. Sorry about the alignment, but it seems very risky 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) | IPng (byte 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | IPng (bytes 1-4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | IPng (bytes 5-8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| IPng (bytes 9-12) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16-19| IPng (bytes 13-15) | NSEL = dummy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- From brian@dxcoms.cern.ch Mon Jul 18 14:25:03 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA26744 for ; Mon, 18 Jul 1994 08:25:38 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA27255; Mon, 18 Jul 1994 14:25:27 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA26625; Mon, 18 Jul 1994 14:25:03 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407181225.AA26625@dxcoms.cern.ch> Subject: pure ASCII version To: ipng@cmf.nrl.navy.mil Date: Mon, 18 Jul 1994 14:25:03 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 9003 This is easier to read for the troffless masses Brian IP next generation (IPng) Scott Bradner Allison Mankin History August 1993 temporary IETF area formed to consolidate IPng activity ADs from other areas on temporary assignment in addition to regular duties existing IPng working groups moved into area charge from the IETS chair to area Charge from IESG chair establish directorate keep process public understand available timeframe recommend policy changes if warranted make a recommendation regarding the scope of IPng 'just' fix addresses or more develop clear and concise set of technical requirements develop a recommendation on which, if any, of current proposals should be next IP Directorate J. Allard - Microsoft Steve Bellovin - AT&T Jim Bound - Digital Ross Callon - Wellfleet Brian Carpenter - CERN Dave Clark - MIT John Curran - NEARnet Steve Deering - Xerox Dino Farinacci - Cisco Paul Francis - NTT Eric Fleischmann - Boeing Mark Knopper - Ameratech Greg Minshall - Novell Rob Ullmann - Lotus Lixia Zhang - Xerox Public Process big-internet mailing list used (big-internet-request@munnari.oz.au) internal directorate mailing list archive made public public reports open directorate meetings archive site hsdndev.harvard.edu anonymous ftp & gopher Available Timeframe Address Lifetime Expectations (ALE) working group Frank Solensky, FTP Software Tony Li, Cisco Systems made prediction at Seattle IETF meeting 2008 \(+-3 assumes no paradigm shifts ADs endorse current address assigment policies ADs do not currently recommend address reclamation efforts may be warranted if large address request(s) received and if sub-Class A nets can be assigned Scope of IPng we have adequate time in IPv4 address space can do more than 'just' fix addresses use requirements process to determine scope IPng Technical Requirements IPng requirements working group (ngreq) Frank Kastenholz, FTP Software Jon Crowcroft, UCL uses big-internet mailing list draft requirements document based on Kastenholz/Partridge draft (draft-kastenholz-ipng-criteria-02.txt) criteria, discussion & time frame RFC1550 white papers White Papers draft-adamson-ipng-radio-req-00.txt draft-bellovin-ipng-addr-per-host-00.txt draft-bellovin-ipng-sec-concerns-00.txt draft-bound-ipng-bsdhost-implement-00.txt draft-brazdziunas-ipng-atm-00.txt draft-britton-ipng-req-corp-netwrk-00.txt draft-brownlee-ipng-acct-req-00.txt draft-carpenter-ipng-whitepaper-00.txt draft-clark-ipng-multipro-interop-00.txt draft-curran-ipng-viability-00.txt draft-estrin-ipng-unified-routing-00.txt draft-fleischman-ipng-corp-view-00.txt draft-ghiselli-ipng-whitepaper-req-00.txt draft-green-ipng-navy-hpn-00.txt draft-heagerty-ipng-input-00.txt draft-simpson-ipng-mobility-00.txt draft-skelton-ipng-epri-00.txt draft-symington-ipng-model-00.txt draft-taylor-ipng-cdpd-viewpt-00.txt draft-vecchi-ipng-tvcable-viewpt-00.txt to become Informational RFCs Proposal Whitepapers tuba draft-ford-ipng-tuba-whitepaper-00.txt sipp draft-ietf-sipp-whitepaper-00.txt catnip draft-mcgovern-ipng-catnip-wpaper-00.txt IPng Criterias 10E9 networks, 10E12 end-systems topologically flexible high performance robust media independent datagram protocol autoconfiguration secure operation globally unique names support multicasting extensible service classes support mobile hosts tunneling straightforward transition plan Nostradamus mode predicting the future is hard from "A Proposal for a Next Generation Internet Protocol" Ross Callon - December, 1987 detailed requirements seen for 1997 Internet doubling every year (720 assigned nets in '87) listed requirements: change should last for at least 10-15 years very high speed nets (microsecond forwarding time) plan for at least 100,000 nets, 10,000 ASs administrative diversity - addressing complexity effective general congestion control efficient source routing side note: "The expected arrival of ISDN will have a major impact on data communications in the 1990's and beyond." Assumptions we see consensus on the following points we need to make a specific recommendation now basic requirements agreed to proceed with single IPng effort Reviews of IPng Proposals xxx Recommendations go forward with single IPng working group all base documents to be ready for proposed standard consideration by December minimual required IPng functionality must include autoconfiguration & security IPng Working Group a new IPng working group be formed chairs: Deering, xxx, yyy short-term milestones for the proposed standards for IPng IPng BOF meeting twice in Toronto base IPng draft documents SIPP-16 SST IPng Working Group, charter outline Existing IPng Proposal Working Groups at start of process we said that we would not force shutdown of existing working groups when IPng recomendation made current IPng proposal working groups returned to Internet area can continue to work, but work will not be on IPng or expected to have specific influence on IPng can disband if chairs so choose IPng Addresses 16 byte Internet address address formats determined by IPng working group assignment coordinated by the IANA IPng Addresses, contd propose mapping algorythms from and to other environments where addresses are globally unique and assigned along network topology IPX, NSAPA, etc work with other organizations for development of such mappings Autoconfiguration autoconfiguration a required feature of IPng an IPng autoconfiguration working group be formed chairs - Sue Thompson & Dave Katz base document draft from Sue Thompson & Dave Katz serverless & serverfull modes must be supported Autoconfiguration WG charter Transition two IPng transition efforts short term refine IPng-specific documents for proposed standard long term transition, coexistance & testing Transition, short term new short lived working group - NGTRANS base document - final SST overview from IPng WG create series of standards track documents NGTRANS charter Transition, long term Transition and Coexistence Including Testing (tacit) WG Atul Bansal, Digital Geoff Huston, AARNet transition to IPng from multiple protocols understand economics of transition multiple protocol coexistence understanding testing requirements is vital Internet now viewed as a utility ongoing effort not just IPv4 -> IPng ???? -> IPng IPng -> IPgang TACIT charter facets of issue transition from the currently deployed protocol to a new protocol heterogeneity and decentralization will need to be accommodated long period of coexistence between a protocol and the existing protocol the Internet must now be considered a utility rigorous testing needed as part of predeployment phase goals learn from other transition and deployment efforts detail problems areas in transition and coexistence recommendation of specific testing procedures recommendation of coexistence operations procedures with IPv4 recommendations for the smoothing of decentralized transition planning facillatate transition pland from other network technologies e.g. IPX, CLNP IPng coordinator (inquisitor?) appoint an IPng directorate member to be specifically responsibe for ensuring that a consistant view of IPng is maintained across the working groups job description ask the exhaustive questions connecting all the points, offering the broadest perspective, but not making architectural decisions that is the work of the wgs and the ietf. Security o - specific efforts be undertaken to establish an IPng security framework as the standard practice authentication header is very important default case encryption is very important EIDs much discussion, little resolution too much at a research status do not think EID work will affect IPng header format sanctioned EID BOF in Toronto any follow on WG likley not in IPng area transport possible Other Needed Work changing the size of the internetwork layer address effects many IETF standards new working groups must be formed in many areas to TCP From scoya@CNRI.Reston.VA.US Mon Jul 18 10:18:16 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA27409 for ; Mon, 18 Jul 1994 10:19:28 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03754; 18 Jul 94 10:18 EDT To: Steve Deering cc: Lois Aylestock , ipng@cmf.nrl.navy.mil Subject: Re: Ipng Teleconference July Monday 18, 1994 In-reply-to: Your message of "Sun, 17 Jul 94 22:31:42 PDT." <94Jul17.223152pdt.12171@skylark.parc.xerox.com> Date: Mon, 18 Jul 94 10:18:16 -0400 From: Steve Coya Message-ID: <9407181018.aa03754@IETF.CNRI.Reston.VA.US> >> [By the way, are Lois Keiper and Lois Aylestock one and the same?] Yup. Lois Keiper became Lois Aylestock on May 27th. From laylesto@IETF.CNRI.Reston.VA.US Mon Jul 18 10:44:57 1994 Return-Path: laylesto@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA27780 for ; Mon, 18 Jul 1994 10:42:53 -0400 Received: from [132.151.1.63] by IETF.CNRI.Reston.VA.US id aa04314; 18 Jul 94 10:39 EDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Jul 1994 10:44:57 -0500 To: ipng@cmf.nrl.navy.mil From: Lois Aylestock MMDF-Warning: Parse error in original version of preceding line at IETF.CNRI.Reston.VA.US Subject: Ipng Teleconference July Monday 18, 1994 Cc: laylestock@IETF.CNRI.Reston.VA.US Message-ID: <9407181039.aa04314@IETF.CNRI.Reston.VA.US> > FINAL: > >> >>The names marked with an asterisk are those who have confirmed participation >>for the IPng teleconference scheduled for July 18, 1994 at 11:30 - 1:30 >>EDT. >>Thank you for your prompt responses!!!! >> >> >> ?J. Allard 206-936-9031? >> *Steve Bellovin 908-582-5886* >> -Jim Bound REGRETS >> *Scott Bradner 617-661-3295* >> *Ross Callon 714-553-0100* (room 806) > *Brian Carpenter +41 22 767 4967* >> *Dave Clark 617-253-6003* > *Steve Coya 703-620-8990* >> *John Curran will call in after 12pm* >> *Steve Deering 415-812-4839* >> *Dino Farinacci 408-226-6870* >> *Eric Fleischman 206-957-5334* >> ?Paul Francis +81 33 928 0408? > ?Mark Knopper 313-741-5445? > *Allison Mankin 212-642-4954* >> *Greg Minshall 408-577-7511* > ?Rob Ullmann 617-693-1315? >> *Lixia Zhang 415-812-4415* >> *Paul Mockapetris 212-642-4954* (special guest) >> >>If you need to be added to the teleconference call in progress, please call >>1-800-232-1234 or for the international participants, 516-424-3151. The call >>can be referenced by the confirmation number -ER16042 in the orginators name, >>Steve Coya. >> >>Thanks >> >> >>Lois >> >> >> > >Lois J. Keiper >IETF Secretariat > > From brian@dxcoms.cern.ch Mon Jul 18 18:32:07 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA00169 for ; Mon, 18 Jul 1994 13:46:22 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA04101; Mon, 18 Jul 1994 19:45:56 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05481; Mon, 18 Jul 1994 18:32:08 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407181632.AA05481@dxcoms.cern.ch> Subject: 15 months progress in understanding? To: ipng@cmf.nrl.navy.mil Date: Mon, 18 Jul 1994 18:32:07 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1019 Look at the date... look at the progress in clarification since then... Brian >--------- Text sent by brian follows: > From brian Thu Apr 15 14:02:08 1993 > Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) > To: Bob.Hinden@eng.sun.com (Bob Hinden) > Date: Thu, 15 Apr 1993 14:02:08 +0200 (MET DST) > In-Reply-To: <9304150514.AA00514@bigriver.Eng.Sun.COM> from "Bob Hinden" at Apr 14, 93 10:14:23 pm > X-Mailer: ELM [version 2.4 PL20] > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Content-Length: 415 > > Bob, > > I won't waste list resources on this but I like the logical structure > of your sentence: > > > > A problem I have with s is that as a general concept they are simple > > to understand, but doesn't seem to be any agreement as to what they are. > > > where of course many things besides EID could be substituted for . > I've kept out of the EID debate for exactly the reason you express > in this sentence! > > Brian > From deering@parc.xerox.com Mon Jul 18 11:08:05 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA00555 for ; Mon, 18 Jul 1994 14:14:43 -0400 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14455(9)>; Mon, 18 Jul 1994 11:08:27 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 18 Jul 1994 11:08:17 -0700 To: ipng@cmf.nrl.navy.mil Subject: SST draft Date: Mon, 18 Jul 1994 11:08:05 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul18.110817pdt.12171@skylark.parc.xerox.com> In case any directorate members are not on the sipp list... ------- Forwarded Message Date: Sun, 17 Jul 1994 07:06:43 -0700 >From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) To: sipp@sunroof.eng.sun.com Subject: (sipp) SST overview paper As promised, I have written up an overview paper explaining the Simple SIPP Transition (SST) proposal. I'll send this in to the internet drafts editor today so that it can be entered into the archives before the Toronto meeting. Send comments, questions or suggestions to me or the list. We can discuss SST more at the SIPP working group meeting in Toronto. Bob. Internet Engineering Task Force Robert E. Gilligan INTERNET-DRAFT Sun Microsystems, Inc. July 17, 1994 Simple SIPP Transition (SST) Overview Abstract In order to address problems of scaling and address space, the Simple Internet Protocol Plus (SIPP) has been proposed as the new version of the Internet Protocol (IP). If SIPP is to be widely adopted in the global Internet, the transition from the current IP must be simple and easy for users as well as network operators. In order for this to occur, hosts and routers implementing the new protocol must interoperate with the large installed base of systems which continue to use the existing IP. In addition, the transition process must not disrupt the operation of the Internet. This paper provides an overview of a set of mechanisms, operational practices, and transition plans that can be used for transitioning the Internet from IPv4 to SIPP. These techniques are collectively termed the Simple SIPP Transition (SST). While specifically designed to transition the IPv4 Internet to SIPP, the methods used in SST could be adapted to transition other internet layer protocols such as IPX or CLNP to SIPP. Status of this Memo 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. This Internet Draft expires on January 17, 1995. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this memo is unlimited. draft-ietf-sipp-sst-overview-00.txt [Page 1] INTERNET-DRAFT SST Overview July 1994 History and Acknowledgements SST is the result of the efforts of the SIPP, SIP, PIP, and IPAE working groups over a period of more than two years. SST is based on the IPAE proposal [IPAE]. IPAE was based on ideas originally developed by Dave Crocker and Bob Hinden. Erik Nordmark, Ron Jacoby, Steve Deering, Bob Hinden and Dave Crocker made significant contributions to the design of IPAE. SST can be viewed as a simplification of IPAE. A number of people provided feedback on IPAE and suggested changes which lead to SST. SST incorporates many of these changes, including: - Complete elimination of table-based IPv4/SIPP address mapping, as suggested by John Curran. - Elimination of the C-bit, and replacing it with a simplified form of "IPv4 compatible SIPP address", using the 32-bit "C prefix" suggested by Bill Simpson. - More use of the "dual stack" technique in both hosts and routers, as suggested by Ross Callon. - A consistent and intuitive nomenclature, as suggested by Jim Bound. A number of people have provided feedback and suggestions on earlier drafts of this paper, including ... draft-ietf-sipp-sst-overview-00.txt [Page 2] INTERNET-DRAFT SST Overview July 1994 1. Introduction The Simple SIPP Transition (SST) is a set of mechanisms and practices to transition the Internet from IP version 4 (IPv4) to the Simple Internet Protocol Plus (SIPP). SST is made up of a number of elements: - A SIPP addressing structure that embeds IPv4 addresses in SIPP addresses, and encodes other information used by the transition mechanisms within SIPP addresses. - Transition mechanisms such as SIPP-in-IPv4 encapsulation and SIPP/IPv4 header translation, which are implemented in hosts, routers, and special header translating routers. These mechanisms allow SIPP nodes to interoperate with IPv4 nodes, and allow SIPP nodes to utilize IPv4 routing infrastructures. - Operational practices for assigning IPv4 and SIPP addresses. - Operational practices for upgrading hosts and routers and deploying new hosts and routers. - Operational practices for deploying DNS servers that support the SIPP address record type. - Plans for transitioning individual Internet sites to SIPP. - Plans for transitioning the global Internet to SIPP. SST provides a number of features, including: - Incremental upgrade. Existing installed IPv4 hosts and routers may be upgraded to SIPP at any time without being dependent on any other hosts or routers being upgraded. - Incremental deployment. New SIPP hosts and routers can be installed at any time without any prerequisites. - Easy Addressing. When existing installed IPv4 hosts or routers are upgraded to SIPP, they may continue to use their existing address. They do not need to be assigned new addresses. - Low start-up costs. Little or no preparation work is needed in order to upgrade existing IPv4 systems to SIPP, or to deploy new SIPP systems. 1.1. Additional Documents draft-ietf-sipp-sst-overview-00.txt [Page 3] INTERNET-DRAFT SST Overview July 1994 This paper provides an overview of SST. It gives an introduction to the concepts used in the transition, and describes the mechanisms that are employed. This is not a specification document. The requirements on the hosts, routers and header translating routers are detailed in two companion documents: - SIPP Transition Mechanisms for Hosts and Routers [SST-HR] This is a detailed specification of the transition mechanisms that hosts and routers implement. This is a specification document, written with the standard MUST/SHOULD/MAY wording. - SIPP Transition Mechanisms for Header Translating Routers [SST-TR] This a detailed specification of the special mechanisms that translating routers must implement. This is a specification document, written with the standard MUST/SHOULD/MAY wording. No transition proposal can be complete without a detailed plan for how the transition will be carried out operationally. For SST, this information is detailed in a companion document: - SIPP Transition Plan [SST-TP] This is an informational paper detailing the specific operational steps that must be taken to transition the Internet to using SIPP globally. This paper includes time lines for the transition, and identifies specific milestones. 1.2. Intended Audience Individuals such as end users and system administrators who are interested in the concepts of SST can read this paper by itself. People implementing host and router software which will incorporate the transition mechanisms should read this paper in conjunction with the specification documents. People who will be involved in the transitioning the operational Internet should read this paper along with the SIPP Transition Plan. All readers should be familiar with SIPP and IPv4. The SIPP specification [SIPP] should be read before reading this document. 1.3. Notation This paper is written assuming a 128-bit SIPP address size. We use draft-ietf-sipp-sst-overview-00.txt [Page 4] INTERNET-DRAFT SST Overview July 1994 the following notation to write SIPP addresses: xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ddd.ddd.ddd.ddd Where "x" represents a hex digit, and "d" represents a decimal digit. Each group of hex digits separated by ":" represents 16 bits of the address. Leading zero digits in each group are suppressed. Each group of decimal digits separated by "." represents 8 bits of the address. Leading zero digits are suppressed here also. It is expected that the notation for 128-bit SIPP addresses will eventually be standardized and defined in the SIPP specification document. 1.4. Adaptability to Other Internet Layer Protocols If SIPP is successful as a successor to IPv4, then organizations operating networks of other internet layer protocols, such as CLNP or IPX, may wish to transition them also to SIPP. The techniques in SST can be adapted to transition virtually any existing internet layer infrastructure to SIPP so long as the following assumptions hold: - Addresses in the other internet layer protocol can be mapped into the SIPP address space efficiently. - The semantics of the other internet layer protocol are similar enough for header translation to work. If these assumptions do not hold, or if the population of nodes running the other protocol is small, a "pure dual stack" transition approach may be more appropriate. The first assumption appears to be true for CLNP and IPX. SIPP address space has been assigned for CLNP NSAP and IPX addresses in the SIPP Routing and Addressing specification document [SIPP-ROAD]. And both CLNP and IPX are semantically close enough to SIPP to believe that header translation may be possible. draft-ietf-sipp-sst-overview-00.txt [Page 5] INTERNET-DRAFT SST Overview July 1994 2. Definitions A number of new terms are introduced in this paper. IPv4-only node: A host or router that speaks only IPv4. An IPv4-only node does not understand SIPP. The existing installed base of IPv4 hosts and routers today are all IPv4-only nodes. SIPP/IPv4 node: A host or router that speaks both IPv4 and SIPP. SIPP/IPv4 nodes must implement transition mechanisms (e.g. tunneling) in addition to the basic SIPP and IPv4 protocols. SIPP-only node: A host or router that speaks only SIPP and implements a few simple transition mechanisms. A SIPP-only node does not understand IPv4. SIPP/IPv4 header translating router: A SIPP/IPv4 router that performs SIPP/IPv4 header translation. IPv4-compatible SIPP address: A SIPP address that holds an IPv4 address embedded in the low-order 32-bits. IPv4-compatible SIPP addresses bear the prefix 0:0:0:0:0:0 or 0:0:0:0:0:1. IPv4-compatible SIPP addresses with the prefix 0:0:0:0:0:0 identify IPv4-only nodes. IPv4-compatible SIPP addresses with the prefix 0:0:0:0:0:1 are assigned to SIPP/IPv4 or SIPP-only nodes. IPv4-incompatible SIPP address: A SIPP address that does not necessarily hold an IPv4-address embedded in the low-order 32-bits. IPv4-incompatible SIPP addresses bear the prefixes 0:0:0:0:0:2 through ffff:ffff:ffff:ffff:ffff:ffff. IPv4-incompatible SIPP addresses are assigned to SIPP/IPv4 or SIPP-only nodes. SIPP/IPv4 area: A region of infrastructure interconnected by IPv4-only or SIPP/IPv4 routers. draft-ietf-sipp-sst-overview-00.txt [Page 6] INTERNET-DRAFT SST Overview July 1994 SIPP-only area: A region of infrastructure interconnected by SIPP-only routers. SIPP-in-IPv4 tunneling (encapsulation): The technique of encapsulating SIPP packets within IPv4 so that it can be carried across the IPv4 topology of a SIPP/IPv4 area. SIPP/IPv4 header translation: The technique of translating SIPP packets into IPv4, and IPv4 packets into SIPP, so that IPv4-only and SIPP-only hosts can interoperate. draft-ietf-sipp-sst-overview-00.txt [Page 7] INTERNET-DRAFT SST Overview July 1994 3. Transition Model The design of SST is based on two fundamental assumptions about how the transition will take place. The first is that the Internet will transition to SIPP in an evolutionary fashion over an extended period of time. The second is that the sites that make up the Internet will transition at different rates and on different time schedules. It is expected that, for most Internet sites, the transition will occur in two phases. First, they will evolve from their initial state, in which all hosts and routers support only IPv4, to a state where most hosts and routers support both SIPP and IPv4. In the second phase, Internet sites would evolve to a state where all of the hosts and routers support only SIPP, and none directly support IPv4. The second phase is optional. Sites may elect to stop when the first phase is complete. The transition from an "IPv4-only" infrastructure to a "dual SIPP and IPv4" infrastructure will take place at different speeds in different Internet sites. Some organizations will transition rapidly, while others will delay transition for quite some time. This transition phase can begin immediately, but may be carried out over an extended period of time. The eventual transition of some areas of the Internet to a "SIPP-only" infrastructure is unlikely to begin immediately. It will more likely begin only after the first phase of transition is completed, or at least well under way. Even after some areas begin a transition to SIPP-only, other areas of the Internet may choose to remain IPv4-only or SIPP/IPv4 indefinitely. In order to accommodate this, SST provides a way for hosts that only support SIPP to continue to interoperate with hosts that only support IPv4. Most organizations that do decide to transition to a SIPP-only infrastructure will likely do so only after first transitioning to a dual SIPP/IPv4 infrastructure. However, this is not strictly required. Sites may transition directly from IPv4-only to SIPP-only if they wish. And organizations building entirely new infrastructures may elect to make them SIPP-only. The general timeline of transition for the Internet can be viewed as: IPv4 only -----> Dual SIPP/IPv4 -----> SIPP only (first phase) (second phase) Today --- Time ---> Future draft-ietf-sipp-sst-overview-00.txt [Page 8] INTERNET-DRAFT SST Overview July 1994 SST is designed to optimize what is expected to be the common case for most sites: a two-phase transition. SST makes the first phase -- transition to dual SIPP/IPv4 -- quite easy, requiring virtually no interdependencies. The second phase -- transition to a SIPP-only infrastructure -- requires somewhat more effort. Some planning is needed, and translating routers must be deployed, before any SIPP-only infrastructure can be built. Nevertheless, once a site has transitioned to SIPP/IPv4, its subsequent transition to SIPP-only is straightforward. draft-ietf-sipp-sst-overview-00.txt [Page 9] INTERNET-DRAFT SST Overview July 1994 4. System Components SST assumes that three different types of hosts and routers will exist: - "IPv4-only nodes" are routers and hosts that only support IPv4; They do not support SIPP. At the beginning of the transition, all hosts and routers in the Internet are IPv4-only. - "SIPP/IPv4 nodes" are hosts and routers that support both SIPP and IPv4, as well as some additional transition mechanisms such as SIPP-in-IPv4 tunneling. SIPP/IPv4 nodes can directly interoperate with both SIPP and IPv4 nodes, although to interoperate with IPv4-only nodes, they must be configured with an "IPv4-compatible" SIPP address. The first transition phase in a site involves converting most or all hosts and routers in that site from IPv4-only to SIPP/IPv4. - "SIPP-only nodes" are hosts and routers that support only SIPP. SIPP-only nodes implement a few simple features (such as a compatible TCP pseudo-header checksum algorithm) that allow them to interoperate with IPv4 nodes, but they do not provide an IPv4 protocol implementation. Like SIPP/IPv4 nodes, SIPP-only nodes must be configured with "IPv4-compatible" SIPP addresses in order to interoperate with IPv4 nodes. The second phase of transition in a site involves converting all of the hosts and routers in that site to SIPP-only. Note: The simple IPv4-compatibility features implement are optional. They need not be implemented in SIPP-only nodes that never will interoperate with IPv4 nodes. However, SIPP-only nodes that do not interoperate with IPv4 are outside the scope of this paper. One additional type of node is used in the transition: - "SIPP/IPv4 header translating routers" are SIPP/IPv4 routers that translate IPv4 packets into SIPP, and SIPP packets into IPv4. Translating routers are needed in order for SIPP-only nodes that are configured with IPv4-compatible addresses to interoperate with IPv4-only nodes. It is expected that as part of their normal evolution, most products that implement the Internet Protocols will eventually become "SIPP/IPv4". Vendors may deliver this product change as part of a normal software release. Users will install such upgrades as part of their normal operational procedures. Thus hosts and routers may transition from IPv4-only to SIPP/IPv4 as part of a normal system draft-ietf-sipp-sst-overview-00.txt [Page 10] INTERNET-DRAFT SST Overview July 1994 upgrade. Since SIPP/IPv4 hosts and routers keep their complete IPv4 implementation, any IPv4-only host or router can be upgraded to SIPP/IPv4 without affecting its IPv4 functionallity in any way. Thus most IPv4-only nodes can be upgraded to SIPP/IPv4 at any time. .bp 5. Addressing The SIPP addressing structure which SST uses encodes the following information into SIPP addresses: - An IPv4 address. Some SIPP addresses hold an IPv4 address in the low-order 32-bits. - Whether an IPv4 address is embedded. The high-order 96-bits of the address encode whether the low-order 32-bits hold an IPv4 address. - Whether the node is IPv4-only. The high-order 96-bits of the address encode whether the address identifies an IPv4-only node or a SIPP node. SST employs two special 96-bit SIPP address prefixes: 0:0:0:0:0:0 and 0:0:0:0:0:1. All SIPP addresses with these two prefixes hold an IPv4 address in the low-order 32 bits. These addresses are termed "IPv4-compatible SIPP addresses." The first prefix, 0:0:0:0:0:0, is used to identify IPv4-only nodes. The addresses of all IPv4-only nodes are mapped into the SIPP address space under the prefix 0:0:0:0:0:0. In other words, a SIPP address of the form: 0:0:0:0:0:0: identifies an IPv4-only host or router that has been assigned the IPv4 address . Addresses with the 0:0:0:0:0:0 prefix show up in packets, but not in the DNS. SIPP "ASEQ" address records are NOT listed in the DNS for IPv4-only nodes. IPv4-only nodes continue to have only IPv4 "A" records listed in the DNS. The prefix 0:0:0:0:0:1 is used to assign addresses to SIPP nodes (SIPP/IPv4 or SIPP-only) that wish to interoperate with IPv4 nodes. Any SIPP node that wishes to interoperate with IPv4 nodes must be assigned an address of the form: 0:0:0:0:0:1: If a SIPP node does not have at least one address with the prefix 0:0:0:0:0:1 it can not interoperate with IPv4 hosts. draft-ietf-sipp-sst-overview-00.txt [Page 11] INTERNET-DRAFT SST Overview July 1994 When an address with the prefix 0:0:0:0:0:1 is assigned to a SIPP node, the low-order 32-bits (the portion) must be a valid, globally unique, IPv4 address assigned according to the IPv4 numbering plan used on the subnet to which that node is attached. Two address records must be listed in the DNS. The full 128-bit SIPP address must be listed in the DNS with an ASEQ record. In addition, the low-order 32-bits of the address must be listed in the DNS with an A record. Listing A records in the DNS allows IPv4-only nodes to contact SIPP nodes that have IPv4-compatible addresses. The remainder of the SIPP address space -- those addresses with 96-bit prefixes from 0:0:0:0:0:2 through ffff:ffff:ffff:ffff:ffff:ffff -- are used to assign addresses to SIPP nodes that DO NOT wish to interoperate with IPv4 nodes. These are termed "IPv4-incompatible" SIPP addresses because they are not be used for interoperating with IPv4 nodes. IPv4-incompatible addresses may hold an embedded IPv4 address, however, the transition mechanisms do not require or use that information. The entire space of IPv4-incompatible SIPP addresses is available for use in a global SIPP addressing plan that is not burdened with transition requirements. For example, an addressing plan for auto-configured addresses could be developed which is completely independent of the transition mechanisms. When IPv4-incompatible SIPP addresses are assigned to SIPP nodes, only "ASEQ" records are listed in the DNS. "A" records are not needed -- or even possible -- because IPv4-incompatible SIPP addresses can not be used for interoperating with IPv4 nodes. SIPP Addressing Summary: Embedded DNS Record IPv4 Type of Type High-order 96-bit prefix Addr Node Required ------------------------ ------- ---------- ------- 0:0:0:0:0:0 Yes IPv4-only A only 0:0:0:0:0:1 Yes SIPP/IPv4 or A and SIPP-only ASEQ 0:0:0:0:0:2 through ffff:ffff:ffff:ffff:ffff:ffff No SIPP/IPv4 or ASEQ only SIPP-only draft-ietf-sipp-sst-overview-00.txt [Page 12] INTERNET-DRAFT SST Overview July 1994 The ability of IPv4-only, SIPP/IPv4 and SIPP-only nodes to interoperate is as follows: --------------------------- SIPP-only node \ w/ IPv4-incompatible \ Address \ ------------------------ \ SIPP-only node \ \ w/ IPv4-compatible \ \ Address \ \ --------------------- \ \ SIPP/IPv4 node \ \ \ w/ IPv4-incompatible \ \ \ Address \ \ | ------------------ \ \ | SIPP/IPv4 node \ \ | | w/ IPv4-compatible \ \ | | Address \ | | | --------------- \ | | | IPv4-only node \ | | | | ------------\ \ | | | | ---------------------+---+----+----+----+----+ IPv4-only node | D | D | N | T | N | ---------------------+---+----+----+----+----+ SIPP/IPv4 node | | | | | | w/ IPv4-compatible | D | D | D | D | D | Address | | | | | | ---------------------+---+----+----+----+----+ SIPP/IPv4 node | | | | | | w/ IPv4-incompatible | N | D | D | D | D | Address | | | | | | ---------------------+---+----+----+----+----+ SIPP-only node | | | | | | w/ IPv4-compatible | T | D | D | D | D | Address | | | | | | ---------------------+---+----+----+----+----+ SIPP-only node | | | | | | w/ IPv4-incompatible | N | D | D | D | D | Address | | | | | | ---------------------+---+----+----+----+----+ D = Direct Interoperability T = Interoperability with aid of a translating router N = Non Interoperable draft-ietf-sipp-sst-overview-00.txt [Page 13] INTERNET-DRAFT SST Overview July 1994 6. Tunneling and Translation 6.1. Topologies The routing model used in SST is designed to deal with the routing topologies that are likely to develop in the Internet as the transition progresses: - "SIPP/IPv4 areas" are topologies that are connected either by IPv4-only routers or SIPP/IPv4 routers. SIPP/IPv4 areas route IPv4 completely to ALL subnets within the area. In addition, they may route SIPP, although this is not required. If SIPP routing is provided in a SIPP/IPv4 area, it may not be to every subnet within the area. Topologies that consist exclusively of IPv4-only routers are considered SIPP/IPv4 areas. There are some restrictions on what types of hosts can operate in SIPP/IPv4 areas. They may hold IPv4-only or SIPP/IPv4 hosts. However SIPP-only hosts can not be deployed in SIPP/IPv4 areas because SIPP routers are not present on every subnet. - "SIPP-only areas" are topologies that are connected by SIPP-only routers, or SIPP/IPv4 routers with IPv4 routing disabled. SIPP is routed completely within SIPP-only areas, and IPv4 is not routed at all. Thus SIPP-only areas can directly carry ONLY SIPP packets. There are some restrictions on what hosts can operate in SIPP-only ares. SIPP/IPv4 or SIPP-only can be deployed, but IPv4-only hosts may not be deployed in SIPP-only areas because IPv4 routers are not present. Note that SST is not designed to deal with a single area that is composed of a mixture of IPv4-only and SIPP-only routers. It is not generally possible to mix SIPP-only and IPv4 only routers. The two can not exchange packets because they do not share a common protocol. However, area sizes may be quite flexible: a single node may be treated as an area, as may the entire Internet. SIPP/IPv4 and SIPP-only areas may be interconnected subject to a few restrictions: - SIPP/IPv4 areas can be inter-connected with other SIPP/IPv4 areas by IPv4-only or SIPP/IPv4 routers, forming larger SIPP/IPv4 areas. For example: SIPP/IPv4 area ---- SIPP/IPv4 router ---- SIPP/IPv4 area draft-ietf-sipp-sst-overview-00.txt [Page 14] INTERNET-DRAFT SST Overview July 1994 or SIPP/IPv4 area ---- IPv4 router ---- SIPP/IPv4 area - SIPP-only areas may be interconnected with other SIPP-only areas by SIPP-only routers, or SIPP/IPv4 routers with IPv4 disabled, forming larger SIPP-only areas. For example: SIPP-only area ---- SIPP-only router ---- SIPP-only area or SIPP-only area ---- SIPP/IPv4 router ---- SIPP-only area (IPv4 disabled) - SIPP/IPv4 areas may ONLY be interconnected with SIPP-only areas by a translating router. SIPP/IPv4 and SIPP-only areas MAY NOT be interconnected by standard IPv4-only, SIPP/IPv4 or SIPP-only routers. For example: SIPP/IPv4 area ---- Translating router ---- SIPP-only area 6.2. SIPP-in-IPv4 Tunneling SIPP packets can be carried across segments of the IPv4 topology of SIPP/IPv4 areas by using the SIPP-in-IPv4 tunneling technique. A SIPP/IPv4 node that has IPv4 reachability to another SIPP/IPv4 node may send SIPP packets to that node by encapsulating them within IPv4 headers. In order for this technique to work, both nodes must be assigned IPv4-compatible SIPP addresses. This is necessary because the low-order 32-bits of those addresses are used as source and destination addresses of the encapsulating IPv4 header. For example, say two SIPP/IPv4 nodes N1 and N2 are attached to a common SIPP/IPv4 area: SIPP/IPv4 ------- SIPP/IPv4 area ------- SIPP/IPv4 Node N1 Node N2 (0:0:0:0:0:1:129.144.1.2) (0:0:0:0:0:1:192.9.5.3) If N1 wishes to send a SIPP packet to N2, it could encapsulate that packet within an IPv4 packet as follows: +---------------------+ | | | src = 129.144.1.2 | IPv4 Header | dst = 192.9.5.3 | | | draft-ietf-sipp-sst-overview-00.txt [Page 15] INTERNET-DRAFT SST Overview July 1994 +---------------------+ | | . . SIPP Header . . . . When N2 receives this packet, it decapsulates it (remove the IPv4 header), and then process the SIPP header as it would any received SIPP packet. Note that the source address of the encapsulating IPv4 packet is the low-order 32-bits of N1's IPv4-compatible SIPP address, and the destination address is the low-order 32-bits of N2's IPv4-compatible SIPP address. The SIPP-in-IPv4 tunneling technique can be used between two SIPP/IPv4 hosts. In that case, the tunneling is "end-to-end". Tunneling can also be used between two SIPP/IPv4 routers, between a SIPP/IPv4 router and a SIPP/IPv4 host, or between a SIPP/IPv4 host and a SIPP/IPv4 router. In these three cases, the tunneling is over only a segment of the complete end-to-end path. In all cases, however, the source address of the IPv4 header is the low-order 32-bits of the SIPP address of the node that performs the encapsulation, and the destination address of the IPv4 header is low-order 32-bits of the SIPP address of the node that the encapsulating node expects to decapsulate the packet. Constructing the encapsulating IPv4 header is straightforward when a SIPP/IPv4 host or router is tunneling a SIPP packet directly to the destination host: The "tunnel endpoint" address (destination address of the encapsulating IPv4 packet) is simply the low-order 32-bits of the SIPP packet's destination address. Since the "tunnel endpoint" address is carried in the SIPP packet being tunneled, tunneling to end-hosts can be viewed as "stateless" or "automatic". When tunneling to an intermediary router, the tunnel endpoint address is the low-order 32-bits of the router's SIPP address. Since this information is not carried in the packet, tunneling to intermediary routers requires configuration on the host or router doing the tunneling. This configuration information could come in the form of routing table information on a host, or neighbor configuration information on a router. Hosts and routers in SST make extensive use of "automatic" tunneling to hosts, but only tunnel to intermediary routers when configured to do so. Except for the case of translating routers (see next section), the intermediary routers on the path between the encapsulating node and the decapsulating node do not look at the SIPP header of the packet. They draft-ietf-sipp-sst-overview-00.txt [Page 16] INTERNET-DRAFT SST Overview July 1994 route the packet entirely based on its IPv4 header. This is the case even if the routers along the path are SIPP/IPv4 routers. In summary, SIPP-in-IPv4 tunneling can be done between the following pairs of SIPP/IPv4 nodes: Encapsulating Decapsulating Node Node Tunnel Endpoint IPv4 Address ----------- ---- ---------------------------- Source Host Dest Host Low-order 32-bits of dest addr Source Host Router Low-order 32-bits of router addr Router Router Low-order 32-bits of router addr Router Dest Host Low-order 32-bits of dest addr 6.3. Header Translation. Header translating routers bridge the IPv4 infrastructure of SIPP/IPv4 areas into the SIPP infrastructure of SIPP-only areas. There are two kinds of traffic that need to be so bridged: IPv4 packets sent to or from IPv4-only nodes, and SIPP packets encapsulated within IPv4 headers sent between SIPP nodes. Translating routers must provide all of the features required of SIPP/IPv4 routers since they must route both SIPP and IPv4 packets. In addition to their routing responsibilities, they must perform three specific functions: - Translate IPv4 headers into SIPP. The IPv4 packets that must be translated are those that are generated by IPv4-only nodes, and addressed to SIPP nodes located within SIPP-only areas. For example: (IPv4 packet) --> (Translate to SIPP) --> (SIPP Packet) SIPP/IPv4 area ----- Translating router ----- SIPP-only area | | | | IPv4-only node SIPP-only node - Translate SIPP headers into IPv4. The SIPP packets that must be translated are those that are generated by SIPP nodes located within SIPP-only areas, and addressed to IPv4-only draft-ietf-sipp-sst-overview-00.txt [Page 17] INTERNET-DRAFT SST Overview July 1994 node. For example: (IPv4 packet) <-- (Translate to IPv4) <-- (SIPP Packet) SIPP/IPv4 area ----- Translating router ----- SIPP-only area | | | | IPv4-only node SIPP-only node - Decapsulate SIPP-in-IPv4 packets. Translating routers must decapsulate all SIPP-in-IPv4 packets, even those that are not addressed to them. For example: (SIPP packet encapsulated in IPv4) --> (Decapsulate) --> (SIPP Packet) SIPP/IPv4 area ----- Translating routers ----- SIPP-only area | | | | SIPP/IPv4 node SIPP-only node 6.4. Routing Decisions When sending packets, SIPP/IPv4 nodes must decide whether to use SIPP-in-IPv4 tunneling. Generally speaking, a SIPP/IPv4 node may encapsulate when the following are true: - It is configured with an IPv4-compatible SIPP address (i.e. its own SIPP address has the prefix 0:0:0:0:0:1). - The destination or the next hop router is a SIPP node represented by an IPv4-compatible SIPP address (i.e. has the prefix 0:0:0:0:0:1). - It is attached to a SIPP/IPv4 area. - The destination or the next hop router is attached to the same SIPP/IPv4 area. (Since SIPP/IPv4 areas must provide complete IPv4 routing, this implies IPv4 reachability between the two nodes.) The first two items can be determined simply by inspecting the source and destination SIPP addresses. draft-ietf-sipp-sst-overview-00.txt [Page 18] INTERNET-DRAFT SST Overview July 1994 The third item -- whether the node is attached to a SIPP/IPv4 area -- is not so trivial. However, since SIPP-only areas hold no IPv4 routers (even SIPP/IPv4 routers operating in SIPP-only areas are required to have IPv4 routing disabled) and SIPP/IPv4 areas require IPv4 routing to all subnets, a SIPP/IPv4 node may safely assume that it is attached to a SIPP/IPv4 area if it has at least one neighbor IPv4 router. The fourth item -- whether the destination is attached to the same SIPP/IPv4 area -- can not be directly determined. However, because of the decapsulation algorithm that all translating routers perform, a SIPP/IPv4 node may safely assume that ALL destinations are within the same SIPP/IPv4 area. If this assumption is false, and the destination actually is located within a SIPP-only area, the translating router at the border of that area will decapsulate the packet and forward it based on its SIPP destination address. In many instances, especially as SIPP/IPv4 routers are being deployed in a site, a node will have the ability to tunnel to a destination, and also have a route via an on-subnet SIPP router to that destination. In some cases, a node may even have a route to a destination via an off-subnet SIPP router that could be reached by tunneling. In general, SIPP/IPv4 nodes should prefer routes via on-subnet SIPP routers. If a route via an on-subnet router is not available, they should prefer a route via an off-subnet router. Only if no routes via SIPP routers are available should a SIPP/IPv4 node tunnel directly to the destination. While this routing policy should be the default, administrators should have the ability to override it. Route preference summary: Preference Route ---------- ----- First Via on-subnet SIPP router Second Via off-subnet SIPP router (tunnel to router) Third Tunnel to destination This preference ordering provides a number of advantages: - Less overhead because non-encapsulated SIPP packets are smaller than SIPP-in-IPv4 packets. - Traffic can take advantage of SIPP routing features such as special handling by flow ID. - Ensures that SIPP routing topology will be used as it is deployed. draft-ietf-sipp-sst-overview-00.txt [Page 19] INTERNET-DRAFT SST Overview July 1994 7. Node Requirements This section gives an overview of the mechanisms that each of the three system components -- SIPP/IPv4 nodes, SIPP-only nodes, and translating routers -- must implement. 7.1. SIPP/IPv4 Nodes SIPP/IPv4 nodes provide complete implementations of both IPv4 and SIPP. They must adhere to all SIPP and IPv4 specifications pertinent to their role as a host or router. Since SIPP/IPv4 nodes implement both protocols, they can directly interoperate with both SIPP and IPv4 nodes located on the same attached subnet. SIPP/IPv4 nodes must implement the SIPP-in-IPv4 tunneling mechanism, and must be able to determine which destinations can be reached by encapsulation as outlined in the previous section. They must implement the IPv4-compatible TCP, UDP, and ICMP pseudo-header checksum algorithm that is specified in [SIPP]. SIPP/IPv4 routers must have the ability to participate in both SIPP and IPv4 routing systems. System administrators must have the ability to disable IPv4 routing on SIPP/IPv4 routers, because those routers operating in SIPP-only areas must not route IPv4. Generally, when SIPP/IPv4 nodes send packets to IPv4-only nodes, they send those packets in the IPv4 format. However, if an IPv4 destination is not located on an attached subnet, and there are no IPv4 routers on the attached subnet, it must send a SIPP format packet. This packet will be translated back to IPv4 form by a translating router before it is delivered to the destination IPv4 node. When sending SIPP format packets to IPv4 destinations, it composes the destination address by prepending the 0:0:0:0:0:0 prefix to the destination's IPv4 address. A SIPP/IPv4 node must be configured with an IPv4-compatible SIPP address with the prefix 0:0:0:0:0:1 in order to interoperate with IPv4 nodes. When sending IPv4 packets to IPv4 nodes, a SIPP/IPv4 node uses the low-order 32-bits of its own IPv4-compatible SIPP address as the source address. When sending SIPP format packets, they must use their full IPv4-compatible SIPP address as the source. SIPP/IPv4 nodes should have the ability to be configured with multiple SIPP addresses per interface. In particular, a SIPP/IPv4 node should draft-ietf-sipp-sst-overview-00.txt [Page 20] INTERNET-DRAFT SST Overview July 1994 have the ability to configure each interface with an IPv4-compatible as well as an IPv4-incompatible SIPP addresses. If a SIPP/IPv4 node is configured with no IPv4-compatible SIPP addresses, it must treat all attempts to send packets to IPv4 destinations as "unreachable". This is necessary because the node can provide no valid IPv4 source address in the packets it would send. 7.2. SIPP-only nodes SIPP-only nodes provide a complete SIPP implementation, but no IPv4 implementation. They can directly interoperate with other SIPP nodes, but can not interoperate with IPv4-only nodes only with the assistance of a translating router. SIPP-only nodes must implement a few simple mechanisms in order make interoperability with IPv4 nodes possible. Like SIPP/IPv4 nodes, they must implement the IPv4-compatible TCP, UDP, and ICMP pseudo-header checksum algorithm that is specified in [SIPP]. Also like SIPP/IPv4 nodes, SIPP-only nodes must have the ability to send SIPP format packets to IPv4-only nodes. However, since SIPP-only nodes never send IPv4 format packets, the algorithm to do this can be simpler. When requested to send a packet to an IPv4 destination, a SIPP-only node can simply pre-pend the prefix 0:0:0:0:0:0 to that address, and send a SIPP format packet to the resulting SIPP address. SIPP-only nodes must also have the ability to handle "A" records in the DNS. Since IPv4-only nodes will only have A records listed in the DNS, SIPP-only nodes must be able to utilize these records when they are found in a DNS lookup. Since there is a one-to-one mapping from the IPv4 addresses of IPv4-only hosts to their corresponding SIPP address, SIPP-only hosts can easily transform the IPv4 address of an IPv4-only host into its SIPP address by pre-pending the prefix 0:0:0:0:0:0. The mapping of IPv4 addresses into SIPP addresses need not affect the SIPP or transport layer code in a SIPP-only host. It can usually be isolated in the DNS resolver or address parsing libraries. SIPP-only routers participate in only the SIPP routing systems. Like SIPP/IPv4 nodes, SIPP-only must be configured with IPv4-compatible SIPP addresses in order to interoperate with IPv4 nodes. And SIPP-only nodes should have the ability to configure multiple SIPP addresses per interface. 7.3. Header Translating Routers draft-ietf-sipp-sst-overview-00.txt [Page 21] INTERNET-DRAFT SST Overview July 1994 Header translating routers are SIPP/IPv4 routers which implement the translation mechanisms discussed in section 5. Translating routers must be configured to know which packets must be translated, and which can be simply forwarded without translation. This can be done by configuring the translating router to know which SIPP addresses are located within the SIPP-only area that it serves. Translating routers use this configuration information, along with the destination SIPP or IPv4 addresses of packets they receive to determine which packets to translate. They must: - Translate SIPP packets addressed to IPv4-only nodes outside the SIPP-only area to IPv4 - Translate IPv4 packets addressed to nodes within the SIPP-only area to SIPP. - Translate IPv4 packets addressed to nodes outside the SIPP-only area to SIPP if the resulting packets may transit the SIPP-only area. When translating SIPP packets to IPv4, translating routers use the low-order 32-bits of the source and destination SIPP addresses to generate the addresses for the IPv4 packet. When translating IPv4 packets to SIPP, translating routers pre-pend the prefix 0:0:0:0:0:0 to the IPv4 source address to generate the source address for the SIPP packet. They prepend either the prefix 0:0:0:0:0:1 or 0:0:0:0:0:0 to generate the destination address. They use the 0:0:0:0:0:1 prefix if the destination is located within, and the prefix 0:0:0:0:0:0 if the destination is located outside, the SIPP-only area that the translating router serves. draft-ietf-sipp-sst-overview-00.txt [Page 22] INTERNET-DRAFT SST Overview July 1994 8. Upgrade Dependencies Perhaps the most important issue for those who must carry out the transition from IPv4 to SIPP is that of upgrade dependencies: Which transition steps must be performed before other steps can be taken? SST is designed so that the prerequisites to installation of SIPP/IPv4 nodes are minimal, while the steps that must be taken before SIPP-only nodes may be deployed are more involved. Essentially the only operation that must be performed before deploying SIPP/IPv4 nodes is that the DNS servers must be upgraded to support the SIPP ASEQ record type. The upgrade dependencies are summarized in the table below: | Transition Step | Depends On | +-------------------------------+------------------------------+ | DNS upgrade to support | None | | ASEQ records (1) | | +-------------------------------+------------------------------+ | Upgrade IPv4 host or router | DNS upgrade to support | | to SIPP/IPv4 | ASEQ records (2) | +-------------------------------+------------------------------+ | Deploy new SIPP/IPv4 host or | DNS upgrade to support | | router | ASEQ records (2) | +-------------------------------+------------------------------+ | Change SIPP/IPv4 area to | Install Translating router | | SIPP-only | at border | | | Upgrade all routers within | | | area to SIPP/IPv4 | | | Disable IPv4 routing inside | | | area. | +-------------------------------+------------------------------+ | Upgrade SIPP/IPv4 host or | Change area from SIPP/IPv4 | | router to SIPP-only | to SIPP-only | +-------------------------------+------------------------------+ | Deploy new SIPP-only | Change area from SIPP/IPv4 | | host or router | to SIPP-only | +-------------------------------+------------------------------+ Notes: (1) Strictly speaking, a DNS server being upgraded to support the SIPP ASEQ address record type does not itself need to be upgraded to SIPP. An IPv4-only DNS server may support ASEQ record types. (2) The DNS upgrade is only required if node being upgraded or installed is going to be listed in the DNS. "Unlisted" nodes do not have this dependency. draft-ietf-sipp-sst-overview-00.txt [Page 23] INTERNET-DRAFT SST Overview July 1994 9. Examples Two SIPP/IPv4 hosts may use SIPP-in-IPv4 tunneling to communicate via an IPv4 infrastructure: SIPP/IPv4 Host H1 (0:0:0:0:0:1:129.144.1.2) | --+--------------------------+-- (subnet A) | (0:0:0:0:0:0:129.144.1.3) IPv4-only Router R1 (0:0:0:0:0:0:129.144.2.3) | -------+-----------------+----- (subnet B) | (0:0:0:0:0:1:129.144.2.4) SIPP/IPv4 Host H2 When H1 sends a packet to H2, the packets that will be transmitted on subnets A and B are: Packet Dest Addr in Dest Addr in Datalink Subnet Type SIPP Header IPv4 Header Next hop ------ ----- ----------------------- ------------ -------- A Enc. 0:0:0:0:0:1:129.144.2.4 129.144.2.4 R1 B Enc. 0:0:0:0:0:1:129.144.2.4 129.144.2.4 H2 Note: Enc. = SIPP-in-IPv4 encapsulation If a SIPP/IPv4 router is added to this topology, H1 will have multiple routes to reach H2. It could use SIPP-in-IPv4 tunneling, sending the traffic via R1 or R2, or use the raw SIPP format routing via R2. Since SIPP/IPv4 hosts prefer routes via SIPP routers, H1 will use send the traffic via R2: draft-ietf-sipp-sst-overview-00.txt [Page 24] INTERNET-DRAFT SST Overview July 1994 SIPP/IPv4 Host H1 (0:0:0:0:0:1:129.144.1.2) | --+-----+-------------------------------+-- (subnet A) | | (0:0:0:0:0:1:129.144.1.4) (0:0:0:0:0:0:129.144.1.3) SIPP/IPv4 Router R2 IPv4-only Router R1 (0:0:0:0:0:1:129.144.2.6) (0:0:0:0:0:0:129.144.2.3) | | ----+--+----------------------------+----- (subnet B) | (0:0:0:0:0:1:129.144.2.4) SIPP/IPv4 Host H2 Now when H1 sends a packet to H2, the packets that will be transmitted on subnets A and B are: Packet Dest Addr in Datalink Subnet Type SIPP Header Next hop ------ ----- ----------------------- -------- A SIPP 0:0:0:0:0:1:129.144.2.4 R2 B SIPP 0:0:0:0:0:1:129.144.2.4 H2 draft-ietf-sipp-sst-overview-00.txt [Page 25] INTERNET-DRAFT SST Overview July 1994 10. Author's Address Robert E. Gilligan Sun Microsystems, Inc. 2550 Garcia Ave. Mailstop UMTV 05-44 Mountain View, California 94043 415-336-1012 (voice) 415-336-6015 (fax) Bob.Gilligan@Eng.Sun.COM 11. References [IPAE] R. E. Gilligan. IPAE: The SIPP Interoperability and Transition Mechanism. March 1994. Internet Draft. [SIPP] S. Deering. Simple Internet Protocol Plus (SIPP) Specification. February 1994. Internet Draft. [SIPP-ROAD] S. Deering, P. Francis, R. Govindan. Simple Internet Protocol Plus (SIPP): Routing and Addressing. February 1994. Internet Draft. [SST-HR] SIPP Transition Mechanisms for Hosts and Routers. Internet Draft to be written. [SST-TR] SIPP Transition Mechanisms for Header Translating routers. Internet Draft to be written. [SST-TP] SIPP Transition Plan. Internet Draft to be written. draft-ietf-sipp-sst-overview-00.txt [Page 26] From deering@parc.xerox.com Mon Jul 18 19:44:02 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com ([13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id WAA03498 for ; Mon, 18 Jul 1994 22:45:45 -0400 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14598(10)>; Mon, 18 Jul 1994 19:44:20 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 18 Jul 1994 19:44:08 -0700 To: ipng@cmf.nrl.navy.mil Subject: new SIPP addressing spec Date: Mon, 18 Jul 1994 19:44:02 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jul18.194408pdt.12171@skylark.parc.xerox.com> Here's the latest SIPP addressing spec, which is also on its way to the Internet Drafts directories. Note that this is an addressing architecture document only, not routing architecture -- after we deleted the stuff about extended addressing, we were pretty much left with conventional hierarchical routing (i.e., what we do now), plus uses of source routing other than extended addressing (e.g., provider-selection, mobility). However, given the up-in-the-airness of SIPP-128 source routing and the security concerns with source routing, we decided not to say anything concrete at this point. This'll leave the new working group something to do. :-) Steve ----------- P. Francis (NTT) S. Deering (Xerox PARC) R. Hinden (Sun) R. Govindan (Bellcore) July 1994 Simple Internet Protocol Plus (SIPP): Addressing Architecture Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of 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." This Internet Draft expires February 1, 1995. Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Changes from Version 01 This version reflects the change to SIPP to support 128 bit address (from 64 bit addresses) and the change made to the SIPP transition mechanisms to remove the C-bit [STT]. The following specific changes were made: o Extended Addresses were removed. o The rules for reversing source routes were moved to the main SIPP specification. o Format prefixes were defined to allocate the SIPP address space to specific usage. o The description of bindings of addresses to specific interfaces was removed. draft-ietf-sipp-routing-addr-02.txt [Page 1] INTERNET-DRAFT SIPP Addressing Architecture July 1994 1.0 INTRODUCTION This specification defines the addressing and routing architecture of Simple Internet Protocol Plus [SIPP]. It includes a detailed description of the address formats for SIPP. The authors would like to acknowledge the contributions of Jim Bound (Digital), Brian Carpenter (CERN), Bob Gilligan (Sun), Christian Huitema (INRIA), Erik Nordmark (Sun), and Sue Thomson (Bellcore). 2.0 SIPP ADDRESSING SIPP addresses are 128-bit identifiers for nodes and sets of nodes. There are two types of addresses: Unicast: Used to send a packet to a single node. Multicast: Used to send a packet to all members of a group of nodes. There are no broadcast addresses in SIPP, their function being superseded by multicast addresses. SIPP continues the IP version 4 model that a subnet is associated with one link. SIPP also allow multiple subnets to be assigned to the same link. 2.1 Text Representation of Addresses There are three conventional forms for representing SIPP addresses as text strings: 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the hexadecimal values of the eight 16-bit pieces of the address. Examples: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 1080:0:0:8:800:200C:417A Note that it is not necessary to write the leading zeros in an individual field, but there must be at least one numeral in every field (except for the case described in 2.). 2. Due to the method of allocating certain styles of SIPP addresses, it will be common for there to be a number of zero bits in the middle of the address. In order to make writing this form easier, draft-ietf-sipp-routing-addr-02.txt [Page 2] INTERNET-DRAFT SIPP Addressing Architecture July 1994 a special syntax is available to compress the zeros. The use of of two "::" indicate multiple groups of 16-bits of zeros. For example the multicast address: FF01:0:0:0:0:0:0:43 would be represented as: FF01::43 The "::" can only appear once in an address. The "::" can also be used to compress the leading zeros in an address. 3. An alternative form that is sometimes more convenient when dealing with a mixed environment of IP and SIPP nodes is x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of the six high-order 16-bit pieces of the address, and the 'd's are the decimal values of the four low-order 8-bit pieces of the address (standard IP representation). Examples: 0:0:0:0:0:0:0:13.1.68.3 0:0:0:0:0:0:1:129.144.52.38 or in compressed form: ::13.1.68.3 ::1:129.144.52.38 2.2 Address Type Representation The specific type of SIPP address is indicated by the leading bits in the address. The variable-length field comprising these leading bits is called the Format Prefix (FP). The initial allocation of these prefixes is as follows: draft-ietf-sipp-routing-addr-02.txt [Page 3] INTERNET-DRAFT SIPP Addressing Architecture July 1994 Allocation Prefix Fraction of (binary) Address Space ------------------------------- -------- ------------- Reserved ** 00 1/4 Provider-Based Unicast Address 01 1/4 Reserved for Geographic Addresses 10 1/4 Reserved 110 1/8 NSAP Allocation 1110 00 1/64 Reserved 1110 01 1/64 Reserved 1110 10 1/64 IPX Allocation 1110 11 1/64 Reserved 1111 0 1/32 Reserved 1111 10 1/64 Reserved 1111 110 1/128 Local Use Addresses 1111 1110 1/256 Multicast Addresses 1111 1111 1/256 This initial allocation supports direct allocation of provider addresses, NSAP addresses, IPX addresses, local use addresses, and multicast addresses. Space is reserved for geographic addresses. The remainder of the address space is reserved for future use. This this can be for expansion of existing use (e.g. additional provider addresses, IPX addresses, etc.) or new uses (e.g. separate locators and EID). 2.3 Unicast Addresses Unicast addresses are distinguished from multicast addresses by the value of the high-order octet of the addresses: a value of FF (11111111) identifies an address as a multicast address; any other value identifies an address as a unicast address. The SIPP unicast address is contiguous bit-wise maskable, similar to IP addresses under Class-less Interdomain Routing [CIDR]. There are several forms of unicast address assignment in SIPP, including the global provider hierarchical unicast address, the geographical hierarchical address, the NSAP hierarchical address, the IPX _________________________ ** SIPP unicast addresses for IPv4 only nodes are assigned out of the 00 format prefix space. See section 2.3.8. draft-ietf-sipp-routing-addr-02.txt [Page 4] INTERNET-DRAFT SIPP Addressing Architecture July 1994 hierarchical address, the cluster address, the local-use address, and the IP-only host address. Other addresses types can be defined in the future. Different SIPP nodes have greater or lesser knowledge of the internal structure of the SIPP address, depending on the role the node plays (for instance, host versus router). At a minimum, a node may consider that unicast addresses (including its own) have no internal structure: | 128 bits | +-----------------------------------------------------------------+ | node address | +-----------------------------------------------------------------+ A slightly sophisticated host (but still rather simple) may additionally be aware of subnet prefix(es) for the link(s) it is attached to, where different addresses may have different values for n: | n bits | 128-n bits | +---------------------------------------------------+-------------+ | subnet prefix | node ID | +---------------------------------------------------+-------------+ Still more sophisticated hosts may be aware of other hierarchical boundaries in the unicast address, primarily in the form of cluster addresses. These include but are not limited to subscriber cluster addresses and provider cluster addresses, and are discussed later. Though a very simple router may have no knowledge of the internal structure of SIPP unicast addresses, routers will more generally have knowledge of one or more of the hierarchical boundaries for the operation of routing protocols. The known boundaries will differ from router to router, depending on what positions the router holds in the hierarchy. 2.3.1 Unicast Address Examples One example Unicast address which will likely be common on LANs and other environments where IEEE 802 MAC addresses are available. It format is: draft-ietf-sipp-routing-addr-02.txt [Page 5] INTERNET-DRAFT SIPP Addressing Architecture July 1994 | n bits | m bits | 48 bits | +--------------------------------+-----------+--------------------+ | subscriber prefix | subnet ID | node ID | +--------------------------------+-----------+--------------------+ Where the 48-bit Node ID is an IEEE-802 MAC address. The inclusion of a unique global node identifier, such as an IEEE MAC address makes possible a very simple form of auto-configuration of addresses. In particular, a node may discover a subnet ID by listening to Router Advertisement messages on its attached link(s), and then fabricating a SIPP address for itself by using its IEEE MAC address as the node ID on that subnet. The details of host auto-configuration are described elsewhere [AUTO]. Another example is for use on serial PPP links. Its format is: | n bits | 126-n bits |bits| +--------------------------------+---------------------------+----+ | subscriber prefix | subnet ID |Node| | | | ID | +--------------------------------+---------------------------+----+ where the Node ID is two bits long and is used to identify each end of the link. The third example is where a site or organization requires additional layers of local hierarchy. Its format is: | s bits | n bits | m bits | 128-s-n-m bits | +----------------------+---------+--------------+-----------------+ | subscriber prefix | area ID | subnet ID | node ID | +----------------------+---------+--------------+-----------------+ 2.3.2 Provider-Based Global Hierarchical Unicast Addresses The global provider-based unicast address is initially assigned as follows [ADDR]: | 2 | n bits | m bits | p bits | 128-n-m-p | +----+---------------+-----------------+-----------+-----------+ | 01 | provider ID | subscriber ID | subnet ID | node ID | +----+---------------+-----------------+-----------+-----------+ The high-order part of the address is assigned to providers, which then assign portions of the address space to subscribers, etc. draft-ietf-sipp-routing-addr-02.txt [Page 6] INTERNET-DRAFT SIPP Addressing Architecture July 1994 The term "provider prefix" refers to the high-order part of the address up to and including the provider ID. This is similar to assignment of IP addresses under the CIDR scheme [CIDR]. The subscriber ID distinguishes among multiple subscribers attached to the provider identified by the provider ID. The term "subscriber prefix" refers to the high-order part of the address up to and including the subscriber ID. The subnet ID identifies a specific physical link. There can be multiple subnets on the same physical link. A specific subnet cannot span multiple physical links. The term "subnet prefix" refers to the high-order part of the address up to and including the subnet ID. The group of nodes identified by the subnet ID must be attached to the same link. The node ID identifies a single node among the group of nodes identified by the subnet prefix. 2.3.3 NSAP Addresses This mapping of NSAP address into SIPP addresses was suggested by Brian Carpenter. | 6 |2| 8 | 16 | 24 bits | 16 bits| 48 bits | 8 | +------+-+-----+-------+------------+--------+-------------+------+ |110000| | AFI | IDI | Prefix | Area | ID | NSEL | +------+-+-----+-------+------------+--------+-------------+------+ The AFI will normally be 39 (DCC, digital country code) or 47 (ICD, international code designator). 2.3.4 Local-use SIPP Unicast Address Local-use addresses are unicast addresses which are only used within a specific subscriber site. Local-use address have the following format: | 8 | | bits | n bits | m bits | p bits | +--------+---------+---------------+------------------------------+ |11111110| 0 | subnet ID | node ID | +--------+---------+---------------+------------------------------+ Local-use addresses may be used for sites or organizations that are not (yet) connected to the global Internet. They do not need to request or draft-ietf-sipp-routing-addr-02.txt [Page 7] INTERNET-DRAFT SIPP Addressing Architecture July 1994 "steal" an address prefix from the global Internet address space. A SIPP local-use addresses can be used instead. When the organization connects to the global Internet, it can then form global addresses. 2.3.5 Cluster Addresses Cluster addresses are unicast addresses that may be used to reach the "nearest" one (according to unicast routings notion of nearest) of the set of boundary routers of a cluster of nodes identified by a common prefix in the SIPP unicast routing hierarchy. A boundary router of cluster C has at least one address with prefix C and at least one link to a node with a prefix other than C. Cluster addresses have the general form: | n bits | 128-n bits | +---------------------------------+-------------------------------+ | cluster prefix |0000000000000000000000000000000| +---------------------------------+-------------------------------+ For example, to reach the nearest boundary router for the routing domain identified by provider ID D, a packet may be sent to the following cluster address: | 2 | m bits | 128-m bits | +----+--------------+---------------------------------------------+ | 01 | provider = D |000000000000000000000000000000000000000000000| +----+--------------+---------------------------------------------+ 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| +----+--------------+----------------+----------------------------+ To reach the nearest boundary router for subnet T of subscriber S, of provider D, a packet may be sent to the following cluster address: | 2 | m bits | n bits | s bits | 128-m-n-s bits | +----+--------------+----------------+-----------+----------------+ | 01 | provider = D | subscriber = S |subnet = T |0000000000000000| +----+--------------+----------------+-----------+----------------+ draft-ietf-sipp-routing-addr-02.txt [Page 8] INTERNET-DRAFT SIPP Addressing Architecture July 1994 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. Cluster addresses are most commonly used as intermediate addresses in a SIPP Routing Header, to cause a packet to be routed to one or more specific clusters on the way to its final destination. The value zero is reserved at each level of the unicast address hierarchy for use in formulating cluster addresses. Cluster addresses may not be used as source addresses in SIPP packets. 2.3.6 The Loopback Address The unicast address FE00:0:0:0:0:0:0:1 is called the loopback address. It may be used by a node to send a SIPP packet to itself. It may never be assigned to any interface. The loopback address may not be used as the source address in SIPP packets that are sent outside of a single node. 2.3.7 The Unspecified Address The address 0:0:0:0:0:0:0:0 is called the unspecified address. It shall never be assigned to any node. It may be used anywhere an address appears, to indicate the absence of an address. One example of its use is in the Source Address field of any SIPP packets sent by an initializing host before it has learned its own address. The unspecified address may not be used as the destination address of SIPP packets or in SIPP Routing Headers. 2.3.8 SIPP Addresses for IP-Only Nodes SIPP unicast addresses are assigned to nodes that only support IPv4 as part of the Simple SIPP Transition [SST] scheme for transition from IPv4 to SIPP. The node's 32-bit IPv4 address is carried in the low-order 32 bits of the SIPP address. SIPP addresses with embedded IPv4 addresses are also assigned to SIPP nodes that wish to interoperate with IPv4 nodes. Such addresses are termed "IPv4 compatible" SIPP addresses. The high order bits of an IPv4 compatible SIPP address identify whether the node supports SIPP, or only IPv4. IPv4-compatible SIPP addresses assigned to nodes that only support IPv4 draft-ietf-sipp-routing-addr-02.txt [Page 9] INTERNET-DRAFT SIPP Addressing Architecture July 1994 have the following form: | 96 bits | 32 bits | +-------------------------------------------+---------------------+ |0000...................................0000| IP address | +-------------------------------------------+---------------------+ IPv4-compatible SIPP addresses assigned to nodes that support SIPP have the following form: | 96 bits | 32 bits | +-------------------------------------------+---------------------+ |0000...................................0001| IP address | +-------------------------------------------+---------------------+ 2.4 Multicast Addresses A SIPP multicast address is an identifier for a group of nodes. A node may belong to any number of multicast groups. Multicast addresses have the following format: | 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+ 11111111 at the start of the address identifies the address as being a multicast address. +-+-+-+-+ flgs is a set of 4 flags: |0|0|0|T| +-+-+-+-+ The high-order 3 flags are reserved, and must be initialized to 0. T = 0 indicates a permanently-assigned ("well-known") multicast address, assigned by the global internet numbering authority. T = 1 indicates a non-permanently-assigned ("transient") multicast address. draft-ietf-sipp-routing-addr-02.txt [Page 10] INTERNET-DRAFT SIPP Addressing Architecture July 1994 scop is a 4-bit multicast scope value: 0 reserved 1 intra-node scope 2 intra-link scope 3 (unassigned) 4 (unassigned) 5 intra-site scope 6 (unassigned) 7 (unassigned) 8 intra-organization scope 9 (unassigned) A (unassigned) B intra-community scope C (unassigned) D (unassigned) E global scope F reserved group ID identifies the multicast group, either permanent or transient, within the given scope. The "meaning" of a permanently-assigned multicast address is independent of the scope value. For example, if the "NTP servers group" is assigned a permanent multicast address with a group ID of 43 (hex), then: FF01:0:0:0:0:0:0:43 means all NTP servers on the same node as the sender. FF02:0:0:0:0:0:0:43 means all NTP servers on the same link as the sender. FF05:0:0:0:0:0:0:43 means all NTP servers at the same site as the sender. FF0E:0:0:0:0:0:0:43 means all NTP servers in the internet. Non-permanently-assigned multicast addresses are meaningful only within a given scope. For example, a group identified by the non-permanent, intra-site multicast address 7F15:0:0:0:0:0:0:43 at one site bears no relationship to a group using the same address at a different site, nor to a non-permanent group using the same group ID with different scope, nor to a permanent group with the same group ID. Multicast addresses must not be used as source addresses in SIPP packets or appear in any routing header. draft-ietf-sipp-routing-addr-02.txt [Page 11] INTERNET-DRAFT SIPP Addressing Architecture July 1994 2.4.1 Pre-Defined Multicast Addresses The following well-known multicast addresses are pre-defined: Reserved Multicast Addresses: FF0s:0:0:0:0:0:0:0 These multicast addresses (with any scope value, s) are reserved, and shall never be assigned to any multicast group. All Nodes Addresses: FF01:0:0:0:0:0:0:1 FF02:0:0:0:0:0:0:1 These multicast addresses identify the group of all SIPP nodes, within scope 1 (intra-node) or 2 (intra-link). All Hosts Addresses: FF01:0:0:0:0:0:0:2 FF02:0:0:0:0:0:0:2 These multicast addresses identify the group of all SIPP hosts, within scope 1 (intra-node) or 2 (intra-link). All Routers Addresses: FF01:0:0:0:0:0:0:3 FF02:0:0:0:0:0:0:3 These multicast addresses identify the group of all SIPP routers, within scope 1 (intra-node) or 2 (intra-link). 2.5 A Node's Required Addresses A host is required to recognize the following addresses as identifying itself: its own unicast addresses, the loopback address, the All Nodes and All Hosts multicast addresses, and the multicast addresses of any other groups to which the host belongs. A router is required to recognize the following addresses as identifying itself: its own unicast addresses, the cluster addresses of all clusters for which the router is a boundary router, the loopback address, the All Nodes and All Routers multicast addresses, and any other multicast addresses to which the router belongs. 3.0 ROUTING ALGORITHMS SIPP routing algorithms are identical to those used with the CIDR version of IP, except that the address used is 128 bits rather than 32 (for instance, [OSPF]). draft-ietf-sipp-routing-addr-02.txt [Page 12] INTERNET-DRAFT SIPP Addressing Architecture July 1994 REFERENCES [CIDR] V. Fuller, T. Li, K. Varadhan, J. Yu, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338. [MULT] S. Deering, "Host Extensions for IP multicasting", RFC 1112. [SST] R. Gilligan et al, "Simple SIPP Transition Overview", Internet Draft. [SIPP] S. Deering, "Simple Internet Protocol Plus (SIPP) Specification", Internet Draft. [ADDR] P. Francis, "SIPP Address Assignment", Internet Draft in preparation. [ICMP] R. Govindan and S. Deering, "ICMP and IGMP for the Simple Internet Protocol Plus", Internet-Draft in preparation. [AUTO] S. Thomson, "Automatic Host Address Assignment in SIPP", Internet Draft in preparation. [OSPF] P. Francis, "OSPF for SIPP", Internet Draft. AUTHOR'S ADDRESSES Paul Francis, francis@cactus.ntt.jp Steve Deering, deering@parc.xerox.com Robert Hinden, hinden@eng.sun.com Ramesh Govindan, rxg@thumper.bellcore.com draft-ietf-sipp-routing-addr-02.txt [Page 13] From smb@research.att.com Tue Jul 19 15:40:34 1994 Return-Path: smb@research.att.com Received: from research.att.com ([192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA09405 for ; Tue, 19 Jul 1994 16:16:21 -0400 From: smb@research.att.com Message-Id: <199407192016.QAA09405@picard.cmf.nrl.navy.mil> Received: by bigbird.zoo.att.com; Tue Jul 19 15:40:36 EDT 1994 To: ipng@cmf.nrl.navy.mil Subject: IPng and ``Dune'' Date: Tue, 19 Jul 94 15:40:34 EDT Given the usual demographics of this business, I suspect that many other members of the directorate have read ``Dune''. The parallel to the religion appendix has been haunting me, enough that I excavated my copy. Occasional rumors leaked out the C.E.T. [Commission of Ecumenical Translators] sessions.... Such rumors inevitably provoked anti- ecumenism riots... [The Commissioners said] ``We are producing an instrument of Love to be played in all ways.'' Many consider it odd that this state provoked the worst outbreaks of violence.... For almost seven years, then, C.E.T labored. And as their seventh anniversary approached, they prepared the human universe for a momentous announcemnt. On that seventh anniversary, they unveiled the Orange Catholic Bible. ``Here is a work with dignity and meaning,'' they said. ... There was an odd sense of calm as the presses and shiawire imprinters rolled and the O.C. Bible spread out through the worlds.... But even the C.E.T. delegates betrayed the fiction of that calm as they returned to their respective congregations. Eighteen of them were lynched within two months. Fifty-three recanted within the year. The O.C. Bible was denounced as a work produced by ``the hubris of the reason''.... it soon became apparent that the ancient superstitions and beliefs had *not* been absorbed by the new ecumenism.... C.E.T. Chairman Toure Bomoko, a Ulema of the Zensunnis and one of the fourteen delegates who never recanted (``The Fourteen Sages'' of popular history), appeared to admit finally that C.E.T. had erred. ``We shouldn't have tried to create new symbols,'' he said. See y'all in Toronto! From jallard@microsoft.com Wed Jul 20 09:41:32 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com ([131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA15199; Wed, 20 Jul 1994 12:54:26 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA18838; Wed, 20 Jul 94 09:54:18 -0700 Message-Id: <9407201654.AA18838@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Wed, 20 Jul 94 09:54:18 PDT X-Msmail-Message-Id: 8A10A973 X-Msmail-Conversation-Id: 8A10A973 From: "James 'J' Allard" To: ericf@atc.boeing.com, ipng-request@cmf.nrl.navy.mil Date: Wed, 20 Jul 94 09:41:32 TZ Subject: Re: John's stake Cc: ipng@cmf.nrl.navy.mil | Sure... Let's drive that stake right beside the one that says that | fixed length is definitely a conclusion, and while an escape hatch is | a possibility, reverting to consideration of fully-variable address | formats is also "not an option". i personally don't think that we should attempt to squelch thinking and researching of v.l. i do agree that we should keep it out of ipng wg discussions in the name of progress closing this door is a mistake. if i published a draft tomorrow detailing how v.l. was faster, easier to administer and offered the possibility of extending the lifetime of ipng, i would hate to see such a document "banned" from the ipng process. on the other hand, an internet draft detailing how we could address all of the electrons in the universe with 8 bytes does not interest our efforts.i believe consensus was reached in this area, whether i agree or not and that it's time to move on. the reason v.l. has not been accepted has to do with fud - fear, uncertainty and doubt. no one really knows what will happen. while some people think it's not ecessary, although i've yet to come across someone that believes that it would be less functional than fixed-16. fixed-8 clearly falls into the "less functional than fixed-16" category and therefore can safely be dismissed. v.l. does not belong to this set, but i agree cannot be accepted by the community until proof is offered. it should not distract from our mission to button up ipng by year end. is this a fair compromise? _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From jnc@ginger.lcs.mit.edu Wed Jul 20 01:27:23 1994 Return-Path: jnc@ginger.lcs.mit.edu Received: from ginger.lcs.mit.edu ([18.26.0.82]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id BAA11750 for ; Wed, 20 Jul 1994 01:27:53 -0400 Received: by ginger.lcs.mit.edu id AA16163; Wed, 20 Jul 94 01:27:23 -0400 Date: Wed, 20 Jul 94 01:27:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407200527.AA16163@ginger.lcs.mit.edu> To: ipng@cmf.nrl.navy.mil Subject: FYI For those you what aren't on the WG mailing list... Noel ------------ Date: Tue, 19 Jul 94 16:38:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) To: nimrod-wg@bbn.com Subject: Updated Nimrod IPNG Rqmts doc Cc: jnc@ginger.lcs.mit.edu, mankin@hsdndev.harvard.edu, sob@harvard.edu I have finally succeeded in finding the time to update the Nimrod IPng requirements document. There are two main areas of change: i) the flow-identification bullet has been updated to include the potential requirement for aggregating flows, and the implications thereof, and ii) and the endpoint identification bullet has been updated to include the results of some of the recent discussion on Big-I. I have put it into I-D form (roughly), and am going to submit it "soon". So, if you want to comment *before* that happens, do so "soon". Also, it's still mostly in first-person, since i) I don't have the energy to change that, and ii) I didn't want to represent this as being an agreed upon WG view. Some people have reviewed earlier versions (for which I thank them, particularly the people at BBN who did a great job on early ones), but these later versions haven't been much reviewed. So. Anyway, there is is. It's in ipng_req.txt on research.ftp.com, in the Nimrod repository (pub/nimrod). Noel From jcurran@nic.near.net Wed Jul 20 12:23:08 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA14964 for ; Wed, 20 Jul 1994 12:24:29 -0400 Received: from platinum.near.net by nic.near.net id aa24316; 20 Jul 94 12:24 EDT To: Eric Fleischman cc: ipng@cmf.nrl.navy.mil Subject: Re: Worry In-reply-to: Your message of Wed, 20 Jul 1994 09:11:06 -0700. <9407201611.AA24978@atc.boeing.com> Date: Wed, 20 Jul 1994 12:23:08 -0400 From: John Curran Message-ID: <9407201224.aa24316@nic.near.net> -------- ] From: Eric Fleischman ] Subject: Worry ] Date: Wed, 20 Jul 94 09:11:06 -0700 ] ... ] In any case, I urge the Area Cochairs to be quite explicit that 128 bit ] addresses are an IPng requirement -- not an option -- and that fixed length ] 64 bit addresses will not be the basis for the IPng WG. If such a stake ] is not firmly put in the ground "up front", then I fear we will continue ] to be troubled by disharmony and sniping. It is time for compromise ] and peace and cooperation. Without such a "stake in the ground", these ] positive attributes may prove illusive. Sure... Let's drive that stake right beside the one that says that fixed length is definitely a conclusion, and while an escape hatch is a possibility, reverting to consideration of fully-variable address formats is also "not an option". /John From scoya@CNRI.Reston.VA.US Wed Jul 20 12:25:11 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id DAA19789 for ; Thu, 21 Jul 1994 03:01:07 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08602; 20 Jul 94 12:25 EDT To: ipng@cmf.nrl.navy.mil Subject: Internet on the cover of Time Date: Wed, 20 Jul 94 12:25:11 -0400 From: Steve Coya Message-ID: <9407201225.aa08602@IETF.CNRI.Reston.VA.US> For those who haven't seen it, the cover story of Time Magazine is: The Strange New World of the Internet Battles on the frontiers of cyberspace There was an FAQ section, one question on connecting to the Internet. I saw in the answer and thought I'd share it (typed in without anyone's permission): For you to be directly plugged into the Internet and use all its services, your computer must have what is inelegantly called a TCP/IP connection. To set that up, you would probably need the help of a professional - or better still, a teenager with a high-speed modem. Does SIPP-16 refer to 16 year olds? Did we include teenagers as part of the IPng solution? :-) Steve (Yes, he IS cracking under the pressure of the Toronto IETF meeting) From jcurran@nic.near.net Wed Jul 20 13:11:30 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA15366 for ; Wed, 20 Jul 1994 13:12:47 -0400 Received: from platinum.near.net by nic.near.net id aa29696; 20 Jul 94 13:12 EDT To: "James 'J' Allard" cc: ericf@atc.boeing.com, ipng@cmf.nrl.navy.mil Subject: Re: John's stake In-reply-to: Your message of Wed, 20 Jul 1994 09:41:32 +0700. <9407201654.AA18838@netmail2.microsoft.com> Date: Wed, 20 Jul 1994 13:11:30 -0400 From: John Curran Message-ID: <9407201312.aa29696@nic.near.net> -------- ] From: James 'J' Allard ] Subject: Re: John's stake ] Date: Wed, 20 Jul 94 09:41:32 TZ ] ] | Sure... Let's drive that stake right beside the one that says that ] | fixed length is definitely a conclusion, and while an escape hatch is ] | a possibility, reverting to consideration of fully-variable address ] | formats is also "not an option". ] ] i personally don't think that we should attempt to squelch thinking ] and researching of v.l. i do agree that we should keep it out of ] ipng wg discussions in the name of progress ] ] closing this door is a mistake. if i published a draft tomorrow ] detailing how v.l. was faster, easier to administer and offered ] the possibility of extending the lifetime of ipng, i would hate to ] see such a document "banned" from the ipng process. ] ] on the other hand, an internet draft detailing how we could ] address all of the electrons in the universe with 8 bytes ] does not interest our efforts.i believe consensus was reached ] in this area, whether i agree or not and that it's time to move ] on. Jay, Personally, I think we're mistaken in not adopting v.l., but I recognize the IETF political factors that make fixed length a requirement. ] the reason v.l. has not been accepted has to do with ] fud - fear, uncertainty and doubt. no one really knows ] what will happen. while some people think it's not ] ecessary, although i've yet to come across someone that ] believes that it would be less functional than fixed-16. Some folks would claim that fixed-8 and -16 are functionally similiar, and that it is fear, uncertainty, and doubt drives fixed-16. They'd be right (at least in my case), since I'm terrified of the possibility of having to go through an Internet-wide transition _twice_, particularly if we fail to fix some serious faults (such as network addresses in p-header checksum) the first time around. ] v.l. does not belong to this set, but i agree cannot be ] accepted by the community until proof is offered. ] it should not distract from our mission to button up ] ipng by year end. ] ] is this a fair compromise? It's a fair compromise... I'm basically seeking parity in the the handling of our findings lest our findings unravel before our eyes. /John From brian@dxcoms.cern.ch Thu Jul 21 08:44:13 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id CAA19753 for ; Thu, 21 Jul 1994 02:44:46 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA27930; Thu, 21 Jul 1994 08:44:14 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA08210; Thu, 21 Jul 1994 08:44:13 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9407210644.AA08210@dxcoms.cern.ch> Subject: Resistance to change To: ipng@cmf.nrl.navy.mil Date: Thu, 21 Jul 1994 08:44:13 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 534 Reading a recent posting on big-i in response to one of mine, I was strongly reminded of this which I got from a management course a few years ago: "Twelve good ways to resist change 1. We tried it in 1982 2. That is ridiculous 3. That is too radical 4. Let's set up a committee 5. That is against our policy 6. We have never done that before 7. It won't work 8. That's too obvious to be serious 9. That's superficial 10. We don't have time/manpower/money 11. Where's the profit? 12. That's not what we expect from you!" Brian From sob@hsdndev.harvard.edu Thu Jul 21 20:35:37 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA27779 for ; Thu, 21 Jul 1994 20:35:43 -0400 Date: Thu, 21 Jul 94 20:35:37 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407220035.AA10588@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: Novell registry info I think it would be a good idea to put a pointer to the Novell registry in as an adendem to any address/addressing document that mentions IPX mapping since we want to mention that this is only good for globally unique IPX addresses & this is the way to get them. (This comes from a suggestion from Jay Israel of Novell, but we should have thought of it since we talked about the registry when we talked about mapping IPX addresses) Scott >From Jay_Israel@Novell.COM Thu Jul 21 19:53:44 1994 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA06032; Thu, 21 Jul 1994 19:56:43 -0400 Received: from by ns.Novell.COM (4.1/SMI-4.1) id AB05375; Thu, 21 Jul 94 17:53:18 MDT X-Nvlenv-01Date-Transferred: 21-Jul-1994 14:14:38 -0400; at sjf-domain-hub.Novell X-Nvlenv-01Date-Posted: 21-Jul-1994 15:06:56 -0400; at sjf-mail-corp.novell To: sob%harvard.edu@sjf-dhub.sjf.novell.com Message-Id: <80C62E2E015C0100@-SMF-> Subject: Novell Network Registry From: Jay_Israel@Novell.COM (Israel, Jay) Date: 21 Jul 94 15:03:19 EDT References: <80C62E2E025C0100@-SMF-> Status: R Here is the contact information for the Novell Network Registry: ********************************************************************* ********************************************************************* ********************************************************************* Novell Network Registry phone: (408) 577-7506 Novell, Inc., M/S F5-82-2 fax: (408) 577-5447 2275 Trade Zone Blvd. Internet e-mail: registry@novell.com San Jose, CA 95131 MHS NHUB e-mail: registry@novell U.S.A. CompuServe email: registry@novell ********************************************************************* ********************************************************************* ********************************************************************* Jay. aka: Jay E. Israel phone: (408) 577-8478 Novell, Inc., M/S F6-91-2 email: jay 2275 Trade Zone Blvd. internet: jay@novell.com San Jose, CA 95131 fax: (408) 577-5520 From scoya@CNRI.Reston.VA.US Fri Jul 22 10:28:15 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA02038 for ; Fri, 22 Jul 1994 14:05:37 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08398; 22 Jul 94 10:28 EDT To: ipng@cmf.nrl.navy.mil Subject: DRAFT minutes from July 11 Telechat Date: Fri, 22 Jul 94 10:28:15 -0400 From: Steve Coya Message-ID: <9407221028.aa08398@IETF.CNRI.Reston.VA.US> DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference July 11, 1994 Reported by: Steve Coya This report contains IPNG Directorate meeting notes. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. ATTENDEES --------- Scott Bradner / Harvard Allison Mankin / NRL Steve Bellovin / AT&T Ross Callon / Wellfleet Brian Carpenter / CERN Dave Clark / MIT Jon Crowcroft / UCL Steve Deering / Xerox PARC Dino Farinacci / Cisco Eric Fleischman / Boeing Frank Kastenholz / FTP Mark Knopper / Ameritech Greg Minshall / Novell Lixia Zhang / Xerox PARC Regrets ------- J Allard / Microsoft Jim Bound / DEC John Curran / NEARnet Paul Francis / NTT Craig Partridge / BBN Rob Ullmann / Lotus 1. After a number of attempts, the teleconference scheduled for 11:30 commenced at 11:55. The next meeting, July 18, will focus on the IPNG presentation to be made by Allison and Scott at the Toronto IETF meeting on Monday morning. 2. It was asserted that no recommendation should be made while the format of the IP address was still being discussed, and that holding a BOF on the fixed vs variable address format would not be beneficial. Comments were solicited from the other directorate members. 3. Steve Deering and Dave Clark were asked to review this topic and recommend if a meeting is needed to focus on the shape of addresses. Allison and Scott will incorporate into the preview they plan to send to the IESG. Is an addressing "last call" to be done as a bof (with other wgs meeting) or in a plenary environment? Many thought it needed to be done earlier in the week, precluding using a plenary session. Mark offered up a TUBA slot as it would facilitate his efforts to prepare a TUBA agenda for Toronto. 4. The TACIT WG chairs are supposed to be working on a revision to the WG charter. There is also a need to start up an auto-configuration WG. 5. There were questions and discussions about the life of the IPNG area and the Directorate. Scott reported that he believes both should continue to live, at least until the appropriate documents appear on the standards track, and probably for another 6-12 months. 6. Allison reviewed comments received from Steve Crocker and Jeff Schiller. There is a need to identify specific efforts to be undetaken to establish an IPng Security Framework. 7. There was some discussion on the IPng Architect position. Most of the concerns voiced so far do not seem to be with the description or the proposed candidate, but with the use of the term Architect on the position title.