From owner-ipng Thu Sep 1 07:07:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03485; Thu, 1 Sep 94 07:07:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03479; Thu, 1 Sep 94 07:07:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23820; Thu, 1 Sep 94 07:04:25 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA07506; Thu, 1 Sep 94 07:04:01 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. To: ipng@sunroof.Eng.Sun.COM Date: Thu, 1 Sep 1994 15:01:09 +0200 (BST) In-Reply-To: <"940822 08:52:36"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> from "/G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au" at Aug 22, 94 11:40:31 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 13004 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >This is fine if one is building simple interconnectivity tools because one > can prove the working code in the "garage".. However, when one is building > global infrastructures that carriers will spend $BBB on over decades, that > insular process does not work... Specifically with global communications.. > one MUST HAVE Global addressing agreed by the regions and countries in > question.. The ITU are under treaty to do this with the UN.. Does it matter ... I think not. The IETF and its previous forms have built the internet. It works - it works rather well and its got an understanding of the real world. The tools tend to have options needed in the real world, and are mostly efficient and suited to the machinery. > one cannot build a global network without global addressing and to me global > addressing MUST relate to countries..and be agreed by those countries. 'Agreed by those countries' - Difficult except where you have some undesirable government bloat body making rules and being a (normally expensive) nuisance. Addresses by country are also unsuited to routing except in the simplistic monopoly telecomm world that thankfully seems to be dying out. In the UK for example demon is routed via sprint in the US not via a global uk carrier so routing with upper bits wouldn't want to be per country. Users know its in the UK because a) it says so and b) its got a *.uk address. > Obviously the IETF believe they can re map the entire planet with funny > numbers all by themselves, on their own and with "working code" all from > their backyard.. (As I assume "working code" means "tested code". Do you have > a replica of the earths communications infrastructure to test IPv6 on?.... HO > HO HO..) Well the world is mapped out in internet name space much more than in anything else barring phone numbers and paper mail addresses and has been said before (several times) address mapping is a mac layer issue for the provider - and not a hard one. Most of the internet code is working tested and proven. IPng is just swapping and tuning a few layers. Its got a sensible migration plan and you can run IPv4 and IPv6 over your current network. That's plenty of test space. > > Next.. the "working code" is across the whole planet and is failing because > of scale.. Scale is directly related to addressing...I might add your working > code is a nothing more than an ugly duck if one wants to design scalable > global networks.. Perhaps you should talk to people who have to build > national / govt networks with a "handful of "funny numbers".. Its a crappy > approach to building a network that will crash into a wall ... A good > business investment.. I dont think..!! > That is why governments are going GOSIP.. (because of the agreed and > recognised global naming and addressing carried by ISO/ITU "protocols").. IPng has a considerable number of addresses per human being, and if it runs out then I suspect the food will run out first and we can all die off anyway. Practicality (a word much missing in the OSI world) dictates fixed length addresses are much faster to process than variable length ones. Any idea what 1 clock cycle/per packet/per machine for 40 million machines costs in real terms..... All the governments I know are going away from OSI. Even previously committed government bodies in the UK now push 'open systems' not OSI. Everyone has realised that grand mandated standards can't compete with IP. > And like it or not the whole TCP/IP world has got to be reconfigured.. > "Working Code?" I see some people are now referring to the problem as > "bigger than the bubonic plague"... Working Code...!!! I just don't see the problem. Everyone said IP will run out of addresses. Options were evaluated standards usable in the real world drafted and transition methods sorted out. Including ones that will basically let IPv4 hosts sit around for ever almost. > Next.. The carriers .. You may be aware of these guys... These guys provide > international standards, they define and build international networks with > international addressing schemes which embrace NSAPs.. these systems will be > supported by X.500 directory systems, X.700 management systems and provide as > an application, global X.400 messaging systems .. All these technologies > have GLOBAL NAMES AND ADDRESSES... Ah yes those funny national bodies that are becoming extinct again. In most countries networks are built by people with money to make more money. That means they'll back working inter-operable products and couldn't care about much else including what people do with their cables. > that does this) more complex than necessary... Why? Are NSAPs that Bad... > After all they are defined in AN INTERNATIONAL STANDARD... After all the > Internet will still RELY ON THEM to support the "working code" they produce.. International standard and good/useful/clever are not always magically connected. > planet with communications.. Not just a set of interconnectivity tools for > workstations on LANs.. Perhaps the IETF would like to publish the number > related to all the lines of code that provide FTP, Telnet, SMTP, SNMP and > TCP/IP, etc.. And the carriers produce a list of the code quantities in PSTN, They are small this is good. > ISDN, FAX, X.400, X.500, X.700, X.25, Frame Relay, Transport and Session, > Mobiles, MPEG, PDH, SDH, etc standards.. and the code lines for Billing They are mostly large and bloated. Few X.400 mailers work properly, they need more computers more memory and more resources. It's not a us and them attitude either. MPEG is useful so the internet is full of mpeg. FAX is quite useful so TIFF file formats are found on the internet. X.400 isn't very useful & X.500 doesnt work properly so they aren't common on the internet. The DOS PC next to me runs TCP/IP for file sharing and POP-3 mail all in 85K (including the applications) now last time I looked I couldn't build an OSI/802.3/802.2LLC stack with FTAM for the files and X.400 mail facilities and expect to see the same performance, or under several megabytes of program. The chances of it working even if I could build it would be near nil due to the complexity and the chances of picking it up freeware off the net due to the size and difficulty involved in designing it are almost NIL. The chances of switching it to IPng when it comes out and getting it still close to the 85K with IPNG and high usability are very good. That for most people with budgets and real number bank balances is what matters Real questions and issues people will ask of IPng are: o Does it work o Is it cheap o Does the cost offset any additional administration costs o Is it open o Can I talk to other companies via it and maybe o Can I order pizza via the web over it > As this planet moves to intelligent networking (as defined by the carriers), Networking will always be defined by the users. Until recently nobody wanted ISDN. Nobody used ISDN it wasn't needed. Now people need 56Kbits they use ISDN - and not because its magical, wonderful, clever but because it does a job. Its probably also worth pointing out that the IP layers over all the ISDN systems are the same and interoperate. ISDN itself is a different mess. 56kbit or 64kbit , uLaw or aLaw voice encoding, EuroISDN or alternative signalling systems... > international mobiles, Audio/Video mobile devices that MUST have global > numbering and User Ids.. what significance will a "funny numbers" approach to > data networking have? (Yes .. data networking only!) Do you honestly believe > that the IETF will replace the carriers, suspend the deployment of global It isn't the IETF's job to replace the carriers. Carriers deal in getting bytes from A to B, service providers in shipping data over these streams and the IETF in making sure that a) it works b) its practical and cheap for everyone to use c) the standard is readable and doesn't contain a million TLA's. I anticipate clicking on Fred and talking to him, or clicking on my phone book typing 'Fred Smith' and talking to him. It doesn't matter what happens below that to a user. > infrastructures (with international addressing), stop the ITU /ISO > standardisation process, undo all the work on GOSIP, undo all the OSI > products that have been developed and erase the progress of OSI from this > planet with a 16 byte internetwoking protocol defined "by consensus".. As far as I can tell the OSI process has almost killed itself off. Marshall Rose worked rather hard at OSI and no longer seems to believe in it. Most governments no longer want to put their money on it. > Do you honestly believe that the IETF will develop standards for security, > billing, fault management (note that SNMP is hitting the wall as well), etc, > etc, etc .. and administer, with the same global capability, a network which > is DIFFERENT to that as implemented carriers!!! IPng like IP is a network layer, its not a carrier its a global all encompassing standard above and beyond carriers. > > AS the broadcasting and telecommunications industries combine across this > planet and deploy domestic and mobile multimedia services there will be > little room for "defacto" standards that only relate to data.. One cannot Bad news pal. Everything _IS_ data - look in a dictionary. If its information its data. Your beloved MPEG for example is data - its domestic multimedia services too but its still data. If its information IPng can carry it. And just to prove it I've ftp'd mpeg files around and played mpeg from mosaic. > have a defacto set of Broadcasting standards.. One cannot have an > "International Networking" standard for anything in today's world .. wait for > it.. without an agreed international address form.. Real world networks live effortlessly in multiple protocol and numbering domains. IP runs over ethernet. IP runs over SLIP (mac layer of phone numbers). It doesn't matter what your carrier is. > the whole planet goes through the bubonic plague of TCP/IP reconfiguration it > will yet again chose a numbering scheme which is administered by the US.. Is that your pet worry. I can get IP addresses free and easily. Getting a set of OSI addresses around here is a little like trying to lease the mona lisa without security. > Some organisations are seeing that TRUE Global Standards are the way.. Yep. the UK Janet network has mostly ditched X.25/X.29 and gone IP over SMDS. The UK government now pushes open systems and doesn't do anything about OSI. The proposals for making the UK government information accessible to people are all about the internet. The US government copyright review is all about the effects of the internet. The BBC is using the internet, selling internet services and doing programs about the internet. The word OSI hasn't even appeared. Newspapers are full of internet/world-wide-web stories and new pull out sections. OSI isn't even mentioned. > Why on earth would the large corporates, security agencies, governments and > carriers of this world go to "an interest group" to get .. yet again.. > another set of funny numbers.. which have no relationship to the planet's > geography or formal IT administration for its IT infrastucture? Routing and geography are nothing to do with each other Formal IT administration is one of these silly government state owned carrier things. As to security services, pray then why does DARPA use TCP/IP. Why does the UK MOD use TCP/IP ? > And please dont say because you have already done that.. Every one who has > to reconfigure his total TCP/IP network now knows the magic of the "working > code"!!!!. Its not hard now on a well managed network, with DHCP you just configure your server via SNMP , check your routers over and adjust them with SNMP from your nice management desktop and go. > .Once bitten .. twice shy? Once bitten not going to fall for OSI again.. > I think its about time your "marketing man" who comes up with such statements > about OSI is dead, OSI is a dream and TCP/IP is living it, kings and votes, > working code and "few exceptions re routing" should review them. I think its time you studied the current market and current market trends in TCP/IP and OSI products. Microsoft windows ships rather a lot of copies. THe new one has TCP/IP - no OSI just TCP/IP. Thats probably 40million seats +. I dont think that many OSI stacks even exist. Microsoft seem to think its so important that they are giving away their windows 3.11 tcp/ip stack by ftp. > PPS It is a wonder that with all the lawyers in the US that some one has not > cottoned on to the misconception that TCP/IP has been promoted as a Global > networking technology and isnt.. Last week I debugged a networking problem between two Linux boxes. One in colombia the other in the ukraine - TCP/IP all the way. Thats getting pretty global. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 07:08:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03497; Thu, 1 Sep 94 07:08:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03491; Thu, 1 Sep 94 07:07:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23851; Thu, 1 Sep 94 07:05:08 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA07616; Thu, 1 Sep 94 07:04:49 PDT Received: from relay.imsi.com by wintermute.imsi.com id KAA26983 for ; Thu, 1 Sep 1994 10:04:42 -0400 Received: from snark.imsi.com by relay.imsi.com id KAA00960 for ; Thu, 1 Sep 1994 10:04:42 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA16893; Thu, 1 Sep 94 10:04:41 EDT Message-Id: <9409011404.AA16893@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. In-Reply-To: Your message of "22 Aug 1994 11:40:31 +1000." <"940822 08:52:36"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> X-Reposting-Policy: redistribute only with permission Date: Thu, 01 Sep 1994 10:04:40 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ALAN LLOYD says: > The Kings and Votes bit with the working code option.. > " Concensus and Working Code" ... > > > This is fine if one is building simple interconnectivity tools because one > can prove the working code in the "garage".. However, when one is building > global infrastructures that carriers will spend $BBB on over > decades, How many ways can we say "The Discussion Is Over"? If you don't like us, why not punish us by denying us the pearls of your wisdom? After all, according to you, its only a matter of time until the ITU asks the UN sends troops to occupy the next IETF meeting and shoot all of us. Why would you want to be around us when that happens? > Next.. The carriers .. You may be aware of these guys... These guys > provide international standards, they define and build international > networks with international addressing schemes which embrace > NSAPs.. these systems will be supported by X.500 directory systems, > X.700 management systems and provide as an application, global X.400 > messaging systems .. All these technologies have GLOBAL NAMES AND > ADDRESSES... You also seem to believe that UUNET, PSI, Sprint, and other similar companies aren't carriers. After all, they run TCP/IP, and they don't use X.700 management systems or X.400 mail. Since none of them are carriers, and the internet doesn't actually run internationally, and ISO is about to crush us all to a ball of wet tissue, and since we are all fools anyway, why not just leave us alone. Please. I beg you, for your own sake. After all, we are idiots who seem to think that this is an engineering group rather than a group here to discuss politics, so why don't you just give up on us? We are all thick simpletons and don't deserve your assistance which we are all so callously ignoring. Meanwhile, as I've said, I have imaginary clients using the non-existant internet technology over fictional international networks and they have delusions about needing to see IPv6 working sometime soon. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 08:45:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03582; Thu, 1 Sep 94 08:45:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03576; Thu, 1 Sep 94 08:45:47 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29791; Thu, 1 Sep 94 08:42:56 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA23327; Thu, 1 Sep 94 08:42:38 PDT Received: from muggsy.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA13678; Thu, 1 Sep 94 08:37:47 -0700 Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA07065; Thu, 1 Sep 1994 11:37:32 -0400 Received: by netrix.lkg.dec.com; id AA27046; Thu, 1 Sep 1994 11:37:42 -0400 Date: Thu, 1 Sep 1994 11:37:42 -0400 From: Dan Harrington Message-Id: <9409011537.AA27046@netrix.lkg.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) I-D on NSAP recommendations Cc: bound@zk3.dec.com, brian@dxcoms.cern.ch Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, Brian, Just a couple of quick comments on the draft...I'm still looking into some other aspects of it, but two things caught my eye right off the bat... 1) > NSAPA mapping into a 16-byte IP6 address for ICD and DCC > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 0-3 |0 0 0 0 0 0 1|G| AFcode| IDI (last 3 digits) |Prefix(octet 0)| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^^^^^^^^^^^^^ ????????????? The SIPP Addressing Architecture draft (Francis et al., dated July 1994) specifies that NSAP Allocation addresses have a leading prefix of 1110 00 (the Format Prefix, section 2.2). Is this not applicable? Or did I misunderstand something? 2) > 2. F.69 (Telex), E.163 (telephone) and Local formats cannot be > mapped. It is not widely expected that IP6 will need to run with a > Telex or POTS addressing plan. IP6 has a native method of supporting > Local addressing plans. I can go along with the bit about private networks (49::), but why the seemingly arbitrary restriction against the other formats? These formats just piggyback existing unique numbering schemes so that a network can be uniquely identified...I can't see that the mapping issue is any different. I don't see this as a huge issue, I'm just curious about the reasoning behind the restriction. Thanks for your time, Dan Harrington ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 09:59:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03642; Thu, 1 Sep 94 09:59:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03636; Thu, 1 Sep 94 09:59:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06689; Thu, 1 Sep 94 09:56:36 PDT Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA08259; Thu, 1 Sep 94 09:56:17 PDT Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id MAA11406; Thu, 1 Sep 1994 12:56:16 -0400 Message-Id: <199409011656.MAA11406@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. In-Reply-To: Your message of "22 Aug 1994 11:40:31 EDT." <"940822 08:52:36"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> From: Valdis.Kletnieks@vt.edu Date: Thu, 01 Sep 1994 12:56:15 +22306356 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Pay no attention to the raving lunatic behind the ranting... Let's peruse the headers and play "put up or shut up"... Received: from vtucs.cc.vt.edu (mail.bev.net [128.173.4.72]) by black-ice.cc.vt.edu (8.6.9/8.6.9) with SMTP id CAA09861 for ; Thu, 1 Sep 1994 02:23:05 -0400 ( 11 Received: tags deleted) Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT01215; Thu, 01 Sep 1994 16:08:21 EST Date: 22 Aug 94 11:40:31 +1000 Ua-Content-Id: 940822 08:52:36 Priority: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940822 08:52:36 006 X400-Trace: AU*TEXTFILE*dcaus; arrival 940822114031+1000 deferred 940822114031+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940825094811+1000 deferred 940825094811+1000 action Relayed Message-Id: <"940822 08:52:36"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> So.. it took it from Aug 22 to Sept 1 to wander around several X.400 systems, but once it got to the TCP/IP world, it got from Australia, to Sun, to me, via 11 intermediate systems, in 15 minutes. Guess we know who knows how to build very fast and reliable e-mail systems, don't we? Nope, isn't us IETF people. Must be them X.400 people, who have invented an online version of "The check is in the mail". My hat's off to them, I now have yet another excuse for not getting work done.... Valdis Kletnieks Computer Systems Engineer Virginia Tech ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 10:49:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03685; Thu, 1 Sep 94 10:49:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03679; Thu, 1 Sep 94 10:49:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12034; Thu, 1 Sep 94 10:46:52 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA19641; Thu, 1 Sep 94 10:46:02 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA17808; Thu, 1 Sep 94 10:05:39 -0700 Received: by xirtlu.zk3.dec.com; id AA01891; Thu, 1 Sep 1994 13:05:25 -0400 Message-Id: <9409011705.AA01891@xirtlu.zk3.dec.com> To: Dan Harrington Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) I-D on NSAP recommendations In-Reply-To: Your message of "Thu, 01 Sep 94 11:37:42 EDT." <9409011537.AA27046@netrix.lkg.dec.com> Date: Thu, 01 Sep 94 13:05:19 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, >1) >> NSAPA mapping into a 16-byte IP6 address for ICD and DCC >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> 0-3 |0 0 0 0 0 0 1|G| AFcode| IDI (last 3 digits) |Prefix(octet 0)| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ^^^^^^^^^^^^^ > ????????????? >The SIPP Addressing Architecture draft (Francis et al., dated July 1994) >specifies that NSAP Allocation addresses have a leading prefix of >1110 00 (the Format Prefix, section 2.2). Is this not applicable? >Or did I misunderstand something? No you did not. It appears that the address reservations still need some work and the draft you referenced has been changed per a presentation a the Toronto IETF (this is one of the updates we need to the spec). At this time "I think" the allocation is 0000 0001. This will need to be aligned with that decision in our next release of the draft. >2) >> 2. F.69 (Telex), E.163 (telephone) and Local formats cannot be >> mapped. It is not widely expected that IP6 will need to run with a >> Telex or POTS addressing plan. IP6 has a native method of supporting >> Local addressing plans. >I can go along with the bit about private networks (49::), but why the >seemingly arbitrary restriction against the other formats? These >formats just piggyback existing unique numbering schemes so that a >network can be uniquely identified...I can't see that the mapping >issue is any different. I don't see this as a huge issue, I'm just >curious about the reasoning behind the restriction. Well in the case of F.69 and E.163 they just cannot be mapped and it is not perceived to be used for this network layer address. In the case of Local Formats the present allocation is 1111 1110, hence, IP6 is defining their own format if that piggy back violates that assignment then it won't work. Unless your saying the Local format will fit within this assignment? If so do you think we should count on that? Good questions. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 11:00:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03706; Thu, 1 Sep 94 11:00:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03234; Thu, 1 Sep 94 00:11:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10128; Thu, 1 Sep 94 00:08:18 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA02437; Thu, 1 Sep 94 00:07:32 PDT Received: from cms.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA28027; Thu, 1 Sep 1994 17:06:15 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@cms.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@cms.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA00697; Thu, 1 Sep 94 17:01:34 +1000 Received: by cms.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00584; Thu, 01 Sep 1994 17:01:33 EST Date: 29 Aug 94 17:37:24 +1000 To: /G=Jeff/S=Latimer/O=FINANCE/P=AUSGOVFINANCE/A=TELEMEMO/C=AU/@cms.datacraft.com.au Cc: /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@cms.datacraft.com.au, ipng@sunroof.Eng.Sun.COM, /G=kim/S=fenley/OU2=cm-dimp/OU=aditcs/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@cms.datacraft.com.au Subject: (IPng) RE: RE: (IPNG) RE: GENERIC QOS SOCKET INTERFACE Ua-Content-Id: 940829 17:34:53 P1-Recipient: /G=Jeff/S=Latimer/O=FINANCE/P=AUSGOVFINANCE/A=TELEMEMO/C=AU/@cms.datacraft.com.au, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@cms.datacraft.com.au, ipng@sunroof.eng.sun.com, /G=kim/S=fenley/OU2=cm-dimp/OU=aditcs/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@cms.datacraft.com.au Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940829 17:34:53 014 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940829173724+1000 deferred 940829173724+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940829173509+1000 deferred 940829173509+1000 action Relayed Message-Id: <"940829 17:34:53"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jeff, Jim.. I am not sure what the issue was here... re the session layer and why do we need it ... X.400 is why we need it and FAx is why we need it.. X.400 uses the Activity Subset to start and synchronise a humungous transfer.. under the common OSI services of Reliable Transfer Service... ie Activity Start, Data, Data, Synchronise, Data, Data -- Activity End.. All Done! The IPS does not seem to have the concept of "Reliable Appliaction Level Transfer" for HUGE lumps of Application Data... That can be recovered from a bilaterally understood sync point... I am open to corrections on this one.. But when the new internet IPS has to accomodate Mbytes of Message Data, Mbytes of Directory Search Data and Management Data.. How will the data as lumps be cut up and resynchronised.. The Transport layer performs "transient recovery" of network connections.. RTS and The sessions activity subset provide Application Oriented "Big Lump" recovery.. So we do need a Session Layer.. For "message based" applications.. It is used by Applications whose protocol is not aware of the restrictions in the underlying transport mechanisms.. Putting it in a Kernel is wrong BECAUSE the session layer machine is driven by the Application Layer services.. The next step if such a move took place is put the Presentation and Application Layers in the Kernel.. A Question.. How is SMTP and other applications going to deal with huge lumps of data and the management of transport / network recovery... Can they use RTSE and ISO Session Layer..or something like it.. regards alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 11:04:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03726; Thu, 1 Sep 94 11:04:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03595; Thu, 1 Sep 94 09:51:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05824; Thu, 1 Sep 94 09:48:26 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA06296; Thu, 1 Sep 94 09:48:03 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA18314; Thu, 1 Sep 94 09:42:05 -0700 Received: by xirtlu.zk3.dec.com; id AA01236; Thu, 1 Sep 1994 12:41:53 -0400 Message-Id: <9409011641.AA01236@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu, mankin@cmf.nrl.navy.mil Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) REQUEST (HELP) to IPng Area Directors on NSAP and OSI Discussion Date: Thu, 01 Sep 94 12:41:46 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Scott and Allison, Can you help us on this IPng base list. You gave us some potential dates as a working group to get IP6 base done. This is a very important working group and therefore I must read all mail. For about two weeks we have been subjected to extreme non-technical and political mail regarding the decision of IP6 per NSAP mapping. I and others have even responded and asked this discussion to go elsewhere either to the big-i or a new mail list. This has done no good at all. It just continues. I even believe that folks have free speech and stated that, but I also respect the wishes of my peers on this list and shut up with responses myself. Brian and I sent out a draft on how NSAPs can be used which was even technical and it was hoped to cause at least a technical discussion, but that did not work either. Then we faced the issue of folks using up the reserved fields in the NSAP and we gave them a format for all other NSAPs as a blank set of BCD digits in the draft specification, again of no avail to persue technical discussion. This draft fyi ate up a whole lot of Brian and I's time after our day job too. I apologize for sending this directly to you, but we have real work to do and the excess mail interferes with our time synch to work on base IP6. This mail discussion subject is influencing no one and will change nothing via the diatribe on this working group mail list or the decision for IPng IMHO. Anything you can do to help is greatly appreciated. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 11:15:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03752; Thu, 1 Sep 94 11:15:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03746; Thu, 1 Sep 94 11:15:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14641; Thu, 1 Sep 94 11:12:21 PDT Received: from postoffice3.mail.cornell.edu by Sun.COM (sun-barr.Sun.COM) id AA25601; Thu, 1 Sep 94 11:12:02 PDT Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id OAA12296 for ; Thu, 1 Sep 1994 14:11:54 -0400 Message-Id: <199409011811.OAA12296@postoffice3.mail.cornell.edu> X-Sender: swb1@postoffice3.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 1 Sep 1994 14:11:57 -0500 To: ipng@sunroof.Eng.Sun.COM From: Scott W Brim Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 13:06 9/1/94 -0400, Valdis.Kletnieks@vt.edu wrote: >Guess we know who knows how to build very fast and reliable e-mail systems, >don't we? Nope, isn't us IETF people. Must be them X.400 people First, I'm trying hard to ignore the unsupportable tone of your mail, but just imagine yourself on the other end of it, and control yourself. Second, the design of IP, TCP, and SMTP all came before the IETF existed. The design of the underlying networks and their interconnectivity came after the IETF was formed, but hardly any of that took place in the IETF. What, exactly, are you feeling so smug about? Think about it. ...Scott ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 11:40:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03778; Thu, 1 Sep 94 11:40:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03772; Thu, 1 Sep 94 11:40:47 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17552; Thu, 1 Sep 94 11:37:56 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA01121; Thu, 1 Sep 94 11:37:38 PDT Received: from muggsy.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA26620; Thu, 1 Sep 94 11:30:30 -0700 Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA08000; Thu, 1 Sep 1994 14:30:15 -0400 Received: by netrix.lkg.dec.com; id AA30283; Thu, 1 Sep 1994 14:29:07 -0400 Date: Thu, 1 Sep 1994 14:29:07 -0400 From: Dan Harrington Message-Id: <9409011829.AA30283@netrix.lkg.dec.com> To: bound@zk3.dec.com Subject: Re: (IPng) I-D on NSAP recommendations Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi Jim, Thanks for the quick response...I'm all set on the Local network issue, that doesn't strike me as much of a problem...whether you're talking 49:: or FE:, you're still a private network, and you're not supposed to be interconnected with anybody else's network (never mind the Internet). (Ironic that the Local Use Address is equivalent to the LLC SAP for CLNP...is this a topic for alt.conspiracy? :-) > Well in the case of F.69 and E.163 they just cannot be mapped and it is > not perceived to be used for this network layer address. Not to beat the poor dead horse, but this part of your statement puzzles me...the various CCITT numbering schemes referenced in ISO 8348/Add. 2 are there to allow Network Identifiers (or Area Addresses, or whatever term you wish) to be generated based on some extant number assigned to an organization...for example, Digital could have organized its addressing plan based on my cube's phone number, and its AFI+IDP could have been: 43:1-508-486-7643: This could then be used with our local addressing scheme to give any system in Digital a globally unique NSAP, e.g.: 43:1-508-486-7643:00-41:08-00-2B-18-B5-33:21 Note that it is in no way implied that this phone number is involved in the network topology...it's just a unique number used to uniquely identify a network. If E.164 can be mapped, then certainly E.163 can be mapped...the IDP length is less than for ISDN. In any event, I don't imagine that it's too big a deal...we happen to use an F.69 based IDP on some of our test networks, but I can't recall anybody basing an operational network addressing plan on F.69 or E.163. Most organizations that I've heard of or dealt with go with ICD or DCC numbering schemes. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 11:45:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03796; Thu, 1 Sep 94 11:45:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03790; Thu, 1 Sep 94 11:45:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18025; Thu, 1 Sep 94 11:42:39 PDT Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA01994; Thu, 1 Sep 94 11:42:17 PDT Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id OAA18142; Thu, 1 Sep 1994 14:42:13 -0400 Message-Id: <199409011842.OAA18142@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. In-Reply-To: Your message of "Thu, 01 Sep 1994 14:11:57 EDT." <199409011811.OAA12296@postoffice3.mail.cornell.edu> From: Valdis.Kletnieks@vt.edu Date: Thu, 01 Sep 1994 14:42:13 +22306356 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Thu, 01 Sep 1994 14:11:57 EDT, you said: > First, I'm trying hard to ignore the unsupportable tone of your mail, > but just imagine yourself on the other end of it, and control yourself. Apologies to any who felt offended and slighted. I admit I probably was a *bit* out of line - but it's *really* hard to read e-mail that was delayed for a week and a half by the same software that's being touted as a solution, and keep a straight face. If the note had been a technical discussion of which parts of X.400 and the rest of the OSI stack should be included in IPv6, I'd probably not have written it. Hell, I can even sympathize with the "Well, how we going to map NSAPs in 16 bytes" discussion.. Speaking of which, I'm not an expert on all the ins and outs of NSAP's. Is there a possibility of using an RFC1006-ish scheme (yes, I know this requires (at least in IPv4) the use of a NSAP chopped out of somebody's address space)... /Valdis (who wonders why we've heard naught from the IPX crew....) ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 12:18:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03867; Thu, 1 Sep 94 12:18:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03861; Thu, 1 Sep 94 12:18:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21587; Thu, 1 Sep 94 12:15:51 PDT Received: from BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA08502; Thu, 1 Sep 94 12:15:27 PDT Message-Id: <9409011915.AA08502@Sun.COM> From: John Day Subject: Re: (IPng) RE: RE: (IPNG) RE: GENERIC QOS SOCKET INTERFACE To: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@cms.datacraft.com.au Cc: /G=Jeff/S=Latimer/O=FINANCE/P=AUSGOVFINANCE/A=TELEMEMO/C=AU/@cms.datacraft.com.au, /G=kim/S=fenley/OU2=cm-dimp/OU=aditcs/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@cms.datacraft.com.au, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@cms.datacraft.com.au, ipng@sunroof.Eng.Sun.COM In-Reply-To: <"940829 17:34:53"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> Date: Thu, 1 Sep 94 15:09:58 EST Mail-System-Version: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan > > I am not sure what the issue was here... re the session layer and why do we >need it ... X.400 is why we need it and FAx is why we need it.. X.400 uses >the Activity Subset to start and synchronise a humungous transfer.. under the >common OSI services of Reliable Transfer Service... ie Activity Start, Data, >Data, Synchronise, Data, Data -- Activity End.. All Done! > I fail too see what relevance this discussion has for this list. (maybe I just came in late) But it would seem that RFC1006 will still work with IPv6 and X.400 can simply be run over RFC1006 over TCP over IPv6 as it is today. >The IPS does not seem to have the concept of "Reliable Appliaction Level >Transfer" for HUGE lumps of Application Data... That can be recovered from a >bilaterally understood sync point... I am open to corrections on this one.. > Well actually, FTP does have checkpoint recovery built into it. >But when the new internet IPS has to accomodate Mbytes of Message Data, >Mbytes of Directory Search Data and Management Data.. How will the data as >lumps be cut up and resynchronised.. The Transport layer performs "transient >recovery" of network connections.. RTS and The sessions activity subset >provide Application Oriented "Big Lump" recovery.. > >So we do need a Session Layer.. For "message based" applications.. It is used >by Applications whose protocol is not aware of the restrictions in the >underlying transport mechanisms.. > You may need a Session Layer, but not for these reasons. The OSI Session Layer is a horrible mess. There is currently a move underway to remove Session Activity from RTSE to simplify it. Furthermore RTSE is not a checkpoint recovery protocol or "a big lump recovery". Checkpoint recovery protocols recover at points of signifigance to the application, e.g. record boundaries and the like, RTSE recovers every so many octets just like a transport protocol. In fact, it is a transport protocol masquerading in the application layer because the ITU-T couldn't admit that X.25 is not perfectly reliable. Furthermore, Session does not perform this function, it merely provides some primitives for building the function in the application. In fact, the primitives do so little, it would appear that it could be done much more efficiently in the application layer and ignore the session layer. >Putting it in a Kernel is wrong BECAUSE the session layer machine is driven >by the Application Layer services.. The next step if such a move took place >is put the Presentation and Application Layers in the Kernel.. > This is true. Session is part of the application and always has been. Session, Presentation and ACSE should be considered part of an applications tool kit. Only an idiot would put it in the kernel. > Take care John Day ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 12:37:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03879; Thu, 1 Sep 94 12:37:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03873; Thu, 1 Sep 94 12:37:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23040; Thu, 1 Sep 94 12:34:11 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA11719; Thu, 1 Sep 94 12:33:37 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA25287; Thu, 1 Sep 94 12:18:15 -0700 Received: by xirtlu.zk3.dec.com; id AA06588; Thu, 1 Sep 1994 15:18:03 -0400 Message-Id: <9409011918.AA06588@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. In-Reply-To: Your message of "Thu, 01 Sep 94 14:42:13." <199409011842.OAA18142@black-ice.cc.vt.edu> Date: Thu, 01 Sep 94 15:17:57 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Speaking of which, I'm not an expert on all the ins and outs of NSAP's. >Is there a possibility of using an RFC1006-ish scheme (yes, I know this >requires (at least in IPv4) the use of a NSAP chopped out of somebody's >address space)... If someone wanted to run an OSI app over IP6 using an NSAP address this would be a good "standard" way to do it. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 12:52:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03897; Thu, 1 Sep 94 12:52:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03891; Thu, 1 Sep 94 12:51:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24326; Thu, 1 Sep 94 12:49:03 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA14338; Thu, 1 Sep 94 12:47:57 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA24987; Thu, 1 Sep 94 12:12:53 -0700 Received: by xirtlu.zk3.dec.com; id AA06443; Thu, 1 Sep 1994 15:12:34 -0400 Message-Id: <9409011912.AA06443@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: /G=Jeff/S=Latimer/O=FINANCE/P=AUSGOVFINANCE/A=TELEMEMO/C=AU/@cms.datacraft.com.au, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@cms.datacraft.com.au, /G=kim/S=fenley/OU2=cm-dimp/OU=aditcs/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@cms.datacraft.com.au Subject: Re: (IPng) RE: RE: (IPNG) RE: GENERIC QOS SOCKET INTERFACE In-Reply-To: Your message of "29 Aug 94 17:37:24 +1000." <"940829 17:34:53"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> Date: Thu, 01 Sep 94 15:12:28 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Jeff, Jim.. Not sure I am the "Jim"? But... > I am not sure what the issue was here... re the session layer and why do we >need it ... X.400 is why we need it and FAx is why we need it.. X.400 uses >the Activity Subset to start and synchronise a humungous transfer.. under the >common OSI services of Reliable Transfer Service... ie Activity Start, Data, >Data, Synchronise, Data, Data -- Activity End.. All Done! Yes I think a session layer is needed I thought this was a better idea. But let me add that I was speaking from my experience what the session does for an application that is not done for one via just a transport interface (more like XTI concept of session for OSI). As opposed to saying we should implement BCS or BAS for IP6. The issue here is that we are trying to determine the BSD sockets interface to IP6. But we have this issue of QOS and RSVP? I don't think we can solve this here or in the BSD API spec other than making sure we have a way to trigger flows and then we need discussion of how he flow ID is built in IP6? It seems RSVP or e-2-2 should figure out what it needs for QOS session type semantics. What I think is discussable for the transport APIs is how does one manage a connection for an application such as QOS via IP6. Right now its roll your own. Thats probably not good. But I am not sure we are charted to fix that in the BSD Sockets API spec or in the IP6 base group? Could we hear from the Chairs of IP6 on this one Please? >The IPS does not seem to have the concept of "Reliable Appliaction Level >Transfer" for HUGE lumps of Application Data... That can be recovered from a >bilaterally understood sync point... I am open to corrections on this one.. This is a transport interface issue for TCP/IP apps isn't it? >But when the new internet IPS has to accomodate Mbytes of Message Data, >Mbytes of Directory Search Data and Management Data.. How will the data as >lumps be cut up and resynchronised.. The Transport layer performs "transient >recovery" of network connections.. RTS and The sessions activity subset >provide Application Oriented "Big Lump" recovery.. >So we do need a Session Layer.. For "message based" applications.. It is used >by Applications whose protocol is not aware of the restrictions in the >underlying transport mechanisms.. Mabye this should be taken to X/Open and POSIX 1003.12.? >Putting it in a Kernel is wrong BECAUSE the session layer machine is driven >by the Application Layer services.. The next step if such a move took place >is put the Presentation and Application Layers in the Kernel.. Well maybe? If I want to make the connection protocol transparent to the network layer type via understanding the name )--> addr returned the connect primitive will pass that request to the kernel and a single entry point to the ipcxxx.c modules (BSD) can be parsed at what is often called the transport layer which is in the kernel. So it depends on what funtions your speaking of and then the performance tradeoffs for memory copies and context switches would have to be analyzed. >A Question.. How is SMTP and other applications going to deal with huge lumps >of data and the management of transport / network recovery... As it does today. This should be transparent to IP6, but I only say this in theory and SMTP is clearly our prototype agenda to test but we need to get the basic architecture done first for IP6. >Can they use RTSE and ISO Session Layer..or something like it.. Not per se in any IP code base I know of just because byte stream record boundries are not assumed. But this goes back to my saying that I think session is a good idea but not necessarily that it can be implemented as has been done for OSI stacks. Its like mixing apples and potatoes. But thats OK. And I do think a session or extended transport interface is the way to go, but this is all theory on my part for TCP/IP right now. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 13:14:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03918; Thu, 1 Sep 94 13:14:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03912; Thu, 1 Sep 94 13:14:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25948; Thu, 1 Sep 94 13:11:11 PDT Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA18282; Thu, 1 Sep 94 13:10:53 PDT Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id QAA22020; Thu, 1 Sep 1994 16:10:52 -0400 Message-Id: <199409012010.QAA22020@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. In-Reply-To: Your message of "Thu, 01 Sep 1994 15:17:57 EDT." <9409011918.AA06588@xirtlu.zk3.dec.com> From: Valdis.Kletnieks@vt.edu Date: Thu, 01 Sep 1994 16:10:52 +22306356 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Thu, 01 Sep 1994 15:17:57 EDT, you said: > If someone wanted to run an OSI app over IP6 using an NSAP address this > would be a good "standard" way to do it. Well, modulo renumbering issues... Doesn't RFC1006 use an NSAP address carved out of University College London's Telex space or someting? Is an NSAP renumbering an OK solution, or do we need a "real" 20->16 mapping? /Valdis (who actually administers an X.500 server, but only via RFC1006 ;) ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 13:19:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03930; Thu, 1 Sep 94 13:19:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03924; Thu, 1 Sep 94 13:19:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26487; Thu, 1 Sep 94 13:17:00 PDT Received: from BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA19409; Thu, 1 Sep 94 13:16:40 PDT Message-Id: <9409012016.AA19409@Sun.COM> From: John Day Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9409011918.AA06588@xirtlu.zk3.dec.com> Date: Thu, 1 Sep 94 16:08:52 EST Mail-System-Version: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim > >>Speaking of which, I'm not an expert on all the ins and outs of NSAP's. >>Is there a possibility of using an RFC1006-ish scheme (yes, I know this >>requires (at least in IPv4) the use of a NSAP chopped out of somebody's >>address space)... > >If someone wanted to run an OSI app over IP6 using an NSAP address this >would be a good "standard" way to do it. > Could you be a little more specific about what you mean. RFC1006 defines how to map TP0 to TCP. No NSAPs involved anywhere. What do you have in mind. Take care John >/jim >------------------------------------------------------------------------------ >IETF IPng Mailing List >Unsubscribe: unsubscribe ipng (as message body, not subject) >Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 16:52:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04339; Thu, 1 Sep 94 16:52:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04333; Thu, 1 Sep 94 16:52:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20024; Thu, 1 Sep 94 16:49:19 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AB02025; Thu, 1 Sep 94 16:47:48 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA01157; Fri, 2 Sep 1994 09:46:27 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA01660; Fri, 2 Sep 94 09:41:29 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT01642; Fri, 02 Sep 1994 09:41:27 EST Date: 22 Aug 94 13:26:20 +1000 To: tli@cisco.com, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, ipng@sunroof.Eng.Sun.COM, /S=bruce-steer/O=saa/P=sa/A=telememo/C=au/@x400gw.datacraft.com.au Subject: (IPng) AUTO CONFIGURATION Ua-Content-Id: 940822 12:17:53 P1-Recipient: tli@cisco.com, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, ipng@sunroof.eng.sun.com, /S=bruce-steer/O=saa/P=sa/A=telememo/C=au/@x400gw.datacraft.com.au Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940822 12:17:53 008 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940822132620+1000 deferred 940822132620+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940825094817+1000 deferred 940825094817+1000 action Relayed Message-Id: <"940822 12:17:53"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony I appreciate the need for dynamic assignment of addresses but where are we going with this one.. Is the scope of this to provide a "connection" to a plugged up PC on a server. Or is there a bigger picture.. eg what managment tools propagate to the PCs, what does the network operator see, is security being dealt with, what about logging, what about repudiation, what about the fact that without any consolidation of UserId / network number all sorts of operational, accounting and security problems will arise.. Also it seems the 16 byte issue could affect this "protocol".. Am I nuts or is the process that is going on .. Lets have 16 bytes cos 4 is too short and twenty is to long.. Lets force the NSAPs (in a buggered form) into the 16 bytes.. And now..Lets have a protocol which can spread these funny numbers around. the same number to several people in the course of minutes!!. Numbers which will have little resemblence to carrier numbers, global naming or user Ids.. Sorry if I seem synical .. It was bad enough trying to design a big network with half a C Class.. But at least I knew where the end point was and who owned it.. Now will there will be Big Funny Numbers flying all over the planet.. Is this virtual networking? There is virtually no way of finding out what did what to whom and when?? Regards PS This debate is good fun isnt it? ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 17:32:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04411; Thu, 1 Sep 94 17:32:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04405; Thu, 1 Sep 94 17:32:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25414; Thu, 1 Sep 94 17:29:44 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA08760; Thu, 1 Sep 94 17:29:23 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA02783; Fri, 2 Sep 1994 10:29:14 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA00699; Fri, 2 Sep 94 10:23:17 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00602; Fri, 02 Sep 1994 10:23:16 EST Date: 18 Aug 94 09:14:38 +1000 To: ipng@sunroof.Eng.Sun.COM, kinnish@dstos3.dsto.gov.au, /G=kim/S=fenley/OU2=cm-dimp/OU=aditcs/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@x400gw.datacraft.com.au, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, /S=bruce-steer/O=saa/P=sa/A=telememo/C=au/@x400gw.datacraft.com.au Subject: (IPng) IPNG - SOME MORE THOUGHTS AND INFO Ua-Content-Id: 940818 08:41:52 P1-Recipient: ipng@sunroof.eng.sun.com, kinnish@dstos3.dsto.gov.au, /G=kim/S=fenley/OU2=cm-dimp/OU=aditcs/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@x400gw.datacraft.com.au, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, /S=bruce-steer/O=saa/P=sa/A=telememo/C=au/@x400gw.datacraft.com.au Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940818 08:41:52 015 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940818091438+1000 deferred 940818091438+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940825094759+1000 deferred 940825094759+1000 action Relayed Message-Id: <"940818 08:41:52"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gentlemen, attached is an article re the IPNG debate. I provide articles monthly to Australian Comms.. It is FYI. Please can any one tell me objectively why the 16 byte field has been chosen. Bearing this decision will implicate the whole planets IT addressing scheme and system design. The next point is that it seems that the IPNG group is now trying to allocate space within the 16 bytes and force 20 byte NSAPs into it.. I find this approach defies computer science and common sense.. bearing in mind the IPNG group is deciding on "one of the world's addressing schemes" how can on earth can one decide on its length without strong definitions of what goes in it, its routing hierarchies, its address administration and if it deals with dependent or independent (logical) addresses AND full agreements from the countries that will administer it!!! Perhaps a sugestion is to model the IPNG addressing on NSAPs. Use a registerd ICD value for the Internet, define an Authority ID or RD for the old four byte scheme and assign RDs and lower for the new internet addresses. This will provide a numeric scheme below the RD level of 11 bytes (area,loc,system id and nsel) which in total should be ample for the Internet or any other independent network across this planet It will also enable global interworking.. At least this approach will be compatible with ISO/ITU schemes and harmonisation and product design will be a thousand times easier.. Please advise on this one (and the 16 byte decision). The next point although is not at the highest priority at the moment as this addressing issue is the one raised in my attachment re SNMP and CMIP.. I am afraid I just cannot see SNMP as being any use to manage switched networks because object methodology has to be used for circuits (because they come and go) and objects when instanciated need a name.. SNMP deals with flat information that has no behaviour.. Hence CMIP uses object naming structures DNs as per X.500. So the management philosophy of IPNG should also be considered in this addressing (and naming issue).. If IPNG adopts NSAPs to harmonise with B-ISDN and OSI technologies and ISO/ITU addrressing schemes. And the Internet is adopting X.500 as one of its directory systems because of its (carrier defined) global naming standards... It follow that the management system should also adopt global naming standards .. ie incorporate CMIP.. Again comments are welcome.. regards alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 18:06:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04471; Thu, 1 Sep 94 18:06:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04465; Thu, 1 Sep 94 18:06:07 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29014; Thu, 1 Sep 94 18:03:16 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AB14825; Thu, 1 Sep 94 18:02:59 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id SAA23646; Thu, 1 Sep 1994 18:02:39 -0700 Date: Thu, 1 Sep 1994 18:02:39 -0700 From: Tony Li Message-Id: <199409020102.SAA23646@lager.cisco.com> To: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Cc: /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, ipng@sunroof.Eng.Sun.COM, /S=bruce-steer/O=saa/P=sa/A=telememo/C=au/@x400gw.datacraft.com.au In-Reply-To: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au's message of 22 Aug 94 13:26:20 +1000 <"940822 12:17:53"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> Subject: (IPng) AUTO CONFIGURATION Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony PS This debate is good fun isnt it? No. When will you realize that the debate is over and let us get back to work? Some of us fought for longer addresses. We lost. But we are still going to make IPv6 work. You're standing in the way. The decision has been made. Period. All you're doing is alienating a whole LOT of people. I'm sorry to be so rude, but this has passed into the absurd. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 18:44:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04509; Thu, 1 Sep 94 18:44:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04503; Thu, 1 Sep 94 18:44:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03125; Thu, 1 Sep 94 18:41:23 PDT Received: from nico.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA20390; Thu, 1 Sep 94 18:40:50 PDT Received: from cruskit.aarnet.edu.au (cruskit.aarnet.edu.au [139.130.204.2]) by nico.aarnet.edu.au (8.6.9/8.6.9) with SMTP id LAA24302 for ; Fri, 2 Sep 1994 11:40:37 +1000 Received: by cruskit.aarnet.edu.au (8.6.9) id LAA27479; Fri, 2 Sep 1994 11:40:37 +1000 Date: Fri, 2 Sep 1994 11:40:37 +1000 (EST) From: Andy Linton To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) AUTO CONFIGURATION In-Reply-To: <199409020102.SAA23646@lager.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Thu, 1 Sep 1994, Tony Li wrote: > Tony > PS This debate is good fun isnt it? > > No. When will you realize that the debate is over and let us get back > to work? > > Some of us fought for longer addresses. We lost. But we are still > going to make IPv6 work. You're standing in the way. The decision > has been made. Period. All you're doing is alienating a whole LOT of > people. > > I'm sorry to be so rude, but this has passed into the absurd. > > Tony As someone living and working in Australia and involved in making IPv4 and, in due course IPv6, work, I'd like to echo Tony's comments and point out to the rest of the list that Alan Lloyd (or any of the rest of the Australian OSI lunatic fringe) does not speak for me. I'd also guess that there is a large group of people in Australia that would not appreciate having him as a spokesman. So as Tony says, the debate is over. Let's allow people to get down to the work that needs doing. andy -- Andy Linton A.Linton@aarnet.edu.au Network Engineer phone: +61 6 249 2874 AARNet fax: +61 6 249 1369 -- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 20:17:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04614; Thu, 1 Sep 94 20:17:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04608; Thu, 1 Sep 94 20:17:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08483; Thu, 1 Sep 94 20:14:13 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA01115; Thu, 1 Sep 94 20:13:50 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA14450; Thu, 1 Sep 94 20:05:15 -0700 Received: by xirtlu.zk3.dec.com; id AA15418; Thu, 1 Sep 1994 23:05:07 -0400 Message-Id: <9409020305.AA15418@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Hotel and other Logistics for Implementors Meeting Date: Thu, 01 Sep 94 23:05:01 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have folks asking me for hotel logistics etc. so here they be. Our Chairs will be working with the WG on the agenda. Also if folks would like to go on a tour of our CRL labs while here send me private mail. Please folks no more than 3 people from one company and 2 is better if possible. The Mbone will not be used for this meeting. /jim ------------------------------ IPng Implementors Meeting October 10-12. Please RSVP to Jim Bound bound@zk3.dec.com unless you already have done so. Meeting will end on October 12th at Noon. Hotel: Cambridge Marriot (617) 494-6600 Rate is $149.00 Standard. You can take a cab from Logan Airport for about $15.00. Location: Cambridge Research Lab Digital Equipment Corporation One Kendall Square Building 700, Second Floor Cambridge, MA 02139 The meeting will be held in the Sahara Conference Room. DIRECTIONS to: Digital Equipment Corporation ========== CAMBRIDGE RESEARCH LAB One Kendall Square, Building 700 Cambridge, Massachusetts 02139 Telephone: (617) 621-6600 Please be warned that THE One Kendall Square complex is NOT in Kendall Square proper. One Kendall Square is a cluster of buildings located on the NORTH side of Technology Square at the JUNCTION of Hampshire Street and Broadway. WALKING Directions FROM Binney Street ======================================= 1. Cross back over Binney Street. Use walkway between Bank of New England [LEFT] and Building 1400 [RIGHT] into One Kendall Square complex. Enter Building 700 on your RIGHT. 2. Walk through Atrium to elevators and go up to 2nd floor. [CRL is UP TO your RIGHT as you ENTER atrium] WALKING directions FROM Hampshire Street ========================================== 1. Walk through MAIN courtyard of One Kendall Square, bear RIGHT up a set of stairs and around Building 200. A clothing store is on your immediate LEFT. 2. Enter doorway to LEFT of Quantum Books, go STRAIGHT down hall through another set of doors and into the five-story atrium, [lobby of Building 700]. 3. FOLLOW "Binney Street" step [2] above. WALKING directions FROM MBTA (Subway stop) ============================================ 1. Take the Red Line to Kendall Square Stop (MIT). 2. At street level, you will see the MIT Coop. 3. Facing the Coop, turn LEFT and walk to end of block. 4. Turn RIGHT (at Legal Seafoods). Walk one block and turn LEFT onto Broadway (toward Cambridge, not Boston). 5. Walk down Broadway. Cross railroad tracks. Walk underneath Draper Lab's pedestrian bridge. 6. When street splits, bear RIGHT onto Hampshire Street and into One Kendall Square Complex. 7. FOLLOW "Hampshire Street" directions. WALKING directions FROM Kendall Square Mariott ================================================ 1. Exit hotel onto Broadway and cross street. 2. Walk down Broadway (towards Cambridge, not Boston). Cross railroad tracks. Walk underneath Draper Lab's pedestrian bridge. 3. When street splits, bear RIGHT onto Hampshire Street and walk into One Kendall Square Complex. 4. FOLLOW "Hampshire Street" directions. Directions by car from ROUTE 2 ================================ 1. Follow Route 2 to Fresh Pond Parkway, Fresh Pond Parkway south to Memorial Drive, and Memorial Drive to the Hyatt Regency Hotel. 2. FOLLOW step [3] of "Directions from MASSACHUSETTS TURNPIKE". Directions by car from the MASSACHUSETTS TURNPIKE ================================================= If you are coming from the WEST on MASS PIKE ============================================== 1a. Exit the Mass Pike at Exit 18, Allston-Cambridge (LEFT exit) and take RIGHT fork to Cambridge. FOLLOW step [2] below. If you are coming from the EAST on MASS PIKE ============================================== 1b. Exit the Mass Pike at Exit 20, Allston-Cambridge , and take RIGHT fork to Cambridge. 2. Go straight, over bridge, and TURN RIGHT (immediately) at traffic light at FAR side of the bridge, onto Memorial Drive. 3. Stay in LEFT lane, and follow Memorial Drive (taking overpass) to first traffic light (JUST after the Hyatt Regency Hotel). 4. Turn LEFT at that light. 5. At end of block (a T-end), turn RIGHT onto Vassar Street. 6. Follow Vassar Street. At first light, cross Massachusetts Avenue. At second light cross Main Street, bearing LEFT. The third light is one block later. 7. At third light, turn LEFT onto Broadway. 8. Proceed across railroad tracks. 9. At fork of Broadway and Hampshire, stay to RIGHT. At first light take a RIGHT onto Cardinal Mederios. Take first RIGHT onto Binney Street. 10. PARKING - Binney Street Garage Directions by car from ROUTE 3 ================================ 1. Take Route 3 to Route 128 South to Route 2 East. FOLLOW ROUTE 2 directions . Alternate directions by car from ROUTE 3 ========================================== 1. Take Route 3 to Route 128 North to I-93 South. 2. Get off I-93 at Sullivan Square exit. Follow signs to Boston. This entails a sort of roller coaster getting off and on about three ramps. 3. Keep following "Boston" signs until you see Bunker Hill Community College on your RIGHT and first sign for Cambridge. Follow sign (i.e., turn RIGHT). This road becomes Commercial Avenue in Cambridge within a block. 4. Follow Commercial until it runs into Memorial Drive at a lift bridge. This is THE first RIGHT that is NOT at a traffic signal. Take RIGHT, which puts you onto Broadway. 5. Follow Broadway for three traffic lights and take RIGHT fork immediately past train tracks. 6. Please refer to "Directions from MASSACHUSETTS TURNPIKE", FOLLOW STEP [8] Directions by car from LOGAN AIRPORT ====================================== 1. Follow street signs to Mass Pike, and FOLLOW the MASSACHUSETTS TURNPIKE directions. Alternate directions from LOGAN AIRPORT ========================================= 1. Take Sumner Tunnel into Boston. Stay in LEFT lane. 2. As you exit tunnel, keep LEFT and go up entrance ramp to Central Artery. 3. Get into RIGHT lane and take 2nd exit to Storrow Drive. 4. Get into LEFT lane and stay LEFT. (This all happens quite fast!) 5. Go through a short tunnel, take LEFT exit ( sign says Government Center). 6. After exit take an immediate RIGHT onto Longfellow Bridge. 7. Come straight off bridge and down Broadway (through Kendall Square proper). 8. FOLLOW step [7] of "Directions from MASSACHUSETTS TURNPIKE". THE BINNEY STREET PARKING GARAGE ================================ PLEASE NOTE: If Parking Ticket is lost you will pay $14. If your ticket is not STAMPED by Digital, 0-1 hrs will cost $2.00. So don't forget to bring it with you!! RATES: 1 hour free with stamp by CRL 1-2 hrs $2.00; $1.00 for each additional hr; $7.00 max. HOURS: 6:00 a.m.-12:00 Midnight. CROSS BACK over Binney Street. Use walkway between Genzyme Bldg. [LEFT] and Building 1400 [RIGHT] into One Kendall Square complex. Enter Building 700, which is the 2nd building on your RIGHT. WALK THROUGH Atrium to elevators and go up to 2nd floor. [CRL is up to your RIGHT as you enter atrium] ----------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 23:39:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04959; Thu, 1 Sep 94 23:39:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04953; Thu, 1 Sep 94 23:39:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13088; Thu, 1 Sep 94 23:36:33 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA16052; Thu, 1 Sep 94 23:36:14 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA07329; Fri, 2 Sep 1994 08:36:12 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA04451; Fri, 2 Sep 1994 08:36:10 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409020636.AA04451@dxcoms.cern.ch> Subject: (IPng) How bout you ta To: ipng@sunroof.Eng.Sun.COM (ip6) Date: Fri, 2 Sep 1994 08:36:10 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2239 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, Yr message was cc to the ipng list but I didn't see it come by. Is there a black hole someehere? > From: Dan Harrington > Message-Id: <9409011829.AA30283@netrix.lkg.dec.com> > To: bound@zk3.dec.com > Subject: Re: (IPng) I-D on NSAP recommendations > Cc: ipng@sunroof.eng.sun.com > > Hi Jim, > > Thanks for the quick response...I'm all set on the Local network issue, > that doesn't strike me as much of a problem...whether you're talking > 49:: or FE:, you're still a private network, and you're not supposed > to be interconnected with anybody else's network (never mind the Internet). > (Ironic that the Local Use Address is equivalent to the LLC SAP for > CLNP...is this a topic for alt.conspiracy? :-) > > > Well in the case of F.69 and E.163 they just cannot be mapped and it is > > not perceived to be used for this network layer address. > > Not to beat the poor dead horse, but this part of your statement puzzles > me...the various CCITT numbering schemes referenced in ISO 8348/Add. 2 are > there to allow Network Identifiers (or Area Addresses, or whatever term > you wish) to be generated based on some extant number assigned to an > organization...for example, Digital could have organized its addressing > plan based on my cube's phone number, and its AFI+IDP could have been: > > 43:1-508-486-7643: > > This could then be used with our local addressing scheme to give any > system in Digital a globally unique NSAP, e.g.: > > 43:1-508-486-7643:00-41:08-00-2B-18-B5-33:21 > > Note that it is in no way implied that this phone number is involved > in the network topology...it's just a unique number used to uniquely > identify a network. If E.164 can be mapped, then certainly E.163 can > be mapped...the IDP length is less than for ISDN. > > In any event, I don't imagine that it's too big a deal...we happen > to use an F.69 based IDP on some of our test networks, but I can't > recall anybody basing an operational network addressing plan on > F.69 or E.163. Most organizations that I've heard of or dealt with > go with ICD or DCC numbering schemes. > > Dan > You said it. My preference is not to define mappings that likely won't be used; we can always add them. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 1 23:47:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05004; Thu, 1 Sep 94 23:47:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04998; Thu, 1 Sep 94 23:47:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13233; Thu, 1 Sep 94 23:44:58 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA16672; Thu, 1 Sep 94 23:44:40 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA08251; Fri, 2 Sep 1994 08:44:38 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA04930; Fri, 2 Sep 1994 08:44:36 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409020644.AA04930@dxcoms.cern.ch> Subject: (IPng) a technical point from Valdis To: ipng@sunroof.Eng.Sun.COM Date: Fri, 2 Sep 1994 08:44:36 +0200 (MET DST) In-Reply-To: <199409011842.OAA18142@black-ice.cc.vt.edu> from "Valdis.Kletnieks@vt.edu" at Sep 1, 94 02:42:13 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 421 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Valdis, > > Speaking of which, I'm not an expert on all the ins and outs of NSAP's. > Is there a possibility of using an RFC1006-ish scheme (yes, I know this > requires (at least in IPv4) the use of a NSAP chopped out of somebody's > address space)... > I can't imagine anything preventing use of RFC1006 over TCP over IP6. There is reference in RFC1006 to 4-byte IP addresses, so we would need RFC1006bis. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 01:45:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05047; Fri, 2 Sep 94 01:45:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05041; Fri, 2 Sep 94 01:45:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19078; Fri, 2 Sep 94 01:42:48 PDT Received: from survis.surfnet.nl by Sun.COM (sun-barr.Sun.COM) id AA28552; Fri, 2 Sep 94 01:42:31 PDT Message-Id: <9409020842.AA28552@Sun.COM> Received: from survis.surfnet.nl by survis.surfnet.nl with SMTP (PP); Fri, 2 Sep 1994 10:42:24 +0200 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. In-Reply-To: Your message of Thu, 01 Sep 1994 14:42:13. <199409011842.OAA18142@black-ice.cc.vt.edu> Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Fri, 02 Sep 1994 10:42:23 +0200 From: Victor Reijs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ==> From: Valdis.Kletnieks@vt.edu > the "Well, how we going to map NSAPs in 16 bytes" discussion.. > In my opinion it is: "How are we going to map NSAP addresses in 15 bytes?" Or is the IPv6 address becoming part of the NSAP address structure? Otherwise the first octet of the IPv6 address will be a 'format identifier for NSAP' (like seen in the proposal). All the best, Victor ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 02:44:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05139; Fri, 2 Sep 94 02:44:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05133; Fri, 2 Sep 94 02:44:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20342; Fri, 2 Sep 94 02:41:20 PDT Received: from ecrc.de by Sun.COM (sun-barr.Sun.COM) id AA03022; Fri, 2 Sep 94 02:41:02 PDT Received: from scorpio.ecrc.de by ecrc.de with SMTP id AA00261 ( for ); Fri, 2 Sep 1994 11:41:00 +0200 Received: from acrab25.ecrc.de by scorpio.ecrc.de (4.1/SMI-3.2) id AA00509; Fri, 2 Sep 94 11:24:23 +0200 Date: Fri, 2 Sep 94 11:24:23 +0200 From: Dave Morton Message-Id: <9409020924.AA00509@scorpio.ecrc.de> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) AUTO CONFIGURATION Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Tony > PS This debate is good fun isnt it? No it's not. If you persist you will drive people off onto other more private mailing lists and spoil this one for everyone concerned. Dave ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 06:18:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05216; Fri, 2 Sep 94 06:18:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05210; Fri, 2 Sep 94 06:18:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24001; Fri, 2 Sep 94 06:15:55 PDT Received: from BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA22502; Fri, 2 Sep 94 06:15:38 PDT Message-Id: <9409021315.AA22502@Sun.COM> From: John Day Subject: Re: (IPng) Hotel and other Logistics for Implementors Meeting To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9409020305.AA15418@xirtlu.zk3.dec.com> Date: Fri, 2 Sep 94 09:09:07 EST Mail-System-Version: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I have folks asking me for hotel logistics etc. so here they be. Our >Chairs will be working with the WG on the agenda. > >Also if folks would like to go on a tour of our CRL labs while >here send me private mail. > >Please folks no more than 3 people from one company and 2 is better if >possible. I'm sorry, but I am bit confused. I thought individuals were represented in the IETF at their meetings. Was there a change in the rules at Toronto to company representation? How do companies joint the IETF? Does each company get one or two votes? This is very interesting. Please advise. Take care John Day ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 06:33:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05228; Fri, 2 Sep 94 06:33:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05222; Fri, 2 Sep 94 06:33:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24392; Fri, 2 Sep 94 06:30:56 PDT Received: from nbkanata.newbridge.com by Sun.COM (sun-barr.Sun.COM) id AA23889; Fri, 2 Sep 94 06:30:38 PDT Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.newbridge.com (4.1/SMI-4.1) id AA15193; Fri, 2 Sep 94 09:25:35 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA10686; Fri, 2 Sep 94 09:25:30 EDT Received: from urchin.newbridge by mako.newbridge (4.1/SMI-4.1) id AA22658; Fri, 2 Sep 94 09:24:43 EDT Received: by urchin.newbridge (5.0/SMI-SVR4) id AA16095; Fri, 2 Sep 1994 09:26:54 +0500 Date: Fri, 2 Sep 1994 09:26:54 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9409021326.AA16095@urchin.newbridge> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Hotel and other Logistics for Implementors Meeting X-Sun-Charset: US-ASCII Content-Length: 706 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM John, You are being deliberately ingenuous, and it ill becomes you. IETF participants represent themselves. However, implementors are almost always working at their employers behest. To keep the meeting from becoming too large, the host is requesting that each implementor group send two or at most three people to the meeting. This was prompted in particular when one notorious troublemaker suggested that he might send 6 people who have never participated in any of this work to the implementors meeting. (If this were a full IETF meeting, the suggestions of restricting the number would not have been made, as you know.) Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 07:21:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05255; Fri, 2 Sep 94 07:21:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05249; Fri, 2 Sep 94 07:21:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26526; Fri, 2 Sep 94 07:18:08 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA00663; Fri, 2 Sep 94 07:17:51 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA16221; Fri, 2 Sep 94 07:10:12 -0700 Received: by xirtlu.zk3.dec.com; id AA27925; Fri, 2 Sep 1994 10:10:10 -0400 Message-Id: <9409021410.AA27925@xirtlu.zk3.dec.com> To: John Day Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. In-Reply-To: Your message of "Thu, 01 Sep 94 16:08:52 EST." <9409012017.AA21609@decvax.dec.com> Date: Fri, 02 Sep 94 10:10:04 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM John, >Jim >> >>>Speaking of which, I'm not an expert on all the ins and outs of NSAP's. >>>Is there a possibility of using an RFC1006-ish scheme (yes, I know this >>>requires (at least in IPv4) the use of a NSAP chopped out of somebody's >>>address space)... >> >>If someone wanted to run an OSI app over IP6 using an NSAP address this >>would be a good "standard" way to do it. >> >Could you be a little more specific about what you mean. RFC1006 >defines how to map TP0 to TCP. No NSAPs involved anywhere. What do you >have in mind. In 1006 the TS-Provider is essentially a black box and no real specifications for its definition or how it is written. At the TS-Provider the NSAP OSI address could be transformed to an IP6 compatible mapping based on an IETF RFC. Thats all. Also 1006 can also be used as a basis to map other than TP0 to TCP but your right that is not in the present RFC. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 07:24:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05267; Fri, 2 Sep 94 07:24:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05261; Fri, 2 Sep 94 07:24:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26692; Fri, 2 Sep 94 07:21:23 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA01275; Fri, 2 Sep 94 07:21:06 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA17188; Fri, 2 Sep 94 07:17:45 -0700 Received: by xirtlu.zk3.dec.com; id AA28087; Fri, 2 Sep 1994 10:17:38 -0400 Message-Id: <9409021417.AA28087@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Hotel and other Logistics for Implementors Meeting In-Reply-To: Your message of "Fri, 02 Sep 94 09:09:07 EST." <9409021315.AA22502@Sun.COM> Date: Fri, 02 Sep 94 10:17:32 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM John, >>Please folks no more than 3 people from one company and 2 is better if >>possible. >I'm sorry, but I am bit confused. I thought individuals were >represented in the IETF at their meetings. Was there a change in the >rules at Toronto to company representation? How do companies joint the >IETF? Does each company get one or two votes? This is very interesting. >Please advise. Your right we are individuals at the IETF. But some organizations have a number of folks that work as individual contributors at the IETF. What we are asking is that if by chance there are 5 engineers working on IP6 in the IETF from one entity then could you maybe only send 2 and max 3 due to space for the meeting. I will not respond to the scarcasim though I want to badly but we have had enough flames and waste on this list already. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 07:40:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05279; Fri, 2 Sep 94 07:40:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05273; Fri, 2 Sep 94 07:40:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27525; Fri, 2 Sep 94 07:37:46 PDT Received: from BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA04000; Fri, 2 Sep 94 07:37:23 PDT Message-Id: <9409021437.AA04000@Sun.COM> From: John Day Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9409021410.AA27925@xirtlu.zk3.dec.com> Date: Fri, 2 Sep 94 10:32:11 EST Mail-System-Version: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >In 1006 the TS-Provider is essentially a black box and no real >specifications for its definition or how it is written. At the >TS-Provider the NSAP OSI address could be transformed to an IP6 >compatible mapping based on an IETF RFC. Thats all. Okay right. It doesn't really provide any insight as to how to map NSAPs into IPv6 addresses (which is what I thought someone was implying). But we will have to modify 1006 a bit to use with IPv6. Well, actually we shouldn't. If we define somewhere how the address mappings are done, since 1006 maps TP0 to TCP changing the network layer protocol "shouldn't" change anything. (But then we all know that layer separation is never real.) >Also 1006 can also >be used as a basis to map other than TP0 to TCP but your right that is not >in the present RFC. > right. Take care John ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 08:05:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05320; Fri, 2 Sep 94 08:05:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05314; Fri, 2 Sep 94 08:05:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29137; Fri, 2 Sep 94 08:02:55 PDT Received: from hsdndev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA07859; Fri, 2 Sep 94 08:02:37 PDT Date: Fri, 2 Sep 94 11:02:26 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9409021502.AA07072@hsdndev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Hotel and other Logistics for Implementors Meeting Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM John, >>Please folks no more than 3 people from one company and 2 is better if >>possible. >I'm sorry, but I am bit confused. I thought individuals were >represented in the IETF at their meetings. Was there a change in the >rules at Toronto to company representation? How do companies joint the >IETF? Does each company get one or two votes? This is very interesting. >Please advise. In case it was not clear, this is an IPng implementers meeting not a regular IETF meeting. The reason to say anything about attendees is that we are trying to be sure that: 1/ the right people come (those who are actually (or will soon be) working on IPng implementations, WG chairs & document authors) 2/ we can have a manageable meeting, i.e. not a cast of thousands of people who have not read the documentation. It is not a question of voting or any such formal process, just a bit of practicality. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 08:08:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05332; Fri, 2 Sep 94 08:08:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05326; Fri, 2 Sep 94 08:08:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29355; Fri, 2 Sep 94 08:05:59 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA08336; Fri, 2 Sep 94 08:05:35 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA21135; Fri, 2 Sep 94 08:01:08 -0700 Received: by xirtlu.zk3.dec.com; id AA29571; Fri, 2 Sep 1994 11:01:02 -0400 Message-Id: <9409021501.AA29571@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. In-Reply-To: Your message of "Fri, 02 Sep 94 10:42:23 +0200." <9409020842.AA28552@Sun.COM> Date: Fri, 02 Sep 94 11:00:55 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >In my opinion it is: "How are we going to map NSAP addresses in 15 >bytes?" Or is the IPv6 address becoming part of the NSAP address >structure? Otherwise the first octet of the IPv6 address will be a >'format identifier for NSAP' (like seen in the proposal). The first octet is the AFI+AFCODE using whatever the IP6 address assignment plans are for allocation for all address types. So we are using 16bytes. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 08:38:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05345; Fri, 2 Sep 94 08:38:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05339; Fri, 2 Sep 94 08:38:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01052; Fri, 2 Sep 94 08:35:58 PDT Received: from nbkanata.newbridge.com by Sun.COM (sun-barr.Sun.COM) id AA13426; Fri, 2 Sep 94 08:35:40 PDT Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.newbridge.com (4.1/SMI-4.1) id AA18679; Fri, 2 Sep 94 11:30:35 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA14496; Fri, 2 Sep 94 11:30:34 EDT Received: from urchin.newbridge by mako.newbridge (4.1/SMI-4.1) id AA22924; Fri, 2 Sep 94 11:29:46 EDT Received: by urchin.newbridge (5.0/SMI-SVR4) id AA16120; Fri, 2 Sep 1994 11:31:58 +0500 Date: Fri, 2 Sep 1994 11:31:58 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9409021531.AA16120@urchin.newbridge> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Apology X-Sun-Charset: US-ASCII Content-Length: 510 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM My apologies to all members of this list, particularly those who may have felt insulted or slighted by my message about participating in the upcoming implementors meeting. The note should have been sent privately, as I had no reason to speak to John Day that way in Public. Further, the paragraph in my note commenting on the motivation for the explicit request for fewer participants was unnecessary and should not have been present. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 08:54:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05358; Fri, 2 Sep 94 08:54:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05352; Fri, 2 Sep 94 08:54:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02127; Fri, 2 Sep 94 08:51:20 PDT Received: from BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA16198; Fri, 2 Sep 94 08:50:53 PDT Message-Id: <9409021550.AA16198@Sun.COM> From: John Day Subject: Re: (IPng) Hotel and other Logistics for Implementors Meeting To: sob@hsdndev.harvard.edu Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9409021502.AA07072@hsdndev.harvard.edu> Date: Fri, 2 Sep 94 11:46:24 EST Mail-System-Version: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joel and Scott, >You are being deliberately ingenuous, and it ill becomes you. >IETF participants represent themselves. However, implementors are >almost always working at their employers behest. To keep the meeting >from becoming too large, the host is requesting that each implementor >group send two or at most three people to the meeting. I am sorry that you feel that I am being ingenuous. But there is a real question here. I understand the desire. I have had it many times. But I have never found a way to do it and remain fair and open. I am assuming that you have and I simply don't understand how this is to work and who can and can't come. >This was prompted in particular when one notorious troublemaker >suggested that he might send 6 people who have never participated in >any of this work to the implementors meeting. I understand and this is not my intent. In any case, you will very likely end up with many people not well versed on the subject. I am concerned about all of the various groups within my company who are either implementing IPv6 or have a substantial stake in ensuring that the implementations support the requirements of our customers and don't create more headaches than we already have. >(If this were a full IETF meeting, the suggestions of restricting the >number would not have been made, as you know.) Of course, then I would know the rules for calling the meeting. >In case it was not clear, this is an IPng implementers meeting not a regular >IETF meeting. The reason to say anything about attendees is that we are trying >to be sure that: I really wish you hadn't said that it wasn't a regular IETF meeting, because now my legal eagles are going to worry about what the anti-trust laws call collusion and no one may be able to attend. Okay, it is not a regular IETF meeting. Then what is it and what are the rules, and how do I allay my legal eagles, so at least three can show up. > 1/ the right people come (those who are actually (or will soon be) working > on IPng implementations, WG chairs & document authors) > 2/ we can have a manageable meeting, i.e. not a cast of thousands of > people who have not read the documentation. > Yes, yes. Meetings are always easier when the right people are there, but in reality it is always hard to determine who the right people are and still be fair. The results of this meeting are important not only for implementors but could have considerable impact on many of our customers. >It is not a question of voting or any such formal process, just a bit of practicality. > In a consensus group is never (or seldom) a question of voting, but how the meeting is put together certainly determines how the consensus gets swayed. Take care John ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 10:02:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05570; Fri, 2 Sep 94 10:02:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05564; Fri, 2 Sep 94 10:02:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08005; Fri, 2 Sep 94 09:59:09 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA29529; Fri, 2 Sep 94 09:58:48 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA14828; Fri, 2 Sep 94 09:51:54 -0700 Received: by xirtlu.zk3.dec.com; id AA02584; Fri, 2 Sep 1994 12:51:49 -0400 Message-Id: <9409021651.AA02584@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: sob@hsdndev.harvard.edu, mankin@cmf.nrl.navy.mil, pvm@isi.edu Subject: (IPng) IMPORTANT IS THERE AN ANTITRUST ISSUE ?? Date: Fri, 02 Sep 94 12:51:43 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, [From: John Day begat on Subject : Hotel and Logistics ...Implementors Meeting] > I really wish you hadn't said that it wasn't a regular IETF meeting, >because now my legal eagles are going to worry about what the anti-trust >laws call collusion and no one may be able to attend. Okay, it is not a >regular IETF meeting. Then what is it and what are the rules, and how >do I allay my legal eagles, so at least three can show up. Right now I would like to ask Scott, Allison, and the Chairs to clear up the above comment from John or I cannot host this implementors meeting. The tone and possible effect of the above just made me very nervous. All we are trying to do is get those implementing IP6 (writing real code based on extensive analysis of the specs) get together and see if there are any holes in the specs per this type of analysis. We had two of them in the past and the results were sent to the working group as technical input. Thats all it is no more no less. The reason was that we want to get more work done before the IETF next meeting and in person so we can roll up our sleeves and work on this per the AD's agressive schedule. I really can't believe this is happening and I am beginning to feel like a Senator listening to a filibuster (ostructionist) to avoid movement and work on proposal, not just because of John's mail, but much of the mail in general. Can we please just do some work or what. Someone higher up in the food chain please tell me we are OK per John's mail. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 11:03:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05970; Fri, 2 Sep 94 11:03:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05964; Fri, 2 Sep 94 11:03:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14037; Fri, 2 Sep 94 11:00:29 PDT Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA12968; Fri, 2 Sep 94 11:00:05 PDT Received: from pobox (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA19170; Fri, 2 Sep 94 13:55:43 EDT Received: from cabernet.wellfleet by pobox (4.1/SMI-4.1) id AA15128; Fri, 2 Sep 94 13:54:13 EDT Date: Fri, 2 Sep 94 13:54:13 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9409021754.AA15128@pobox> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Implementors Meeting Announcement and Logistics Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The IPng working group will hold an implementors meeting, hosted by Digital Equipment Corporation, from October 10-12. The implementation discussion will include the base IPv6 protocol, and also transition and autoconfiguration details. The particulars are: IPng Implementors meeting 9:00am Mon. Oct. 10 through 12:00 noon Wed Oct. 12. DEC, Cambridge Research Lab One Kendall Square Building 700, Second Floor Cambridge, MA 02139 Attendees should be WG chairs, document authors, or engineers who are, or will be building IPv6 products. Notes from the meeting will be published expeditiously. Please let Jim Bound (bound@zk3.dec.com) know if you are planning on attending (so that he can know how large a group to plan for). In order to keep attendance to a reasonable size, we are asking companies/organizations to limit their attendance to 3 engineers. (and no lawyers ;-). Ross --------------------------------------------------------------- A friendly warning to anyone planning to fly in and rent a car. Rush hour traffic leaving the airport can be legendary. Cab drivers are able to bypass most of this traffic and the subway works well (well OK, it works well enough) and stops very near the hotel. Logistics: IPng Implementors Meeting October 10-12. Please RSVP to Jim Bound bound@zk3.dec.com unless you already have done so. Meeting will end on October 12th at Noon. Hotel: Cambridge Marriot (617) 494-6600 Rate is $149.00 Standard. You can take a cab from Logan Airport for about $15.00. Location: Cambridge Research Lab Digital Equipment Corporation One Kendall Square Building 700, Second Floor Cambridge, MA 02139 The meeting will be held in the Sahara Conference Room. DIRECTIONS to: Digital Equipment Corporation ========== CAMBRIDGE RESEARCH LAB One Kendall Square, Building 700 Cambridge, Massachusetts 02139 Telephone: (617) 621-6600 Please be warned that the One Kendall Square complex is NOT in Kendall Square proper. One Kendall Square is a cluster of buildings located on the NORTH side of Technology Square at the JUNCTION of Hampshire Street and Broadway. WALKING Directions FROM Binney Street ======================================= 1. Cross back over Binney Street. Use walkway between Bank of New England [LEFT] and Building 1400 [RIGHT] into One Kendall Square complex. Enter Building 700 on your RIGHT. 2. Walk through Atrium to elevators and go up to 2nd floor. [CRL is UP TO your RIGHT as you ENTER atrium] WALKING directions FROM Hampshire Street ========================================== 1. Walk through MAIN courtyard of One Kendall Square, bear RIGHT up a set of stairs and around Building 200. A clothing store is on your immediate LEFT. 2. Enter doorway to LEFT of Quantum Books, go STRAIGHT down hall through another set of doors and into the five-story atrium, [lobby of Building 700]. 3. FOLLOW "Binney Street" step [2] above. WALKING directions FROM MBTA (Subway stop) ============================================ 1. Take the Red Line to Kendall Square Stop (MIT). 2. At street level, you will see the MIT Coop. 3. Facing the Coop, turn LEFT and walk to end of block. 4. Turn RIGHT (at Legal Seafoods). Walk one block and turn LEFT onto Broadway (toward Cambridge, not Boston). 5. Walk down Broadway. Cross railroad tracks. Walk underneath Draper Lab's pedestrian bridge. 6. When street splits, bear RIGHT onto Hampshire Street and into One Kendall Square Complex. 7. FOLLOW "Hampshire Street" directions. WALKING directions FROM Kendall Square Mariott ================================================ 1. Exit hotel onto Broadway and cross street. 2. Walk down Broadway (towards Cambridge, not Boston). Cross railroad tracks. Walk underneath Draper Lab's pedestrian bridge. 3. When street splits, bear RIGHT onto Hampshire Street and walk into One Kendall Square Complex. 4. FOLLOW "Hampshire Street" directions. Directions by car from ROUTE 2 ================================ 1. Follow Route 2 to Fresh Pond Parkway, Fresh Pond Parkway south to Memorial Drive, and Memorial Drive to the Hyatt Regency Hotel. 2. FOLLOW step [3] of "Directions from MASSACHUSETTS TURNPIKE". Directions by car from the MASSACHUSETTS TURNPIKE ================================================= If you are coming from the WEST on MASS PIKE ============================================== 1a. Exit the Mass Pike at Exit 18, Allston-Cambridge (LEFT exit) and take RIGHT fork to Cambridge. FOLLOW step [2] below. If you are coming from the EAST on MASS PIKE ============================================== 1b. Exit the Mass Pike at Exit 20, Allston-Cambridge , and take RIGHT fork to Cambridge. 2. Go straight, over bridge, and TURN RIGHT (immediately) at traffic light at FAR side of the bridge, onto Memorial Drive. 3. Stay in LEFT lane, and follow Memorial Drive (taking overpass) to first traffic light (JUST after the Hyatt Regency Hotel). 4. Turn LEFT at that light. 5. At end of block (a T-end), turn RIGHT onto Vassar Street. 6. Follow Vassar Street. At first light, cross Massachusetts Avenue. At second light cross Main Street, bearing LEFT. The third light is one block later. 7. At third light, turn LEFT onto Broadway. 8. Proceed across railroad tracks. 9. At fork of Broadway and Hampshire, stay to RIGHT. At first light take a RIGHT onto Cardinal Mederios. Take first RIGHT onto Binney Street. 10. PARKING - Binney Street Garage Directions by car from ROUTE 3 ================================ 1. Take Route 3 to Route 128 South to Route 2 East. FOLLOW ROUTE 2 directions . Alternate directions by car from ROUTE 3 ========================================== 1. Take Route 3 to Route 128 North to I-93 South. 2. Get off I-93 at Sullivan Square exit. Follow signs to Boston. This entails a sort of roller coaster getting off and on about three ramps. 3. Keep following "Boston" signs until you see Bunker Hill Community College on your RIGHT and first sign for Cambridge. Follow sign (i.e., turn RIGHT). This road becomes Commercial Avenue in Cambridge within a block. 4. Follow Commercial until it runs into Memorial Drive at a lift bridge. This is THE first RIGHT that is NOT at a traffic signal. Take RIGHT, which puts you onto Broadway. 5. Follow Broadway for three traffic lights and take RIGHT fork immediately past train tracks. 6. Please refer to "Directions from MASSACHUSETTS TURNPIKE", FOLLOW STEP [8] Directions by car from LOGAN AIRPORT ====================================== 1. Follow street signs to Mass Pike, and FOLLOW the MASSACHUSETTS TURNPIKE directions. Alternate directions from LOGAN AIRPORT ========================================= 1. Take Sumner Tunnel into Boston. Stay in LEFT lane. 2. As you exit tunnel, keep LEFT and go up entrance ramp to Central Artery. 3. Get into RIGHT lane and take 2nd exit to Storrow Drive. 4. Get into LEFT lane and stay LEFT. (This all happens quite fast!) 5. Go through a short tunnel, take LEFT exit ( sign says Government Center). 6. After exit take an immediate RIGHT onto Longfellow Bridge. 7. Come straight off bridge and down Broadway (through Kendall Square proper). 8. FOLLOW step [7] of "Directions from MASSACHUSETTS TURNPIKE". THE BINNEY STREET PARKING GARAGE ================================ PLEASE NOTE: If Parking Ticket is lost you will pay $14. If your ticket is not STAMPED by Digital, 0-1 hrs will cost $2.00. So don't forget to bring it with you!! RATES: 1 hour free with stamp by CRL 1-2 hrs $2.00; $1.00 for each additional hr; $7.00 max. HOURS: 6:00 a.m.-12:00 Midnight. CROSS BACK over Binney Street. Use walkway between Genzyme Bldg. [LEFT] and Building 1400 [RIGHT] into One Kendall Square complex. Enter Building 700, which is the 2nd building on your RIGHT. WALK THROUGH Atrium to elevators and go up to 2nd floor. [CRL is up to your RIGHT as you enter atrium] ----------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 2 17:14:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06907; Fri, 2 Sep 94 17:14:43 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06901; Fri, 2 Sep 94 17:14:35 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA26136; Fri, 2 Sep 94 17:13:39 PDT Received: from ftp.com (wd40.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA21670; Fri, 2 Sep 94 17:11:25 PDT Received: from ftp.com by ftp.com ; Fri, 2 Sep 1994 20:09:58 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 2 Sep 1994 20:09:58 -0400 Received: from solensky.fenway.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA28374; Fri, 2 Sep 94 20:07:09 EDT Date: Fri, 2 Sep 94 20:07:09 EDT Message-Id: <9409030007.AA28374@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IMPORTANT IS THERE AN ANTITRUST ISSUE ?? From: solensky@ftp.com (Frank T Solensky) Cc: bound@zk3.dec.com, sob@hsdndev.harvard.edu, mankin@cmf.nrl.navy.mil, pvm@isi.edu Repository: mailserv-D.ftp.com, [message accepted at Fri Sep 2 20:06:59 1994] Originating-Client: fenway.ftp.com Content-Length: 544 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Fri, 02 Sep 94 12:51:43 -0400 > From: bound@zk3.dec.com > > Right now I would like to ask Scott, Allison, and the Chairs to clear up > the above comment from John or I cannot host this implementors meeting. > The tone and possible effect of the above just made me very nervous. I'd think that it might be considered collusion if we told some vendor that they couldn't send *anybody*. The request to limit attendance to five people per organization is simply recognizing the logistics and seems more than reasonable. -- Frank ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 3 10:54:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08098; Sat, 3 Sep 94 10:54:46 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08092; Sat, 3 Sep 94 10:54:35 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA17492; Sat, 3 Sep 94 10:53:39 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA21985; Sat, 3 Sep 94 10:51:25 PDT Received: from via.rmm2.merit.edu ([35.195.225.6]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA23234 for ; Sat, 3 Sep 1994 13:51:22 -0400 Date: Sat, 3 Sep 94 16:01:07 GMT From: "William Allen Simpson" Message-Id: <3121.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Valdis.Kletnieks@vt.edu > Guess we know who knows how to build very fast and reliable e-mail systems, > don't we? Nope, isn't us IETF people. Must be them X.400 people, who have > invented an online version of "The check is in the mail". My hat's off to > them, I now have yet another excuse for not getting work done.... > I think this is exactly the right note, and laughed out loud. Thanks! Next week service in a nanosecond world.... Oh, and Scott, your smugness, it seems that enough of the "old" pre-formal IETF progenitors are still participating that we might consider that continuity.... Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 3 12:01:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08184; Sat, 3 Sep 94 12:01:03 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08172; Sat, 3 Sep 94 12:00:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18418; Sat, 3 Sep 94 11:59:54 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA27160; Sat, 3 Sep 94 11:57:39 PDT Received: from via.rmm3.merit.edu ([35.196.49.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA26098 for ; Sat, 3 Sep 1994 14:57:37 -0400 Date: Sat, 3 Sep 94 18:10:36 GMT From: "William Allen Simpson" Message-Id: <3125.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Neighbor Discovery draft coming soon Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Ran Atkinson > We're also quite eager to see some ICMP Discovery specs so we can > implement and test them. > Well, I will begin re-working the draft as soon as I finish catching up on the 500K barrage to this list last week or so. I was waiting for some promised comments from Dave Katz, but they haven't appeared in 3 weeks, so I'll just do without. Next pass. Isn't this what holiday weekends are for? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 3 12:01:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08185; Sat, 3 Sep 94 12:01:05 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08178; Sat, 3 Sep 94 12:00:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18421; Sat, 3 Sep 94 11:59:56 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA27165; Sat, 3 Sep 94 11:57:41 PDT Received: from via.rmm3.merit.edu ([35.196.49.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA26101 for ; Sat, 3 Sep 1994 14:57:39 -0400 Date: Sat, 3 Sep 94 18:30:48 GMT From: "William Allen Simpson" Message-Id: <3126.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) cluster addresses and routing and such.... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: yakov@watson.ibm.com > >>The cluster *are the prefixes ! > > > Further assume that n = 4, and we allocate value S=0001 for subscriber > S1, S=0010 for subscriber S2, S=0011 for subscriber S3, and S=0100 > for subscriber S4. > > 1. Is it possible to form a new cluster X that includes only S1, S2, and S3 ? > This is another "have you stopped beating your wife" question. Since, by definition, the cluster address RESERVES prefix zero, the obvious answer to your question is "S4 violates the reserved cluster", not "yes" or "no". To create a new cluster of (S1 to S3) which excludes (S4) would require either (S1 to S3) or (S4) to renumber. Since auto-renumbering is a part of IPv6, this will be easy to do. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 4 08:15:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09218; Sun, 4 Sep 94 08:15:42 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09212; Sun, 4 Sep 94 08:15:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA01142; Sun, 4 Sep 94 08:14:33 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA13011; Sun, 4 Sep 94 08:12:17 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA16520; Sun, 4 Sep 1994 17:11:01 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA22368; Sun, 4 Sep 1994 17:10:59 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409041510.AA22368@dxcoms.cern.ch> Subject: Re: (IPng) IMPORTANT IS THERE AN ANTITRUST ISSUE ?? To: ipng@sunroof.Eng.Sun.COM Date: Sun, 4 Sep 1994 17:10:59 +0200 (MET DST) Cc: sob@hsdndev.harvard.edu, mankin@cmf.nrl.navy.mil, pvm@isi.edu In-Reply-To: <9409021651.AA02584@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Sep 2, 94 12:51:43 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 672 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, I feel hesitant to answer since I am also an IAB member and anyway you are asking for a counsel's opinion. Probably you should forward the question to Tony Rutkowski and Vint Cerf who have been seeking counsel's opinion on standards process. Do you want me also to raise it on the IAB list? My personal opinion (as a non-US observer fascinated by US anti-trust law) is that an implementor's meeting has no, repeat no, right to modify draft standards and of course no right to talk about specific product dates or prices. If you stick to that and publish the record of the meeting I would say it was squeaky clean but you need to check with legal eagles. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 4 20:20:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09339; Sun, 4 Sep 94 20:20:55 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09333; Sun, 4 Sep 94 20:20:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10099; Sun, 4 Sep 94 20:19:49 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA05956; Sun, 4 Sep 94 20:16:19 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA21453; Mon, 5 Sep 1994 13:16:02 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA05579; Mon, 5 Sep 94 13:09:41 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT01715; Mon, 05 Sep 1994 13:09:33 EST Date: 5 Sep 94 13:12:01 +1000 To: /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, /S=bruce-steer/O=saa/P=sa/A=telememo/C=au/@x400gw.datacraft.com.au, /G=jeff/S=latimer/O=finance/P=ausgovfinance/A=telememo/C=au/@x400gw.datacraft.com.au, kgk@nic.ott.hookup.net, /G=kim/S=fenley/OU2=cm-dimp/OU=aditcs/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@x400gw.datacraft.com.au, ipng@sunroof.Eng.Sun.COM Subject: (IPng) A SUMMARY FOR DEBATE (IPNG - NSAPS) Ua-Content-Id: 940905 10:35:25 P1-Recipient: /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, /S=bruce-steer/O=saa/P=sa/A=telememo/C=au/@x400gw.datacraft.com.au, /G=jeff/S=latimer/O=finance/P=ausgovfinance/A=telememo/C=au/@x400gw.datacraft.com.au, kgk@nic.ott.hookup.net, /G=kim/S=fenley/OU2=cm-dimp/OU=aditcs/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@x400gw.datacraft.com.au, ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940905 10:35:25 000 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940905131201+1000 deferred 940905131201+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940905130835+1000 deferred 940905130835+1000 action Relayed Message-Id: <"940905 10:35:25"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Gentlemen.. I wish to provide the following for debate / agreement.. so that we all can say what is happening on this issue in terms of Internet operations, technologies and network design issues.. I have provided the points below as the result of the numerous exchanges I have had. I would like to see a collective "report/statement" on the harmonisation and operational issues.. Then we can either resolve them or see how we have to deal with them. The points listed below are the main ones as I see it.. 1. Network Addressing The IP4 addressing structure is limited and is depleating due to the success of IPs deployment. IP6 is being designed to replace IP4 and utilises a 16 byte address field. The IP address structure is formated for Networks and Hosts and can be allocated on a country/regional basis under the control of the Internet. OSI addressing uses a variable length field (max 20 bytes) called an NSAP. NSAPs are allocated by registration authorities under the ISO/ITU. They align with carrier numbering plans and contain formal country codes or a globally recognised (registered) organisation's number that wish to have part of the global addressing space. ie NSAPs apply to the formal country boundaries or logical organisational boundaries .. and both can interwork. THe IP6 address can be carried over NSAPs as an ICD dedicated to the Internet (although its routing hierarchy may not be honoured). The NSAP can be carried over IP6 in a trucated form (although its routing hierarchy may not be honoured). The requirements for the Internet is that the new Internet is based on IP6.. It is not a requirement of the Internet to utilise NSAPs as formalised (by the ISO/ITU naming and addressing). This is simply because the INternet as a network is operated and run by its own group and as such its technologies / standards will always apply. It is a benefit if such technologies and standards apply to the wider community (as they have with FTP, SMTP, SNMP and SMTP, etc). The IT community can use the Internet Technologies in either a private way or as a part of the bigger Internet. In this case (not private use) the users of the Internet technology related to network addressing (and higher level naming) accept the fact that they are "subordinate" to overall address forms as administered by the Internet. Their networks (if they use assigned addresses) will be under the adminstration of the INternet - and the " operational rules" and technologies that deal with eg. security, management, billing, interworking and levels of service will possibly apply. The ISO/ITU are required to have a different and more formal approach to addressing.. because it allocates numbers to countries under agreement with those countries. It recognises / assigns authority to those countries and operators within those countries. It also recognises the multi national organisation by providing ICD forms of addressing. The addressing (and naming) structures of the ISO /ITU schemes have many characteristics.. ie. They are internationally allocated by a formal body. They are considered truly global (because of formal country codes). They define authority hierarchies. They define adminstration hierachies. The define routing hierarchies. They define boundaries .. based on the above.. Boundaries which align to countries, administrations and operators. ie.. Boundaries which define responsibility. Boundaries which define global position. Boundaries which define the levels of service. Boundaries which define the use of communications technology types. Boundaries which define commercial management. Boundaries which define technical management. Boundaries which define billing centres. Boundaries which enable (commercial) bilateral agreements. Boundaries which have transit signalling schemes and defined admin data. IE. The two approaches to network addressing, design and adminstration are different.. where one (The internet) is "borderless" .. The ISO/ITU bounded by countries, administrations, etc. Neither is wrong.. they both work. It will be the ownership issues, management, costs, levels of service, security and technology evolution that will be different. 2. Interworking and address/ id allocation. One can architect one's network on IP addressing as provided by the Internet and map these to the ISO/ITU schemes. Or one can use NSAP addressing and map these to the IP scheme. In both cases, gateways are required. All Internetworking technologies have to map to carrier based addressing (on switched circuit oriented services). Governments and Defence Forces and Aviation etc have chosen ISO/ITU schemes, as the basis of their system design because they do operate within and over defined borders and follow the "management requirements" of countries and utilise the infrastructure of carriers and commercial service providors. Address Allocation The Internet does not (yet?) have the administrative mechanisms for allocating the address space to the extent and recognition as provided by ISO/ITU systems. eg for PSTN, X.25, ISDN, Mobiles, ICDs and DCCs, etc. or formalising address allocation for specific sectors.. Defence, Aviation. The address registration procedures for NSAPs is through the BSI for ICD forms or through the ISO standards body / regulatory body within the respective country. X.400 addresses and X.500 names are as per national NSAPs. The IP6 address adminstration (is, will be, through, body/group/country).. etc (text wanted here please..) about allocation and registration of IP6. Object Identifiers for data, protocols, syntaxes, etc. These will still be administered under the ISO/ITU schemes. The Internet has its own allocated arc under this scheme for its protocols, etc. Other organisations can also register data, protocols under the ISO/ITU scheme. 3. Migration In terms of network evolution the migration from IP4 to IP6 and interworking with OSI is still under review.. Comments to date seem to leave this in the hands of "product suppliers".. Users of IP4 and wish to go to IP6 will have to run "two stacks" (or two addressing regimes) which cannot (do not?) interwork simply because the old addressed devices cannot deal with the new. Embracing OSI and NSAPs will require an additional network addressing regime within the system. IP users migrating to OSI can map (in procedural and network administration terms) their IP addresses into NSAPs at the eg. RD and Area levels. Users should put NSAP routing at the core of the network so that other defacto/ proprietary schemes can "relate" to the formalised global space and all non OSI subnets are treated as the lower order subnets of the OSI address space. NSAPs to IP ** I could do with some words here on how NSAPs should be "migrated from" to go to IP given the above.. It is not just a question of "mapping" I feel.** OR AT BEST: Is it just map them into IP6 a design the network in the same way as NSAPs but with 16 byte addressing? Does interworking with the bigger internet affect this as defined above.. honoured routing schemes. Implications of X.400 and X.500, etc. These two distributed technologies are rapidly being deployed..From an X.400 point .. additional address forms be required for "Terminal" type addresses for IP6 entities (printers, etc).. In terms of X.500, IP6 address forms require definition for Object Class/Attribute , Syntax and Matching Rules. X.500 Name forms.. How will these be aligned.. Do they fit eg.. Country, Org, OrgU etc, etc. 4. Commercial Internet Providors I suppose this one is wide open .. is it too early to discuss / raise this issue. ** Could do with some guidance here.. Will IP6 help to resolve Internet commercial operations by allocating numbers to operators in regions.. Will carriers and other private network operators seek IP address space to run with region / country network services.. Do bilateral agreements have to be reached between them and the IAB/ISOC .. Will Service level agreements be developed for users.. Any Others? Comments / Replies of the non emotive sort are welcomed.. Additions to the list.. ditto Regards Alan@oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 4 20:50:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09367; Sun, 4 Sep 94 20:50:32 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09361; Sun, 4 Sep 94 20:50:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10485; Sun, 4 Sep 94 20:49:28 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA07134; Sun, 4 Sep 94 20:47:11 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 5 Sep 1994 13:43:10 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Mon, 5 Sep 1994 13:46:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 5 Sep 1994 13:43:50 +1000 Date: Mon, 5 Sep 1994 13:43:50 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Sep 05 13:43:49 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 494313050994 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <494313050994*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>In my opinion it is: "How are we going to map NSAP addresses in 15 >>bytes?" Or is the IPv6 address becoming part of the NSAP address >>structure? Otherwise the first octet of the IPv6 address will be a >>'format identifier for NSAP' (like seen in the proposal). >The first octet is the AFI+AFCODE using whatever the IP6 address >assignment plans are for allocation for all address types. So we are >using 16bytes. Is this saying that the AFI+AFCode are being uniquely mapped to the IP6 address space ie. the IP6 address will allocate address space for the AFI's so that the NSAP becomes another IP6 address. If this is not the case, how does this form of encoding get recognised? Regards Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 4 22:08:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09408; Sun, 4 Sep 94 22:08:53 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09402; Sun, 4 Sep 94 22:08:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA11692; Sun, 4 Sep 94 22:07:48 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA11205; Sun, 4 Sep 94 22:05:32 PDT Received: from via.rmm2.merit.edu ([35.195.225.7]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id BAA28770 for ; Mon, 5 Sep 1994 01:05:30 -0400 Date: Mon, 5 Sep 94 02:50:45 GMT From: "William Allen Simpson" Message-Id: <3130.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Suggestions for IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As I am working on updating the IPv6 Header Compression from my old SIPP draft, I noticed a few things: 1) the Ext Len fields should just be called "Length". This would be consistent with IP and UDP practice. 2) the Authentication Header should have a "Next Header" field. 3) the More bit in the Fragment Header could be changed to a Last bit instead (that is, the converse). This would simplify comparison and updating for my purposes. 4) It would be really helpful if the Routing Header had a Length in the same place as the others. That way, we could simply test for equality without knowing the format of the contents, and go to the next header. Pretty Please!?! 5) Change the name of Type 0 to simply "Cluster Routing", rather than "Loose Source Routing". I want to insert these headers for Mobility, and therefore, it won't be "source" specified routing. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 4 22:52:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09480; Sun, 4 Sep 94 22:52:25 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09474; Sun, 4 Sep 94 22:52:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12128; Sun, 4 Sep 94 22:51:21 PDT Received: from drax.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA12852; Sun, 4 Sep 94 22:49:03 PDT Received: from drax.isi.edu by drax.isi.edu (5.65c/5.61+local-16) id ; Sun, 4 Sep 1994 22:48:58 -0700 To: ipng@sunroof.Eng.Sun.COM Cc: /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, /S=bruce-steer/O=saa/P=sa/A=telememo/C=au/@x400gw.datacraft.com.au, /G=jeff/S=latimer/O=finance/P=ausgovfinance/A=telememo/C=au/@x400gw.datacraft.com.au, kgk@nic.ott.hookup.net, /G=kim/S=fenley/OU2=cm-dimp/OU=aditcs/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@x400gw.datacraft.com.au Subject: Re: (IPng) A SUMMARY FOR DEBATE (IPNG - NSAPS) In-Reply-To: Your message of "05 Sep 1994 13:12:01 +1000." <"940905 10:35:25"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> Date: Sun, 04 Sep 94 22:48:58 PDT Message-Id: <20664.778744138@drax.isi.edu> From: Craig Milo Rogers Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I wish to provide the following for debate / agreement.. Thank you, for putting all this together. I'll comment on some sections. Unfortunatelly, my comments sound more like a rebuttal than the amplification I think you requested. Sorry. >The requirements for the Internet is that the new Internet is based on IP6.. >It is not a requirement of the Internet to utilise NSAPs as formalised (by >the ISO/ITU naming and addressing). This is simply because the INternet as a >network is operated and run by its own group and as such its technologies / >standards will always apply. This is not quote a fair statement. The Internet has, occasionally, adopted other group's standards. For example, we use ASN.1 in SNMP. Of course, there are those who will argue that adoption of ASN.1 in SNMP was a terrible mistake... :-) >The IT community can use the Internet Technologies in either a private way or >as a part of the bigger Internet. > >In this case (not private use) the users of the Internet technology related >to network addressing (and higher level naming) accept the fact that they are >"subordinate" to overall address forms as administered by the Internet. I think we'd prefer to phrase it "cooperate with" rather than "subordinate to". The Internet is a network of peers: peer-to-peer networking, so to speak. :-) The routing and addressing heirarchies are intended to be service-enhancing, rather than constraining. >Their networks (if they use assigned addresses) will be under the >adminstration of the INternet - and the " operational rules" and >technologies that deal with eg. security, management, billing, interworking >and levels of service will possibly apply. I'm not certain that I follow your discussion here. It's certainly the case that IP6 addresses will primarily be used in the context of the IP6 protocol, and that the IP6 protocol places certain constraints on security, management, billing, etc. An individual or organization who feels that changes are needed at the IP level, with regards to these issues, can still submit comments and proposals into the IETF standardization process. You don't even have to be politically well-connected to do so! >The ISO/ITU are required to have a different and more formal approach to >addressing.. because it allocates numbers to countries under agreement with >those countries. It recognises / assigns authority to those countries and >operators within those countries. It also recognises the multi national >organisation by providing ICD forms of addressing. > >The addressing (and naming) structures of the ISO /ITU schemes have many >characteristics.. >ie. >They are internationally allocated by a formal body. >They are considered truly global (because of formal country codes). >They define authority hierarchies. >They define adminstration hierachies. >The define routing hierarchies. >They define boundaries .. based on the above.. This may be the crux of the technical problem. The research experience in the Internet by-and-large implies that it is counterproductive for IP-level addresses to attempt all those goals. They should be assigned in a fashion that maximizes network efficiency. They should be truly global, by eschewing nationalistic anachronisms (such as formal country codes). They should probably reflect routing heirarchy first and foremost. Any administrative hierarchy imbedded in them is a secondary issue, an administrative convenience, as it were. Of course, there are those in the Internet community who might disagree with these statements, too. :-) >Boundaries which align to countries, administrations and operators. >ie.. Boundaries which define responsibility. >Boundaries which define global position. >Boundaries which define the levels of service. >Boundaries which define the use of communications technology types. >Boundaries which define commercial management. >Boundaries which define technical management. >Boundaries which define billing centres. >Boundaries which enable (commercial) bilateral agreements. >Boundaries which have transit signalling schemes and defined admin data. Too many boundaries, and some of them are downright counterproductive. Take "communication technology types". Why should they appear in an IP-level address? Why should service levels be part of the address -- shouldn't they be in a separate service level field, instead? Look at the awful mess the EDI community is in because their standards bilateral agreements: we *definately* don't want any of those at in the IP layer! Actually, on communication technology types, it is true that a 6-octet Ethernet address fits comfortably within a 16-octet IP6 address, and it would certainly be convenient (except when you swap boards) to have a host auto configure using the lower-level address... but, that's at the bottom of the address space, and doesn't impact top-level routing much. I certainly wouldn't want to issue top-level prefixes on the basis of 1 if by telephone, 2 if by telex, etc. >IE. The two approaches to network addressing, design and adminstration are >different.. where one (The internet) is "borderless" .. The ISO/ITU bounded >by countries, administrations, etc. The "borderless" approach is, of course, the true international spirit. :-) One currency, one address space? :-) But, I politically digress... >One can architect one's network on IP addressing as provided by the Internet >and map these to the ISO/ITU schemes. Or one can use NSAP addressing and map >these to the IP scheme. In both cases, gateways are required. One can quibble over the words "gateway" vs. "router". Mapping between general NSAPs and IP6 addresses is not necessarily expensive, with a good hardware hash-and-cache scheme. Translating between higher-level protocols *is* expensive. >All Internetworking technologies have to map to carrier based addressing (on >switched circuit oriented services). I'm not sure what you mean here. Are you referring to situations in which the host is connected to the Internet via a switched-circuit oriented carrier, or the case in which the host is providing a switched-circuit oriented service for a higher-level application? Assuming the former, there may be technical justification for embedding carrier-based addresses into the IP-level address when an endpoint is solely connected to a specific carrier. On the other hand, a universal hash-and-cache may be cheaper than special-purpose parse-and-mask lookup code that varies from location to location. Assuming the latter, it is probably true that there will continue to be services for which carier-based circuit switching will be appropriate. Even virtual circuit switches or micro-packet switches such as ATM may be needed. However, such services require relatively small, compact address tokens for circuit identification. Thus, address translation from IP6- or NSAP-based address to circuit identifiers will be required for operation. As far as circuit setup goes -- why couldn't ATM circuits be setup using IP6 addresses for endpoint identification? >Governments and Defence Forces and Aviation etc have chosen ISO/ITU schemes, >as the basis of their system design because they do operate within and over >defined borders and follow the "management requirements" of countries and >utilise the infrastructure of carriers and commercial service providors. Governments, etc., have chosen ISO/ITU because they are members of a closely-coupled adminstrative block. It is unclear that they have given full weight to technical or cost issues in doing so. Border policing, "management requirements", etc., may be better off implemented above the IP layer. In the current economic conditions, any Governments, Defense Forces, and Aviation carriers that have chosen ISO-based implementations may wish to reconsider should IP6-based networks provide more cost-effective services. "Management requirements" may be reevaluated in this light. It is, however, relevant to note that IP6 derives from a community that was created due to the perception that the then-curent ITU-based communication infrastructure was suboptimal and needed to be redirected down more productive paths. >Address Allocation >The Internet does not (yet?) have the administrative mechanisms for >allocating the address space to the extent and recognition as provided by >ISO/ITU systems. eg for PSTN, X.25, ISDN, Mobiles, ICDs and DCCs, etc. >or formalising address allocation for specific sectors.. Defence, Aviation. No, and it probably won't, because it regards those as irrelevant and counterproductive when applied to IP-layer addressing. Why should the Internet allocate PSTN or ISDN addresses? Let the carriers allocate them, in accordance with their own technical and business requirements. We'll allocate an IP address to the endpoint and enter the translation into a database. Why worry? There may be special provision made for mobile host addresses. There will certainly be special provisions made to support multicast applications. IP4 allocated address blocks to Defense; IP6 will probably do the same at some level. However, this is an administrative issue, and hence should be secondary to routing considerations. Certainly, IP-level addresses should not be considered a security or authority token! >In terms of network evolution the migration from IP4 to IP6 and interworking >with OSI is still under review.. Comments to date seem to leave this in the >hands of "product suppliers".. Users of IP4 and wish to go to IP6 will have >to run "two stacks" (or two addressing regimes) which cannot (do not?) >interwork simply because the old addressed devices cannot deal with the new. >Embracing OSI and NSAPs will require an additional network addressing regime >within the system. That doesn't sound right at all. The old, 8-octet SIPP address scheme was specifically designed to allow easy interoperation with IP4 systems during the transition period. I assume that the same will be true of the new 16-octet IP6 addresses. Interoperating with NSAP-based peers can, I claim, be done with caches. "Embracing OSI" means, to me, a far more significant change in application-level protocols; the address regime changes are less significant. >IP users migrating to OSI can map (in procedural and network administration >terms) their IP addresses into NSAPs at the eg. RD and Area levels. >Users should put NSAP routing at the core of the network so that other >defacto/ proprietary schemes can "relate" to the formalised global space and >all non OSI subnets are treated as the lower order subnets of the OSI address >space. I guess that sounds just too inefficient for some members of the IP community to swallow at the present time. The NSAP routing, if it exists at all, should be at the borders of the network; the core should run something compact and efficient. > NSAPs to IP > ** I could do with some words here on how NSAPs should be "migrated from" >to go to IP given the above.. It is not just a question of "mapping" I feel.** >OR AT BEST: Is it just map them into IP6 a design the network in the same >way as NSAPs but with 16 byte addressing? Does interworking with the bigger >internet affect this as defined above.. honoured routing schemes. Sorry, don't understand you here. Transmission broke up. :-) >Implications of X.400 and X.500, etc. >These two distributed technologies are rapidly being deployed..From an X.400 >point .. additional address forms be required for "Terminal" type addresses >for IP6 entities (printers, etc).. > >In terms of X.500, IP6 address forms require definition for Object >Class/Attribute , Syntax and Matching Rules. >X.500 Name forms.. How will these be aligned.. Do they fit eg.. Country, Org, >OrgU etc, etc. Sorry, still don't understand you, but here I don't have the proper background info. In the current Internet, email addresses are mapped in the DNS from a "domain name" to an IP4 address. However, the DNS map doesn't have to know the structure of the IP4 address (net, subnet, subnet mask, etc.). Do X.400/X.500 care about the structure of the lower-level addressing scheme? Do they parse NSAPs (other than for simple reasons, like putting periods into the printed representation for human convenience), or treat them as other than opaque object handles? Craig Milo Rogers ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 01:11:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09728; Mon, 5 Sep 94 01:11:29 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09722; Mon, 5 Sep 94 01:11:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14516; Mon, 5 Sep 94 01:10:25 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA23466; Mon, 5 Sep 94 01:08:07 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng) IP(ng) To: ipng@sunroof.Eng.Sun.COM Date: Mon, 5 Sep 1994 09:05:19 +0200 (BST) In-Reply-To: <9409030007.AA28374@mailserv-D.ftp.com> from "Frank T Solensky" at Sep 2, 94 08:07:09 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1894 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM One thing that I wouldn't mind seeing considered from the IPng implementation point of view (since there is no way the free software world can afford to attend 8) ) is multicasting. With the current IP address space the mapping of multicasts onto ethernet multicasts is sufficient that combined with the low use of multicasts collisions between protocols are unlikely, even when accentuated by the filter limitations of some NIC chips (hash function based ones). With both IPng and with the higher use of multicasts as new toys like the MBONE become popular there is a real need to seperate multicasts by class. It would be good if IPng mandated cleanly three classes of IP multicast 1. Organisation private - much like the private network allocations. No collisions, local allocation policy 2. Low bandwidth services (things like mwhod, mrouted(in theory)) 3. High bandwidth services (visual, audio et al) This is important as otherwise when people start using MAC level multicast filtering run the risk of some poor microcontroller happening to get the same MAC multicast address for its (different) IPng multicast and being wiped out by a 200kb/second stream of digital video is too high. Apart from the worries about this issue and concerns about header compression requirements (which are a link layer issue rather than directly an IPng issue) things seem sane. Another issue for people considering MAC level is whether there should be padding on MAC headers to long word align the IPng header over fast networks and how much it would improve IPng performance knowing the buffer is already sensibly aligned for current and future CPU's. Alan ..-----------,,----------------------------,,----------------------------,, // Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU // ``----------'`----------------------------'`----------------------------'' ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 09:44:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09907; Mon, 5 Sep 94 09:44:48 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09886; Mon, 5 Sep 94 09:44:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22274; Mon, 5 Sep 94 09:43:31 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA27227; Mon, 5 Sep 94 09:41:15 PDT Received: from via.rmm3.merit.edu ([35.196.49.5]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA05345 for ; Mon, 5 Sep 1994 12:41:12 -0400 Date: Mon, 5 Sep 94 13:43:38 GMT From: "William Allen Simpson" Message-Id: <3136.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Multicast Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: iialan@iifeak.swan.ac.uk (Alan Cox) > This is important as otherwise when people start using MAC level multicast > filtering run the risk of some poor microcontroller happening to get the same > MAC multicast address for its (different) IPng multicast and being wiped out > by a 200kb/second stream of digital video is too high. > Sounds like a good idea. We certainly have the bits. Code the scope in the high order bits of the Ethernet block? > Apart from the worries about this issue and concerns about header compression > requirements (which are a link layer issue rather than directly an IPng issue) > things seem sane. Another issue for people considering MAC level is whether > there should be padding on MAC headers to long word align the IPng header > over fast networks and how much it would improve IPng performance knowing the > buffer is already sensibly aligned for current and future CPU's. > The way I do it now is to tell the controller to start the ethernet packet header at a byte alignment which puts the IP header at the 32-bit boundary. In this case, the 32-bit boundary is also a 64-bit boundary, so I'm OK for IPv6. Can we outlaw SNAP encoded headers for IPv6, since they can't possibly align in a mixed environment? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 09:44:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09916; Mon, 5 Sep 94 09:44:51 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09892; Mon, 5 Sep 94 09:44:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22277; Mon, 5 Sep 94 09:43:35 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA27233; Mon, 5 Sep 94 09:41:19 PDT Received: from via.rmm3.merit.edu ([35.196.49.5]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA05348 for ; Mon, 5 Sep 1994 12:41:15 -0400 Date: Mon, 5 Sep 94 13:50:27 GMT From: "William Allen Simpson" Message-Id: <3137.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) A SUMMARY FOR DEBATE (IPNG - NSAPS) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I would like to agree with Craig, but in a more succinct fashion: Security, management, and billing, are outside the scope of the IPv6 address. IPv6 addresses are truly global, and indeed, solar, galactic, and universal. Boundaries are parochial. No authority heirarchies. Few adminstration heirarchies (2 currently). No boundaries, except topological. - No defined responsibility. - No levels of service. - No communications technology types. - No commercial management. - No technical management. - No billing centres. - No bilateral agreements. - No transit signalling schemes and defined admin data. Some of these are part of the policy database, but well outside the scope of an IPv6 address. No special forms for "Terminal" type addresses. No Object/Class/Attribute, Syntax and Matching Rules. The lack of these is a clear advantage of IPv6. > >Address Allocation > >The Internet does not (yet?) have the administrative mechanisms for > >allocating the address space to the extent and recognition as provided by > >ISO/ITU systems. eg for PSTN, X.25, ISDN, Mobiles, ICDs and DCCs, etc. > >or formalising address allocation for specific sectors.. Defence, Aviation. > The Internet has long had the administrative mechanisms for allocating the address space for Mobiles, and specific sectors such as Defense and Aviation. It is completely documented and works quite well, thank you. The Internet has no need or desire to allocate address spaces for PSTN, X.25, ISDN, ICDs and DCCs, etc, since they are _used_ by the Internet, not a _part_ of the Internet. Because the Internet is not tied to a particular low-level mechanism, it can and will change over time. This promotes competition and flexibility. Finally, as far as Alan has responded to my documentation request of the deployment of "millions" of NSAP installed base, it has become apparent that we can relegate NSAP migration somewhere after 5-bit baudot Telex. Let's get on to important migrations, such as IPX and AppleTalk, shall we? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 09:54:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09934; Mon, 5 Sep 94 09:54:06 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09928; Mon, 5 Sep 94 09:53:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22568; Mon, 5 Sep 94 09:53:02 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA28597; Mon, 5 Sep 94 09:50:43 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Multicast To: ipng@sunroof.Eng.Sun.COM Date: Mon, 5 Sep 1994 17:47:59 +0200 (BST) In-Reply-To: <3136.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Sep 5, 94 01:43:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1240 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > there should be padding on MAC headers to long word align the IPng header > > over fast networks and how much it would improve IPng performance knowing the > > buffer is already sensibly aligned for current and future CPU's. > > > The way I do it now is to tell the controller to start the ethernet > packet header at a byte alignment which puts the IP header at the 32-bit > boundary. In this case, the 32-bit boundary is also a 64-bit boundary, > so I'm OK for IPv6. Not every controller has the luxury. Its common that 32bit wide bus controllers like to DMA into 32 bit aligned addresses and you lose. > Can we outlaw SNAP encoded headers for IPv6, since they can't > possibly align in a mixed environment? SNAP people have already opted for a performance hit. I see no point in outlawing what is simply a small performance issue. Thats like arguing that Ethernet ought to be excluded because its slower than FDDI 8). I'm not yet 100% decided on the alignment issue, but for caches and some controllers getting sensible mac level alignment ought to help fractionally. Of course almost everyone will then throw it through streams drivers and waste the CPU totally. The important thing is the people who need it can do it. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 12:50:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10204; Mon, 5 Sep 94 12:50:28 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09391; Sun, 4 Sep 94 21:58:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA11536; Sun, 4 Sep 94 21:57:16 PDT Received: from bos1c.delphi.com by Sun.COM (sun-barr.Sun.COM) id AA10723; Sun, 4 Sep 94 21:55:00 PDT Received: from delphi.com by delphi.com (PMDF V4.3-9 #7804) id <01HGQG9VJYHC8YCRAY@delphi.com>; Mon, 05 Sep 1994 00:54:47 -0400 (EDT) Date: Mon, 05 Sep 1994 00:54:47 -0400 (EDT) From: MARTILLO@delphi.com Subject: (IPng) IPng and the Smugness of the IETF To: ipng@sunroof.Eng.Sun.COM Message-Id: <01HGQG9VKHRM8YCRAY@delphi.com> X-Vms-To: INTERNET"ipng@sunroof.eng.sun.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Date: Thu, 1 Sep 1994 14:11:57 -0500 >To: ipng@sunroof.Eng.Sun.COM >From: Scott W Brim >Subject: Re: (IPng) IPNG AND "FUNNY NUMBERS".. >At 13:06 9/1/94 -0400, Valdis.Kletnieks@vt.edu wrote: > >Guess we know who knows how to build very fast and reliable e-mail systems, > >don't we? Nope, isn't us IETF people. Must be them X.400 people >First, I'm trying hard to ignore the unsupportable tone of your mail, >but just imagine yourself on the other end of it, and control yourself. >Second, the design of IP, TCP, and SMTP all came before the IETF >existed. The design of the underlying networks and their >interconnectivity came after the IETF was formed, but hardly any of >that took place in the IETF. What, exactly, are you feeling so smug >about? Think about it. >...Scott IETF contributors have even less reason for smugness than Scott Brim indicates. The major efforts of the IETF have been directed toware OSPF, SNMPv*, PPP, MPI/X.25, MPI/FR and now IPv6. I suppose judgement should be reserved on IPv6, but the IPv6 requirements document was something out of the twilight zone, and what has been appearing since with respect to IPv6 has not been terribly impressive. A genuine OSPF protocol specification has yet to appear. This lack may in some sense be understandable because link state protocols involving the synchronization of potentially very large databases within large networks suffer from all the problems of synchronizing large distributed databases. The correct approach (from the standpoints of management, reliability and performance) to building large internets should start with building reliable minimally managed high performance communications subnets each of which can interconnect a very large number of hosts. Such high performance communications subnets can then be interconnected by a modest number of multiprotocol routers. The SNMPv* SMIs betray a fairly serious misunderstanding of ASN.1. Despite this misunderstanding SNMP actually will work in the management of fairly simple sorts of devices like toasters, power supplies and modems. Of course, managing any sophisticated device which might contain multiple network layers, multible bridging or routing functionalities, multiple end host functionalities or any other sort of simple virtualized functionality is a complete debacle. For the simple sort of management capabilities which SNMP provides, SNMP is outrageously complex. But these problems are mere quibbles compared to the rude and crude behavior of the principal designers of SNMP. The principal designers, as legends in their own minds, have never shown the least inclination, as good engineers would, to attempt to comprehend any of the criticisms of SNMP so that the problems and misunderstandings associated with SNMPv* and its SMIs might have been corrected. >From the standpoint of product development and support, the creation of two incompatible management standards is a complete disaster and will ultimately cost network device purchasers (to whom costs are passed in the end) piles of money. As for PPP, MPI/X.25 and MPI/FR, the specifications of these encapsulations takes no account of the differing needs of USER-NETWORK and NETWORK-NETWORK interconnectivity. There is no evidence of consideration of issues of interconnecting devices functioning at different protocol layers, nor is there any evidence that the contributors to the specification of these encapsulations ever analyzed earlier work in the area of wide area serial connectivity. The PPP specification is outrageously silly because it requires psychic capabilities on the part of devices (because rather than providing a reasonable registration capability PPP only provides the ability to NAK an option request). With PPP and the MPI encapsulations, bridge to router interconnectivity can be unachievable even though in the local environment bridges and routers can be interconnected with hardly any effort whatsoever. The lack of technical insight on the part of the IETF WGs is particularly obvious in the treatment of the end host functionality which both bridges and routers may contain. Such end host functionality is almost always present in todays bridges and routers for the purpose of management via SNMP or TELNET. Presumably bridges would use a bridging encapsulation while routers use a networking encapsulation. If a management station is to manage both bridges and routers over serial connections, presumably it must support bridging and potentially all network layer encapsulations. Not content with defining different encapsulations for every single possible network layer protocol and bridging, the various working groups have typically also defined special encapsulations for currently standard MAC layer path selection frames (although with complete inconsistency no similar special encapsulations are defined for network layer path selection packets). The MAC layer definition of special frames makes no sense at the MAC layer for the following reasons. 1) There might be some reason to pass such frames downstream so that the next packet switching device could handle them and 2) The IETF WGs have not provided obvious means to distinguish clearly between various current and future MAC layer path selection frames. The IETF is often a good source of comic relief from the rather mundane tasks associated with developing product. But by creating deficient, inconsistent, misguided or bad standards the IETF often makes developing quality products hard and expensive. If the IETF recapitulates past performances in the specification of IPv6, there would be good reason to reject the IETF altogether. Joachim Carlo Santos Martillo Ajami ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 14:04:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10280; Mon, 5 Sep 94 14:04:11 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10274; Mon, 5 Sep 94 14:03:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00636; Mon, 5 Sep 94 14:02:41 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA26845; Mon, 5 Sep 94 14:00:12 PDT Received: from pcsbst.pcs.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA18207; Mon, 5 Sep 94 13:59:25 -0700 Received: by pcsbst.pcs.dec.com (5.65/jmh-inet-gateway-sendmail-V1.05); id AA14485; Mon, 5 Sep 1994 22:59:20 +0200 Message-Id: <9409052059.AA14485@pcsbst.pcs.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: ihanson@pcsbst.pcs.dec.com Subject: Re: (IPng) IPng and the Smugness of the IETF In-Reply-To: Your message of "Mon, 05 Sep 94 00:54:47 EDT." <01HGQG9VKHRM8YCRAY@delphi.com> Date: Mon, 05 Sep 94 22:59:19 +0200 From: "Iain K. Hanson" X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Subject to this being from whom it purports to be from ( the sig is not one of the usual ) >The IETF is often a good source of comic relief from the rather >mundane tasks associated with developing product. At times, your posting have been the source of much amusement to myself, and I suspect to others. As usual, there is a small amount of truth, mixed with a large dose of ( I suspect deliberate ) distortion, plus what would apear to be intentional insult. On many occasions you have been invited to contribute in a positive manner. As yet, I have not seen such a contribution. What saddens me most is that good people often feel the need to try to answer this sort of email point by point in a serrious vein. As I beleive has been seen by many on this and other lists, this is a pointless excerise. The only reason that I have botherered to respond to this email is in the hope that it may prevent someone from taking it serriously. I, for one, have become bored with this sort of contribution. /ikh ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 14:18:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10295; Mon, 5 Sep 94 14:18:01 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10289; Mon, 5 Sep 94 14:17:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00997; Mon, 5 Sep 94 14:16:56 PDT Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA28390; Mon, 5 Sep 94 14:14:40 PDT Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id OAA16157; Mon, 5 Sep 1994 14:14:36 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Sep 1994 14:14:38 -0700 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: (IPng) IPng and the Smugness of the IETF Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joachim, As always, your ability to provide insightful commentary about the IETF is exceeded only by your experience in working with it. One would have thought that the last few rounds on major lists would have dissuaded you from continuing your tone and style. Alas, no. What, pray tell, does it take with you? Rather than offer constructive suggestions, your notes are filled only with criticism and ignorance. The latter, of course, obviates any useful impact of the former. Or rather, the latter permeates the former. Give it a rest, Joachim. Please. d/ At 9:54 PM 9/4/94, MARTILLO@delphi.com wrote: >The major efforts of the IETF have been directed toware OSPF, SNMPv*, >PPP, MPI/X.25, MPI/FR and now IPv6. Gee, I guess Mime and SMTP extensions never happened? The large amount of applications-related work with information services isn't happening? The considerable amount of MIB specification was a figment of our imaginations? On-going work in user services coordination and collaboration? Etc. >A genuine OSPF protocol specification has yet to appear. This lack That's not what I hear from folks who are using it. >The SNMPv* SMIs betray a fairly serious misunderstanding of ASN.1. The rest of your note contains your usual set of plaintive text. One assumes you have recently mastered your text editor's ability to do cut and paste and wish to show the rest of us that you can keep sending the same silly stuff. Just how many times are you going to rehash your laundry list of complaints, Joachim? And why? So, just what constructive purpose do you think you are trying to serve? d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 15:36:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10320; Mon, 5 Sep 94 15:36:10 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10314; Mon, 5 Sep 94 15:36:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA02728; Mon, 5 Sep 94 15:35:04 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA06781; Mon, 5 Sep 94 15:32:45 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA25258; Tue, 6 Sep 1994 08:32:42 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA06760; Tue, 6 Sep 94 08:27:34 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT01715; Tue, 06 Sep 1994 08:27:32 EST Date: 6 Sep 94 08:30:40 +1000 To: /DDV=owner-ipng#064#sunroof2.Eng.Sun.COM/DDT=RFC-822/O=AARN/P=OZ.AU/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) RE: RE: SUMMARY FOR DEBATE- ADDRESSING Ua-Content-Id: 940906 08:25:36 P1-Recipient: /DDV=owner-ipng#064#sunroof2.Eng.Sun.COM/DDT=RFC-822/O=AARN/P=OZ.AU/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au, ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940906 08:25:36 002 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940906083040+1000 deferred 940906083040+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940906082700+1000 deferred 940906082700+1000 action Relayed Message-Id: <"940906 08:25:36"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM bill.. thanks for the response on my summary... However, the point I was making that in a commercial world one has to have boundaries for administration, service levels and commercial management.. As per the carriers and service providors.. I see a strong relationship with address forms (global ones) and authority hierarchies (the people that define and own them) and the administration (the people that operate within the bounds of the addressing space) and the routing hierarchies (the networks provided by the administrators).. It follows that if Commercial Internet operators are being set up that they will have to have commercial domains related to their address allocation... just so they own something and make money out of providing service over this addressed space.. It then follows that the IP6 address structure and administration must take care of network operators who are country bound (as per NSAP DCC form) or supra nationals (mega coms) who are global operators (as per NSAP ICD form).. If IPv6 is being designed and administered to be boundless.. it makes it commercially unusable, unmanageble and somewhat difficult to design global networks with..And please do not get this statement wrong!.. It is IP6s addressing scheme and administration that will need to be understood by all. The Summary I feel should cover the commercial Internet operator issues.. I have copied this back to ipng.sunroof because you have raised a good point and I would be interested in other peoples view on the addressing relationships as described above... A certainly how IP6s address space will be administered. Thanks and Regards Alan@oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 16:20:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10349; Mon, 5 Sep 94 16:20:11 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10343; Mon, 5 Sep 94 16:20:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03838; Mon, 5 Sep 94 16:19:06 PDT Received: from clark.net by Sun.COM (sun-barr.Sun.COM) id AA11916; Mon, 5 Sep 94 16:16:30 PDT Received: (hcb@localhost) by clark.net (8.6.9/8.6.5) id TAA05333; Mon, 5 Sep 1994 19:16:29 -0400 From: Howard Berkowitz Message-Id: <199409052316.TAA05333@clark.net> Subject: Re: (IPng) RE: RE: SUMMARY FOR DEBATE- ADDRESSING To: ipng@sunroof.Eng.Sun.COM Date: Mon, 5 Sep 1994 19:16:28 -0400 (EDT) Cc: /DDV=owner-ipng#064#sunroof2.Eng.Sun.COM/DDT=RFC-822/O=AARN/P=OZ.AU/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au In-Reply-To: <"940906 08:25:36"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> from "/G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au" at Sep 6, 94 08:30:40 am X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2606 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > bill.. > thanks for the response on my summary... However, the point I was making > that in a commercial world one has to have boundaries for administration, > service levels and commercial management.. As per the carriers and service > providors.. Radio, microwave, cellular, and satellite carriers all have boundaries, service levels, and commercial management. > > I see a strong relationship with address forms (global ones) and authority > hierarchies (the people that define and own them) and the administration (the > people that operate within the bounds of the addressing space) and the > routing hierarchies (the networks provided by the administrators).. These carriers, however, do not use addresses; they use frequencies. Depending on the propagation characteristics of the frequency and its administrative assignment, it may or may not be uniquely assigned. > > It follows that if Commercial Internet operators are being set up that they > will have to have commercial domains related to their address allocation... > just so they own something and make money out of providing service over this > addressed space.. Frequency assignments are indeed comercially valuable, and regulated carriers make money out of them. > > It then follows that the IP6 address structure and administration must take > care of network operators who are country bound (as per NSAP DCC form) or > supra nationals (mega coms) who are global operators (as per NSAP ICD form).. It follows from the real-world, ITU/etc. regulated practice of allocating frequencies (including delegating allocations to national bodies) that the frequency structure does not need to be country bound, in the sense that frequencies do not carry identifiers. It does follow that an administrative assignment mechanism, orthogonal to the IPv6 address structure, may manage assignment of addresses or frequencies. "Provider" prefixes for IPv6 certainly can be assigned by an administrative mechanism and be bound to countries. They need not be. > > If IPv6 is being designed and administered to be boundless.. it makes it > commercially unusable, unmanageble and somewhat difficult to design global > networks with..And please do not get this statement wrong!.. It is IP6s > addressing scheme and administration that will need to be understood by all. See above. Administration != addressing scheme. > > The Summary I feel should cover the commercial Internet operator issues.. Howard Berkowitz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 17:17:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10732; Mon, 5 Sep 94 17:17:10 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10726; Mon, 5 Sep 94 17:17:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05495; Mon, 5 Sep 94 17:16:07 PDT Received: from drax.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA18467; Mon, 5 Sep 94 17:13:50 PDT Received: from drax.isi.edu by drax.isi.edu (5.65c/5.61+local-16) id ; Mon, 5 Sep 1994 17:13:49 -0700 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) RE: RE: SUMMARY FOR DEBATE- ADDRESSING In-Reply-To: Your message of "06 Sep 1994 08:30:40 +1000." <"940906 08:25:36"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> Date: Mon, 05 Sep 94 17:13:48 PDT Message-Id: <7483.778810428@drax.isi.edu> From: Craig Milo Rogers Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >bill.. > thanks for the response on my summary... However, the point I was making >that in a commercial world one has to have boundaries for administration, >service levels and commercial management.. As per the carriers and service >providors.. As demonstrated by the current commercial IP4 world, one doesn't necessarily need so many different boundaries in an IP-level address. They're unnecessary for normal business practice. >I see a strong relationship with address forms (global ones) and authority >hierarchies (the people that define and own them) and the administration (the >people that operate within the bounds of the addressing space) and the >routing hierarchies (the networks provided by the administrators).. Internet research and experience suggest that the IP-layer address forms should be strongly related to routing heirarchies, if they are related to anything at all. Additional superimposed heirarchy may be convenient for the allocation and administration of blocks of addresses, but this is a second priority function. Also, the distinction you make between "authority" and "administration" may sound superfluous, or even socially undesireable, to many in the United States. >It follows that if Commercial Internet operators are being set up that they >will have to have commercial domains related to their address allocation... >just so they own something and make money out of providing service over this >addressed space.. Since I've negated one of your precepts, this conclusion is no longer justified. Certainly each commercial Internet service provider would have a block of addresses allocated to them. However, there's no particular reason to mark all such blocks with a "commercial domain" indicator, particularly if doing so would degrade routing efficiency. Note: I'm not saying that commercial addresses "can't" be uniformly marked in IP6, or even that they "won't" be so marked. I'n emphasizing that they needn't be marked (fact), and that they oughtn't be (opinion). >It then follows that the IP6 address structure and administration must take >care of network operators who are country bound (as per NSAP DCC form) or >supra nationals (mega coms) who are global operators (as per NSAP ICD form).. Again, IP6 address allocation can "take care" of them by simply allocating a block of addresses to each operator. There's no significant technical requirement that the blocks have some uniform embedded country code or international organization marker. Such codes or markers are probably better off somewhere else, in a security and authentication field, if they must be carried at all. >If IPv6 is being designed and administered to be boundless.. it makes it >commercially unusable, unmanageble and somewhat difficult to design global >networks with..And please do not get this statement wrong!.. It is IP6s >addressing scheme and administration that will need to be understood by all. It certainly doesn't make it commercially unusable. Manageability remains a concern. Designing global networks is probably simplified by the IP6 approach (whatever that ends up being :-). If we can impose a uniform encoding of topological information in the address, we should be able to create highly-efficient network switches that don't need expensive localization. Now. let's consider some positive action. Suppose that there *is* a significant requirement to label all traffic by country of origen or destination, or by commercial vs. governmental entity. Offhand, I can think of two approaches for IP6: 1) include the labeling information (an NSAP, perhaps? :-) in a (new) field in the Authentication Header. 2) define a new header: Provinence Header, or Passport Control Header, or something like that. However, this header would have to incororate its own digest function, or be used in conjunction with the Authentication or Security Headers. to protect against tampering. Craig Milo Rogers ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 17:23:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10766; Mon, 5 Sep 94 17:23:52 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10760; Mon, 5 Sep 94 17:23:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05742; Mon, 5 Sep 94 17:22:49 PDT Received: from drax.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA19342; Mon, 5 Sep 94 17:20:32 PDT Received: from drax.isi.edu by drax.isi.edu (5.65c/5.61+local-16) id ; Mon, 5 Sep 1994 17:20:31 -0700 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) A SUMMARY FOR DEBATE (IPNG - NSAPS) In-Reply-To: Your message of "Mon, 05 Sep 1994 13:50:27 GMT." <3137.bill.simpson@um.cc.umich.edu> Date: Mon, 05 Sep 94 17:20:30 PDT Message-Id: <7622.778810830@drax.isi.edu> From: Craig Milo Rogers Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Finally, as far as Alan has responded to my documentation request of the >deployment of "millions" of NSAP installed base, it has become apparent >that we can relegate NSAP migration somewhere after 5-bit baudot Telex. As you point out, 5-bit baudot is still alive and kicking. Onerous regulatory standardization has made it the required communication medium for governmentally-mandated TDD (Telecommunications device for the deaf) service. Many large commercial and governmental organizations maintain special terminals, modems, and telephone lines dedicated to baudot service. Perhaps someone in comp.dcom.modems or comp.dcom.telecom could provide us with figures on 5-bit baudot units currently in service, and new service installation rates? There may, indeed, be more of them than there are NSAP-type systems. Craig Milo Rogers ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 18:46:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10842; Mon, 5 Sep 94 18:46:13 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10836; Mon, 5 Sep 94 18:46:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07549; Mon, 5 Sep 94 18:45:08 PDT Received: from drax.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA03986; Mon, 5 Sep 94 18:42:51 PDT Received: from drax.isi.edu by drax.isi.edu (5.65c/5.61+local-16) id ; Mon, 5 Sep 1994 18:42:49 -0700 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) A SUMMARY FOR DEBATE (IPNG - NSAPS) In-Reply-To: Your message of "Mon, 05 Sep 1994 13:50:27 GMT." <3137.bill.simpson@um.cc.umich.edu> Date: Mon, 05 Sep 94 18:42:49 PDT Message-Id: <8621.778815769@drax.isi.edu> From: Craig Milo Rogers Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >IPv6 addresses are truly global, and indeed, solar, galactic, and >universal. Boundaries are parochial. I tried holding back, but I just don't have the willpower. One address plan is draft-ietf-sipp-routing-addr-02.txt. I don't see any solar addresses in it. An earlier, 8-byte SIPP address plan is draft-simpson-sipp-64-bit-plan-00.txt. It specifies global regions, but not solar addresses. Another document on IP6 addresses and routing is Subject: Internet Draft on Planetary Aggregation Date: Mon, 22 Aug 94 18:10:46 PDT Message-ID: <16828.777604246@drax.isi.edu> Sender: rogers@drax.isi.edu The SIPP-16 Address Allocation Internet Draft mentions Continental Aggregation as a means for compressing top-level routing exchanges. Clearly, this exhibits a lack of vision. To prevent the kind of routing disaster we've experienced in the past, now is the time to implement Planetary Aggregation. Background: NASA is already using IP networks onboard interplanetary probes. Within the lifetime of IPv6, the economy may possibly recover and interplanetary exploration might resume. Certainly, as Clinton-era crime bills take effect, new prison sites will be needed; due to the "not in my backyard" syndrome, Lunar Federal Penitentiaries are forecast (ref: British colonization of Australia). (Footnote: cost of transporting a prisoner to the Moon, approx. $250,000/each, will be recovered within the first five years due to the reduced security requirements once they get there.) Let's consider the allocation of address space for planetary aggregation. A simple encoding assigns a seperate prefix for each major planetary body and the asteroid belt; let's call this the Bode code: 0 Sun 1 Mercury 2 Venus 3 Earth 4 Mars 5 Asteroids 6 Jupiter 7 Saturn 8 Uranus 9 Neptune 10 Pluto 11 Comets 12-19 reserved for future allocation It would be prudent to reserve two or more bits between this field and the following field, to allow the Interplanetary Engineering Task Force to insert additional planets between existing ones in the future. Each Bode code will be further subdivided according to major satellite and orbital dynamics. For example, for Earth: 0 Earth 1 Low Earth Orbit 2 Clarke Orbit and above 3 Luna, perhaps subdivided by maria 4-8 Lagrangian orbital loci Similarly, one would want to separate Earth-crossing asteroids from main-orbit asteroids, Trojan asteroids, etc. When addressing individual asteroids and comets, the object's International Astronomical Union (IAU) number can be used as an intermediate address prefix. Note: It is important to reserve address space after the IAU number to allow for fragmentation (ref: Comet Swift-Tuttle). Addressing requirements for Saturn's rings are a current research area. Since round-trip times to Saturn exceed the allowable values used by vat, and since sources to vat may *still* be unavailable, it is proposed that the IETF schedule a meeting on Titan in the year 2010 to converse with local authorities. Craig Milo Rogers ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 18:59:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10899; Mon, 5 Sep 94 18:59:43 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10893; Mon, 5 Sep 94 18:59:35 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07775; Mon, 5 Sep 94 18:58:39 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA05865; Mon, 5 Sep 94 18:56:16 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA01496; Tue, 6 Sep 1994 11:56:02 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA07013; Tue, 6 Sep 94 11:50:38 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT01715; Tue, 06 Sep 1994 11:50:36 EST Date: 6 Sep 94 11:53:10 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) SUMMARY -- IP ADDRESSES AND ATM Ua-Content-Id: 940906 11:19:41 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940906 11:19:41 001 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940906115310+1000 deferred 940906115310+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940906114932+1000 deferred 940906114932+1000 action Relayed Message-Id: <"940906 11:19:41"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig MR raised an interesting one from the summary which could be worth progessing formally.. This one had escaped me.. If you want to run IP over switched ATM.. then I assumed that the switches used will conform to I. series recommendations for the ATM bit with Q.2931 for the signalling. Q.2931 permits the called / calling party to be of NSAP or E.164 form.. Therefore if IP addressing is needed to be processed within ATM signalling.. the following approach should be made.. X.300 series ("Internetworking Between Networks, Mobile Data Transmission Systems, Internetwork Management") provides the models for interworking between public data networks and to a lesser degree private ones.. It prescribes a NPI/TOA (Numbering Plan Indicator / Type of Address) identifier for networks.. The ones defined include ISO NSAP, E.164, X.121, etc.. The NPI/TOA use is also referenced in Q.2931 and later versions of X.25 (I believe) . They permit underlying switching devices to understand the nature of the higher level address form.. As ISDN has to. SIf the Internet body wish to formalise IP4 and IP6 address structures with the ISO/ITU so that its forms can be referenced in ISDN and B-ISDN signalling and X.300 they should liaise with SC6 or ITU SG7. Probably this would be useful if the Internet wish to ratify IP6 with ISO because if it would be difficult (i feel) to pass a standard (particularly a network one .. through the formal voting system) without the addressing schemes being internationally workable and available.. (this is just a formal view of the issue though.) In addition to the addressing registration also the other points should be progressed.. eg. Are IP6 addresses needed as an X.400 O/R address for access units or physical delivery.. Is the IP6 address needed to be stored within the X.500 directory.. If so its syntax and matching rules will have to be "imported" into X.500. Because without these definitions "searches for IP addresses" in theory will be impossible.. These definitions should be declared (if the IETF want to) through the liaison mechanism.. Regards Alan @Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 20:47:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11130; Mon, 5 Sep 94 20:47:51 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11124; Mon, 5 Sep 94 20:47:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA09536; Mon, 5 Sep 94 20:46:47 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA18795; Mon, 5 Sep 94 20:44:28 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 6 Sep 94 12:33:03 +0900 From: Masataka Ohta Message-Id: <9409060333.AA14907@necom830.cc.titech.ac.jp> Subject: Re: (IPng) SUMMARY -- IP ADDRESSES AND ATM To: ipng@sunroof.Eng.Sun.COM Date: Tue, 6 Sep 94 12:33:02 JST In-Reply-To: <"940906 11:19:41"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS>; from "/G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au" at Sep 6, 94 11:53 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > If you want to run IP over switched ATM.. then I assumed that the switches > used will conform to I. series recommendations for the ATM bit with Q.2931 > for the signalling. That may occur within a single link layer. > Q.2931 permits the called / calling party to be of NSAP or E.164 form.. NSAP or E.164 here is a MAC address. End-end QoS reservation beyond routers will be done with IP packets, not with Q.2931. > They permit underlying switching devices to understand the nature > of the higher level address form.. As ISDN has to. And what we need is an ATM switch which recognizes IP addresses, works as an IP router and processes IPv6 QoS requirements. That's all. > SIf the Internet body wish to formalise IP4 and IP6 address structures with > the ISO/ITU so that its forms can be referenced in ISDN and B-ISDN signalling > and X.300 they should liaise with SC6 or ITU SG7. ISDN or B-ISDN signalling issues are link layer issues unrelated to IP addresses. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 5 23:20:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11159; Mon, 5 Sep 94 23:20:52 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11153; Mon, 5 Sep 94 23:20:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12058; Mon, 5 Sep 94 23:19:48 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA07729; Mon, 5 Sep 94 23:17:30 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA20475; Tue, 6 Sep 1994 08:17:26 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA17891; Tue, 6 Sep 1994 08:17:24 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409060617.AA17891@dxcoms.cern.ch> Subject: Re: (IPng) Multicast To: ipng@sunroof.Eng.Sun.COM Date: Tue, 6 Sep 1994 08:17:23 +0200 (MET DST) In-Reply-To: <3136.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Sep 5, 94 01:43:38 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 896 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, > Can we outlaw SNAP encoded headers for IPv6, since they can't > possibly align in a mixed environment? > I can see the arguments for this but I think it's impractical. Since IP6 is distinguished from IPv4 by looking at the version # in the first byte, there must be implementation arguments for IP6 and IPv4 to share the link level code point. Also I think that all 802.5 and FDDI driver implementations support *only* LLC format, which means SNAP is more or less compulsory. There is also the lazy argument: by re-using the existing code points for IP (including SNAP), we save work on a whole lot of RFCs. Thanks, Bill, for being one of the few people to discuss technical IP6 issues on this list. I am now deleting around 80% of ipng mail without wasting my time reading it. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 01:57:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11193; Tue, 6 Sep 94 01:57:56 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11187; Tue, 6 Sep 94 01:57:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA14811; Tue, 6 Sep 94 01:56:48 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA00155; Tue, 6 Sep 94 01:54:30 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) IPng and the Smugness of the IETF To: ipng@sunroof.Eng.Sun.COM Date: Tue, 6 Sep 1994 09:51:50 +0200 (BST) In-Reply-To: <01HGQG9VKHRM8YCRAY@delphi.com> from "MARTILLO@delphi.com" at Sep 5, 94 00:54:47 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2726 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >From the standpoint of product development and support, the creation > of two incompatible management standards is a complete disaster and > will ultimately cost network device purchasers (to whom costs are > passed in the end) piles of money. Or the network device purchasers can build stuff themselves cheaply based on easy to implement standards like IP, RIP. I can pick up free routing/bridging filtering tools for IP, free IP stacks that are well tested. From my point of view which is partly as someone paid to write things like routers and partly as someone who maintains the GPL'd network stack for Linux the internet protocols are good because they can be implemented by human beings without a 6 foot thick dictionary of TLA's. I regard that as one of the most important features of the IP and IPng specs. > The PPP specification is outrageously silly because it requires > psychic capabilities on the part of devices (because rather than > providing a reasonable registration capability PPP only provides the > ability to NAK an option request). Apart from the fact that if it worries you then you can add an option registration facility and people with it won't NAK the DO_OPTION_REGISTRATION. You can go out and write it and get it working and spec it now. > interconnectivity can be unachievable even though in the local > environment bridges and routers can be interconnected with hardly any > effort whatsoever. Not my real world experience. Firstly you always specify boxes that can talk to each other and require standards. Secondly they tend to interwork. > Presumably bridges would use a bridging encapsulation while routers > use a networking encapsulation. If a management station is to manage > both bridges and routers over serial connections, presumably it must > support bridging and potentially all network layer encapsulations. This would be an issue if TCP/IP wasn't so trivial and the fact you can go out and buy a TCP/IP stack for almost nothing (or use a free one) in your product. SNMP only needs the very minimal IP support. > makes developing quality products hard and expensive. If the IETF > recapitulates past performances in the specification of IPv6, there > would be good reason to reject the IETF altogether. Well its an option you always have. I've never had problems implementing those areas of IP and the related protocols I've been involved in helping implement. I can get the specifications for free. I can test against other systems easily. I can download other free systems for test purposes. Now trying to develop a product based on most CCITT standards involves a large outlay in documentation and a large outlay in programming and development time. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 06:14:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11385; Tue, 6 Sep 94 06:14:03 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11379; Tue, 6 Sep 94 06:13:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18456; Tue, 6 Sep 94 06:12:53 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA00777; Tue, 6 Sep 94 06:10:35 PDT Received: from relay.imsi.com by wintermute.imsi.com id JAA04729 for ; Tue, 6 Sep 1994 09:10:34 -0400 Received: from snark.imsi.com by relay.imsi.com id JAA06482 for ; Tue, 6 Sep 1994 09:10:33 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA21094; Tue, 6 Sep 94 09:10:32 EDT Message-Id: <9409061310.AA21094@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) A SUMMARY FOR DEBATE (IPNG - NSAPS) In-Reply-To: Your message of "05 Sep 1994 13:12:01 +1000." <"940905 10:35:25"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> X-Reposting-Policy: redistribute only with permission Date: Tue, 06 Sep 1994 09:10:32 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ALAN LLOYD says: > Gentlemen.. > > I wish to provide the following for debate / agreement. I would propose that since Mr. Lloyd still refuses to pay attention to the fact that this is an internet engineering list that the rest of us simply refuse to pay any further attention to him. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 08:03:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11441; Tue, 6 Sep 94 08:03:11 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11435; Tue, 6 Sep 94 08:02:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA23885; Tue, 6 Sep 94 08:02:01 PDT Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA17315; Tue, 6 Sep 94 07:59:44 PDT Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA07097; Tue, 6 Sep 94 10:55:13 EDT Received: from cabernet.wellfleet by wellfleet (4.1/SMI-4.1) id AA12096; Tue, 6 Sep 94 10:53:49 EDT Date: Tue, 6 Sep 94 10:53:49 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9409061453.AA12096@wellfleet> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) A SUMMARY FOR DEBATE (IPNG - NSAPS) Cc: rcallon@pobox.wellfleet.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Just a quick question: When receiving an Email message from an X.400 system, does anyone know how to reply privately to the sender? The difficulty in doing this would seem to be a drawback in the current methods for X.400 to SMTP interoperation. Ross ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 08:27:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11453; Tue, 6 Sep 94 08:27:10 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11447; Tue, 6 Sep 94 08:27:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25867; Tue, 6 Sep 94 08:26:06 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA21506; Tue, 6 Sep 94 08:23:39 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) A SUMMARY FOR DEBATE (IPNG - NSAPS) To: ipng@sunroof.Eng.Sun.COM Date: Tue, 6 Sep 1994 16:20:48 +0200 (BST) In-Reply-To: <9409061453.AA12096@wellfleet> from "Ross Callon" at Sep 6, 94 10:53:49 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 491 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Just a quick question: When receiving an Email message > from an X.400 system, does anyone know how to reply > privately to the sender? The difficulty in doing this > would seem to be a drawback in the current methods for > X.400 to SMTP interoperation. > You hit 'r'. At least with a properly set up PP gateway the reverse X.400 (and X.29 and other mail mappings) do mostly work properly. The UK is blessed 8) with some of this legacy and the current mapping does seem to work. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 09:06:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11470; Tue, 6 Sep 94 09:06:06 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11464; Tue, 6 Sep 94 09:05:59 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00146; Tue, 6 Sep 94 09:05:02 PDT Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA00543; Tue, 6 Sep 94 09:02:44 PDT Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA08005; Tue, 6 Sep 94 11:58:13 EDT Received: from cabernet.wellfleet by wellfleet (4.1/SMI-4.1) id AA13438; Tue, 6 Sep 94 11:56:49 EDT Date: Tue, 6 Sep 94 11:56:49 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9409061556.AA13438@wellfleet> To: iialan@iifeak.swan.ac.uk Subject: Re: (IPng) A SUMMARY FOR DEBATE (IPNG - NSAPS) Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Just a quick question: When receiving an Email message > > from an X.400 system, does anyone know how to reply > > privately to the sender? The difficulty in doing this > > would seem to be a drawback in the current methods for > > X.400 to SMTP interoperation. > > > You hit 'r'. At least with a properly set up PP gateway > the reverse X.400 (and X.29 and other mail mappings) do > mostly work properly. The UK is blessed 8) with some of > this legacy and the current mapping does seem to work. > > Alan Didn't work. My original question was sent using "reply sender", and it replied to the entire IPng working group mailing list. My mailer doesn't seem to know how to respond to a multi-line X.400 address" (not that I blame it!). The message that arrives at my workstation has two "from" lines, one from the IPng mailing list, and one from the original X.400 originator. Someone with one of the X.400 addresses might try sending a test message to me directly, and I could try responding to that. I will also try by responding to exactly the text string that is in the message that I receive, and see if this seems to work. Ross ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 09:53:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11535; Tue, 6 Sep 94 09:53:12 PDT Received: from damrak.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11529; Tue, 6 Sep 94 09:53:04 PDT Received: from damrak (localhost) by damrak.Eng.Sun.COM (5.x/SMI-SVR4) id AA24568; Tue, 6 Sep 1994 09:49:17 -0700 Message-Id: <9409061649.AA24568@damrak.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng) Sending to X.400 addresses... Date: Tue, 06 Sep 1994 09:49:16 -0700 From: Steve Parker Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Since the mailing list software is RFC-822 based, it maintains a list of all addresses on the list, in simple RFC-822 forms. The members of the list are public knowledge, and can be had by sending mail to majordomo@sunroof.eng.sun.com with the body: who ipng Then, search this list for . for an address to send a reply to is the method I would recommend. As a side comment as list maintainer: The X.400 gateways are problematic. I do have problems where: o 'Reply-To:' is ignored, and so postings from X.400 participants sometimes end up in the error pile. I try to salvage them, but the volume of error messages makes this difficult. o X.400 gateways post messages which break many SMTP mailers by sending continued mail headers with more than 1024 characters. Although I forward them, many end up being bounced. o Contacting postmasters at X.400 sites almost never works. As a result I am forced to drop people when their address fails consistently, with no way to notify them or their administrators I have dropped them. I mention these things so that participants on this list better understand and adapt to these difficulties. As always, suggestions for the list administration may be sent to ipng-approval@sunroof.eng.sun.com. Cheers, ~sparker ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 10:12:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11566; Tue, 6 Sep 94 10:12:12 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11560; Tue, 6 Sep 94 10:12:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10491; Tue, 6 Sep 94 10:11:08 PDT Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA14889; Tue, 6 Sep 94 10:07:33 PDT Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Sep 1994 18:07:25 +0100 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Sending to X.400 addresses... In-Reply-To: Your message of "Tue, 06 Sep 94 09:49:16 PDT." <9409061649.AA24568@damrak.Eng.Sun.COM> Date: Tue, 06 Sep 94 18:07:25 +0100 Message-Id: <6220.778871245@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >o Contacting postmasters at X.400 sites almost never works. As a result I am > forced to drop people when their address fails consistently, with no way to > notify them or their administrators I have dropped them. strange - me experience is that SMTPng postmasters in the UK generally respond very helpfully.....but then we use a non-commercially written x.400 implementation:-) speaking of which, when is the first PD IPng going to be out? i thought it was a pre-requisite, at least traditionally, that there were 2-3 inerworking implementations before something got ratified as an Internet Standard, and that one preferrably would be in the Public Domain... maybe the CIS equivalent of ARPA could fund Moscow state university to do one... jon ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 10:33:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11584; Tue, 6 Sep 94 10:33:33 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11578; Tue, 6 Sep 94 10:33:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA13882; Tue, 6 Sep 94 10:32:28 PDT Received: from Mordor.Stanford.EDU ([36.53.0.155]) by Sun.COM (sun-barr.Sun.COM) id AA19392; Tue, 6 Sep 94 10:27:58 PDT Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id KAA19596; Tue, 6 Sep 1994 10:26:15 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 Sep 1994 10:26:20 -0700 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: (IPng) Sending to X.400 addresses... Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 10:07 AM 9/6/94, Jon Crowcroft wrote: >speaking of which, when is the first PD IPng going to be out? i >thought it was a pre-requisite, at least traditionally, that there >were 2-3 inerworking implementations before something got ratified as >an Internet Standard, and that one preferrably would be in the Public >Domain... Jon, the usual, formal rules require 2, fully interoperable implementations before advancing a spec to the SECOND level of standardization (DRAFT) and not the first (PROPOSED). In the case of special, important, and/or difficult specs, that requirement is sometimes moved to the first stage. This has been true for routing protocols and is now true for IPng, I believe. No requirement for public domain (or freely available) code is every made. However, the benefits of such code are well recognized. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 11:03:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11627; Tue, 6 Sep 94 11:03:00 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11621; Tue, 6 Sep 94 11:02:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA18177; Tue, 6 Sep 94 11:01:51 PDT Received: from runix.runit.sintef.no ([129.241.1.5]) by Sun.COM (sun-barr.Sun.COM) id AA25178; Tue, 6 Sep 94 10:57:29 PDT Received: from runit.sintef.no by runix.runit.sintef.no id <23629-0@runix.runit.sintef.no>; Tue, 6 Sep 1994 19:55:42 +0200 Date: Tue, 6 Sep 1994 19:55:39 +0200 (MET DST) From: Steinar Haug To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Sending to X.400 addresses... In-Reply-To: <6220.778871245@cs.ucl.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >o Contacting postmasters at X.400 sites almost never works. As a result I am > > forced to drop people when their address fails consistently, with no way to > > notify them or their administrators I have dropped them. > > strange - me experience is that SMTPng postmasters in the UK generally > respond very helpfully.....but then we use a non-commercially written > x.400 implementation:-) This has nothing to do with IPng, but...having worked as a postmaster for both X.400 and SMTP domains (in a former job), - There is no requirement for X.400 sites to implement a "postmaster" address. This *is* a requirement for SMTP sites. Thus you shouldn't be surprised if mail to postmaster@x400-only-site doesn't work. - Many X.400 sites have implemented a "helpdesk" address, because this is a recommendation from either ITU (formerly CCITT) or EEMA (can't remember which one). Thus you might have better luck with helpdesk@x400-only-site. Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug@runit.sintef.no ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 11:26:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11708; Tue, 6 Sep 94 11:26:58 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11702; Tue, 6 Sep 94 11:26:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA22265; Tue, 6 Sep 94 11:25:55 PDT Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA00399; Tue, 6 Sep 94 11:22:37 PDT Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id LAA20002; Tue, 6 Sep 1994 11:22:03 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 Sep 1994 11:22:05 -0700 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: (IPng) Sending to X.400 addresses... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >- There is no requirement for X.400 sites to implement a "postmaster" >address. This *is* a requirement for SMTP sites. Thus you shouldn't be >surprised if mail to postmaster@x400-only-site doesn't work. Here, we get to distinguish between formal requirements and useful requirements. The formal requirement for the postmaster address is part of RFC822. Hence, your assertion is formally correct. On the other hand, anyone participating in Internet email would do well to follow this convention, since it has proved highly useful. >which one). Thus you might have better luck with helpdesk@x400-only-site. While I would encourage EVERYONE to implement any and all addresses for which there is reasonable convention, I also will note that there is some benefit in having those attach to the Internet add ITS conventions to theirs, rather than requiring the installed base of the Internet to learn the conventions of other systems. Lest my comment be the trigger for flames, I will acknowledge that this is all a sensitive issue and my comment is motivated primarily by the matter of installed user base and dominance of mail traffic than by technical religion. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 11:58:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11742; Tue, 6 Sep 94 11:58:00 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11736; Tue, 6 Sep 94 11:57:53 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (8.6.9/SMI-SVR4) id LAA14125; Tue, 6 Sep 1994 11:54:55 -0700 Received: by kandinsky.Eng.Sun.COM (5.0/SMI-SVR4) id AA12524; Tue, 6 Sep 1994 11:55:03 +0800 Date: Tue, 6 Sep 1994 11:55:03 +0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9409061855.AA12524@kandinsky.Eng.Sun.COM> To: ipng@sunroof, ngtrans@sunroof Subject: (IPng) Draft IPng transition working group charter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A first cut at a charter for the IPng transition working group is included below. We'd like to get comments/suggestions on it. Since there has been such a high volume of mail on the ipng list, I would suggest that the discussion of the transition group's charter take place on the transition group's mailing list (ngtrans@eng.sun.com). You may add yourself to this list by sending mail to "majordomo@eng.sun.com" and including the line: subscribe ngtrans in the body of the message. Bob. DRAFT Charter IPng Transition (ngtrans) ------------------------- Chair(s): Bob Gilligan TBD Internet Area Director(s): Scott Bradner Allison Mankin Mailing lists: General Discussion: ngtrans@sunroof.eng.sun.com To Subscribe: majordomo@sunroof.eng.sun.com (include "subscribe ngtrans" in body of message) Archive: ftp:/playground.sun.com/pub/ngtrans Description of Working Group: The purpose of this group is to design the mechanisms and procedures to support the transition of the Internet from IPv4 to IP6. The work of the group will fall into three areas: * Define the processes by which the Internet will be transitioned from IPv4 to IP6. As part of this effort, the group will produce a document explaining to the general Internet community what mechanisms will be employed in the transition, how the transition will work, the assumptions about infrastructure deployment inherent in the operation of these mechanisms, and the types of functionality that applications developers will be able to assume as the protocol mix changes over time. * Define and specify the mandatory and optional mechanisms that vendors are to implement in hosts, routers, and other components of the Internet in order for the transition to be carried out. Dual-stack, encapsulation and header translation mechanisms must all be defined, as well as the interaction between hosts using different combinations of these mechanisms. The specifications produced will be used by people implementing these IP6 systems. * Articulate a concrete operational plan for transitioning the Internet from IPv4 to IP6. The result of this work will be a transition plan for the Internet that network operators and Internet subscribers can execute. The group will use the Simple SIPP Transition (SST) overview document as the starting point for the IP6 transition. The group will work closely with the main IPng working group and the IPng Address Configuration (addrconf) working group. The group will co-ordinate with the tacit working group. Goals and Milestones: September 94 - Submit Internet-Drafts on the following: - General Overview of Transition. - Specifications of Transition Mechanisms for Hosts and Routers. - Transition Plan for the Internet. November 94 - Revise above Internet-Drafts. December 94 - Submit Internet-Drafts for Proposed Standard. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 12:14:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11766; Tue, 6 Sep 94 12:14:58 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11760; Tue, 6 Sep 94 12:14:46 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA29515; Tue, 6 Sep 94 12:13:49 PDT Received: from vangogh.CS.Berkeley.EDU by Sun.COM (sun-barr.Sun.COM) id AB07292; Tue, 6 Sep 94 12:11:23 PDT Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Alpha.1/8.6.9.Beta0) id MAA07171 for ipng@sunroof.Eng.Sun.COM; Tue, 6 Sep 1994 12:10:53 -0700 (PDT) Date: Tue, 6 Sep 1994 12:10:53 -0700 (PDT) From: Keith Sklower Message-Id: <199409061910.MAA07171@vangogh.CS.Berkeley.EDU> To: -v@vangogh.CS.Berkeley.EDU, ipng@sunroof.Eng.Sun.COM Subject: (IPng) re: PD implementation of IPng Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I'm surprised Ran Atkinson hasn't piped up. We talked at the last IETF about his efforts (towards a BSD compatible prototype), and exchanged some mail subsequently. I checked with the people here, and told him that if he had sample code that would limp along, it could be included in the very final bug-fix release of 4.4-lite (intended for November). He said that the US Government could not copyright code, and was trying to find some way to offer it for public consumption, without leaving it vulnerable to having somebody else come along and assert a copyright on it. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 12:20:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11778; Tue, 6 Sep 94 12:20:32 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11772; Tue, 6 Sep 94 12:20:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA00341; Tue, 6 Sep 94 12:19:27 PDT Received: from nbkanata.newbridge.com by Sun.COM (sun-barr.Sun.COM) id AA08388; Tue, 6 Sep 94 12:17:07 PDT Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.newbridge.com (4.1/SMI-4.1) id AA06184; Tue, 6 Sep 94 14:14:45 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA12978; Tue, 6 Sep 94 14:14:38 EDT Received: by mako.newbridge (4.1/SMI-4.1) id AA28609; Tue, 6 Sep 94 14:13:46 EDT From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9409061813.AA28609@mako.newbridge> Subject: Re: (IPng) SUMMARY -- IP ADDRESSES AND ATM To: ipng@sunroof.Eng.Sun.COM Date: Tue, 6 Sep 1994 14:13:46 -0400 (EDT) In-Reply-To: <"940906 11:19:41"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> from "/G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au" at Sep 6, 94 11:53:10 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 460 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I do not wish to get into this fight on another list, but I felt that some clarification is called for. It is not a foregone conclusion that running IP over ATM requires IP addresses (of any version) in the called/calling party number/subaddress. There are peple who think that is a good iea. I believe that they are VERY wrong. This will be hashed out, again, in the ATM Forum. Thank you, Joel M. halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 12:49:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11798; Tue, 6 Sep 94 12:49:34 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11792; Tue, 6 Sep 94 12:49:26 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03535; Tue, 6 Sep 94 12:48:29 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA14392; Tue, 6 Sep 94 12:46:01 PDT Subject: PD IPng (was: Re: (IPng) Sending to X.400 addresses...) To: J.Crowcroft@cs.ucl.ac.uk, ipng@sunroof2.Eng.Sun.COM Date: Tue, 6 Sep 1994 13:36:35 -0500 (EST) From: Dan McDonald Cc: Dan McDonald , Ran Atkinson X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 948 Message-Id: <9409061836.aa05033@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > speaking of which, when is the first PD IPng going to be out? i > thought it was a pre-requisite, at least traditionally, that there > were 2-3 inerworking implementations before something got ratified as > an Internet Standard, and that one preferrably would be in the Public > Domain... We here at NRL plan to have ours be freely distributable, etc. (although not QUITE in the "public domain" as we wish to have NRL's name plastered all over it. Kinda like the BSD Net/2 and 4.4 Lite distrubution rules, I believe.) Two things must happen first: 1. We have to finish the &(^&*%^$^% thing. With only myself and 1/2 of Ran; it may take a while. 2. Make sure NRL and the rest of the US Govt. says its okay. My trial balloon of S/Key with MD5 seems to have worked, but after all, this is the US Govt. (For example, it is impossible for us to copyright anything. Thank the U.S. Congress for this one. :-P ) Dan McD. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 13:29:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11823; Tue, 6 Sep 94 13:29:38 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11817; Tue, 6 Sep 94 13:29:30 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (8.6.9/SMI-SVR4) id NAA23752; Tue, 6 Sep 1994 13:26:33 -0700 Received: by kandinsky.Eng.Sun.COM (5.0/SMI-SVR4) id AA12578; Tue, 6 Sep 1994 13:26:40 +0800 Date: Tue, 6 Sep 1994 13:26:40 +0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9409062026.AA12578@kandinsky.Eng.Sun.COM> To: ipng@sunroof, ngtrans@sunroof Subject: (IPng) Correction: IPng transition working group mailing list address Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ooops. I gave an incorrect address for the IPng transition working group mailing list in my previous email message. The correct address for the list is "ngtrans@sunroof.eng.sun.com". To join the mailing list, send mail to "majordomo@sunroof.eng.sun.com" and include the line: subscribe ngtrans in the body of your message. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 16:26:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12189; Tue, 6 Sep 94 16:26:18 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12183; Tue, 6 Sep 94 16:26:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA09754; Tue, 6 Sep 94 16:25:12 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA06215; Tue, 6 Sep 94 16:22:51 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA14031; Wed, 7 Sep 1994 09:22:35 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA02098; Wed, 7 Sep 94 09:16:53 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Wed, 07 Sep 1994 09:16:53 EST Date: 7 Sep 94 09:20:56 +1000 To: ipng@sunroof.Eng.Sun.COM, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au Subject: (IPng) IPNG -- PROGRESS MECHANISMS Ua-Content-Id: 940907 08:44:27 P1-Recipient: ipng@sunroof.eng.sun.com, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940907 08:44:27 006 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940907092056+1000 deferred 940907092056+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940907091648+1000 deferred 940907091648+1000 action Relayed Message-Id: <"940907 08:44:27"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday.. gentle folk.. I am new to the way the IETF works so is there any guidelines that one can follow re progressing IPNG and its deployment / migration. eg. Do you have a subject list re (eg.) Addressing Design Philosophy Formats Administration Transistion / Migration Mapping to underlying services (signalling) Interworking (eg NSAPs/IP) Dynamic Allocation Routing Design Philosophy Network Topologies Protocol Design and Algorithms Route Management and Dynamics Interworking (OSPF-IS/IS-ES/IS) QOS QOS specification Interaction - with lower layers Measurement Error Management Security General Model (and Scope) Security Levels and Options Security Services (Authentication / Integrity, etc) Key Management Security Domains Administration Migration / Interworking IP4 -> IP6 IP4 -> CLNP IP6 -> CLNP CLNP -> IP4 CLNP -> IP6 IP4 + IP6 + CLNP Upgrades to SNMP Upgrades to OSPF And any status indications to see what are of priority and could be most effectively worked on... Also I raised the issue of registering IP address syntax with ISO/ITU.. Is this idea .. Off the planet Useful Can be formalised Progressed with current IETF structure. Regards Alan@Oz Re ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 16:28:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12201; Tue, 6 Sep 94 16:28:46 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12195; Tue, 6 Sep 94 16:28:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10195; Tue, 6 Sep 94 16:27:41 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA06807; Tue, 6 Sep 94 16:25:22 PDT Received: from pm002-07.dialip.mich.net (pm002-07.dialip.mich.net [35.1.48.88]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id TAA28159 for ; Tue, 6 Sep 1994 19:25:18 -0400 Date: Tue, 6 Sep 94 23:06:12 GMT From: "William Allen Simpson" Message-Id: <3147.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: Draft IPng transition working group charter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I'd like to object. I've joined the list, but I don't see the need. Isn't there already a tacit list? (I grep'd for it, but couldn't find it.) Or was that just a BOF? > The group will use the Simple SIPP Transition (SST) overview document > as the starting point for the IP6 > transition. > I also object to this. There were other proposals at Tornonto, both of which were simpler than SST, and easier to deploy. I refer you to my own Deployment draft posted to the SIPP list (and posted as a draft whenever Cynthia gets to it). Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 17:38:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12424; Tue, 6 Sep 94 17:38:32 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12418; Tue, 6 Sep 94 17:38:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19453; Tue, 6 Sep 94 17:37:27 PDT Received: from hsdndev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA20042; Tue, 6 Sep 94 17:35:09 PDT Date: Tue, 6 Sep 94 20:35:03 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9409070035.AA24390@hsdndev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: Draft IPng transition working group charter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, There are two transition working groups, ngtrans is designed to fly high & fast & burn out early having done just the IPv4 to IPng transition plan. Tacit is a long term WG, which is to be more concerned with the operator side of things, planning, testing etc. We expect it to stay around for quite a while (moving to the OPS area when the IPng area evaporates) dealing with transition issues as they come up during the actual transition. We recommended that the ngtrans wg start with the sst doc but as with all IETF WGs the actual details are issues for the working group to hash out. Clearly your draft should be part of what the WG evaluates during its deliberations. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 6 17:39:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12440; Tue, 6 Sep 94 17:39:22 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12433; Tue, 6 Sep 94 17:39:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19560; Tue, 6 Sep 94 17:38:18 PDT Received: from efficient.com by Sun.COM (sun-barr.Sun.COM) id AA20156; Tue, 6 Sep 94 17:35:56 PDT Received: from sakana by efficient.com (5.0/SMI-SVR4) id AA00889; Tue, 6 Sep 94 19:34:36 CDT Received: by sakana (931110.SGI/930416.SGI.AUTO) for @efficient:jhalpern@newbridge.com id AA22227; Tue, 6 Sep 94 19:44:18 -0700 From: chase@efficient.com (Chase Bailey) Message-Id: <9409061944.ZM22225@sakana> Date: Tue, 6 Sep 1994 19:44:15 -0700 In-Reply-To: jhalpern@Newbridge.COM (Joel Halpern) "Re: (IPng) SUMMARY -- IP ADDRESSES AND ATM" (Sep 6, 19:29) References: <9409061813.AA28609@mako.newbridge> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) SUMMARY -- IP ADDRESSES AND ATM Cc: chase@efficient.com, jhalpern@newbridge.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Content-Length: 1490 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Sep 6, 19:29, Joel Halpern wrote: > Subject: Re: (IPng) SUMMARY -- IP ADDRESSES AND ATM > I do not wish to get into this fight on another list, but I felt > that some clarification is called for. > > It is not a foregone conclusion that running IP over ATM requires IP > addresses (of any version) in the called/calling party number/subaddress. > There are peple who think that is a good iea. I believe that they are > VERY wrong. This will be hashed out, again, in the ATM Forum. > > Thank you, > Joel M. halpern jhalpern@newbridge.com > Newbridge Networks Inc. > > ------------------------------------------------------------------------------ > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com >-- End of excerpt from Joel Halpern Maybe I missed a lot in the earlier parts of this discussion, but the called/calling party numbers shouldn't be IP. This is bad and will definitely cause problems. I do agree with Joel on this point. -- - arigato gozaimasu, -/chase (Chase Bailey, CTO), -efficient networks, inc. - phone: (214) 991-3884 (ext 314), fax: (214) 991-3887 -"Everything is determined, the begining as well as the end, by forces over - which we have no control. It is determined for the insect as well as the - star. .... we all dance to a mysterious tune, intoned in the distance by - an invisible piper." - Albert Einstein, 1913 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 7 05:10:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13396; Wed, 7 Sep 94 05:10:54 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13390; Wed, 7 Sep 94 05:10:47 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA13122; Wed, 7 Sep 94 05:09:50 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA22648; Wed, 7 Sep 94 05:07:31 PDT Received: from relay.imsi.com by wintermute.imsi.com id IAA06951 for ; Wed, 7 Sep 1994 08:07:22 -0400 Received: from snark.imsi.com by relay.imsi.com id IAA15106 for ; Wed, 7 Sep 1994 08:07:21 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA22414; Wed, 7 Sep 94 08:07:21 EDT Message-Id: <9409071207.AA22414@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) re: PD implementation of IPng In-Reply-To: Your message of "Tue, 06 Sep 1994 12:10:53 PDT." <199409061910.MAA07171@vangogh.CS.Berkeley.EDU> X-Reposting-Policy: redistribute only with permission Date: Wed, 07 Sep 1994 08:07:20 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Keith Sklower says: > I'm surprised Ran Atkinson hasn't piped up. He is on vacation. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 7 11:31:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13709; Wed, 7 Sep 94 11:31:21 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13703; Wed, 7 Sep 94 11:31:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20843; Wed, 7 Sep 94 11:30:17 PDT Received: from interlock.ans.net by Sun.COM (sun-barr.Sun.COM) id AA02606; Wed, 7 Sep 94 11:27:29 PDT Received: by interlock.ans.net id AA18306 (InterLock SMTP Gateway 1.1 for ipng@sunroof.eng.sun.com); Wed, 7 Sep 1994 14:26:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 7 Sep 1994 14:26:37 -0400 Date: Wed, 7 Sep 94 14:26:32 EDT From: Guy Almes To: ipng@sunroof.Eng.Sun.COM Cc: almes@ans.net Subject: Re: PD IPng (was: Re: (IPng) Sending to X.400 addresses...) In-Reply-To: Your message of Tue, 6 Sep 1994 13:36:35 -0500 (EST) Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, Will your IPng work include Gated modules? -- Guy ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 7 17:28:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14129; Wed, 7 Sep 94 17:28:19 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14123; Wed, 7 Sep 94 17:28:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA17846; Wed, 7 Sep 94 17:27:14 PDT Received: from hsdndev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA10912; Wed, 7 Sep 94 17:24:54 PDT Date: Wed, 7 Sep 94 20:24:49 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9409080024.AA28193@hsdndev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPng walkthrough slides Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM FYI - the postscript files for the slides used during the IPng walkthrough on 22 Aug are now on hsdndev.harvard.edu in pub/ipng/walkthru.Aug.94. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 7 19:23:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14165; Wed, 7 Sep 94 19:23:57 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14159; Wed, 7 Sep 94 19:23:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA01470; Wed, 7 Sep 94 19:22:52 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA25458; Wed, 7 Sep 94 19:20:34 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA18565; Wed, 7 Sep 94 19:19:26 -0700 Received: by xirtlu.zk3.dec.com; id AA25299; Wed, 7 Sep 1994 22:19:12 -0400 Message-Id: <9409080219.AA25299@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Suggestions for IPv6 In-Reply-To: Your message of "Mon, 05 Sep 94 02:50:45 GMT." <3130.bill.simpson@um.cc.umich.edu> Date: Wed, 07 Sep 94 22:19:06 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 4) It would be really helpful if the Routing Header had a Length in the > same place as the others. That way, we could simply test for > equality without knowing the format of the contents, and go to the > next header. Pretty Please!?! I would like to have this length too. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 7 20:03:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14202; Wed, 7 Sep 94 20:03:00 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14196; Wed, 7 Sep 94 20:02:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA04205; Wed, 7 Sep 94 20:01:55 PDT Received: from cps202.cps.cmich.edu by Sun.COM (sun-barr.Sun.COM) id AA29509; Wed, 7 Sep 94 19:59:35 PDT Received: (from wilson@localhost) by cps202.cps.cmich.edu (8.6.9/8.6.9) id WAA04064 for ipng@sunroof.Eng.Sun.COM; Wed, 7 Sep 1994 22:50:24 -0400 From: Brad Wilson Message-Id: <199409080250.WAA04064@cps202.cps.cmich.edu> Subject: Re: (IPng) re: PD implementation of IPng To: ipng@sunroof.Eng.Sun.COM Date: Wed, 7 Sep 1994 22:50:23 -0400 (EDT) In-Reply-To: <199409061910.MAA07171@vangogh.CS.Berkeley.EDU> from "Keith Sklower" at Sep 6, 94 12:10:53 pm X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1262 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> I'm surprised Ran Atkinson hasn't piped up. We talked at the last IETF >> about his efforts (towards a BSD compatible prototype), and exchanged >> some mail subsequently. I checked with the people here, and told him >> that if he had sample code that would limp along, it could be included >> in the very final bug-fix release of 4.4-lite (intended for November). I'm also working on an IPv6 implementation that will be publicly available with source (GNU-style license), though it won't be ready by November, and it's being written for Windows/NT and Windows 4.0 in C++. Most of the code is independent of the operating system, so porting should be a pretty simple task (I would hope ;-). Speaking of which ... I'm certain people have already debated te question of applying IPv6 to sockets (though that's not really the IETF charter ;-). Are there any documents available with recommendations for directions? Is anybody using them? Thanks... Brad -- Brad Wilson Crucial Software Share and Enjoy! msg++; smiley++; Internet: wilson@cps201.cps.cmich.edu Speaking for myself and myself alone "i am the bullet in the gun . i am the truth from which you run i am the silencing machine . i am the end of all your dreams" - nin ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 7 23:05:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14248; Wed, 7 Sep 94 23:05:19 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14242; Wed, 7 Sep 94 23:05:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA11815; Wed, 7 Sep 94 23:04:14 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA18183; Wed, 7 Sep 94 23:01:32 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA17806; Thu, 8 Sep 1994 16:00:03 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA04262; Thu, 8 Sep 94 15:50:59 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Thu, 08 Sep 1994 15:50:59 EST Date: 8 Sep 94 15:55:05 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) TO SPARKER FOR SUNROOF.ENG TEST Ua-Content-Id: 940908 15:47:10 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940908 15:47:10 001 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940908155505+1000 deferred 940908155505+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940908155056+1000 deferred 940908155056+1000 action Relayed Message-Id: <"940908 15:47:10"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM sparker is this better I re wrote the address in the address book.. Other wise I will have to find where sunroof is changing to sunroof2 Regards and Thanks Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 8 08:03:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14465; Thu, 8 Sep 94 08:03:22 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14459; Thu, 8 Sep 94 08:03:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA01983; Thu, 8 Sep 94 08:02:16 PDT Received: from postoffice3.mail.cornell.edu by Sun.COM (sun-barr.Sun.COM) id AA14785; Thu, 8 Sep 94 07:59:55 PDT Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id KAA21143 for ; Thu, 8 Sep 1994 10:59:51 -0400 Message-Id: <199409081459.KAA21143@postoffice3.mail.cornell.edu> X-Sender: swb1@postoffice3.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Sep 1994 10:59:55 -0500 To: ipng@sunroof.Eng.Sun.COM From: Scott W Brim Subject: Re: PD IPng (was: Re: (IPng) Sending to X.400 addresses...) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM We (actually our collaborators) have plans for a gated OSPF for IP6, but I can't promise you that it will be done this year. ...Scott At 14:26 9/7/94 -0400, Guy Almes wrote: >Dan, > Will your IPng work include Gated modules? ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 8 08:21:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14477; Thu, 8 Sep 94 08:21:15 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14471; Thu, 8 Sep 94 08:21:07 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AB03769; Thu, 8 Sep 94 08:20:09 PDT Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA18390; Thu, 8 Sep 94 08:17:42 PDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03952; 8 Sep 94 10:47 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-simpson-ipv6-deploy-00.txt Date: Thu, 08 Sep 94 10:47:13 -0400 Message-Id: <9409081047.aa03952@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Deployment Author(s) : W. Simpson Filename : draft-simpson-ipv6-deploy-00.txt Pages : 13 Date : 09/07/1994 This document specifies strategies related to deployment of IPv6, and effects on addressing, configuration, routing and transition. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-simpson-ipv6-deploy-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-simpson-ipv6-deploy-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940907095055.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-ipv6-deploy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-ipv6-deploy-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940907095055.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 8 08:45:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14500; Thu, 8 Sep 94 08:45:50 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14494; Thu, 8 Sep 94 08:45:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA06735; Thu, 8 Sep 94 08:44:46 PDT Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA22956; Thu, 8 Sep 94 08:42:26 PDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04038; 8 Sep 94 10:48 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-simpson-ipv6-discovery-req-00.txt Date: Thu, 08 Sep 94 10:48:42 -0400 Message-Id: <9409081048.aa04038@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Neighbor Discovery -- Design Requirements Author(s) : W. Simpson Filename : draft-simpson-ipv6-discovery-req-00.txt Pages : 13 Date : 09/07/1994 This document discusses the requirements for identification of and forwarding to adjacent IPv6 nodes. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-simpson-ipv6-discovery-req-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-simpson-ipv6-discovery-req-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940907151100.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-ipv6-discovery-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-ipv6-discovery-req-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940907151100.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 8 10:58:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14713; Thu, 8 Sep 94 10:58:00 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14654; Thu, 8 Sep 94 10:48:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA26774; Thu, 8 Sep 94 10:47:04 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA19763; Thu, 8 Sep 94 10:44:36 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Thu, 8 Sep 1994 18:43:19 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Thu, 8 Sep 1994 15:23:38 +0100 Date: Thu, 8 Sep 1994 15:23:38 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003667] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3667 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3667*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: sob@hsdndev.harvard.edu, brian.carpenter@cern.ch, bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Cc: rjthomas@bnr.ca, /G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@pipex.net Subject: (IPng) Numbers of NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Scott It's gone very quiet on the majordomo list - has the plug been pulled? To be on the safe side I have mailed to a few people personally as well so - sorry if some of you get two copies!! Numbers of NSAPS I now have some indications from my sources that we are looking at upwards of 1 million 20 byte NSAP addresses in Local Government, Public Corporations and Central Government in the UK (including defence and other related). If we add large recently Privatised Corporations (electricity, gas, water, rail, etc.) and those traditionally non-public sector UK corporations who followed the GOSIP lead we must be looking at 1.25 million in the UK alone. I do not seem to be able to get any figures out of my contacts in the rest of Europe - as you will understand the information on numbers and placements is very sensitive, particularly in Central Government and especially in defence!, and you need to be pretty close to get anything at all! This is probably why previous estimates have been so low. However, it is well known that the EEC edict, which demands that all purchases over 100,000 ECUs (150,000 dollars) in the public sector must be OSI, has caused a similar pattern of procurement in Europe. Hence, by extrapolation, we must be looking well North of 5 million NSAP terminations in Europe and maybe double that. These are sure to be modelled in most cases on the UK GOSIP 20 byte structure because of the EWOS influence. Furthermore, the current UK GOSIP strategy is that all TCP/IP systems installed (and all upgrades) should be migrated to OSI over 5 years. Initially the IP4 address will be embedded in a standard 20 byte NSAP and migrated to a full NSAP address after migration. This policy could change but, if carried, would increase the full 20 byte NSAP addresses still further. This policy could also spill over into the EEC. I have no figures at all for North America or the Pacific Rim and there are others who are better placed than I to get them. The upshot of all this is that this estimate for Europe alone is looking like an order different from the original hypothesis that there are only 500,000 NSAP terminations 'out there', which was dismissed as so trivial that the IETF doesn't need to concern itself with the 20 byte NSAP problem. I would like your reaction to these figures! Jack Houldsworth ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 8 11:12:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14736; Thu, 8 Sep 94 11:12:49 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14730; Thu, 8 Sep 94 11:12:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AB01348; Thu, 8 Sep 94 11:11:43 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA25793; Thu, 8 Sep 94 11:09:03 PDT Received: from relay.imsi.com by wintermute.imsi.com id OAA10051 for ; Thu, 8 Sep 1994 14:08:44 -0400 Received: from snark.imsi.com by relay.imsi.com id OAA26163 for ; Thu, 8 Sep 1994 14:08:44 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA24572; Thu, 8 Sep 94 14:08:43 EDT Message-Id: <9409081808.AA24572@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Numbers of NSAPs In-Reply-To: Your message of "Thu, 08 Sep 1994 15:23:38 BST." <"3667*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> X-Reposting-Policy: redistribute only with permission Date: Thu, 08 Sep 1994 14:08:43 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM J.Houldsworth@ste0906.wins.icl.co.uk says: > I now have some indications from my sources that we are > looking at upwards of 1 million 20 byte NSAP addresses The decision to go with 16 byte IPng addresses was made and is final. We have other work to do. Can we please get on with it? Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 8 11:15:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14765; Thu, 8 Sep 94 11:15:52 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14759; Thu, 8 Sep 94 11:15:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA01900; Thu, 8 Sep 94 11:14:47 PDT Received: from hsdndev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA26296; Thu, 8 Sep 94 11:11:11 PDT Date: Thu, 8 Sep 94 14:10:23 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9409081810.AA24763@hsdndev.harvard.edu> To: J.Houldsworth@ste0906.wins.icl.co.uk, bound@zk3.dec.com, brian.carpenter@cern.ch, ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: Numbers of NSAPs Cc: /G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@pipex.net, rjthomas@bnr.ca Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, Can you provide documentation to back up the numbers, they are interesting. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 8 11:41:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14830; Thu, 8 Sep 94 11:41:01 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14824; Thu, 8 Sep 94 11:40:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA06407; Thu, 8 Sep 94 11:39:57 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA01908; Thu, 8 Sep 94 11:37:03 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Numbers of NSAPs To: ipng@sunroof.Eng.Sun.COM Date: Thu, 8 Sep 1994 21:43:44 +0200 (BST) In-Reply-To: <"3667*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> from "J.Houldsworth@ste0906.wins.icl.co.uk" at Sep 8, 94 03:23:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1869 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I now have some indications from my sources that we are > looking at upwards of 1 million 20 byte NSAP addresses > in Local Government, Public Corporations and Central > Government in the UK (including defence and other > related). If we add large recently Privatised The defence people are also all on the internet. All current/future aims for these people need to be checked out. Most you will find like the universities are on the internet and I suspect don't want OSI, are sick of OSI and wish it to go away. I suspect the number of NSAP's needing conversion is therefore much lower as many are duplicated solely for the politics. > Corporations (electricity, gas, water, rail, etc.) and > those traditionally non-public sector UK corporations > who followed the GOSIP lead we must be looking at 1.25 > million in the UK alone. The rail people I can investigate now.. "Not a lot [of OSI]. Lots of X.25 however and mostly closed proprietary systems." [Thats an unofficial not to go off list quote for a senior consultant...] > Furthermore, the current UK GOSIP strategy is that all > TCP/IP systems installed (and all upgrades) should be > migrated to OSI over 5 years. Initially the IP4 The UK DTI seems to have dropped OSI from its requirements and is 'open systems' now. Fortunately! That there may be big OSI groups remaining is a good case. You might want to talk to 'The European MAP/TOP user group' and see if they have good figures. I can't think of a better bet. [Email me if you cant find contact info] > I would like your reaction to these figures! Interesting. I still suspect that it's mostly a political problem not an insurmountable one. Will GATT force the EEC to drop any silly rules ? Alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 8 12:11:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14889; Thu, 8 Sep 94 12:11:12 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14873; Thu, 8 Sep 94 12:11:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA11126; Thu, 8 Sep 94 12:10:02 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA07921; Thu, 8 Sep 94 12:07:39 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Thu, 8 Sep 1994 19:13:40 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Thu, 8 Sep 1994 19:06:49 +0100 Date: Thu, 8 Sep 1994 19:06:49 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003676] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3676 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3676*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Numbers of NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Scott It's gone very quiet on the majordomo list - has the plug been pulled? To be on the safe side I have mailed to a few people personally as well so - sorry if some of you get two copies!! Numbers of NSAPS I now have some indications from my sources that we are looking at upwards of 1 million 20 byte NSAP addresses in Local Government, Public Corporations and Central Government in the UK (including defence and other related). If we add large recently Privatised Corporations (electricity, gas, water, rail, etc.) and those traditionally non-public sector UK corporations who followed the GOSIP lead we must be looking at 1.25 million in the UK alone. I do not seem to be able to get any figures out of my contacts in the rest of Europe - as you will understand the information on numbers and placements is very sensitive, particularly in Central Government and especially in defence!, and you need to be pretty close to get anything at all! This is probably why previous estimates have been so low. However, it is well known that the EEC edict, which demands that all purchases over 100,000 ECUs (150,000 dollars) in the public sector must be OSI, has caused a similar pattern of procurement in Europe. Hence, by extrapolation, we must be looking well North of 5 million NSAP terminations in Europe and maybe double that. These are sure to be modelled in most cases on the UK GOSIP 20 byte structure because of the EWOS influence. Furthermore, the current UK GOSIP strategy is that all TCP/IP systems installed (and all upgrades) should be migrated to OSI over 5 years. Initially the IP4 address will be embedded in a standard 20 byte NSAP and migrated to a full NSAP address after migration. This policy could change but, if carried, would increase the full 20 byte NSAP addresses still further. This policy could also spill over into the EEC. I have no figures at all for North America or the Pacific Rim and there are others who are better placed than I to get them. The upshot of all this is that this estimate for Europe alone is looking like an order different from the original hypothesis that there are only 500,000 NSAP terminations 'out there', which was dismissed as so trivial that the IETF doesn't need to concern itself with the 20 byte NSAP problem. I would like your reaction to these figures! Jack Houldsworth ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 8 12:34:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14923; Thu, 8 Sep 94 12:34:07 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14917; Thu, 8 Sep 94 12:33:59 PDT Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id MAA19290; Thu, 8 Sep 1994 12:30:55 -0700 Date: Thu, 8 Sep 1994 12:30:55 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <199409081930.MAA19290@jurassic.Eng.Sun.COM> To: J.Houldsworth@ste0906.wins.icl.co.uk Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <"3676*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> Subject: (IPng) Numbers of NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, > It's gone very quiet on the majordomo list - has the > plug been pulled? To be on the safe side I have mailed > to a few people personally as well so - sorry if some > of you get two copies!! The list is alive and well. It is not the "majordomo" list. It is the IPNG list. Majordomo is the name of the software which manages subscriptions to the list. In the future if you have administrative questions about the list send them to ipng-owner@sunroof.eng.sun.com. Please do not sent them to the list. Also, you do not need to send duplicate copies of your messages to the list. I will send you a separate message with a complete set of instructions. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 8 12:44:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14939; Thu, 8 Sep 94 12:44:51 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14933; Thu, 8 Sep 94 12:44:43 PDT Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id MAA19720; Thu, 8 Sep 1994 12:41:44 -0700 Date: Thu, 8 Sep 1994 12:41:44 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <199409081941.MAA19720@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) [ipng' mailing list passes the 500 member mark...] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, The IPng list now has over 500 entries (which includes a number of exploders). I wonder if it is growing faster than the Internet.... I would like to urge everyone, give the size of the list, that they use some restraint when posting to the list. Bob ------- Start of forwarded message ------- From: Steve Parker To: hinden@damrak Subject: 'ipng' mailing list passes the 500 member mark... Date: Thu, 08 Sep 1994 10:16:56 -0700 The IETF IPng mailing list surpassed 500 entries yesterday, September 7th. The count today is 504 entries, of which 27 are obvious exploders with an unknown number of subscribers. The addresses represent 30 top level domains: au be ca ch com de dk edu ee fi fr gb gov il in int it jp kr mil net nl no org pt se sg uk us za Cheers, ~sparker ------- End of forwarded message ------- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 8 15:50:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15112; Thu, 8 Sep 94 15:50:25 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15106; Thu, 8 Sep 94 15:50:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15046; Thu, 8 Sep 94 15:49:19 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA24784; Thu, 8 Sep 94 15:46:57 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA22941; Fri, 9 Sep 1994 08:46:52 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA05334; Fri, 9 Sep 94 08:41:13 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Fri, 09 Sep 1994 08:41:12 EST Date: 9 Sep 94 08:44:46 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) ALAN'S CONFESSION Ua-Content-Id: 940909 08:34:02 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940909 08:34:02 005 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940909084446+1000 deferred 940909084446+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940909084037+1000 deferred 940909084037+1000 action Relayed Message-Id: <"940909 08:34:02"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Gday, Gentlefolk.. I am sorry for confusing the mailing list topics so I will move the non technical stuff to big Internet.. Thanks for the candid input... I will attempt to do some review on SIPP and NSAP docs over the next few days and provide constructive comments.. Also apologies to the ladies on the group for using gender specific introductions .. I will use "gday" in future.. Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 8 21:31:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15257; Thu, 8 Sep 94 21:31:14 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15251; Thu, 8 Sep 94 21:31:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10386; Thu, 8 Sep 94 21:30:08 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA02405; Thu, 8 Sep 94 21:27:46 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA04821; Fri, 9 Sep 1994 14:27:19 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA05536; Fri, 9 Sep 94 12:02:46 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Fri, 09 Sep 1994 12:02:45 EST Date: 9 Sep 94 12:06:46 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) REQUEST FOR SIPP-ROAD AND SIPP-ICMP Ua-Content-Id: 940909 11:59:34 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940909 11:59:34 010 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940909120646+1000 deferred 940909120646+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940909120241+1000 deferred 940909120241+1000 action Relayed Message-Id: <"940909 11:59:34"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday all I have not got ftp access yet.. so can some one mail me Sipp Road and Sipp ICMP.. or tell me how to get them.. Many Thanks and Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 8 21:31:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15269; Thu, 8 Sep 94 21:31:58 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15263; Thu, 8 Sep 94 21:31:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA10417; Thu, 8 Sep 94 21:30:53 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA02447; Thu, 8 Sep 94 21:28:31 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA04832; Fri, 9 Sep 1994 14:27:57 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA05746; Fri, 9 Sep 94 14:20:26 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Fri, 09 Sep 1994 14:20:25 EST Date: 9 Sep 94 14:24:28 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) FIRST THOUGHTS ON SIPP Ua-Content-Id: 940909 12:30:01 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940909 12:30:01 019 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940909142428+1000 deferred 940909142428+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940909142023+1000 deferred 940909142023+1000 action Relayed Message-Id: <"940909 12:30:01"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday.. have reviewed the Sipp doc .. and note the review is my interpretation of the text.. I see some of you have implemented it so I may be covering old stories.. I will do a few of these responses.. to separate addressing issues for migration issues or just protocol review.. Here goes. An Objective appraisal... Types used in the comments are E=Editorial, T=Technical, X=? 1. Addressing.. I will cover that in a separate response.. 2. Section .. 4 Type: E Clarification Add "held in the previous Next Header field" to the end of the 2nd sentence. 3. Section .. 4.2 Type: E Clarification The use of the word Option in both the "Options" and the sub fields is confusing.. The term "Parameter" or "Argument" for the fields of the Option would provide greater distinction. 4. Section .. 4.3 (and others) Type: E Correction The Definition of Next Header.. "8 bit selector. Identifies the type of header immediately following this header. The Id values are as for the options as specified in this RFC or that ... RFC - 1340" (I assume 1340 does not specify SIPP options) 5. Section .. 4.3 - general consistency in length specifications. Type: T Comment The Hdr Ext Len field specifies 8 octet units less the first 8 octets for Hop BY Hop and End to End Options.. whereas all other options (Routing, option parameters, Authorisation, etc have exact length specifications.. eg. For error checking and robustness.. zero length fields are treated as such. Is there a reason for this. 6. Section .. 4.4 Type T Comment The routing header mechanism.. Is it open to misuse such as originator designed loops.. Does the Hop Limit catch such characteristics.. Should the hop count be refreshed on change of Dest Address? ie. Theoretical point.. One can specify 255 Addresses and 255 Hops. This permits one router per Address Hop. (Hopefully no one would do this but I assume one day some one will) .. Also I assume that some testing gets done with Routing Headers and Hop counts..and this case should be included. Also the comment "It is expected..additional types...more sophisticated routing alternatives".. last sentence.. I always find these comments a worry...They leave things open to re engineering the total network. 7. Section .. 4.6 Type X Comment I am not sure what this authentication is trying to achieve.. The term Authenticate is generally used to prove who some one is by a signature or password..I can assume one or two options from the text.. the authentication is between the end system and the routers (and the other end system) or just between the end systems. In the first case the routers need to understand a security domain and be configured with the originators security data..In the second case there is just a need to transfer "security data" before the payload. Not having a copy of Sipp_Auth.. I will just add the following.. Security Assoc Id.. "identifies the receivers" is this the routers or the end system(s).. Authentication Data... "its integrity" What Integrity? is it of the payload or the payload and the hop by hop options(when selected for integrity checks) . Because this mechanism cannot provide integrity to the SIPP header simply because it is updated in transit (hop counts and dest addresses if routing opts are used.. Also the route opts are updated).. If it is the integrity of the hop by hop options and the payload and security is applied to the router network.. then each router will have to recalculate "integity" including the options on every hop..not a good idea! I suppose the confusion arrises by having a specification that provides a feel of authentication and then specifies optional parameters (hop by hop) that can be either be included or excluded from the authentication process but not actually specifying whats actually being protected in the hop by hop options.. Certainly, implementing such an open ended security regime.. will be any bodies guess.. I obviously seek clarification.. Last point .. the field marked "payload type" should be Next option if the order of options as specified in 4.1 apply.. 8. Section .. 6 Type: XXXXXXXXXXXXXXXXXXXXXX Comments This one defies gravity! sorry this is an option beyond the scope of this document! Flow Ids are assigned by the source.. used by hashing in the routers.. assigned by the originator on demand... life time - any bodies guess.. state machines (but no states declared).. The whole concept defined (defined?) here is one that relies on originator specification and a high degree on interaction (on a single service basis) with each node in the network. >From a networks nodes point of view the whole concept relies on high node latency.. eg prioritorising packets "from the same source".. Wheras a router or switch is a lot more predicatble if priority and flow parameters are universally defined and applied in the local context. Also.. "There is no relative ordering between the flow controlled and non flow controlled.." does this mean an unattened mail message can get better priority than LF Audio.. This one (in my opinion is broken on the drawering board).. Whats wrong with the Type of Service field from the old IP (with a few adjustments). Simply because migration will be easier.. It can be processed relative to the nodes resources, It will make integration easier with ..., It will be much more aligned to the routing metrics of the current routing metrics and QOS specifications.. And (most of all) it can be implemented and tested! DIAGNOSTICS I am a great believer in "droppings".. that show the way.. It would be nice to have a Option where the transit router(s) could plant its Id so that source / destination hop testing and route determination can be performed. eg A single length (empty field is provided at the source which is refurbished at every hop... Or is this a candidate for Hop by Hop?? Closing I will continue to review.. but I am not sure of the process for the above.. Is there a "mail debate" or are these comments recorded formally for review and sign off.. The issue I see with Sipp (barring the fact I was continually informed that variable address headers (like NSAPs) are bad news for processing and to me SIPP with its options does look worse) is the open ended nature of it and therefore the openedness of router processing functions.. Specifing "Hop by Hop" and "End by End" options that will affect latency, routing, reliability, integrity and testing, etc.. AND not giving indications on what they are for does not make a good robust protocol specification.. Hopefully some ideas are in the tubes on this.. if so please send Regards (Objectively) Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 9 16:30:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16018; Fri, 9 Sep 94 16:30:58 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16012; Fri, 9 Sep 94 16:30:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA13429; Fri, 9 Sep 94 16:29:52 PDT Received: from post.demon.co.uk by Sun.COM (sun-barr.Sun.COM) id AA17788; Fri, 9 Sep 94 05:54:23 PDT Received: from peeras.demon.co.uk by post.demon.co.uk id aa21733; 9 Sep 94 13:48 GMT-60:00 Date: Fri, 09 Sep 94 11:28:16 GMT From: Phil Royse Message-Id: <1717@peeras.demon.co.uk> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Numbers of NSAPs X-Mailer: PCElm 1.09 Lines: 108 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, I have a few comments about your estimates for the number of NSAPs for the UK (I have no experience of the European market). (However, I have worked on developement of the several NSAP address schemes for the UK's National Health Service, and one scheme for govt. depts. in Northern Ireland.) In message <"3667*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> J.Houldsworth@ste0906.wins.icl.co.uk writes: > > Numbers of NSAPS > > I now have some indications from my sources that we are > looking at upwards of 1 million 20 byte NSAP addresses > in Local Government, Public Corporations and Central > Government in the UK (including defence and other > related). But these are only theoretical, in the sense that they are conditional upon those UK public sector users ever installing any GOSIP conformant (or OSI) transport systems. (And this is just not happening in the UK). > If we add large recently Privatised > Corporations (electricity, gas, water, rail, etc.) and > those traditionally non-public sector UK corporations > who followed the GOSIP lead we must be looking at 1.25 > million in the UK alone. I am not aware of any large corporations following GOSIP (in the sense of actually installing any). > However, it is well known that the EEC edict, which > demands that all purchases over 100,000 ECUs (150,000 > dollars) in the public sector must be OSI, EC/87/95 requires that international or European standtad are "referenced" in public sector procurements. It does not specify "OSI". But, moreover, there have been more non-OSI systems (typically using TCP/IP as their transport) purchased by public sector bodies in the UK since EC/867/95, than OSI-based ones. > .. similar pattern of procurement in Europe. Hence, by > extrapolation, we must be looking well North of 5 > million NSAP terminations in Europe and maybe double > that. I disagree. I estimate only in the low tens of thousands of OSI transport entities have NSAPs configured into them, and are *actually operational** in the UK today. The prognoses for incresed purchase of OSI systems is not very high either. > These are sure to be modelled in most cases on > the UK GOSIP 20 byte structure because of the EWOS > influence. Maybe not 20 octets. For example, the NHS has selected 16 octets (partly because it has registered its own UK Domain Indentifier (103) and doesn't need to fit into the HM Govt domain ID (104). > Furthermore, the current UK GOSIP strategy is that all > TCP/IP systems installed (and all upgrades) should be > migrated to OSI over 5 years. Initially the IP4 > address will be embedded in a standard 20 byte NSAP and > migrated to a full NSAP address after migration. Yes. I have read this GOSIP transition document, which I believe to be very misguided in a number of areas. Among other mistakes, it prevents NSAPs from having the correct syntax as recommended/specified in ISO 10589 (Ross?) for good IS-IS routing. (Or for autoconfiguring the SID etc.) Also, the CCTA/GOSIP strategy to migrate TCP/IP systems to OSI over five years is wholly unrealistic and can only lose credibility for the CCTA. (The document in question is dated May 1992 and has now therefore only three years of the five left to complete the migration to OSI). I am certain that the TCP/IP systems being successfully installed currently in the public sector, will continue with that transport architecture for the foreseeable future (5, 7 10 years &c..) > This > policy could change but, if carried, would increase the > full 20 byte NSAP addresses still further. This policy > could also spill over into the EEC. > > The upshot of all this is that this estimate for Europe > alone is looking like an order different from the > original hypothesis that there are only 500,000 NSAP > terminations 'out there', which was dismissed as so > trivial that the IETF doesn't need to concern itself > with the 20 byte NSAP problem. > > I would like your reaction to these figures! > > Jack Houldsworth I think that the IETF's original hypothesis is likely to be about right. There is a trivial amount of OSI transport 'out there' in the UK. (Trivial equals a few thousand...) -- Phil Royse | Comms Consultant. TUDOR HOUSE | proyse@peeras.demon.co.uk 12 Woodside Road Purley, Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 9 17:53:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16059; Fri, 9 Sep 94 17:53:21 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16053; Fri, 9 Sep 94 17:53:12 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA26200; Fri, 9 Sep 94 17:52:15 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA26244; Fri, 9 Sep 94 00:30:17 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA11067; Fri, 9 Sep 1994 17:29:41 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA06128; Fri, 9 Sep 94 17:24:06 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Fri, 09 Sep 1994 17:24:05 EST Date: 9 Sep 94 17:27:28 +1000 To: ipng@sunroof.Eng.Sun.COM, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au Subject: (IPng) ADDRESSSING..A START Ua-Content-Id: 940909 15:39:55 P1-Recipient: ipng@sunroof.eng.sun.com, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940909 15:39:55 030 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940909172728+1000 deferred 940909172728+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940909172321+1000 deferred 940909172321+1000 action Relayed Message-Id: <"940909 15:39:55"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday, Re the addressing of IP4,6 and NSAPs.. Firstly before any comments are made on which one is best or most political or most idealistic we all have to take the view that both IP4/IP6 and NSAPs are going to exist (regardless of perceptions of the future and regardless of the counts today).. ie we wont do NSAPs because there are more IP4 addresses than NSAPs in use.. But there are more NSAPs than IP 6 in use.. so what? All must be accomodated. We must also accept that the address selection (and therefore the network architecture) philosophy is. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 10 02:39:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16116; Sat, 10 Sep 94 02:39:30 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16110; Sat, 10 Sep 94 02:39:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA06536; Sat, 10 Sep 94 02:38:24 PDT Received: from ecrc.de by Sun.COM (sun-barr.Sun.COM) id AA02116; Fri, 9 Sep 94 01:04:28 PDT Received: from scorpio.ecrc.de by ecrc.de with SMTP id AA20158 ( for ); Fri, 9 Sep 1994 10:03:18 +0200 Received: from acrab25.ecrc.de by scorpio.ecrc.de (4.1/SMI-3.2) id AA06888; Fri, 9 Sep 94 10:03:17 +0200 Date: Fri, 9 Sep 94 10:03:17 +0200 From: Dave Morton Message-Id: <9409090803.AA06888@scorpio.ecrc.de> To: bound@zk3.dec.com, brian.carpenter@cern.ch, ipng@sunroof.Eng.Sun.COM, sob@hsdndev.harvard.edu Subject: Re: (IPng) Numbers of NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > However, it is well known that the EEC edict, which > demands that all purchases over 100,000 ECUs (150,000 > dollars) in the public sector must be OSI, has caused > a similar pattern of procurement in Europe. Hence, by > extrapolation, we must be looking well North of 5 > million NSAP terminations in Europe and maybe double > that. These are sure to be modelled in most cases on > the UK GOSIP 20 byte structure because of the EWOS > influence. Jack - is this "edict" still in place - I thought it was scrapped about a year ago ? On another point I find it strange that the German parliment, most of the state parliments, utility companies, defence and even the Telekom internally have some of the biggest IP networks in Europe (at least here in Germany). I don't know of anyone seriously using NSAPs but I could be completely wrong of course... Dave ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 10 04:16:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16149; Sat, 10 Sep 94 04:16:52 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16143; Sat, 10 Sep 94 04:16:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA07973; Sat, 10 Sep 94 04:15:45 PDT Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA25345; Fri, 9 Sep 94 00:26:01 PDT Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 9 Sep 1994 08:25:48 +0100 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Numbers of NSAPs Date: Fri, 09 Sep 94 08:25:47 +0100 Message-Id: <486.779095547@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Numbers of NSAPS > > I now have some indications from my sources that we are > looking at upwards of 1 million 20 byte NSAP addresses > in Local Government, Public Corporations and Central > Government in the UK (including defence and other > related). If we add large recently Privatised > Corporations (electricity, gas, water, rail, etc.) and > those traditionally non-public sector UK corporations > who followed the GOSIP lead we must be looking at 1.25 > million in the UK alone. this is probably realistic - i did some consulting with the UK DSS and a couple of large companies in the UK, and extrapolating, i'd say you are probably a tad low... however, note that while there are 194293 DNS registered IP hosts in the UK, these are 90% in the ac.uk. domain; a realistic estimate of the real number of hosts with internet access in that domain alone can be made by extrapolating from the fact that for example my university has 300 registered hosts, but in fact 6000 on the net. Then factor in the number of multi-national commercial sites who find UK and European GOSIP fairly irrelevant (as do swift:-) i would guess that IPv4 dominates by quite a bit.... also, i nterms of traffic (and therefore telco revenue, and corporate and public benefit) check out what protocols run on the wires - on the UK-US links i know of, it is certainly 70% + IPv4. > Furthermore, the current UK GOSIP strategy is that all > TCP/IP systems installed (and all upgrades) should be > migrated to OSI over 5 years. Initially the IP4 > address will be embedded in a standard 20 byte NSAP and > migrated to a full NSAP address after migration. This > policy could change but, if carried, would increase the > full 20 byte NSAP addresses still further. This policy > could also spill over into the EEC. clearly, UK GOSIP should be re-formulated to say that we wil lconverge on the best technical non-propietary thing availalbe at anyone time at the appropriate rate. > The upshot of all this is that this estimate for Europe > alone is looking like an order different from the > original hypothesis that there are only 500,000 NSAP > terminations 'out there', which was dismissed as so > trivial that the IETF doesn't need to concern itself > with the 20 byte NSAP problem. clearly the NSAP/IP6 problem needs "addressing"< but i thought brian carpenter had this in hand... jon ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 11 08:27:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16361; Sun, 11 Sep 94 08:27:29 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16349; Sun, 11 Sep 94 08:27:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA11561; Sun, 11 Sep 94 08:26:17 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA21949; Sun, 11 Sep 94 08:23:54 PDT Received: from pm002-24.dialip.mich.net (pm002-24.dialip.mich.net [35.1.48.105]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA23668 for ; Sun, 11 Sep 1994 11:23:50 -0400 Date: Sun, 11 Sep 94 14:05:43 GMT From: "William Allen Simpson" Message-Id: <3171.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-simpson-ipv6-hc-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Cynthia forgot to CC this list: Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09165; 9 Sep 94 15:33 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09078; 9 Sep 94 15:32 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:@MorningStar.Com ; Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-simpson-ipv6-hc-00.txt Date: Fri, 09 Sep 94 15:32:27 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-Id: <9409091532.aa09078@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Header Compression Author(s) : W. Simpson Filename : draft-simpson-ipv6-hc-00.txt Pages : 26 Date : 09/08/1994 This document describes a mechanism to improve IP performance over low and medium speed (300 bps to 155.2 Kbps and beyond) point-to-point links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-simpson-ipv6-hc-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-simpson-ipv6-hc-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940908153739.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-ipv6-hc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-ipv6-hc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940908153739.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 11 12:52:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16452; Sun, 11 Sep 94 12:52:48 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16444; Sun, 11 Sep 94 12:52:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA15840; Sun, 11 Sep 94 12:51:42 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA01804; Sun, 11 Sep 94 12:49:19 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA03640; Sun, 11 Sep 1994 21:49:13 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA01490; Sun, 11 Sep 1994 21:49:11 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409111949.AA01490@dxcoms.cern.ch> Subject: Re: (IPng) Numbers of NSAPs To: ipng@sunroof.Eng.Sun.COM Date: Sun, 11 Sep 1994 21:49:10 +0200 (MET DST) In-Reply-To: <486.779095547@cs.ucl.ac.uk> from "Jon Crowcroft" at Sep 9, 94 08:25:47 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 616 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, As I recall, UK-GOSIP primarily recommended TP0 over CONS over X.25, with CLNP as a secondary recommendation. The domain of discourse is IP6, hopefully the successor to CLNP as well as to IPv4. This leads to two precise questions. Can you estimate how many of the 1.25M systems you refer to are currently running CLNP as their main network layer protocol? Can you also clarify how many of those systems, running CLNP, use NSAP addresses that cannot be mapped as in the Carpenter/Bound Internet Draft? Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 11 15:10:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16516; Sun, 11 Sep 94 15:10:07 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16510; Sun, 11 Sep 94 15:09:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA19964; Sun, 11 Sep 94 15:09:01 PDT Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA06537; Sun, 11 Sep 94 15:06:38 PDT Received: from [45.250.200.161] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id PAA18069; Sun, 11 Sep 1994 15:06:31 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 11 Sep 1994 17:06:34 -0500 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: (IPng) Numbers of NSAPs Cc: sob@hsdndev.harvard.edu, brian.carpenter@cern.ch, bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, rjthomas@bnr.ca, /G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@pipex.net Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, What was the purpose of your submission? It would appear to be intended to plead for 20byte addresses. As has been commented, 16 bytes is the choice. Alternatively, perhaps you are concerned about various types of transition (from IPv4 to IPv6 -- but using NSAP addresses?; from OSI's IP to IPv6 but retaining NSAP addresses?) Unless you have specific technical suggestions as part of the on going IPng working group effort, it's difficult to know how to factor in the comments. Just moving from IPv4 to IPv6 is very, very tough. To the extent reasonable and convenient, it will/would be great to facilitate movement from other protocol stacks. But for each such case, we need a spec. Dave -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 11 15:57:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16529; Sun, 11 Sep 94 15:57:08 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16523; Sun, 11 Sep 94 15:57:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20647; Sun, 11 Sep 94 15:56:03 PDT Received: from post.demon.co.uk by Sun.COM (sun-barr.Sun.COM) id AA08105; Sun, 11 Sep 94 15:53:38 PDT Received: from peeras.demon.co.uk by post.demon.co.uk id aa21532; 11 Sep 94 23:48 GMT-60:00 Date: Sun, 11 Sep 94 23:09:45 GMT From: Phil Royse Message-Id: <1725@peeras.demon.co.uk> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Numbers of NSAPs X-Mailer: PCElm 1.09 Lines: 47 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message <9409111949.AA01490@dxcoms.cern.ch> Brian Carpenter CERN-CN writes: > Jack, > > As I recall, UK-GOSIP primarily recommended TP0 over CONS over X.25, > with CLNP as a secondary recommendation. Yes, but only for LAN-connected end systems. The GOSIP WAN subprofile has always been strictly CONS. (With CO/CL IFUs at the transition.) Quote: " GOSIP 4 requires that end systems which are directly connected to WAN subnetworks support the CONS." and ".... (GOSIP has)... no plans to include a CLNS WAN specification." > .... The domain of discourse is > IP6, hopefully the successor to CLNP as well as to IPv4. This leads to > two precise questions. > > Can you estimate how many of the 1.25M systems you refer to are currently > running CLNP as their main network layer protocol? If by main, you mean the predominant internetworking protocol, linking LANs over intermediate WAN links or WAN subnets, I would estimate this to be a few hundred or so. Public sector end systems which have followed GOSIP generally have not implemented CLNP. (Even the "OSI-demonstrator" projects have not used any OSI network layer. A typical configuration being X.400(84) over X.25(80), with the protocol identified in the X.25 Call User Data Field, as prohibited in ISO 8878 - ergo, no NSAPs.) There are a few ICL OSLAN (new version) systems installed in the UK, but CLNP is used in little islands, typically connecting hosts with network processors. I suspect any NSAPs have been made up for local convenience, as distinct from being an enterprise address space plan. Very few organisations in the UK are doing any serious, multi-host LAN-WAN- LAN internetworking with CLNP. Therefore re-configuring any NSAPs would be a trivial task for them. > Can you also clarify how many of those systems, running CLNP, use > NSAP addresses that cannot be mapped as in the Carpenter/Bound > Internet Draft? I would estimate no significant quantity. -- Phil Royse | Comms Consultant. TUDOR HOUSE | proyse@peeras.demon.co.uk 12 Woodside Road Purley, Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 11 18:52:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16591; Sun, 11 Sep 94 18:52:57 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16585; Sun, 11 Sep 94 18:52:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA23750; Sun, 11 Sep 94 18:51:51 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA15682; Sun, 11 Sep 94 18:49:25 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA01986; Mon, 12 Sep 1994 11:49:16 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA09733; Mon, 12 Sep 94 11:44:07 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Mon, 12 Sep 1994 11:44:07 EST Date: 12 Sep 94 11:47:32 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) SIPP DOCS FOR ALAN.. ALL DONE Ua-Content-Id: 940912 11:45:05 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940912 11:45:05 009 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940912114732+1000 deferred 940912114732+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940912114324+1000 deferred 940912114324+1000 action Relayed Message-Id: <"940912 11:45:05"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Re my request for SIPP docs.. I have them now.. so please ignore it Thanks.. Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 11 19:10:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16603; Sun, 11 Sep 94 19:10:03 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16597; Sun, 11 Sep 94 19:09:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24120; Sun, 11 Sep 94 19:08:58 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA16518; Sun, 11 Sep 94 19:06:28 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA02512; Mon, 12 Sep 1994 12:06:19 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA09750; Mon, 12 Sep 94 12:00:35 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Mon, 12 Sep 1994 12:00:34 EST Date: 12 Sep 94 12:04:32 +1000 To: ipng@sunroof.Eng.Sun.COM, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au Subject: (IPng) ADDRESSSING..A START Ua-Content-Id: 940909 15:39:55 P1-Recipient: ipng@sunroof.eng.sun.com, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940909 15:39:55 011 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940912120432+1000 deferred 940912120432+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940912120029+1000 deferred 940912120029+1000 action Relayed Message-Id: <"940909 15:39:55"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Forwarded to: x400@mis@dcpmel[c=au;a=telememo;p=datacraft;o=smtp;s=ipng(a)sunroof.eng.sun.com;] x400@mis@dcpmel[c=gb;a=gold 400;p=icl;o=icl;ou1=ste0906;i=j;s=houldsworth;] cc: Comments by: Alan Lloyd@Marketing@DCTHQ Comments: JUst resending this because the one I got back got " decapitated".. Regards Alan@Oz -------------------------- [Original Message] ------------------------- gday, Re the addressing of IP4,6 and NSAPs.. Firstly before any comments are made on which one is best or most political or most idealistic we all have to take the view that both IP4/IP6 and NSAPs are going to exist (regardless of perceptions of the future and regardless of the counts today).. ie we wont do NSAPs because there are more IP4 addresses than NSAPs in use.. But there are more NSAPs than IP 6 in use.. so what? All must be accomodated. We must also accept that the address selection (and therefore the network architecture) philosophy is. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 11 19:21:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16615; Sun, 11 Sep 94 19:21:38 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16609; Sun, 11 Sep 94 19:21:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24386; Sun, 11 Sep 94 19:20:32 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA17153; Sun, 11 Sep 94 19:17:51 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA02898; Mon, 12 Sep 1994 12:17:35 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA09776; Mon, 12 Sep 94 12:11:56 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Mon, 12 Sep 1994 12:11:55 EST Date: 12 Sep 94 12:15:28 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) ADDRESSSING..A START Ua-Content-Id: 940909 15:39:55 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940909 15:39:55 014 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940912121528+1000 deferred 940912121528+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940912121124+1000 deferred 940912121124+1000 action Relayed Message-Id: <"940909 15:39:55"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Forwarded to: x400@mis@dcpmel[c=au;a=telememo;p=datacraft;o=smtp;s=ipng(a)sunroof.eng.sun.com;] cc: Comments by: Alan Lloyd@Marketing@DCTHQ Comments: Just resending It AGAIN.. cos it got its head cut orff! -------------------------- [Original Message] ------------------------- gday, Re the addressing of IP4,6 and NSAPs.. Firstly before any comments are made on which one is best or most political or most idealistic we all have to take the view that both IP4/IP6 and NSAPs are going to exist (regardless of perceptions of the future and regardless of the counts today).. ie we wont do NSAPs because there are more IP4 addresses than NSAPs in use.. But there are more NSAPs than IP 6 in use.. so what? All must be accomodated. We must also accept that the address selection (and therefore the network architecture) philosophy is. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 11 19:25:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16627; Sun, 11 Sep 94 19:25:16 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16621; Sun, 11 Sep 94 19:25:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24470; Sun, 11 Sep 94 19:24:11 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA17400; Sun, 11 Sep 94 19:21:39 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA03061; Mon, 12 Sep 1994 12:21:29 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA09806; Mon, 12 Sep 94 12:15:55 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Mon, 12 Sep 1994 12:15:54 EST Date: 12 Sep 94 12:19:51 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) FIRST THOUGHTS ON SIPP Ua-Content-Id: 940909 12:30:01 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940909 12:30:01 015 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940912121951+1000 deferred 940912121951+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940912121549+1000 deferred 940912121549+1000 action Relayed Message-Id: <"940909 12:30:01"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Forwarded to: x400@mis@dcpmel[c=au;a=telememo;p=datacraft;o=smtp;s=ipng(a)sunroof.eng.sun.com;] cc: Comments by: Alan Lloyd@Marketing@DCTHQ Comments: just resending as it did not return regards -------------------------- [Original Message] ------------------------- gday.. have reviewed the Sipp doc .. and note the review is my interpretation of the text.. I see some of you have implemented it so I may be covering old stories.. I will do a few of these responses.. to separate addressing issues for migration issues or just protocol review.. Here goes. An Objective appraisal... Types used in the comments are E=Editorial, T=Technical, X=? 1. Addressing.. I will cover that in a separate response.. 2. Section .. 4 Type: E Clarification Add "held in the previous Next Header field" to the end of the 2nd sentence. 3. Section .. 4.2 Type: E Clarification The use of the word Option in both the "Options" and the sub fields is confusing.. The term "Parameter" or "Argument" for the fields of the Option would provide greater distinction. 4. Section .. 4.3 (and others) Type: E Correction The Definition of Next Header.. "8 bit selector. Identifies the type of header immediately following this header. The Id values are as for the options as specified in this RFC or that ... RFC - 1340" (I assume 1340 does not specify SIPP options) 5. Section .. 4.3 - general consistency in length specifications. Type: T Comment The Hdr Ext Len field specifies 8 octet units less the first 8 octets for Hop BY Hop and End to End Options.. whereas all other options (Routing, option parameters, Authorisation, etc have exact length specifications.. eg. For error checking and robustness.. zero length fields are treated as such. Is there a reason for this. 6. Section .. 4.4 Type T Comment The routing header mechanism.. Is it open to misuse such as originator designed loops.. Does the Hop Limit catch such characteristics.. Should the hop count be refreshed on change of Dest Address? ie. Theoretical point.. One can specify 255 Addresses and 255 Hops. This permits one router per Address Hop. (Hopefully no one would do this but I assume one day some one will) .. Also I assume that some testing gets done with Routing Headers and Hop counts..and this case should be included. Also the comment "It is expected..additional types...more sophisticated routing alternatives".. last sentence.. I always find these comments a worry...They leave things open to re engineering the total network. 7. Section .. 4.6 Type X Comment I am not sure what this authentication is trying to achieve.. The term Authenticate is generally used to prove who some one is by a signature or password..I can assume one or two options from the text.. the authentication is between the end system and the routers (and the other end system) or just between the end systems. In the first case the routers need to understand a security domain and be configured with the originators security data..In the second case there is just a need to transfer "security data" before the payload. Not having a copy of Sipp_Auth.. I will just add the following.. Security Assoc Id.. "identifies the receivers" is this the routers or the end system(s).. Authentication Data... "its integrity" What Integrity? is it of the payload or the payload and the hop by hop options(when selected for integrity checks) . Because this mechanism cannot provide integrity to the SIPP header simply because it is updated in transit (hop counts and dest addresses if routing opts are used.. Also the route opts are updated).. If it is the integrity of the hop by hop options and the payload and security is applied to the router network.. then each router will have to recalculate "integity" including the options on every hop..not a good idea! I suppose the confusion arrises by having a specification that provides a feel of authentication and then specifies optional parameters (hop by hop) that can be either be included or excluded from the authentication process but not actually specifying whats actually being protected in the hop by hop options.. Certainly, implementing such an open ended security regime.. will be any bodies guess.. I obviously seek clarification.. Last point .. the field marked "payload type" should be Next option if the order of options as specified in 4.1 apply.. 8. Section .. 6 Type: XXXXXXXXXXXXXXXXXXXXXX Comments This one defies gravity! sorry this is an option beyond the scope of this document! Flow Ids are assigned by the source.. used by hashing in the routers.. assigned by the originator on demand... life time - any bodies guess.. state machines (but no states declared).. The whole concept defined (defined?) here is one that relies on originator specification and a high degree on interaction (on a single service basis) with each node in the network. >From a networks nodes point of view the whole concept relies on high node latency.. eg prioritorising packets "from the same source".. Wheras a router or switch is a lot more predicatble if priority and flow parameters are universally defined and applied in the local context. Also.. "There is no relative ordering between the flow controlled and non flow controlled.." does this mean an unattened mail message can get better priority than LF Audio.. This one (in my opinion is broken on the drawering board).. Whats wrong with the Type of Service field from the old IP (with a few adjustments). Simply because migration will be easier.. It can be processed relative to the nodes resources, It will make integration easier with ..., It will be much more aligned to the routing metrics of the current routing metrics and QOS specifications.. And (most of all) it can be implemented and tested! DIAGNOSTICS I am a great believer in "droppings".. that show the way.. It would be nice to have a Option where the transit router(s) could plant its Id so that source / destination hop testing and route determination can be performed. eg A single length (empty field is provided at the source which is refurbished at every hop... Or is this a candidate for Hop by Hop?? Closing I will continue to review.. but I am not sure of the process for the above.. Is there a "mail debate" or are these comments recorded formally for review and sign off.. The issue I see with Sipp (barring the fact I was continually informed that variable address headers (like NSAPs) are bad news for processing and to me SIPP with its options does look worse) is the open ended nature of it and therefore the openedness of router processing functions.. Specifing "Hop by Hop" and "End by End" options that will affect latency, routing, reliability, integrity and testing, etc.. AND not giving indications on what they are for does not make a good robust protocol specification.. Hopefully some ideas are in the tubes on this.. if so please send Regards (Objectively) Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 11 19:45:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16639; Sun, 11 Sep 94 19:45:25 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16633; Sun, 11 Sep 94 19:45:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24836; Sun, 11 Sep 94 19:44:19 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA18452; Sun, 11 Sep 94 19:41:51 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA03721; Mon, 12 Sep 1994 12:41:35 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA09824; Mon, 12 Sep 94 12:36:01 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Mon, 12 Sep 1994 12:36:00 EST Date: 12 Sep 94 12:39:53 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) RESENDING -- TRUNCATED DOC -ATTACH Ua-Content-Id: 940912 12:37:24 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940912 12:37:24 018 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940912123953+1000 deferred 940912123953+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940912123549+1000 deferred 940912123549+1000 action Relayed Message-Id: <"940912 12:37:24"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM To: x400@mis@dcpmel[c=au;a=telememo;p=datacraft;o=smtp;s=ipng(a)sunroof.eng.sun.com;] x400@mis@dcpmel[c=gb;a=gold 400;p=icl;o=icl;ou1=ste0906;i=j;s=houldsworth;] Cc: Bcc: From: Alan Lloyd@Marketing@DCTHQ Subject: Addresssing..A start Date: Friday, September 9, 1994 15:39:55 AUS Attach: Certify: N Forwarded by: ---------------------------------------------------------------------------- gday, Re the addressing of IP4,6 and NSAPs.. Firstly before any comments are made on which one is best or most political or most idealistic we all have to take the view that both IP4/IP6 and NSAPs are going to exist (regardless of perceptions of the future and regardless of the counts today).. ie we wont do NSAPs because there are more IP4 addresses than NSAPs in use.. But there are more NSAPs than IP 6 in use.. so what? All must be accomodated. We must also accept that the address selection (and therefore the network architecture) philosophy is. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 11 20:30:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16652; Sun, 11 Sep 94 20:30:53 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16646; Sun, 11 Sep 94 20:30:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25684; Sun, 11 Sep 94 20:29:48 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA20997; Sun, 11 Sep 94 20:23:55 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA04974; Mon, 12 Sep 1994 13:23:10 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA09906; Mon, 12 Sep 94 13:17:37 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Mon, 12 Sep 1994 13:17:36 EST Date: 12 Sep 94 13:21:37 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) RESEND OF ADDRESSING - ATTACHED Ua-Content-Id: 940912 13:18:11 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940912 13:18:11 022 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940912132137+1000 deferred 940912132137+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940912131731+1000 deferred 940912131731+1000 action Relayed Message-Id: <"940912 13:18:11"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday, this is another attempt to get the document through.. sorry if you are being flooded. Re the addressing of IP4,6 and NSAPs.. Firstly before any comments are made on which one is best or most political or most idealistic we all have to take the view that both IP4/IP6 and NSAPs are going to exist (regardless of perceptions of the future and regardless of the counts today).. ie we wont do NSAPs because there are more IP4 addresses than NSAPs in use.. But there are more NSAPs than IP 6 in use.. so what? All must be accomodated. We must also accept that the address selection (and therefore the network architecture) philosophy is-------------- Internet If one requires their network to be part of (or subordinate to the technologies and services of) the Internet..and the addressing schemes and network topologies as defined by the IETF then choose IP. In this case the ISOC/IETF is a network operator (of the Internet) and can as such administer its own addressing space (and its users addressing space). GOSIP and Carriers If one requires the formal registered globally structured carrier based / ISO defined addressing schemes..and the resultant routing hierachies and allocations then chose NSAP based schemes. (Govts and formal bodies associated with operations that require boundaries of countries, etc for bounding their domains (both commercially and technically) will seek NSAP schemes..eg Transport, Maritime, Aviation, Defence and Large govt agencies..This one has been "debated" I know.. but the majority of organisations on this planet use the Atlas as the base reference point for their operations.. It follows that they require their distributed IT systems should do the same) Network operators and multi national may choose logical schemes such as the ICD or a slice of addressing space within the Internet. Or if one wants a mixture of the two then that is also an option and gateways will be needed and the network architectures will require greater understanding. Side Note: I get greatly concerned when people view addressing just as "4 bytes" or what ever or just as being there for "protocol connectivity".. OK so far? The Address in a (global) protocol identifies not only its routing hierarchy, but also it infers network topology, address registration hierarchies and the source of its design and administration. Naturally the routing hierarchies reflect the administrations under the authority. Probably the first point on just the mapping of NSAPs into IP6 is the fact that it is truncated and secondly that its routing hierachy is not (or could not) be honoured in the IP network. The NSAP mapping is provided as carriage only because of IPs percieved different routing hierarchies. Probably the reverse will apply to IP6. IP6 in NSAPS as ICD = ISOC will be transferred to the nearest ICD routing level which may not be the most optimal route. Not having SIPP ROAD with me yet.. the basic problem is not one of address carriage but one of alignment in representation.. ie. If one can align the NSAP DCC form with regionally / country based IP6 routing levels and the NSAP ICD form with the International Operator levels of the IP6 form then the high level route optimisations can occur. If we can get agreement here we can then work down the addressing levels to where it is seen to be useful. So I think the NSAP mapping document needs to be put on hold for a while.. And If SIPP can be provided with an "Address" Extension option the main address can carry the NSAP to the System ID and the Option Field carry the System ID and Nsel.. But I will reserve judgement until further study.. This Option mechanism for NSAP carriage will then unfortunately negate the ability to use the Routing Options in SIPP (as they are 16 byte lengths)..Unless we can have a series of Addr extensions which support the Route Options .. (Clunky) or in fact just use a different style or route option (for big addresses) Can I get some ideas on what people think about how much NSAP routing functionality they want in the SIPP RFC and in a SIPP Node.. (eg. use of ext options and route options).. Comments welcome (nice ones please!) Regards Alan@Oz Options. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 00:15:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16718; Mon, 12 Sep 94 00:15:46 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16712; Mon, 12 Sep 94 00:15:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA29745; Mon, 12 Sep 94 00:14:41 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AB10610; Mon, 12 Sep 94 00:11:25 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA13680; Mon, 12 Sep 1994 17:11:15 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA10145; Mon, 12 Sep 94 17:06:07 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Mon, 12 Sep 1994 17:06:06 EST Date: 12 Sep 94 17:10:03 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) SST - SOME COMMENTS FROM OZ Ua-Content-Id: 940912 15:53:51 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940912 15:53:51 031 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940912171003+1000 deferred 940912171003+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940912170559+1000 deferred 940912170559+1000 action Relayed Message-Id: <"940912 15:53:51"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday.. comments on SST Simple Sipp Transition.. I think I may have a bolt loose so I could be wrong! Put it down to the Sun. Given the configuration scenario of a V4 node, through a gateway router to a SIPP / V4 compatible node (SIPP+V4).. Does not the SIPPV4 node (although it uses 16 byte addresses) also require that its SIPPV4 part of its address is unique within the V4 environment? (It may have a few bits in front like 000000.V4 to talk to the V4 node, but does the V4 node still address the SIPV4 node with a V4 address which gets prefixed with 000001 in the gateway. In both directions the V4 address must be unique.. If this is the case then to make any SIPP node talk to other V4 addressed devices, they will all need unique V4 assigned addresses. Say there is a network where there are pure SIPP nodes that can talk "Pure SIPP" to each other .. and this network then wants to be connected to any V4 node, it will need a pile of "V4" addresses that will have to be unique within the V4 address space.. Will this have problems with address overlap and administration?? Eg. A national Providor gets 1000 SIPP Unicast address, puts up hosts as information servers and then.. one day someone wants to connect to these from any point on the globe that has V4.. Sods Law might even have the V4 addresses the same as the bottom end of the Providors address space! Given the case above and as this V4 space is running out.. How does SIPP expansion occur if it has to be backward compatible with V4 in an arbitary way.. Because if one is adding nodes to the INternet in SIPP form at the same rate V4 forms are being retired then that could be OK.. If the subnets sizes are similar.. If the V4 nodes remain and the SIPP nodes get deployed more quickly.. V4 addresses will go very quickly. The other point is about "vendors may deliver upgrades.. users will install such upgrades.." (SST Page 10).. A couple of points.. 1. How much extra memory and processor power is needed for SIPP, ICMP, route tables in the average router.. Does such an upgrade also need more "Iron".. Does any body have a feel for this? 2. Does the user now have to re address the network with three address scenarios.. a) IPV4 addresses. b) SIPPV4 addresses c) SIPP Provider addresses (Non V4 compatible) (Plus and IPX and Carrier based schemes).. And map them.. 3. Do users now have to seek End Systems (Hosts) that can have a separate SIPP address from that of a V4 address (ie respond to 2 completely different addresses. and the V4 one mapped to SIPP. 4. SNMP managers and agent devices will also have to do the same (ie.) Have 3 address forms.. Migration and Upgrading - just an approach If a network was to take the NSAP direction.. the methodology was to make IPV4 and IPX subnets subrdinate to the global NSAP format (within the RD) so that each subnet within that NSAP was in fact globally unique..ie. this works because there is a logical or geographic ownership of the subnet.. and a CORE UP CLNP approach to the addressing scheme of the network to global addressing. Gateways place at points on the network for external connections permit this migration. I suppose the same approach could work for IP to SIPP, it really depends on how "core networks" are developed, which really means organising and segmenting the Internet.. in the best way possible.. As you can see .. I think the planning of this will be the biggest issue (apart from the support required for 3 address forms within equipment). I hope I am wrong on this one.. Please Advise.. Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 03:35:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16869; Mon, 12 Sep 94 03:35:12 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16863; Mon, 12 Sep 94 03:35:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03973; Mon, 12 Sep 94 03:34:07 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA08924; Mon, 12 Sep 94 03:31:41 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 12 Sep 1994 11:29:40 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Mon, 12 Sep 1994 10:59:38 +0100 Date: Mon, 12 Sep 1994 10:59:38 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003679] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3679 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3679*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9409081808.AA24572@snark.imsi.com> Subject: RE: Re: (IPng) Numbers of NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM J.Houldsworth@ste0906.wins.icl.co.uk says: > I now have some indications from my sources that we are > looking at upwards of 1 million 20 byte NSAP addresses >The decision to go with 16 byte IPng addresses was made and >is final. We have other work to do. Can we please get on >with it? >Perry Nothing I said stops you from getting on with your work, whatever it is. I was simply supplying information which should be of interest to the IETF because it seems to indicate that the numbers of NSAP terminations is higher than originally estimated because of the greater emphasis on OSI within Europe. I'm sorry if it's a story you don't want to hear but I thought that Internet would be keen to grow it's penetration by adding traffic from NSAP terminations and that it may encourage new thoughts on at least avoiding making it difficult for NSAP users. This is an opportunity, not a threat. Folding NSAPs into NSAPs into IP6 is clearly not facilitated by the current encoding/compression draft which shrugs off the ability to carry 20 bytes as an unnecessary luxury. Originally, some said that the requirement should be ignored because it conceded to the OSI community but I hope we are through that syndrome. I don't care what size the native IP6 address is provided that there is a proper mechanism for carrying 20 byte NSAPs! (eg. by an extension/option field or some other technical solution). Despite your protestations, I hope others would share the view that it would be a good idea to make sure that we have a viable solution to all known problems before banning further input. Perhaps you could wrestle with this interesting technical alongside the current work that you have to get on with. Jack ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 04:34:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16903; Mon, 12 Sep 94 04:34:20 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16897; Mon, 12 Sep 94 04:34:12 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA04632; Mon, 12 Sep 94 04:33:15 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA12371; Mon, 12 Sep 94 04:30:42 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 12 Sep 1994 12:25:47 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; Relayed; Mon, 12 Sep 1994 11:50:56 +0100 Date: Mon, 12 Sep 1994 11:50:56 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003686] X400-Content-Type: P2-1984 (2) Content-Identifier: 3686 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3686*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9409111949.AA01490@dxcoms.cern.ch> Subject: RE: Re: (IPng) Numbers of NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM 1. The connection mode edict went long ago when GOSIP realsied that nobody supplied connection mode in LANS! Except for JNT!! 2. Don't know the split but even X.25 connections are convertable to CLNP or IP6 so it's irrelevant. 3. All of them because the compression leaves only 15 bytes of space for the NSAP. Jack ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 04:38:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16920; Mon, 12 Sep 94 04:38:15 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16914; Mon, 12 Sep 94 04:38:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA04709; Mon, 12 Sep 94 04:37:11 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA12761; Mon, 12 Sep 94 04:34:47 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA16504; Mon, 12 Sep 1994 13:34:45 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA21724; Mon, 12 Sep 1994 13:34:42 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409121134.AA21724@dxcoms.cern.ch> Subject: (IPng) Re: draft-simpson-ipv6-discovery-req-00.txt To: ipng@sunroof.Eng.Sun.COM (ip6) Date: Mon, 12 Sep 1994 13:34:41 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 512 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, Is this the right list to discuss your discovery draft? I strongly approve the move from media broadcast to media multicast, but IMHO you should go further. Once a host has discovered an autoconfig server, presumably using a well-known media multicast address, why should it ever need to multicast again for discovery purposes? The autoconfig server should be able to tell it everything it needs to know. Let's try to keep media multicast for "useful" multicasts, i.e. multicast applications. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 05:27:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16946; Mon, 12 Sep 94 05:27:51 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16940; Mon, 12 Sep 94 05:27:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA05441; Mon, 12 Sep 94 05:26:46 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA16499; Mon, 12 Sep 94 05:24:21 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 12 Sep 1994 13:23:44 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Mon, 12 Sep 1994 12:54:03 +0100 Date: Mon, 12 Sep 1994 12:54:03 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003687] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3687 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3687*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Subject: RE: Re: (IPng) Numbers of NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17079; Mon, 12 Sep 94 09:23:20 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17073; Mon, 12 Sep 94 09:23:12 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA20434; Mon, 12 Sep 94 09:22:14 PDT Received: from drax.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA00692; Mon, 12 Sep 94 09:19:30 PDT Received: from drax.isi.edu by drax.isi.edu (5.65c/5.61+local-16) id ; Mon, 12 Sep 1994 08:48:35 -0700 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Numbers of NSAPs In-Reply-To: Your message of "Mon, 12 Sep 1994 12:54:03 BST." <"3687*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> Date: Mon, 12 Sep 94 08:48:34 PDT Message-Id: <3741.779384914@drax.isi.edu> From: Craig Milo Rogers Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack Houldsworth: >I am asking for the ability to carry the full 20 byte NSAP, >which many users have been allocated, in an IP6 message. Another option is bidirectional mapping between arbitrary 20-octet NSAPs and 16-octet IP6 addresses at boundary nodes, in conjunction with either protocol encapsulation (example: CNLP over IP6) or gatewaying (FTAM to FTP and/or NFS). I believe that the anticipated traffic patterns will allow effective use of local cache and. on high-performance routers/gateways, hardware lookup and header translation. I also contend that automatic registration procedures can be used to implement the map without creating an enormous administrative nightmare. It has also been pointed out that a map such as this can be used to configure tunnels and other encapsulation or translation functions. I have distributed over this mailing list a proposal to do NSAP/IP6 address mapping with DNS as the underlying distributed database; essentially, ARP over DNS. I'll email you a copy, if you wish. I have not yet created an Internet Draft, although it's on my work queue. Craig Milo Rogers ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 11:16:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17245; Mon, 12 Sep 94 11:16:25 PDT Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17239; Mon, 12 Sep 94 11:16:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA09384; Mon, 12 Sep 94 11:15:20 PDT Received: from relay3.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA25710; Mon, 12 Sep 94 11:12:52 PDT Received: from uucp7.UU.NET by relay3.UU.NET with SMTP id QQxhbk11952; Mon, 12 Sep 1994 14:12:47 -0400 Received: from ons.UUCP by uucp7.UU.NET with UUCP/RMAIL ; Mon, 12 Sep 1994 14:12:53 -0400 From: ons!moulton@uunet.uu.net (James Moulton) X-Mailer: SCO System V Mail (version 3.2) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPng API Date: Mon, 12 Sep 94 13:52:21 EDT Message-Id: <9409121352.aa17359@ons.UUCP> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In reviewing the discussions on this list, it seems to me that a critical piece of the IPng puzzle is a generic API which can then be used to build the actual socket interface and STREAMS interface. What I am looking for is a description of what a "user" of IPng should expect to use in calling IPng for transferring a packet and what it should receive from IPng when it receives a packet. One concern I have, is that we make the interface flexible enough so that IPng evolution will not require a re-design of the interface. For example, the interface could include an addressing structure that accomodates both a length value (restricted now to 16) and the actual address. This allows changes without a re-design of the using protocols. Is there someone working on a generic API for IPng? Jim Moulton ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 16:05:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17544; Mon, 12 Sep 94 16:05:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17538; Mon, 12 Sep 94 16:05:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00901; Mon, 12 Sep 94 16:02:34 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA29724; Mon, 12 Sep 94 16:02:11 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA13807; Tue, 13 Sep 1994 09:01:57 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA11030; Tue, 13 Sep 94 08:56:25 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Tue, 13 Sep 1994 08:56:23 EST Date: 13 Sep 94 09:00:22 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) SKIPPY THE BUSH KANGAROO - HOPS Ua-Content-Id: 940913 08:51:46 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940913 08:51:46 004 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940913090022+1000 deferred 940913090022+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940913085617+1000 deferred 940913085617+1000 action Relayed Message-Id: <"940913 08:51:46"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday, I made comments on SIPP the other day (no response yet).. But the issue of HOP counts was raised.. Does any one have a feel for the actual hops that can be encountered on a global internet.. I get the feeling that 255 could be a bit on the threshold.. If it is then something has to be done to extend it.. or we need a better mechanism to stop looping.. Any thoughts Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 16:24:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17574; Mon, 12 Sep 94 16:24:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17568; Mon, 12 Sep 94 16:24:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02926; Mon, 12 Sep 94 16:21:02 PDT Received: from nbkanata.newbridge.com by Sun.COM (sun-barr.Sun.COM) id AA04018; Mon, 12 Sep 94 16:20:37 PDT Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.newbridge.com (4.1/SMI-4.1) id AA15294; Mon, 12 Sep 94 19:15:18 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA12685; Mon, 12 Sep 94 19:15:16 EDT Received: from urchin.newbridge by mako.newbridge (4.1/SMI-4.1) id AA08220; Mon, 12 Sep 94 19:14:22 EDT Received: by urchin.newbridge (5.0/SMI-SVR4) id AA01187; Mon, 12 Sep 1994 19:16:34 +0500 Date: Mon, 12 Sep 1994 19:16:34 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9409122316.AA01187@urchin.newbridge> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) SKIPPY THE BUSH KANGAROO - HOPS X-Sun-Charset: US-ASCII Content-Length: 831 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM There was a long discussion on big-internet about hop counts. The conlusions were: 1) If we count mini-hops (through complex switches) we might easily exceed 255. 2) If the hop count gets much larger, it is not a very useful loop suppressor. 3) As long as we count only IP forwarding entities and are reasonable about how we do things (switches do not gratuitously perform extra decrements) it is likely that 255 meets the rule of being safely larger than what we need. The result was that while some people felt a larger hop count was desirable, it was generally (but not universally) concluded that it would not work out well. You should consult the big-internet archives for more details. (I believe they are at Munnari, down your way.) Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 16:24:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17575; Mon, 12 Sep 94 16:24:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17562; Mon, 12 Sep 94 16:24:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02917; Mon, 12 Sep 94 16:20:58 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA04005; Mon, 12 Sep 94 16:20:34 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA14556; Tue, 13 Sep 1994 09:19:16 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA11090; Tue, 13 Sep 94 09:14:03 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Tue, 13 Sep 1994 09:14:03 EST Date: 13 Sep 94 09:18:03 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) (IPNG) NUMBERS OF NSAPSAND SST Ua-Content-Id: 940913 07:57:30 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940913 07:57:30 006 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940913091803+1000 deferred 940913091803+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940913091359+1000 deferred 940913091359+1000 action Relayed Message-Id: <"940913 07:57:30"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Forwarded to: x400@mis@dcpmel[c=au;a=telememo;p=datacraft;o=smtp;s=ipng(a)sunroof.eng.sun.com;] cc: Comments by: Alan Lloyd@Marketing@DCTHQ -------------------------- [Original Message] ------------------------- gday, re Jack's request for NSAP carriage in IP6..( I agree.. but you would expect that anyway!) I have already provided some input on this re the SST document, IP6 addressing, re the summary and some direct comments that request the ITU/ISO to change its numbering schemes.. This one is a bit extreme though.. To go forward on this one.. It seems to me that moving from IP4 to IP6 is not a simple transition as one might be led to believe.. It requires that all devices in the IP4 env and the SIPPV4 env will still require IP4 addresses in the IP4 space. Devices that move from the SIPPV4 space to the SIPP space will need another address for that environment..Therefore devices will require TWO distinct addresses and manage 3 ie.. their IP4 address and their SIPP native address and their mapped 16 byte V4 address. This is easy when discussing a single end system, but when dealing with an operational network which spans the planet.. Such an upgrade will need a sound, well managed approach (and address administration) and possibly segmentation of the network. Devices in this environment might need a range of discovery and announcement features such as "Alternative Address OPtions".. Just so that interworking and gateways can do something to support the transition and/or find the best route to the preferred routing environment.. eg AAO could indicate V4 addresses in the IP6 env or NSAPs.. eg. AAO = TLV Type = Src/Dest + protocol- IP4/IP6/IPX/NSAP Len = 4,12,16, n Value = Address Should the source or address field be empty (or set to a "see AAO" indicator) the AAO could be selected as the preferred addressing mode. OR if the destination address expires on route.."Unable to forward".. then the AAO is used if it is set..gateways could manage the address mapping explicitly rather than guessing the mapping process.. eg. the SIPP dest address is set to the domain of the NSAP ICD..the packet is sent via SIPP routers to the ICD routing level... The ICD routing level then takes the AAO the dest NSAP.. and off we go.. In the NSAP environment the IP4 and IP6 addresses for the Internet env will be NSAPs (ICD = ISOC) so there is no problem here in the return path. Any comments or support for this... Regards Alan@Oz PS Any comments on the two addresses required for each SIPPV4 node? (re its administration and dealing with international overlaid networks) ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 17:55:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17670; Mon, 12 Sep 94 17:55:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17649; Mon, 12 Sep 94 17:49:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10944; Mon, 12 Sep 94 17:46:48 PDT Received: from wolf.arl.mil by Sun.COM (sun-barr.Sun.COM) id AA23426; Mon, 12 Sep 94 17:46:27 PDT Date: Tue, 13 Sep 94 0:03:29 GMT From: Mike Muuss To: "Robert J. Reschly Jr." Cc: Keith Sklower , ipng@sunroof.Eng.Sun.COM Subject: (IPng) Protection of Government Software Message-Id: <9409122003.aa11506@wolf.arl.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob Reschly wrote - > Do I correctly recall that you found out how to copyright (or > otherwise protect) something developed by the Government. The strongest protection that is available to the Government is to acquire a trademark on the NAME of the product. It does not protect the actual software itself, but keeps someone from offering offering your software with your original product's name used. This at least protects the _reputation_ of the Government software, even if it does not prevent the "theft" of the software. The cost and paperwork are minimal, and the body of trademark protection case law is strong. The US Government can not hold copyright in the USA, but it can hold copyright in all other countries. Depending on whether you want to restrict the availability of the software, or if you just want to prevent another party from asserting ownership of it, I would suggest that you use something like these markings, which we developed for the government-owned BRL-CAD (tm) package: /* * Source - * The U. S. Army Research Laboratory * Aberdeen Proving Ground, Maryland 21005-5068 USA * * Distribution Status - * Public Domain, Distribution Unlimited. */ and /* * Source - * The U. S. Army Research Laboratory * Aberdeen Proving Ground, Maryland 21005-5068 USA * * Distribution Notice - * Re-distribution of this software is restricted, as described in * your "Statement of Terms and Conditions for the Release of * The BRL-CAD Package" agreement. * * Copyright Notice - * This software is Copyright (C) 1994 by the United States Army * in all countries except the USA. All rights reserved. */ Note that for the second form, the Government makes each recipient (foreign and domestic) execute a legally binding contract which spells out the terms and conditions under which are allowed to have the software. We do not charge for the software, and the restrictions are minimal -- mostly just "tell us who you are, and don't give/sell copies to anyone else, refer them to us". We collect significant "brownie points" for our technology transfer accomplishments and "dual use technology" as a result. Government managers will understand the importance of this pastime. Also note that the second statement and the contract that goes with it have been reviewed for suitability by numerous government lawyers, and have been deemed both fully legal and fully suitable for the desired purpose. Government-generated computer software is _not_ a "record" as defined by the Freedom of Information Act (FOIA), and thus does not _have_ to be released to the public. We have executed copies of this contract with more than 800 establishments, including most of the major corporations of the western world and most of the notable Universities. Only one company took substantial objection to these terms (Martin Marietta), but they eventually signed anyway. If you use our contract as a prototype, you should encounter minimal difficulty. The contract and related survey form is available for your inspection via anonymous ftp from FTP.ARL.MIL file brl-cad/agreement, or on the Web as http://ftp.arl.mil/ftp/brl-cad/agreement In the case of contributing software to the Berkeley Software Distribution (BSD), I have done that myself (PING, TTCP, etc.) using the first distribution statement, and have been pleased with the results. The Berkeley people are most scrupulous about providing proper credit to contributors and leaving original markings intact. Certain system vendors are in the habit of running obnoxious shell scripts to attach copyright notices to all "their" source code, even when that code is already clearly marked as copyright protected (e.g. by Berkeley), or public domain (e.g. my contributions). At some future date, should such a vendor attempt to assert ownership of such inappropriately re-marked materials, they open themselves up to a lawsuit that they would find difficult to win. On the other hand, if a vendor makes additions to the software, then those additions (and only those additions) become eligible for copyright protection as a "derivative work". The copyright law has a lot to say about derivative works too, and grants a significant degree of control to the original author. I'm shooting in the dark here, but if what you are really trying to protect here is a new _process_ or _invention_ for, say, handling packets, then that process or invention can be protected by patent. There are over 8,000 such software "process" patents already granted by the Patent and Trademark Office (PTO), so don't let anyone tell you that you can't patent software or algorithms. That day has passed. The US Government is permitted to protect it's inventions by patent, and may even collect royalties for licensing them. The disadvantage is that patents take a substantial amount of legal effort to prepare, several thousand dollars to file for, and typically several years to acquire. The Patent Office has not yet moved into the Information Age, but that's a topic for another diatribe. I am not a lawyer, so before putting your own protection plan into practice, it is essential that you contact competent legal council. Government employees have access to a broad variety of legal resources to assist them, so don't be shy. You'll find that hacking contracts is much like hacking code, and it can be a lot of fun! Best, -Mike Muuss Leader, Advanced Computer Systems Team The US Army Research Laboratory APG, MD 21005-5068 USA 410-278-6678 Voice 410-278-6656 Secretary 410-278-5058 FAX ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 17:58:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17682; Mon, 12 Sep 94 17:58:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17676; Mon, 12 Sep 94 17:58:19 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11509; Mon, 12 Sep 94 17:55:16 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA25448; Mon, 12 Sep 94 17:54:44 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 13 Sep 1994 01:53:38 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; Relayed; Mon, 12 Sep 1994 11:46:01 +0100 Date: Mon, 12 Sep 1994 11:46:01 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003685] X400-Content-Type: P2-1984 (2) Content-Identifier: 3685 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3685*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <486.779095547@cs.ucl.ac.uk> Subject: RE: Re: (IPng) Numbers of NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM 1. Did you send this to the ipng list? Most people on there are saying that I must be smoking something to arrive at figures like that! It doesn't matter how many provided that there is a conversion path for 20 byte NSAPs. Yes, Brian was addressing that but his draft has been published and offers no solution for 20 bytes. Even admits it can't be done! Jack Houldsworth ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 18:30:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17734; Mon, 12 Sep 94 18:30:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17728; Mon, 12 Sep 94 18:30:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13419; Mon, 12 Sep 94 18:27:44 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA01292; Mon, 12 Sep 94 18:27:23 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA19115; Tue, 13 Sep 1994 11:26:58 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA11233; Tue, 13 Sep 94 10:56:16 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Tue, 13 Sep 1994 10:56:15 EST Date: 13 Sep 94 11:00:14 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) SIPP - INTEGRITY Ua-Content-Id: 940913 10:48:58 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940913 10:48:58 013 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940913110014+1000 deferred 940913110014+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940913105611+1000 deferred 940913105611+1000 action Relayed Message-Id: <"940913 10:48:58"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday, re the SIPP integrity (section 4.6 page 16 Auth Data definition) and the Hop by Hop option bits for including Option data in the integrity checks.. Is there a model for this? What are the routers to do with integrity checks on the SIPP protocol.. Do specific options require integrity testing? What is the interaction required between one or more routers (to set this up) and the end systems.. Is there a document available? Also are there SIPP Options being proposed at the moment.. as per my original comments on SIPP Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 18:31:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17744; Mon, 12 Sep 94 18:31:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17735; Mon, 12 Sep 94 18:31:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13440; Mon, 12 Sep 94 18:28:05 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA01328; Mon, 12 Sep 94 18:27:43 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA19152; Tue, 13 Sep 1994 11:27:36 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA11284; Tue, 13 Sep 94 11:21:24 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Tue, 13 Sep 1994 11:21:23 EST Date: 13 Sep 94 11:25:19 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) (IPNG) NUMBERS OF NSAPSAND SST Ua-Content-Id: 940913 07:57:30 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940913 07:57:30 016 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940913112519+1000 deferred 940913112519+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940913112114+1000 deferred 940913112114+1000 action Relayed Message-Id: <"940913 07:57:30"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Forwarded to: x400@mis@dcpmel[c=au;a=telememo;p=datacraft;o=smtp;s=ipng(a)sunroof.eng.sun.com;] cc: Comments by: Alan Lloyd@Marketing@DCTHQ Comments: just resending it .. email is cracking up ..I seem to be getting "bits of messages".. -------------------------- [Original Message] ------------------------- gday, re Jack's request for NSAP carriage in IP6..( I agree.. but you would expect that anyway!) I have already provided some input on this re the SST document, IP6 addressing, re the summary and some direct comments that request the ITU/ISO to change its numbering schemes.. This one is a bit extreme though.. To go forward on this one.. It seems to me that moving from IP4 to IP6 is not a simple transition as one might be led to believe.. It requires that all devices in the IP4 env and the SIPPV4 env will still require IP4 addresses in the IP4 space. Devices that move from the SIPPV4 space to the SIPP space will need another address for that environment..Therefore devices will require TWO distinct addresses and manage 3 ie.. their IP4 address and their SIPP native address and their mapped 16 byte V4 address. This is easy when discussing a single end system, but when dealing with an operational network which spans the planet.. Such an upgrade will need a sound, well managed approach (and address administration) and possibly segmentation of the network. Devices in this environment might need a range of discovery and announcement features such as "Alternative Address OPtions".. Just so that interworking and gateways can do something to support the transition and/or find the best route to the preferred routing environment.. eg AAO could indicate V4 addresses in the IP6 env or NSAPs.. eg. AAO = TLV Type = Src/Dest + protocol- IP4/IP6/IPX/NSAP Len = 4,12,16, n Value = Address Should the source or address field be empty (or set to a "see AAO" indicator) the AAO could be selected as the preferred addressing mode. OR if the destination address expires on route.."Unable to forward".. then the AAO is used if it is set..gateways could manage the address mapping explicitly rather than guessing the mapping process.. eg. the SIPP dest address is set to the domain of the NSAP ICD..the packet is sent via SIPP routers to the ICD routing level... The ICD routing level then takes the AAO the dest NSAP.. and off we go.. In the NSAP environment the IP4 and IP6 addresses for the Internet env will be NSAPs (ICD = ISOC) so there is no problem here in the return path. Any comments or support for this... Regards Alan@Oz PS Any comments on the two addresses required for each SIPPV4 node? (re its administration and dealing with international overlaid networks) ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 18:50:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17770; Mon, 12 Sep 94 18:50:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17764; Mon, 12 Sep 94 18:50:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14667; Mon, 12 Sep 94 18:47:23 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA05902; Mon, 12 Sep 94 18:47:00 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA16416; Tue, 13 Sep 1994 10:12:42 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA11157; Tue, 13 Sep 94 10:07:25 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00450; Tue, 13 Sep 1994 10:07:24 EST Date: 13 Sep 94 10:11:05 +1000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) SIPP ADDRESSING.. Ua-Content-Id: 940913 09:02:58 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940913 09:02:58 010 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TEXTFILE*dcaus; arrival 940913101105+1000 deferred 940913101105+1000 action Relayed X400-Trace: au*telememo*datacraft; arrival 940913100659+1000 deferred 940913100659+1000 action Relayed Message-Id: <"940913 09:02:58"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Forwarded to: x400@mis@dcpmel[c=au;a=telememo;p=datacraft;o=smtp;s=ipng(a)sunroof.eng.sun.com;] cc: Comments by: Alan Lloyd@Marketing@DCTHQ -------------------------- [Original Message] ------------------------- gday, comments on SIPP Road and Arch The SIPP ROAD doc only "suggests" formats for the SIPP address beyond that of defining the top few bits or byte.. eg m bits, p bits and n bits..without actually defining the range of m, n and p.. Are these similar to IP4 where providers will be given a variable length subnet mask and a range of addresses.. (expansion and continutity?) Are there country based codes for "geographic addresses" assigned.. Are there a range of Providor /Providor size codes.. Are administrations being set up with a range of the above.. and is there any administrative relationship between the two address forms. The SIPP Arch document is interesting but does not prescribe anything that defines the addressing POLICY of the SIPP addresses.. I would have thought that the SIPP ROAD doc should give us the exact format of the bits for all fields (the top selectors and the m,n and p fields) based on its administrative requirements oaf SIPP addresses and reference IPX and NSAP documents.. And the SIPP Arch provide us with the background material (as it does) but then identifies the allocation practices of IP4, IP6 for both the providor and geographic schemes.. Certainly these would be useful so that integration and migration issues can be focussed on..AS you can see from my other comments, the SST document seems to hide a few big gotchas in this area. Integration and MIgration is not just one of address mapping.. It will be a case or reachitecting thousands of networks across the planet. Now SIPP is decided as a point in the future.. we really must see if it possible to get to it.. The information (as defined above) will be fundamental to the way of introducing such a move.. Is this a BiG I topic? Please advise Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 12 19:07:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17818; Mon, 12 Sep 94 19:07:20 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17812; Mon, 12 Sep 94 19:07:12 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA13261; Mon, 12 Sep 1994 19:04:09 -0700 Received: by kandinsky.Eng.Sun.COM (5.0/SMI-SVR4) id AA18469; Mon, 12 Sep 1994 19:04:25 +0800 Date: Mon, 12 Sep 1994 19:04:25 +0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9409130204.AA18469@kandinsky.Eng.Sun.COM> To: ipng@sunroof Subject: re: (IPng) SST - SOME COMMENTS FROM OZ Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan - I forwarded your mail with your comments on the SST transition document to the "ngtrans@sunroof.eng.sun.com" mailing list. This is the mailing list for the IPng transition working group. I'd propose that we discuss your IPv4-to-IPv6 transition issues on the ngtrans list, rather than the main IPng mailing list. I note that you are already subscribed to the ngtrans mailing list. Others may subscribe by just sending a message to "majordomo@sunroof.eng.sun.com" and including the line: subscribe ngtrans in the body of the message. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 13 08:13:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18272; Tue, 13 Sep 94 08:13:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18260; Tue, 13 Sep 94 08:13:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07722; Tue, 13 Sep 94 08:09:59 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA05428; Tue, 13 Sep 94 08:09:33 PDT Received: from pm012-00.dialip.mich.net (pm012-00.dialip.mich.net [35.1.48.201]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA19209 for ; Tue, 13 Sep 1994 11:09:25 -0400 Date: Tue, 13 Sep 94 14:18:13 GMT From: "William Allen Simpson" Message-Id: <3179.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: draft-simpson-ipv6-discovery-req-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Is this the right list to discuss your discovery draft? > Yes, this is the right place. > I strongly approve the move from media broadcast to media > multicast, but IMHO you should go further. Once a host has > discovered an autoconfig server, presumably using a well-known > media multicast address, why should it ever need to multicast > again for discovery purposes? The autoconfig server should be > able to tell it everything it needs to know. > Because there are no plans for: - an autoconfig server which advertises a record for the media address for the local hop. So, we need some mechanism for discovering local hops. - an autoconfig server which advertises a record for the appropriate router to use for the next hop. So, we need some mechanism for discovering routers. This is also important for mobility. - the autoconfig server to be in place on _every_ link. It is likely to be on the other side of the router somewhere. That's why we now have SCOPE of multicast. > Let's try to keep media multicast for "useful" multicasts, > i.e. multicast applications. Note that the media multicast is used sparingly, and only when no router has been discovered. (The router is a pretty darn useful application.) That's as small a use as I can figure. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 13 08:13:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18273; Tue, 13 Sep 94 08:13:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18266; Tue, 13 Sep 94 08:13:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07736; Tue, 13 Sep 94 08:10:06 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA05436; Tue, 13 Sep 94 08:09:35 PDT Received: from pm012-00.dialip.mich.net (pm012-00.dialip.mich.net [35.1.48.201]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA19202 for ; Tue, 13 Sep 1994 11:09:21 -0400 Date: Tue, 13 Sep 94 13:56:23 GMT From: "William Allen Simpson" Message-Id: <3177.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ADDRESSSING..A START Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > JUst resending this because the one I got back got " decapitated".. Alan, I can't send back to you, because your return address is "not understandable" to my mail machine here in the Internet. But this affects the group, so here it is: I got all four of your messages of this subject, and multiples of other recent messages. I sometimes get 2 or more copies of your messages, even when you aren't doing it deliberately. The decapitation is by your MTA, not by the list. The Internet SMTP doesn't have these kind of problems. It would be really nice if you were actually _on_ the Internet before criticising it. If this MTA problem is typical of X.400, then you have some serious housecleaning to do before we would be interested in trying to merge with OSI. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 13 08:47:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18298; Tue, 13 Sep 94 08:47:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18292; Tue, 13 Sep 94 08:47:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09926; Tue, 13 Sep 94 08:44:06 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA11000; Tue, 13 Sep 94 08:43:41 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11942; Tue, 13 Sep 1994 17:43:34 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28749; Tue, 13 Sep 1994 17:43:31 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409131543.AA28749@dxcoms.cern.ch> Subject: Re: (IPng) Re: draft-simpson-ipv6-discovery-req-00.txt To: ipng@sunroof.Eng.Sun.COM Date: Tue, 13 Sep 1994 17:43:31 +0200 (MET DST) In-Reply-To: <3179.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Sep 13, 94 02:18:13 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 246 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, > Note that the media multicast is used sparingly, and only when no router > has been discovered. (The router is a pretty darn useful application.) > That's as small a use as I can figure. > Ack. Thanks for the clarifications. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 13 09:27:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18311; Tue, 13 Sep 94 09:27:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18305; Tue, 13 Sep 94 09:27:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12836; Tue, 13 Sep 94 09:24:00 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA18286; Tue, 13 Sep 94 09:23:37 PDT To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) Aside: US Gov't & Copyrights Date: Tue, 13 Sep 94 13:10:11 GMT From: Ran Atkinson Message-Id: <9409131310.aa07069@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I'd like to clarify that note from BRL by adding a little precision. The US Government cannot _create_ a copyright within the US but it can _own_ a copyright that was created by any other person or organisation, for example an on-site contractor, if the copyright creator sells the copyright. This is a fairly basic principle of property law in the US. Both copyrights and patents are property and may be sold. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 13 18:21:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19071; Tue, 13 Sep 94 18:21:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19065; Tue, 13 Sep 94 18:21:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05014; Tue, 13 Sep 94 18:18:26 PDT Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA19255; Tue, 13 Sep 94 18:18:07 PDT Received: from [199.171.59.210] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id SAA00664; Tue, 13 Sep 1994 18:17:57 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 Sep 1994 20:18:00 -0500 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: RE: Re: (IPng) Numbers of NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, To respond to your response: At 6:54 AM 9/12/94, J.Houldsworth@ste0906.wins.icl.co.uk wrote: >I am asking for the ability to carry the full 20 byte NSAP, Do you have a proposal or, better still, a spec to submit for this? No doubt there could be endless debate about the need, the benefit, etc. Ultimately, work in the IETF involves developing specs. It's fine if you can recruit others to the task; to the extent that your notes are attempting to do that, that's fine too. To the extent that there is less than a resounding roar of support, the fall-back position is for you to develop a spec and submit it. > >The latter. I had a dream that ISO and Internet would end >up with a common IP that we could both work on. That would Perfectly nice dream. Meanwhile, the clock is ticking and deadlines approach. As with any product development effort, it leaves us with choices of priorities. If you have a solution to the tensions between time, features and development (specification) resources, please do offer it. >I am speaking for SC6. Remember the co-operative agreement. I beg your pardon? Is this supposed to mean that we are under a requirement to satisfy the specific requirement you are stating? If we do not satisfy it, are you suggesting that it will be taken as failing to honor the cooperative agreement? Please clarify. >Please do not tell me that this is political and should be >on some other list. Wouldn't dream of it. We have enough difficulties just coordinating specification efforts and trying to meet our agreed delivery dates. Wouldn't think there was TIME for very much politics. What prompts you to raise this point? Dave -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 14 15:17:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19988; Wed, 14 Sep 94 15:17:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19982; Wed, 14 Sep 94 15:16:57 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16523; Wed, 14 Sep 94 15:13:51 PDT Received: from nic.ott.hookup.net by Sun.COM (sun-barr.Sun.COM) id AA02797; Wed, 14 Sep 94 15:13:27 PDT Received: from [165.154.16.159] (kgk.ott.hookup.net [165.154.16.159]) by nic.ott.hookup.net (8.6.9/1.37) with SMTP id SAA02421; Wed, 14 Sep 1994 18:13:14 -0400 Message-Id: <199409142213.SAA02421@nic.ott.hookup.net> X-Sender: kgk@nic.ott.hookup.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Sep 1994 18:14:47 -0500 To: ipng@sunroof.Eng.Sun.COM From: kgk@hookup.net (Keith G Knightson) Subject: (IPng) Canadian OSI NSAP Format Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Gentlemen, For informational purposes I am providing the format used in Canada. The DCC format is used = 3 octets DFI = 1 octet Org Id = 3 octets Reserved = 2 octets RD = 2 octets Area = 2 octets ID = 6 octets sel = 1 octet Total = 20 octets There are no restrictions on the values of RD or Area, so all possible combinations of 2**16 -1 must be assumed. Something like 50 Org Ids have been issued for this format. Many large organizations, the Government, Bell Canada, the National Air Traffic Control System, etc, have been allocated Org Ids. Comments on this scheme would be appreciated, in relation to IP6-16. Regards Keith G Knightson PS. I suggest we set up a new group called Black_Hole @........ for all this OSI nonsense. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 14 23:19:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20655; Wed, 14 Sep 94 23:19:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20649; Wed, 14 Sep 94 23:19:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11469; Wed, 14 Sep 94 23:16:29 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA01161; Wed, 14 Sep 94 23:16:08 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24131; Thu, 15 Sep 1994 08:16:05 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA08796; Thu, 15 Sep 1994 08:16:03 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409150616.AA08796@dxcoms.cern.ch> Subject: Re: (IPng) Canadian OSI NSAP Format To: ipng@sunroof.Eng.Sun.COM Date: Thu, 15 Sep 1994 08:16:03 +0200 (MET DST) In-Reply-To: <199409142213.SAA02421@nic.ott.hookup.net> from "Keith G Knightson" at Sep 14, 94 06:14:47 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 546 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Keith, > > For informational purposes I am providing the format used in Canada. > > The DCC format is used = 3 octets > DFI = 1 octet > Org Id = 3 octets > Reserved = 2 octets > RD = 2 octets > Area = 2 octets > ID = 6 octets > sel = 1 octet > Thanks. I don't know what the DFI is. If it is by chance a constant you can drop it. If not you would have to squeeze the Org ID to 2 bytes, and in any case you drop the reserved bytes. Then you can fit into the format of draft-carpenter-ip6-nsap-map-00.txt. I don't see a problem here. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 15 01:54:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20710; Thu, 15 Sep 94 01:54:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20704; Thu, 15 Sep 94 01:54:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18369; Thu, 15 Sep 94 01:51:34 PDT Received: from post.demon.co.uk by Sun.COM (sun-barr.Sun.COM) id AA15598; Thu, 15 Sep 94 01:51:14 PDT Received: from peeras.demon.co.uk by post.demon.co.uk id aa03746; 15 Sep 94 9:33 GMT-60:00 Date: Thu, 15 Sep 94 07:07:33 GMT From: Phil Royse Message-Id: <1726@peeras.demon.co.uk> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: IPng Numbers of NSAPs X-Mailer: PCElm 1.09 Lines: 57 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message Dave Crocker writes: [stuff deleted...on OSI...] > Perfectly nice dream. Meanwhile, the clock is ticking and deadlines > approach. As with any product development effort, it leaves us with > choices of priorities. Yes, and in the debate: "Do we need to take deployed NSAPs into consideration?" I am convinced that the answer is "No". > >I am speaking for SC6. Remember the co-operative agreement. > > I beg your pardon? Is this supposed to mean that we are under a > requirement to satisfy the specific requirement you are stating? If we do > not satisfy it, are you suggesting that it will be taken as failing to > honor the cooperative agreement? Please clarify. I think this means that we should be friendly to SC6 and not to marginalise, ignore or otherwise criticise 20-octet NSAPs. But IP6 address space is too valuable not to conserve it wisely. I cannot speak for the UK, but I can speak of it: 1. There is a negligible quantity of ESs running CONS or CLNS in the UK. 2. What few networks of CLNP (or ISO 8878) there are exist in experimental, closed or other speciality environments (ATC, Telecomms Switching & Transmission Control etc.). 3. There are no government departments, of which I know, which are actually planning to implement OSI transport based applications solutions (with only X.400 and FTAM realistically available). 4. However, UK govt depts are obliged to announce that they are following GOSIP 4 and EC/87/95. They give the impression that they are buying OSI, no more than that. Bi-directional mapping is good enough to cater for all the UK NSAPs. > ...... We have enough difficulties just coordinating > specification efforts and trying to meet our agreed delivery dates. > Wouldn't think there was TIME for very much politics. What prompts you to > raise this point? > > Dave Yes. Please take this input as further justification for ignoring NSAPs and getting on with the real engineering problems. -- Phil Royse | Comms Consultant. TUDOR HOUSE | proyse@peeras.demon.co.uk 12 Woodside Road Purley, Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 15 08:09:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20897; Thu, 15 Sep 94 08:09:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20890; Thu, 15 Sep 94 08:09:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29182; Thu, 15 Sep 94 08:06:26 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA21722; Thu, 15 Sep 94 08:06:05 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA23829; Thu, 15 Sep 1994 16:55:10 +0200 Message-Id: <199409151455.AA23829@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Cc: Tony Li , ip-ng@sunroof2.Eng.Sun.COM Subject: Re: (IPng) Re: source routing & authentication In-Reply-To: Your message of "Mon, 29 Aug 1994 08:53:53 CDT." <9408290853.ZM6661@sundance.itd.nrl.navy.mil> Date: Thu, 15 Sep 1994 16:55:08 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, I have a lot of sympathy for your concern vs source route and authentication. There are two reasons why we want to do this, i.e. the usage of ressources by arbitrary routing and the need in some cases to "reverse the source route". We all know the second problem, so I will just mention the first one. I do not believe that a router should blindly execute any source routing request. Policy based routing requirements (as met by IDPR, SDRP) suppose that before relaying the router checks whether the source is authorized to use the transit networks. This supposes that the source address can be checked. One should however not forget (1) the performance requirements and (2) the requirements on the key exchange mechanism. As Tony mentioned, routers are very likely to only check a small fraction of the packets. They can for example "cache" the source + flow-id combination which have been checked. On the other hand, the sender cannot predict which packets will be checked and which will not be: they must all be signed. Thus, if we have to chose, we should be sure that we optimize for ease of signature... Authentication requires a key exchange. The results of the IAB retreat were very clear there: the same key is used by all points in the source route. Any idea how to do that without requiring monstruous signalisation exchanges? Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 15 08:09:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20896; Thu, 15 Sep 94 08:09:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20884; Thu, 15 Sep 94 08:09:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29174; Thu, 15 Sep 94 08:06:21 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA21710; Thu, 15 Sep 94 08:06:01 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA23829; Thu, 15 Sep 1994 16:55:10 +0200 Message-Id: <199409151455.AA23829@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Cc: Tony Li , ip-ng@sunroof2.Eng.Sun.COM Subject: Re: (IPng) Re: source routing & authentication In-Reply-To: Your message of "Mon, 29 Aug 1994 08:53:53 CDT." <9408290853.ZM6661@sundance.itd.nrl.navy.mil> Date: Thu, 15 Sep 1994 16:55:08 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, I have a lot of sympathy for your concern vs source route and authentication. There are two reasons why we want to do this, i.e. the usage of ressources by arbitrary routing and the need in some cases to "reverse the source route". We all know the second problem, so I will just mention the first one. I do not believe that a router should blindly execute any source routing request. Policy based routing requirements (as met by IDPR, SDRP) suppose that before relaying the router checks whether the source is authorized to use the transit networks. This supposes that the source address can be checked. One should however not forget (1) the performance requirements and (2) the requirements on the key exchange mechanism. As Tony mentioned, routers are very likely to only check a small fraction of the packets. They can for example "cache" the source + flow-id combination which have been checked. On the other hand, the sender cannot predict which packets will be checked and which will not be: they must all be signed. Thus, if we have to chose, we should be sure that we optimize for ease of signature... Authentication requires a key exchange. The results of the IAB retreat were very clear there: the same key is used by all points in the source route. Any idea how to do that without requiring monstruous signalisation exchanges? Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 15 09:29:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20949; Thu, 15 Sep 94 09:29:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20943; Thu, 15 Sep 94 09:29:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05337; Thu, 15 Sep 94 09:25:56 PDT Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA07187; Thu, 15 Sep 94 09:25:31 PDT Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA02724 for ipng@sunroof.eng.sun.com; Thu, 15 Sep 94 12:25:15 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA01372; Thu, 15 Sep 1994 09:24:27 -0700 Message-Id: <199409151624.JAA01372@aland.bbn.com> To: J.Houldsworth@ste0906.wins.icl.co.uk Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Numbers of NSAPs In-Reply-To: Your message of Mon, 12 Sep 94 12:54:03 +0100. <"3687*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> From: Craig Partridge Date: Thu, 15 Sep 94 09:24:19 -0700 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack: I've only gotten to pick up this thread on NSAPS after three weeks of travel and then got to read it all at once. My sense is that some of this discussion has been a procedural misunderstanding. As I understand your most recent note to Dave Crocker, you believe the proposed NSAP mapping schemes currently under discussion do not work. Technically speaking that's very useful input, but procedurally if you want to get anything done, you (or someone) needs to draft the proposed IP6 option (or whatever) to achieve the mapping you desire and then submit it for approval. In the absence of written text, the IETF typically doesn't do much. Good luck! Craig ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 15 23:55:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21336; Thu, 15 Sep 94 23:55:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21330; Thu, 15 Sep 94 23:55:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04385; Thu, 15 Sep 94 23:52:23 PDT Received: from bunyip.cc.uq.oz.au by Sun.COM (sun-barr.Sun.COM) id AA00522; Thu, 15 Sep 94 23:52:03 PDT Received: from clix.aarnet.edu.au by bunyip.cc.uq.oz.au with SMTP (PP); Fri, 16 Sep 1994 14:21:29 +1000 X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 16 Sep 1994 14:16:47 +1000 X400-Received: by /PRMD=AUSGOVDEFENCENET/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 16 Sep 1994 14:13:38 +1000 Date: Fri, 16 Sep 1994 14:13:38 +1000 X400-Originator: Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au X400-Recipients: IPNG@SUNROOF.ENG.SUN.COM X400-Mts-Identifier: [/PRMD=AUSGOVDEFENCENET/ADMD=TELEMEMO/C=AU/;40A 940916141327] X400-Content-Type: P2-1984 (2) Content-Identifier: 40A 940916141327 From: Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au Message-Id: <"40A 940916141327*"@MHS> To: IPNG@SUNROOF.Eng.Sun.COM (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: (IPng) Australian NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Gentlemen, Here is more information regarding NSAP structures as used in Australia. Australia allows both ICD and DCC formats - ICD is preferred. The ICD/DCC format is used = 3 octets Ver = 1 octet Org Id = 2 octets Reserved = 3 octets RD = 2 octets Area = 2 octets ID = 6 octets sel = 1 octet Australia Defence Force has its own ICD and only allows use of ICD. The ICD format is used = 3 octets Ver = 1 octet Org Id = 2 octets Reserved = 2 octets ** use of one Res field as a special qualifier RD field RD = 3 octets Area = 2 octets ID = 6 octets sel = 1 octet Total = 20 octets There are no restrictions on the values of RD or Area, so all possible combinations of 2**16 -1 must be assumed. Something like 150 Org Ids have been issued for the Australian format. Many large organisations. >PS. I suggest we set up a new group called Black_Hole @........ for all >this OSI nonsense. I think this is derogatory, a better one would be: convergence@ or harmonisation@ Because this, I hope is what we are trying to achieve. Kim@oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 16 03:14:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21495; Fri, 16 Sep 94 03:14:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21489; Fri, 16 Sep 94 03:14:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12129; Fri, 16 Sep 94 03:11:10 PDT Received: from post.demon.co.uk by Sun.COM (sun-barr.Sun.COM) id AA28986; Fri, 16 Sep 94 03:10:49 PDT Received: from peeras.demon.co.uk by post.demon.co.uk id aa12767; 16 Sep 94 9:58 GMT-60:00 Date: Fri, 16 Sep 94 08:53:24 GMT From: Phil Royse Message-Id: <1731@peeras.demon.co.uk> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Australian NSAPs X-Mailer: PCElm 1.09 Lines: 81 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message <"40A 940916141327*"@MHS> Kim.Fenley@aditcs.cm-dimp.hqadf. defencenet.gov.au writes: > > Australia allows both ICD and DCC formats - ICD is preferred. > > The ICD/DCC format is used = 3 octets > Ver = 1 octet > Org Id = 2 octets > Reserved = 3 octets > RD = 2 octets > Area = 2 octets > ID = 6 octets > sel = 1 octet > IMHO, the setting of a specific length for all the NSAPs in a country, or even one organisation above the routing domain is ill-advised. There is no need for it. NSAPs need only have a fixed length SID **within any domain** (re: ISO 10589, with concepts derived from TR 9575)). The implicit philisophy of NSAP allocation and semantics (which I have not seen articulated anywhere) is that each level in the hierarchy need only specify the "identifier" of the next level down. Therefore, all that the top level (i.e. your govt./registration authority) needs to do is to give you an AFI, IDI and an Organisation ID. Your organisation is responsible for the semantics of the octets following what you are given in your addresses, nobody else. Therefore, if the RD manager chooses to allocate 1, 2 or 3 octets for Area ID, that's his/her freedom of choice. It is unecessary and impertinent for the top level to proscribe the rest of your NSAP structure, especially to tell you to reserve three octets at the beginning of **YOUR** RD identifier. (In actuality, these three reserved octets must be given real values (00 to FF?.) Therefore, by definition, when given to you by the Reg Authority, they become part of the Org ID whether you or they like it or not.) Note that even if the Australian Registration Authority started using the 3 reserved octets for anything (after you were using your addresses and putting (say) FF.FF.FF in that space in your addresses) this would have zero affect on your domain.... your NSAPs would still be carrying this useless payload. They are committing your packets to carry 48 bits of fresh air, in order for the registration authority to reserve the right to address 16*5 other organisations. This is wrong. I argued through this point when developing the NSAP structure for a major service in the UK. After the Org ID, which was given us by the Reg Authority, we have chosen 2 octets of RD and 2 octets of Area ID, giving a 16-octet (max) NSAP (for our service). This gives us 64k routing domains and 64k areas.... sufficient, we think. But even then, (if OSI transport is installed anywhere) we are only going to give out RDs, plus the rule that the RD manager must ensure unique Area numbers and fixed length SIDs in his/her domain (to meet ISO 10589 needs). IMHO, Australia, Canada and UK GOSIP have prescribed the wrong NSAP structure. They don't need to mandate length and the reserved space is uneccessary. However, the fact that these points have not been noticed, nor any problems arisen, is indication that not much CONS or CLNS routing is actually taking place.... ...which brings us round full circle to the point that NSAPs need not be taken into consideration for the semantics of IP6 addresses. I think a look-up table (NSAP<->IP6addr) would be adequate for all the NSAPs used in the UK. If my estimates are very inaccurate, then Brian Carpenters' 16-octet NSAP mapping can be used when needed. Phil -- Phil Royse | Comms Consultant. TUDOR HOUSE | proyse@peeras.demon.co.uk 12 Woodside Road Purley, Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 16 03:51:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21520; Fri, 16 Sep 94 03:51:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21514; Fri, 16 Sep 94 03:50:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13549; Fri, 16 Sep 94 03:47:45 PDT Received: from carmen.logica.co.uk by Sun.COM (sun-barr.Sun.COM) id AA01639; Fri, 16 Sep 94 03:47:05 PDT Received: from smtpmail.logica.com (mssmtp.logica.com) by carmen.logica.co.uk (4.1/SMI-4.1) id AA12714; Fri, 16 Sep 94 11:47:19 BST Received: by smtpmail.logica.com with Microsoft Mail id <2E798603@smtpmail.logica.com>; Fri, 16 Sep 94 11:48:19 bst From: Fieldhouse Dirk To: 'IPng mailing list' Subject: Re: (IPng) Numbers of NSAPs Date: Fri, 16 Sep 94 11:47:00 bst Message-Id: <2E798603@smtpmail.logica.com> Encoding: 58 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ---------- From: Fieldhouse Dirk To: 'IPng mailing list' Cc: 'Crocker Dave'; Houldsworth Jack Subject: RE: Re: (IPng) Numbers of NSAPs Date: 14 September 1994 18:00 dcrocker@mordor.stanford.edu (Crocker Dave) wrote: > Jack, > > To respond to your response: > > At 6:54 AM 9/12/94, J.Houldsworth@ste0906.wins.icl.co.uk wrote: [Apparently no time zone compensation here?] > >I am asking for the ability to carry the full 20 byte NSAP, > > Do you have a proposal or, better still, a spec to submit for this? Apart from the obvious but plainly technopolitically incorrect idea of a 20 byte address field, it looks like we need NSAP-(source/dest)-address-extension options for the IP6 end-to-end options header. You'd only need them for addresses not handled by the Carpenter-Bound proposal/kluge/whatever. But, what would go in the IP6 address field when this option is used to carry the full NSAP address? It has to be something that will get routed sensibly in the IP6 world. The first n bytes of the NSAP address might be adequate for this purpose. If n>=13, this includes all of the NSAP address needed to route to an area (CLNS) or subnetwork (CONS) in the address schemes I know about. Are there any objections to the IP6 address field holding something that is not a complete network address? [-- snip --] > >Please do not tell me that this is political and should be > >on some other list. > > Wouldn't dream of it. We have enough difficulties just coordinating > specification efforts and trying to meet our agreed delivery dates. > Wouldn't think there was TIME for very much politics. What prompts you to > raise this point? Now I don't believe this. Any time Jack mentions the idea that IPng might do well to support those horrid old 20-byte NSAP addresses to promote IETF's cooperation with SC6 he gets positive solar flares complaining that this is politics and getting in the way of real technical work. You _were_ being ironic, right? Dirk Fieldhouse Logica UK Limited fieldhouse@lgwct.logica.com 68 Newman St c=gb;a=tmailuk;p=logica; London W1A 4SE ou1=lgwct;s=fieldhouse UK +44 (171) 637 9111 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 16 04:19:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21545; Fri, 16 Sep 94 04:19:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21539; Fri, 16 Sep 94 04:19:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14470; Fri, 16 Sep 94 04:16:38 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03061; Fri, 16 Sep 94 04:16:18 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA23764; Fri, 16 Sep 94 04:13:43 -0700 Received: by xirtlu.zk3.dec.com; id AA20558; Fri, 16 Sep 1994 07:09:53 -0400 Message-Id: <9409161109.AA20558@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: (ngtrans) RE: (IPNG) NUMBERS OF NSAPS In-Reply-To: Your message of "15 Sep 94 08:53:34 +1000." <"940915 07:20:16"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> Date: Fri, 16 Sep 94 07:09:47 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, First this was to ngtrans and NSAPs should be discussed on ipng list. PLease use one list so I don't have to read your mail twice. Also your X.400 interface to SMTP is horrible. I talked to our X.400 experts and showed them your mail and they told me it could be more friendly. It is very poor to receive your X.400 UI. Second Brian and I have sent out an ID on NSAPS. We have received much input and there will be a BOF at the next IETF meeting. We have stated the objective of that ID. If you don't like it write a new ID. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 16 04:50:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21565; Fri, 16 Sep 94 04:50:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21559; Fri, 16 Sep 94 04:50:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15508; Fri, 16 Sep 94 04:47:26 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA04935; Fri, 16 Sep 94 04:47:05 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18742; Fri, 16 Sep 1994 13:47:03 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA15436; Fri, 16 Sep 1994 13:47:01 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409161147.AA15436@dxcoms.cern.ch> Subject: Re: (IPng) Numbers of NSAPs To: ipng@sunroof.Eng.Sun.COM Date: Fri, 16 Sep 1994 13:47:00 +0200 (MET DST) In-Reply-To: <2E798603@smtpmail.logica.com> from "Fieldhouse Dirk" at Sep 16, 94 11:47:00 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 110 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dirk, Dan Harrington has already proposed the same thing as you in private mail. Watch this space. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 16 11:47:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21729; Fri, 16 Sep 94 11:47:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21723; Fri, 16 Sep 94 11:47:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14585; Fri, 16 Sep 94 11:44:21 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA12578; Fri, 16 Sep 94 11:42:08 PDT Received: from muggsy.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA04034; Fri, 16 Sep 94 11:11:58 -0700 Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA29434; Fri, 16 Sep 1994 14:10:23 -0400 Received: by netrix.lkg.dec.com; id AA18959; Fri, 16 Sep 1994 14:11:17 -0400 Date: Fri, 16 Sep 1994 14:11:17 -0400 From: Dan Harrington Message-Id: <9409161811.AA18959@netrix.lkg.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Another NSAP addressing proposal Cc: dan@netrix.lkg.dec.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The following is a proposal that I developed after taking some time to read the various IPng/SIPP16 specs available, and the Carpenter/Bound NSAP/IP6 usage draft. I would like to state two things up front: - I'm new at this IETF/Internet thing, and I don't know IP all that well, so please bear with me and be patient. I would very much appreciate any constructive criticism and feedback about it, especially if my assumptions are way out of whack. - I am not an OSI bigot. I am not trying to pursue any sort of OSI agenda. I fully agree with the statement made in the abstract of the Carpenter/Bound draft: "...network implementors...should redesign a native IP6 addressing plan to meet their needs." However, I do feel that this proposal has some merit, as there are undoubtedly people and organizations which have some made investment in addressing plans based on NSAPs. I think that the future of internetworking would be better served via accomodation and transition, rather than dismissing the issue as "trivial". You catch more flies with honey than with vinegar. Sorry for the long introduction, but having followed this topic for the past month, and I felt it important to state my position. Finally, it will quickly become obvious that the following is not a finished spec, by any stretch of the imagination. It's just a proposal...if it is deemed to be useful, it could be expanded and polished. Dan P.S. A very large "Thank You" to Dirk Fieldhouse for proposing the same sort of idea, which finally convinced me that I wasn't completely nuts. ============================================================================== Fitting 20 pounds of flour in a 16 pound sack. Abstract: The following proposal offers a mechanism by which Network Service Access Point addresses (NSAPs) may be utilized in an IP6 routing environment, by means of two techniques found in the IP6 architecture: extension headers and cluster addresses. It differs from the proposal offerred in the Internet Draft "Recommendations for OSI NSAP usage in IP6" by B. Carpenter and J. Bound, but it is not necessarily meant as a wholesale replacement of that draft, merely as an alternative. Introduction: The problem at hand is how 20 octet NSAP addresses can be utilized in a network which utilizes an IP6 routing infrastructure. Please note the following two points: - The problem is really 19=>15, as the final octet of the NSAP is equivalent to the protocol identifier in IP/IP6, and the first octet of the IP6 address is used to flag the address as being of type "NSAP". - 20 octet NSAP addresses are a subset of the potential set of NSAP addresses. There is no requirement that NSAPs must use the maximum permissible number of octets, and many addressing plans use fewer than 20. Some plans do call for the use of all 20 octets, however. [See RFC 1629, Colella et al, for examples] The proposed mechanism does not differentiate between NSAPs based on length. NSAP addresses can be logically divided into two parts, as per ISO 10589. Area Address + Node ID/Selector By Area Address I refer to the IDP + High Order DSP + Local Area. For intra- and inter- network routing the Area Address is of most interest, in terms of getting the data to the destination local area (which I believe is roughly equivalent to a subnet?). For example, consider the following example NSAP: 47:0005:80:005A00:0000:0001:E137:080020079EFC:1E < Area Address > < Node ID/Sel > For the purposes of getting data to this system, the area address is used to get to the correct network, routing domain, and finally the local area, and the Node ID is used within that area to get to the correct node. The node uses the selector field to figure out which protocol/transport/service gets the packet. The key elements of my proposal are the following: - Use the NSAP Area Address as a SIPP cluster address within a standard SIPP header. - Create new extension header to hold complete NSAP addresses. - Map the NSAP directly, rather than converting the AFI to an AF-code. This is for readability, mainly...NSAPs are obtuse enough without compressing the AFI to an AFcode, and dropping assumed values. Because SIPP cluster addresses appear (to me) to be a means of using address prefixes as a destination address, in order to get from area to area, or even network to network, this seems an appropriate use. The means of converting the NSAP to cluster address would be to zero the Node ID and Selector field, and truncate to a length of 15 octets. The NSAP Allocation Format Prefix would then be prepended to form an IP6 address. Example: The following diagram uses example NSAPs meant to represent my workstation and a fictional system in France. Source NSAP = 41:45418715:00-41:08-00-2B-18-B5-33:21 Dest NSAP = 39:250:00-00-00-00-00-00-00-01-19-91:08-00-2B-06-E3-F4:00 [Note: The IP6 Format Prefix D0 (1100 0000) is used below, although I have been told that this might not be the final value for NSAPs.] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | D0:41:45418715:00-41:: | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | D0:39:250F:00-00-00-00-00-00-00-01-19-91:: | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Note: I have not attempted to be completely faithful to octet boundaries for the example NSAPS below.] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | NSAP ID | Total Length |Source NSAP Len| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + Source NSAP + | 41:45418715:00-41:08-00-2B-18-B5-33:21 | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest NSAP Len | | +-+-+-+-+-+-+-+-+ + | | + Destination NSAP + | 39:250:00-00-00-00-00-00-00-01-19-91:08-00-2B-06-E3-F4:00 | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Some possible advantages offered by this scheme are: - No need for special processing by IP6 routers (for transit). - No loss of addressing information (it's all there somewhere). - Allows NSAP capable transports (e.g. OSI Transport, NSP) to run over IP6 with no special conversion (or even mapping, though that would obviously be permitted). - Note that any and all NSAP formats would be permitted in this approach. I do not feel that the exclusion of any AFI values is appropriate. There are also issues which make this proposal less than ideal: - Extra processing overhead within local area (but only for those cases where NSAP addressing plan is retained). - Violation of SIPP constraint against using cluster address as source address. [Francis, et al, s. 2.3.5] - Does not fully handle case where 20 octet NSAP addressing plan is desired as the IP6 addressing plan, e.g. for autoconfiguration (but neither does the current proposal...in fact, native addressing plans are strongly encouraged in both proposals). Open questions: - How would the header extension for this scheme fit into the proposed hierarchy of header extension order [Deering, sect 4.1], and how would/could it interact with other extension types? - This mapping appears to make sense for CLNP <=> IP6 interactions, but do CONS/X.25 networks (and/or subnets) need to be considered? - The Node ID field can be from 1 to 8 octets in length (ISO 10589), though 6 octets is the typical value. Is this an issue? Should the Node ID field just be zero'd according to the length in use at the source routing domain? Contact Info: Dan Harrington Digital Equipment Corp. 550 King Street (LKG2-2/Q9) Littleton, MA 01460 1+ 508 486-7643 dan@netrix.lkg.dec.com Thanks for Brian Carpenter and Jim Bound for reviewing this initially. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 17 02:34:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22032; Sat, 17 Sep 94 02:34:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22026; Sat, 17 Sep 94 02:34:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04103; Sat, 17 Sep 94 02:31:13 PDT Received: from coombs.anu.edu.au by Sun.COM (sun-barr.Sun.COM) id AA17107; Sat, 17 Sep 94 02:30:53 PDT Message-Id: <9409170930.AA17107@Sun.COM> Received: by coombs.anu.edu.au (1.37.109.8/16.2) id AA20590; Sat, 17 Sep 1994 19:27:59 +1000 From: Darren Reed Subject: Re: (IPng) Re: Automatic Renumbering To: ipng@sunroof.Eng.Sun.COM Date: Sat, 17 Sep 1994 19:27:58 +1000 (EST) In-Reply-To: <9408250922.aa17195@nic.near.net> from "John Curran" at Aug 25, 94 09:22:05 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2052 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > At 10:05 PM 8/23/94 -0400, bound@zk3.dec.com wrote: > >Ouch this brings up heartburn for me. Today we have a class A address. > >We pay a provider to route in/out. Why with IP6 is the model changing? > >Or is it not changing? Why would a provider have anything to say about > >anyones address. They just route packets. > > Hmm. Providers do a lot more than "just route packets", but that's a > different discussion for a different mailing list. > > Jim, in order to "just route packets", providers need to maintain routing > tables. These routing tables have a cost, and historically this cost was > not directly visible to the organization connecting to the Internet. > > I imagine that sometime in the near future such costs _will_ be visible > (or, at least, they will be visible to those organizations which contribute > disproportionately to the size of the overall routing tables. :-) At that > time, folks will have an incentive to not generate routing table entries... > i.e. to renumber into the provider's address space. Software that supports > autoconfiguration (and even better: auto-re-configuration) will be highly > desired as a result. Can I ask, how will renumbering (automatic or otherwise) affect in-use source routes ? I assume this would be part of the software's problem of handling the renumbering, correct ? What happens to a source route if it dictates that packets should pass through a network that if it should renumber would not affect the numbering of the end hosts ? (ie source route becomes obselete). Then if another network is renumbered to where your source route passes through, you're now routing through a network, which although is present, is not the same as when you first started out. A rather bizarre set of situations indeed, but this is how many crackers `make their money'- out of operating systems or programs "misbehaving" in strange situations. Although, I guess if you are worried about this and packet contents, you'd be using encryption on packet contents anyway... Darren ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 19 08:39:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22439; Mon, 19 Sep 94 08:39:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22427; Mon, 19 Sep 94 08:39:29 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27959; Mon, 19 Sep 94 08:36:20 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA07064; Mon, 19 Sep 94 08:35:59 PDT Received: from Bill.Simpson.DialUp.Merit.edu (pm002-23.dialip.mich.net [35.1.48.104]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA24436 for ; Mon, 19 Sep 1994 11:35:57 -0400 Date: Mon, 19 Sep 94 14:24:56 GMT From: "William Allen Simpson" Message-Id: <3211.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: Automatic Renumbering Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Darren Reed > Can I ask, how will renumbering (automatic or otherwise) affect in-use > source routes ? > A very clever question, which I have never heard addressed! Here's my attempt at an answer. Under SIPP, any renumbering assumed that there was still an "identifying-address" which remained the same for very long periods. Source specified routes were only in the link establishment packets, and after that the Flow was used. Renumbering was easy! Under the assumptions of IPng (big addresses to allow sparse assignment), there is much more topology in the address, which changes all the time in the routing environment. No identifying-address, so the Address-Flow pairing can be disrupted. However, because the topology information is very sparse, renumbering could aways go to an unused prefix, allowing detection of failed source specified routes. That still means we need some fancy ICMP message to indicate that the numbering has changed, and this will affect transport layers such as TCP. Could be hard! Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 19 08:39:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22440; Mon, 19 Sep 94 08:39:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22433; Mon, 19 Sep 94 08:39:33 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27970; Mon, 19 Sep 94 08:36:23 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA07067; Mon, 19 Sep 94 08:36:02 PDT Received: from Bill.Simpson.DialUp.Merit.edu (pm002-23.dialip.mich.net [35.1.48.104]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA24442 for ; Mon, 19 Sep 1994 11:35:59 -0400 Date: Mon, 19 Sep 94 14:34:28 GMT From: "William Allen Simpson" Message-Id: <3212.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) next hop resolution Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have two conflicting reviews of Neighbor Discovery next hop resolution. Currently, whenever a router is discovered, a host sends all packets to the preferred router. That router then sends a redirect to the host if the target host is actually on the same link (let's call this "host redirect"). This is in addition to the IPv4 mechanism where the router redirects to another router (let's call this "router redirect"). Also, the routers advertise the various Cluster prefixes on the links. This has several uses: - different organizations choose different preferred routers (as in RFC-1256). - multi-homed hosts choose the right link based on "best match". - the prefix information is used in self-configuration. Dave Katz is happy with the router plus host redirect mechanism, but wants all prefix advertisement to be removed. He wants hosts which are ignorant of prefixes. He also wants prefixes which span multiple links (like ES-IS Areas). He has another plan in mind for self-configuration, which apparently involves the routers doing the assignment. I'll call this the "dumb host - big router" model. Alex Conta wants to use the prefix information to allow the host to determine whether the target host is on the same link. This is more like IPv4, and eliminates the redirect in most cases. It also eliminates a fair amount of router involvement in local traffic. I'll call this the "smart host - small router" model. Alex cites his experience with DECnet ES-IS. There were problems getting the redirect to work. Some of that may have had to do with the ES-IS Areas. The counter argument is that there are fewer routers, and getting it to work in routers may be easier than in the many hosts. Alex correctly points out that if the code has to work in multi-homed hosts, then all hosts will need the algorithm anyway, so we still have to get it right. ---- Right now, I'm with Alex. I'd like to take the next hop determination back to smarter IPv4-like hosts. However, we still need both "router redirect" and "host redirect" for mobility. A router can redirect a host to a mobile host which doesn't appear in the advertised prefixes. SIPP explicitly rejected ES-IS Areas. I don't think we need to debate this again. Since we need the prefixes for multi-homed hosts, we might as well use them for next hop resolution. Since we have the prefixes, we should keep the same self-configuration methods, and get Dave to concentrate on auto-registration instead. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 19 09:28:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22485; Mon, 19 Sep 94 09:28:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22479; Mon, 19 Sep 94 09:28:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02102; Mon, 19 Sep 94 09:25:00 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA16801; Mon, 19 Sep 94 09:24:28 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA10696; Mon, 19 Sep 1994 18:26:40 +0200 Message-Id: <199409191626.AA10696@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) next hop resolution In-Reply-To: Your message of "Mon, 19 Sep 1994 14:34:28 GMT." <3212.bill.simpson@um.cc.umich.edu> Date: Mon, 19 Sep 1994 18:26:39 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, Could you precise the reasons why you would want to avoid router redirects? Is it related to blackholes? Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 19 11:46:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00308; Mon, 19 Sep 94 11:46:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00302; Mon, 19 Sep 94 11:45:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15392; Mon, 19 Sep 94 11:42:46 PDT Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA20815; Mon, 19 Sep 94 11:42:23 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id LAA11248; Mon, 19 Sep 1994 11:42:19 -0700 Date: Mon, 19 Sep 1994 11:42:19 -0700 From: Dave Katz Message-Id: <199409191842.LAA11248@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "William Allen Simpson"'s message of Mon, 19 Sep 94 14:34:28 GMT <3212.bill.simpson@um.cc.umich.edu> Subject: (IPng) next hop resolution Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 19 Sep 94 14:34:28 GMT From: "William Allen Simpson" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have two conflicting reviews of Neighbor Discovery next hop resolution. Currently, whenever a router is discovered, a host sends all packets to the preferred router. That router then sends a redirect to the host if the target host is actually on the same link (let's call this "host redirect"). This is in addition to the IPv4 mechanism where the router redirects to another router (let's call this "router redirect"). Also, the routers advertise the various Cluster prefixes on the links. This has several uses: - different organizations choose different preferred routers (as in RFC-1256). - multi-homed hosts choose the right link based on "best match". - the prefix information is used in self-configuration. Dave Katz is happy with the router plus host redirect mechanism, but wants all prefix advertisement to be removed. He wants hosts which are ignorant of prefixes. He also wants prefixes which span multiple links (like ES-IS Areas). He has another plan in mind for self-configuration, which apparently involves the routers doing the assignment. I'll call this the "dumb host - big router" model. Alex Conta wants to use the prefix information to allow the host to determine whether the target host is on the same link. This is more like IPv4, and eliminates the redirect in most cases. It also eliminates a fair amount of router involvement in local traffic. I'll call this the "smart host - small router" model. Alex cites his experience with DECnet ES-IS. There were problems getting the redirect to work. Some of that may have had to do with the ES-IS Areas. This is news to me. I haven't seen any problems in the field with this mechanism. Hosts do need to be careful to discard the redirect entry when either the holding time expires, or the router to which they were redirected goes down (known because it stops announcing itself), of course. If there's hard technical info about this, I'd like to hear it. The counter argument is that there are fewer routers, and getting it to work in routers may be easier than in the many hosts. Also, don't underestimate the fact that routers are usually under a single (or at least fairly coordinated) administration, whereas hosts often have as many adminstrators as machines. Alex correctly points out that if the code has to work in multi-homed hosts, then all hosts will need the algorithm anyway, so we still have to get it right. Advertising prefixes alone is insufficient for multihomed hosts to make intelligent routing decisions, as the destination may well not have anything in common with either prefix. The multihomed host needs to get real routing information (and even then ultimately has to make an educated guess, especially in the face of aggregation.) In such cases I advocate a route-request model; the host asks for route information out each of its interfaces and the routing infrastructure gives it hints (such as the length of the prefix that the route request matched, and any metric information). Note that even this information may make it impossible to make an informed decision (suppose it matched a zero-length prefix on both sides...) It's a hard problem... ---- Right now, I'm with Alex. I'd like to take the next hop determination back to smarter IPv4-like hosts. However, we still need both "router redirect" and "host redirect" for mobility. A router can redirect a host to a mobile host which doesn't appear in the advertised prefixes. SIPP explicitly rejected ES-IS Areas. I don't think we need to debate this again. Since we need the prefixes for multi-homed hosts, we might as well use them for next hop resolution. Since we have the prefixes, we should keep the same self-configuration methods, and get Dave to concentrate on auto-registration instead. I've been pushing for an explicit decoupling between host knowledge/first hop routing and the overall routing paradigm. This is why I'm strongly in favor of the "dumb host" model. The more intelligence you build into the hosts, the more you will be locked into a routing world view, and the less flexibility you end up with. I don't believe that OSPF-and-subnets is necessarily where we're going to be forever, and it behooves us to try not to eliminate future possibilities by building in restrictions now, especially if the flexibility has a low cost. (For instance, redirects can be refreshed in the face of reverse traffic given symmetric first/last hop routing; this tends to be true especially if the host is on the same wire--this reduces the redirect load to one per conversation, more or less. And I pointed out to Bill a mechanism whereby the possibility of prefixes that span multiple wires could be supported without any cost to networks that use a prefix-to-wire binding.) ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 19 11:54:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00347; Mon, 19 Sep 94 11:54:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00338; Mon, 19 Sep 94 11:54:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16207; Mon, 19 Sep 94 11:51:15 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA22801; Mon, 19 Sep 94 11:50:46 PDT To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) Discovery Date: Mon, 19 Sep 94 19:50:50 GMT From: Ran Atkinson Message-Id: <9409191950.aa04465@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I agree with Alex (and the other folks at Digital) that hosts *do* need to know the routing prefix. I also prefer the "smart host, small router" approach (as the term was used by Bill Simpson). It would be productive if folks closely examined their code and Bill's recent drafts for implementation issues and for provided capabilities. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 19 12:06:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00364; Mon, 19 Sep 94 12:06:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00358; Mon, 19 Sep 94 12:06:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17177; Mon, 19 Sep 94 12:03:32 PDT Received: from nbkanata.newbridge.com by Sun.COM (sun-barr.Sun.COM) id AA24863; Mon, 19 Sep 94 12:03:08 PDT Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.newbridge.com (4.1/SMI-4.1) id AA01451; Mon, 19 Sep 94 14:57:47 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA08787; Mon, 19 Sep 94 14:57:35 EDT Received: from urchin.newbridge by mako.newbridge (4.1/SMI-4.1) id AA22731; Mon, 19 Sep 94 14:56:37 EDT Received: by urchin.newbridge (5.0/SMI-SVR4) id AA04763; Mon, 19 Sep 1994 14:56:37 +0500 Date: Mon, 19 Sep 1994 14:56:37 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9409191856.AA04763@urchin.newbridge> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery X-Sun-Charset: US-ASCII Content-Length: 770 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The number of problems we have had with "prefix knowledge" is such that I would personally prefer that singly attached hosts NOT pretent to know (nor try to learn) their "prefix". Technologies such as ATM suggest that the prefix match model is not the way to have broadly functioning internetworking in the future. (For clarity, I believe that this argument holds true even if ATM as a specific technology turns out to be completely irrelevant.) Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. PS To put it another way, having hosts "know" or "learn" their "prefix" makes the host part of the routing problem. This makes migration to alternate routing strategies and topologies harder. Evolutionary solutions should help us evolve. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 19 13:10:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00682; Mon, 19 Sep 94 13:10:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00676; Mon, 19 Sep 94 13:10:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23997; Mon, 19 Sep 94 13:06:58 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA08401; Mon, 19 Sep 94 13:06:38 PDT Received: from Bill.Simpson.DialUp.Merit.edu (pm002-16.dialip.mich.net [35.1.48.97]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA18663 for ; Mon, 19 Sep 1994 16:06:36 -0400 Date: Mon, 19 Sep 94 19:33:45 GMT From: "William Allen Simpson" Message-Id: <3215.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) host redirects Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Christian Huitema > Could you precise the reasons why you would want to avoid router > redirects? Is it related to blackholes? > Didn't say anything about avoiding router redirects. The issue that Alex raised was avoiding host redirects. Host redirects are new in Neighbor Discovery (they don't exist in IPv4, except by proxy ARP and such). Host redirects allow multiple subnets on the same link, rather than having a router in the path. Once we had host redirects, someone (perhaps you?) suggested that all initial host traffic go host -> router, and the router would send a host redirect to the true target when needed. I changed to comply. I just had a private message that I can summarize as saying, allow _both_ smart and dumb hosts. Smart hosts will figure out the prefix themselves, dumb hosts will rely on the router to send host redirects. Alex thinks we are using them too much, that they add too much traffic, and they confuse caching. But Alex should argue his own case. He sounded fine on the phone. My current suggestion is that we use them only for visiting mobiles, but I could go with the "both" solution. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 19 15:03:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00823; Mon, 19 Sep 94 15:03:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00817; Mon, 19 Sep 94 15:03:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07091; Mon, 19 Sep 94 15:00:32 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA02705; Mon, 19 Sep 94 14:59:34 PDT Received: from muggsy.lkg.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA03465; Mon, 19 Sep 94 14:28:31 -0700 Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA02752; Mon, 19 Sep 1994 17:08:11 -0400 Received: by netrix.lkg.dec.com; id AA11072; Mon, 19 Sep 1994 17:09:18 -0400 Date: Mon, 19 Sep 1994 17:09:18 -0400 From: Dan Harrington Message-Id: <9409192109.AA11072@netrix.lkg.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) next hop resolution Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Alex cites his experience with DECnet ES-IS. There were problems > getting the redirect to work. Some of that may have had to do with > the ES-IS Areas. > > This is news to me. I haven't seen any problems in the field with > this mechanism. Hosts do need to be careful to discard the redirect > entry when either the holding time expires, or the router to which > they were redirected goes down (known because it stops announcing > itself), of course. If there's hard technical info about this, I'd > like to hear it. I'm very curious too. The only problem I can recall in ES-IS was from our early field test, when it was unclear if NETs (e.g. in ISHello) had a selector of 0, or no selector at all. Mixing the two styles tended to confuse the endsystems when it came to autoconfiguration, and the local area would be wrong. I believe the folks at Boeing ran across this pretty quickly... Dan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 04:30:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01110; Tue, 20 Sep 94 04:30:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01104; Tue, 20 Sep 94 04:30:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26472; Tue, 20 Sep 94 04:27:19 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA25349; Tue, 20 Sep 94 04:26:57 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 20 Sep 1994 12:26:10 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Tue, 20 Sep 1994 12:19:12 +0100 Date: Tue, 20 Sep 1994 12:19:12 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003735] Original-Encoded-Information-Types: ia5 text (2),undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3735 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3735*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) NSAP MAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 Contribution from Alan Lloyd along the suggested lines. There may be better ways of skinning the cat (or kangaroo in this case) but it is a starter. Jack ------------------------------ Start of body part 2 Jack, because SIPP addressing has allocated a range for NSAPs.. Is there a reason why ISO cannot propose the format.. I think keith did something but not much happened.. I dont mind the format of the address to be : SIPP Address = SIPP Id byte = 111000gr (NSAP follows) NSAP LEN = less than 14 = NSAP in this field = greater than 14 (and less than 20) remainder of NSAP in Hop by Hop option. OR (as an additional form) SIPP Address = a number which indicates Full NSAP in Hop by Hop options eg. SIPP Id byte = 111000gr NSAP LEN = 255 (all ones)..goto options plus the following defined HOP by Hop Option Type (a) Len/ NSAP Fragment Source (b) Len/ NSAP Fragment Dest (c) Len/ NSAP Complete Source (d) Len/ NSAP Complete Dest This is not the best way I feel but it is the simplest for the SIPP definition.. Jack, forward this to ipng if it is acceptable.. regards Alan@Oz ------------------------------ End of body part 2 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 07:04:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01208; Tue, 20 Sep 94 07:04:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01202; Tue, 20 Sep 94 07:04:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06705; Tue, 20 Sep 94 07:01:28 PDT Received: from cheops.anu.edu.au by Sun.COM (sun-barr.Sun.COM) id AA10936; Tue, 20 Sep 94 07:00:52 PDT Message-Id: <9409201400.AA10936@Sun.COM> Received: by cheops.anu.edu.au (1.37.109.11/16.2) id AA122139628; Wed, 21 Sep 1994 00:00:28 +1000 From: Darren Reed Subject: Re: (IPng) Re: Automatic Renumbering To: ipng@sunroof.Eng.Sun.COM Date: Wed, 21 Sep 1994 00:00:28 +1000 (EST) In-Reply-To: <3211.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Sep 19, 94 02:24:56 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1835 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > From: Darren Reed > > Can I ask, how will renumbering (automatic or otherwise) affect in-use > > source routes ? > > > A very clever question, which I have never heard addressed! [...] > However, because the topology information is very sparse, renumbering > could aways go to an unused prefix, allowing detection of failed source > specified routes. That still means we need some fancy ICMP message > to indicate that the numbering has changed, and this will affect > transport layers such as TCP. Could be hard! Doesn't this imply that you are looking for a change in renumbering whilst the TCP connection is active ? Maybe if routers kept track (somehow) of the source-route hops used for flows, then in the absence of a packet passing by they could do it themselves (?). Many (if not all) applications that use TCP these days turn _OFF_ SO_KEEPALIVE. I remember reading somewhere that a TCP connection should be able to stay up a year or more (assuming bug-free s/w :). IF a connection is idle for a large period of time, then when a system is renumbered, it isn't going to send a packet for someone to detect a missing link and send back an ICMP. The tree maybe sparse...to begin with, but what happens in the future (when as the doomsdayers (OSI ppl :)) have predicted 128bits is not enough, and we're renumbering in dense topology ? Is it worth mandating a "keepalive" packet on flows and TCP connections every x seconds to ensure that they receive some sort of notice about a renumbered host in their source route ? Maybe even a minimum time between when a number maybe reused by network renumbering ? I don't think this (?) has been brought up either, and is very much critical. I can imagine being able to send out magic packets telling a router to renumber every 10ms >:-) Darren ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 07:10:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01226; Tue, 20 Sep 94 07:10:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01214; Tue, 20 Sep 94 07:10:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07134; Tue, 20 Sep 94 07:07:03 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA11857; Tue, 20 Sep 94 07:06:43 PDT Received: from Bill.Simpson.DialUp.Merit.edu (pm002-05.dialip.mich.net [35.1.48.86]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA22681 for ; Tue, 20 Sep 1994 10:06:40 -0400 Date: Tue, 20 Sep 94 12:52:53 GMT From: "William Allen Simpson" Message-Id: <3217.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Learning Prefixes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: jhalpern@Newbridge.COM (Joel Halpern) > The number of problems we have had with "prefix knowledge" is such that > I would personally prefer that singly attached hosts NOT pretent to know > (nor try to learn) their "prefix". > Joel, you had better come up with an alternative, and then convince the entire IETF. You have 3 weeks. 1) Right now, the changing topology is encoded in the IPv6 address. 2) That prefix has to be embedded in every host's global address. Therefore, every host has to learn its prefix(es), by some configuration method. No choice. The first hop selection has to be made based on some technique when there are no routers. For implementation efficiency and robustness, the same mechanism has to be used when there are routers, although we can add an alternate based on the presence of those routers. The same code should be in both multiply and singly attached hosts. I say "should" because there is no way to require vendors to ship only one version of their code. Just the vendors that I've talked to think that multiple version would be a support problem. And the Providers that I've talked to want as little retraining as possible. So tell us, what is your design? Inquiring minds want to know. > PS To put it another way, having hosts "know" or "learn" their > "prefix" makes the host part of the routing problem. This makes > migration to alternate routing strategies and topologies harder. > Evolutionary solutions should help us evolve. > This has absolutely nothing to do with routing, although the format of the prefix might be affected by routing. The hosts do not know or care about the format of the prefix (I fought this battle already with Paul, who wanted provider, site, and link masks). I want to know why we are re-discussing such a basic principle at such a late date?!? The principles of design are clearly spelled out in Neighbor Discovery. Learning the Prefix is clearly listed as a design requirement. These were decided in the SIPP WG. Read the minutes. And perhaps you might read the drafts someday, before making further comments. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 07:10:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01227; Tue, 20 Sep 94 07:10:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01220; Tue, 20 Sep 94 07:10:19 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07149; Tue, 20 Sep 94 07:07:07 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AB11873; Tue, 20 Sep 94 07:06:47 PDT Received: from Bill.Simpson.DialUp.Merit.edu (pm002-05.dialip.mich.net [35.1.48.86]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA22684 for ; Tue, 20 Sep 1994 10:06:43 -0400 Date: Tue, 20 Sep 94 13:13:24 GMT From: "William Allen Simpson" Message-Id: <3218.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) next hop resolution Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Dave Katz > The counter argument is that there are fewer routers, and getting it to > work in routers may be easier than in the many hosts. > > Also, don't underestimate the fact that routers are usually under a > single (or at least fairly coordinated) administration, whereas hosts > often have as many adminstrators as machines. > Good point. > Alex correctly points out that if the code has to work in multi-homed > hosts, then all hosts will need the algorithm anyway, so we still have to > get it right. > > Advertising prefixes alone is insufficient for multihomed hosts to make > intelligent routing decisions, as the destination may well not have > anything in common with either prefix. NO. Because topology is encoded in the prefix, the destination has to have at least something in common with the prefix. Otherwise, the destination isn't reachable. When the destination gives the SAME match on more than one link, then the router Preference kicks in. Automatic propagation of prefixes (as described in my first discovery draft long ago, and currently in my deployment draft), guarantees that longest match prefixes are unique on different links within a site. > The multihomed host needs to > get real routing information (and even then ultimately has to make an > educated guess, especially in the face of aggregation.) In such cases > I advocate a route-request model; the host asks for route information > out each of its interfaces and the routing infrastructure gives it hints > (such as the length of the prefix that the route request matched, and > any metric information). Note that even this information may make it > impossible to make an informed decision (suppose it matched a zero-length > prefix on both sides...) It's a hard problem... > The fact that the destination isn't reachable is good information. Actually, I don't think this is a hard problem. Please give more examples. As far as a route request, that's a good idea, particularly for source determined policy-based routing. Join Nimrod. For simple next hop resolution, we need a model that works when a router is not present. > I've been pushing for an explicit decoupling between host > knowledge/first hop routing and the overall routing paradigm. This is > why I'm strongly in favor of the "dumb host" model. The more > intelligence you build into the hosts, the more you will be locked > into a routing world view, and the less flexibility you end up with. What routing? Who said anything about routing? I carefully labeled this Subject "next hop resolution". It is very important to stop the tendency of host vendors to build in listeners for routing protocols. Longest match of prefixes eliminates the need for knowledge about provider/site/link masks, and decouples the host from routing. > I don't believe that OSPF-and-subnets is necessarily where we're going > to be forever, and it behooves us to try not to eliminate future > possibilities by building in restrictions now, especially if the > flexibility has a low cost. It was a design decision of SIPP to use the subnet model. The bottom part of the address will alway be unique per link. By using longest match, the mechanism is completely flexible about the upper bit topology. Again, we are not re-deciding at this time. Please keep within the bounds of IPng, not the failed proposals. > (For instance, redirects can be refreshed > in the face of reverse traffic given symmetric first/last hop routing; > this tends to be true especially if the host is on the same wire--this > reduces the redirect load to one per conversation, more or less. Absolutely NOT!!! Symmetry is not required! This would also break mobility! Each cache entry has a LifeTime, which is obtained through the Solicitation and Advertisement messages. When an entry expires, the routing availability of the destination MUST be redetermined as if no prior entry had existed. Negative "advice" from other layers, such as excessive retransmissions by a transport-layer protocol, or a down indication from a link-layer, SHOULD be used to invalidate a cache entry. Positive "advice" from other layers MUST NOT extend the LifeTime of a cache entry. ICMP Echo "pings" MUST NOT be used to actively check a cache entry. > And > I pointed out to Bill a mechanism whereby the possibility of prefixes > that span multiple wires could be supported without any cost to > networks that use a prefix-to-wire binding.) > The mechanism you suggested was all hosts sending periodic hellos. This was rejected over a year and a half ago. It resulted in the 2nd criteria (reduced net traffic), and specific language rejecting ES-IS. We've trod this road before. It goes nowhere. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 07:28:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01249; Tue, 20 Sep 94 07:28:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01243; Tue, 20 Sep 94 07:28:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08897; Tue, 20 Sep 94 07:25:30 PDT Received: from nbkanata.newbridge.com by Sun.COM (sun-barr.Sun.COM) id AA14428; Tue, 20 Sep 94 07:25:08 PDT Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.newbridge.com (4.1/SMI-4.1) id AA03780; Tue, 20 Sep 94 10:20:07 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA27599; Tue, 20 Sep 94 10:20:06 EDT Received: from urchin.newbridge by mako.newbridge (4.1/SMI-4.1) id AA28298; Tue, 20 Sep 94 10:19:08 EDT Received: by urchin.newbridge (5.0/SMI-SVR4) id AA05223; Tue, 20 Sep 1994 10:19:07 +0500 Date: Tue, 20 Sep 1994 10:19:07 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9409201419.AA05223@urchin.newbridge> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Learning Prefixes X-Sun-Charset: US-ASCII Content-Length: 2110 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill Simpson has asked me to propose a solution as to how hosts can avoid having knowledge of "prefixes". He has then proposed a set of constraints. To start with, I believe that Dave Katz has already proposed a solution which meets the needs. It does not meet certain of Bill's constraints. 1) Bill suggests that first-hop selection has to be made based on some technique when there are no routers. This is true. However, when there are no routers, it follows that everything is either directly reachable, or completely unreachable. Techniques for this situation can follow naturally from this. 2) Bill asks that the same code should be in both multiply and singly attached hosts. I disagree. A singly attached host knows which interface it will send traffic out. It needs a technique for selecting a destination address. A multiply attached host needs a technique for selecting an interface. This would not be a difficulty if a device could be re-directed to use a different interface. But such an external redirection is probably impossible. It follows that a multiply attached host will need to participate in routing. While I do not like this requirement, I prefer that such be done directly, rather than trying to create a new technique for getting reachability information to a host. In specific, prefix advertisements are no help at all for a host in selecting an exit interface. The reason I assert that prefix advertisement has something to do with routing is that if hosts "learn" what prefixes are directly reachable, and behave differently based on that information, this has direct effects on the routing and addressing architecture. It is not merely that the advertisements are affected by routing, but that routing is affected by the host behavior. (Note that this kind of prefix advertisement is independent of a prefix used for address assignment. The issue is what conclusions about reachability a host "knows", not where its address comes from.) Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 07:42:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01261; Tue, 20 Sep 94 07:42:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01255; Tue, 20 Sep 94 07:42:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10007; Tue, 20 Sep 94 07:39:27 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA16524; Tue, 20 Sep 94 07:38:23 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng) Learning who we are To: ipng@sunroof.Eng.Sun.COM Date: Tue, 20 Sep 1994 15:36:03 +0200 (BST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 189 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM It's probably worth pointing out here that learning prefixes is not a massive problem and IPX already does this to a limited extent by querying for network numbers from the server. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 08:22:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01294; Tue, 20 Sep 94 08:22:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01288; Tue, 20 Sep 94 08:22:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13322; Tue, 20 Sep 94 08:19:09 PDT Received: from venera.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA23973; Tue, 20 Sep 94 08:18:44 PDT Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-18) id ; Tue, 20 Sep 1994 08:18:39 -0700 From: bmanning@ISI.EDU Posted-Date: Tue, 20 Sep 1994 08:18:09 -0700 (PDT) Message-Id: <199409201518.AA02247@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 20 Sep 1994 08:18:10 -0700 Subject: Re: (IPng) next hop resolution To: ipng@sunroof.Eng.Sun.COM Date: Tue, 20 Sep 1994 08:18:09 -0700 (PDT) In-Reply-To: <3218.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Sep 20, 94 01:13:24 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1315 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Advertising prefixes alone is insufficient for multihomed hosts to make > > intelligent routing decisions, as the destination may well not have > > anything in common with either prefix. > > NO. Because topology is encoded in the prefix, the destination has to > have at least something in common with the prefix. Otherwise, the > destination isn't reachable. > .... > > I've been pushing for an explicit decoupling between host > > knowledge/first hop routing and the overall routing paradigm. This is > > why I'm strongly in favor of the "dumb host" model. The more > > intelligence you build into the hosts, the more you will be locked > > into a routing world view, and the less flexibility you end up with. > > What routing? Who said anything about routing? I carefully labeled > this Subject "next hop resolution". > > It is very important to stop the tendency of host vendors to build in > listeners for routing protocols. > > Longest match of prefixes eliminates the need for knowledge about > provider/site/link masks, and decouples the host from routing. These two responses from Bill to Dave seem to contradict each other. Since the prefix encodes topology, it carries defacto routing information, ergo the host has predetermined routing information. Bill please correct me. -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 08:23:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01306; Tue, 20 Sep 94 08:23:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01300; Tue, 20 Sep 94 08:23:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13436; Tue, 20 Sep 94 08:20:17 PDT Received: from oxygen.house.gov by Sun.COM (sun-barr.Sun.COM) id AA24224; Tue, 20 Sep 94 08:19:57 PDT Received: by oxygen.house.gov (AIX 3.2/UCB 5.64/3.2.083191-) id AA20523; Tue, 20 Sep 1994 11:19:53 -0400 Date: Tue, 20 Sep 1994 11:19:53 -0400 From: johns@oxygen.house.gov (John Schnizlein) Message-Id: <9409201519.AA20523@oxygen.house.gov> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Learning who we are Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Message-Id: > From: iialan@iifeak.swan.ac.uk (Alan Cox) > > It's probably worth pointing out here that learning prefixes is not a massive > problem and IPX already does this to a limited extent by querying for > network numbers from the server. > Please be very careful about using Novell's Get-Nearest-Server style of discovery. Even in our small environment we have found a number of unfortunate interactions with other Novell routing features. The last thing we should do with IPng is create a string of customer demands for workarounds like what we (and others) have asked of Cisco. I normally just lurk here, but I fear many of you may not know the trouble involved with routing Novell. -- John ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 09:03:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01347; Tue, 20 Sep 94 09:03:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01341; Tue, 20 Sep 94 09:03:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17527; Tue, 20 Sep 94 09:00:29 PDT Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA02268; Tue, 20 Sep 94 09:00:09 PDT Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id MAA21263; Tue, 20 Sep 1994 12:00:07 -0400 Message-Id: <199409201600.MAA21263@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Learning Prefixes In-Reply-To: Your message of "Tue, 20 Sep 1994 10:19:07 EDT." <9409201419.AA05223@urchin.newbridge> From: Valdis.Kletnieks@vt.edu Date: Tue, 20 Sep 1994 12:00:07 +22306356 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Tue, 20 Sep 1994 10:19:07 EDT, you said: > 2) Bill asks that the same code should be in both multiply and singly > attached hosts. I disagree. A singly attached host knows which > interface it will send traffic out. It needs a technique for > selecting a destination address. A multiply attached host needs a > technique for selecting an interface. This would not be a difficulty > if a device could be re-directed to use a different interface. But Umm.. can somebody point me at an *existing* singly attached host? Note that all Unix systems I'm aware of have a 'loopback' interface for net 127. (I freely admit I don't know what the average MS/DOG stack or MacTCP do, and I'm still trying to get a grip on what IBM's TCP/IP for VM does with loopback (they use net 14 gaak). Or did I blink and miss something important re: "loopback"? Valdis Kletnieks Computer Systems Engineer Virginia Tech ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 09:49:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01444; Tue, 20 Sep 94 09:49:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01140; Tue, 20 Sep 94 05:09:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28532; Tue, 20 Sep 94 05:06:40 PDT Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA28443; Tue, 20 Sep 94 05:06:20 PDT Received: by newdev.harvard.edu (5.64/Tenon-1.35.01) id AA03100; Tue, 20 Sep 94 08:07:22 -0400 (EDT) Date: Tue, 20 Sep 94 08:07:22 -0400 (EDT) From: sob@harvard.edu (Scott Bradner) Message-Id: <9409201207.AA03100@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NSAP MAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, Should this be in an End-to-End option or a Hop-by-Hop? i.e. where is it looked at. It would seem to me that it would be looked at by the destination node and is not needed by the routers along the way. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 10:18:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01555; Tue, 20 Sep 94 10:18:41 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01549; Tue, 20 Sep 94 10:18:29 PDT Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id KAA08123; Tue, 20 Sep 1994 10:15:17 -0700 Date: Tue, 20 Sep 1994 10:15:17 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <199409201715.KAA08123@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9409201400.AA10936@Sun.COM> Subject: Re: (IPng) Re: Automatic Renumbering Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > > Can I ask, how will renumbering (automatic or otherwise) affect in-use > > > source routes ? > > > > > A very clever question, which I have never heard addressed! > [...] > > However, because the topology information is very sparse, renumbering > > could aways go to an unused prefix, allowing detection of failed source > > specified routes. That still means we need some fancy ICMP message > > to indicate that the numbering has changed, and this will affect > > transport layers such as TCP. Could be hard! My model for renumbering is that the routing for the old addresses would stay around for a while. The steps would be 0) Assign new prefix(es) to a site. 1) Turn on routing for the new prefix(es) 2) Start advertising the new prefix(es) at the site 3) Wait until active connections using the old prefix(es) had closed and the DNS and address caches had been updated (the latter will probably take longer than the former). 4) Turn off routing for the old prefix(es). 5) Wait a reasonably long time before assigning the old prefix(es) to someone else. I think this avoids the problem with source routes. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 11:23:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01639; Tue, 20 Sep 94 11:23:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01621; Tue, 20 Sep 94 11:22:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02057; Tue, 20 Sep 94 11:19:43 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA04373; Tue, 20 Sep 94 11:19:13 PDT Received: from Bill.Simpson.DialUp.Merit.edu (pm002-14.dialip.mich.net [35.1.48.95]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA13451 for ; Tue, 20 Sep 1994 14:19:09 -0400 Date: Tue, 20 Sep 94 17:30:12 GMT From: "William Allen Simpson" Message-Id: <3221.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: Automatic Renumbering Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Bob.Hinden@eng.sun.com (Bob Hinden) > My model for renumbering is that the routing for the old addresses would > stay around for a while. The steps would be > > 0) Assign new prefix(es) to a site. > 1) Turn on routing for the new prefix(es) > 2) Start advertising the new prefix(es) at the site > 3) Wait until active connections using the old prefix(es) had closed and > the DNS and address caches had been updated (the latter will probably > take longer than the former). > 4) Turn off routing for the old prefix(es). > 5) Wait a reasonably long time before assigning the old prefix(es) to > someone else. > > I think this avoids the problem with source routes. > That's the same model I'm using. But, the model needs some time in it. Look at (3). How long do we wait? A recent message said years. My Neighbor Discovery says a maximum of 18 hours for the route cache update. Some want to extend that by the use of reverse traffic, which is specifically prohibited in my drafts. We need a _hard_ limit. But, many TCP sessions last longer than 18 hours, and we want to be able to change providers based on time of day. So, I conclude that TCP sessions have to either change addresses dynamically, or be closed every 18 hours. Then, look at (5). Another time is needed here. But, we can limit this one to whatever was advertised by the DNS for the life of the address. Can we guarantee that no TCP session lasts longer than the DNS TTL, to ensure that bogus but correct looking TCP packets don't show up? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 11:23:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01640; Tue, 20 Sep 94 11:23:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01627; Tue, 20 Sep 94 11:23:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02085; Tue, 20 Sep 94 11:19:52 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA04384; Tue, 20 Sep 94 11:19:15 PDT Received: from Bill.Simpson.DialUp.Merit.edu (pm002-14.dialip.mich.net [35.1.48.95]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA13454 for ; Tue, 20 Sep 1994 14:19:12 -0400 Date: Tue, 20 Sep 94 17:39:16 GMT From: "William Allen Simpson" Message-Id: <3222.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) next hop resolution Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bmanning@ISI.EDU > > NO. Because topology is encoded in the prefix, the destination has to > > have at least something in common with the prefix. Otherwise, the > > destination isn't reachable. > > > > It is very important to stop the tendency of host vendors to build in > > listeners for routing protocols. > > > > Longest match of prefixes eliminates the need for knowledge about > > provider/site/link masks, and decouples the host from routing. > > These two responses from Bill to Dave seem to contradict each other. > Since the prefix encodes topology, it carries defacto routing information, > ergo the host has predetermined routing information. Bill please correct > me. > Sure. The host doesn't care about the _content_ of the prefix. Therefore, the host is not cognizant of the routing. The host can do longest match on any prefix, without having to know the length of the fields internal to the prefix. The routing can assign any values it likes to the prefix. The routing can change, the prefix can change. But, the host needs to know _when_ the prefix changes, since that affects its own address. If that doesn't clear things up for you, I'll just go back to writing the drafts, and try another time in a higher bandwidth environment. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 11:23:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01641; Tue, 20 Sep 94 11:23:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01632; Tue, 20 Sep 94 11:23:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02084; Tue, 20 Sep 94 11:19:52 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA04401; Tue, 20 Sep 94 11:19:21 PDT Received: from Bill.Simpson.DialUp.Merit.edu (pm002-14.dialip.mich.net [35.1.48.95]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA13457 for ; Tue, 20 Sep 1994 14:19:14 -0400 Date: Tue, 20 Sep 94 17:45:14 GMT From: "William Allen Simpson" Message-Id: <3223.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Learning Prefixes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: jhalpern@Newbridge.COM (Joel Halpern) > Bill Simpson has asked me to propose a solution as to how hosts can avoid > having knowledge of "prefixes". He has then proposed a set of constraints. > I see your gripe, but not your solution. The contraints were posed long ago. > To start with, I believe that Dave Katz has already proposed a solution > which meets the needs. It does not meet certain of Bill's constraints. > What "needs"? Since you haven't specified them, I have no other method to evaluate that you have any idea what you are talking about. > 1) Bill suggests that first-hop selection has to be made based on some > technique when there are no routers. This is true. However, when > there are no routers, it follows that everything is either directly > reachable, or completely unreachable. Techniques for this situation > can follow naturally from this. > As they do in my drafts. A simple solicitiation, followed by an advertisement. Have you read the drafts? > 2) Bill asks that the same code should be in both multiply and singly > attached hosts. I disagree. You can disagree all you like, but several others have asked that the same code be used, and have given good reasons. > A singly attached host knows which > interface it will send traffic out. It needs a technique for > selecting a destination address. A multiply attached host needs a > technique for selecting an interface. This would not be a difficulty > if a device could be re-directed to use a different interface. But > such an external redirection is probably impossible. It follows that > a multiply attached host will need to participate in routing. While > I do not like this requirement, I prefer that such be done directly, > rather than trying to create a new technique for getting reachability > information to a host. You ask that every host be shipped with code to recognize routing protocol packets. This is anathema. (It's done all the time, and has become a serious problem.) A multiply attached host which uses Neighbor Discovery does not need to participate in routing, and uses the same techniques for interfaces which have routers as those which don't have routers. Please don't postulate until you have read the drafts. > In specific, prefix advertisements are no help at all for a host in > selecting an exit interface. > They aren't? Amazing! Obviously, the rest of us know nothing. > The reason I assert that prefix advertisement has something to do with > routing is that if hosts "learn" what prefixes are directly reachable, > and behave differently based on that information, this has direct effects > on the routing and addressing architecture. It is not merely that the > advertisements are affected by routing, but that routing is affected by > the host behavior. > That's a very broad view of what constitutes routing. Most people do not call ARP routing. The IPv6 routing and addressing architecture assumes that the host have an address which is unique to the subnet. No other routing and addressing model is under consideration. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 12:17:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01729; Tue, 20 Sep 94 12:17:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01723; Tue, 20 Sep 94 12:17:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07033; Tue, 20 Sep 94 12:14:02 PDT Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA15107; Tue, 20 Sep 94 12:13:34 PDT Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id PAA12250; Tue, 20 Sep 1994 15:13:03 -0400 Message-Id: <199409201913.PAA12250@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: Automatic Renumbering In-Reply-To: Your message of "Tue, 20 Sep 1994 17:30:12 EST." <3221.bill.simpson@um.cc.umich.edu> From: Valdis.Kletnieks@vt.edu Date: Tue, 20 Sep 1994 15:13:03 +22306356 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Tue, 20 Sep 1994 17:30:12 EST, you said: > Can we guarantee that no TCP session lasts longer than the DNS TTL, to > ensure that bogus but correct looking TCP packets don't show up? % finger valdis@vtaix.cc.vt.edu Login name: valdis In real life: Valdis Kletnieks Site Info: Computing Center,231-9509 Directory: /home/spd/valdis Shell: /bin/ksh On since Aug 23 15:20:50 on pts/3 from black-ice.cc.vt. No Plan. % Yes, that's a correct 'On since'. The wonders of xterm'ing between two stable systems (black-ice has been up for 187 days, and vtaix for 40). My DNS admin will have kittens if I tell him he has to run with a TTL of a month. ;) Fortunately for us, the X11 programs that have been running for all this time on black-ice for the most part were talking on the loopback interface - I don't think a 6-month TTL for the DNS would be a workable solution.. Valdis Kletnieks Computer Systems Engineer Virginia Tech ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 12:33:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01783; Tue, 20 Sep 94 12:33:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01777; Tue, 20 Sep 94 12:33:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08941; Tue, 20 Sep 94 12:29:54 PDT Received: from nbkanata.newbridge.com by Sun.COM (sun-barr.Sun.COM) id AA19062; Tue, 20 Sep 94 12:29:30 PDT Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.newbridge.com (4.1/SMI-4.1) id AA12284; Tue, 20 Sep 94 15:24:09 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA08720; Tue, 20 Sep 94 15:24:02 EDT Received: from urchin.newbridge by mako.newbridge (4.1/SMI-4.1) id AA00589; Tue, 20 Sep 94 15:23:04 EDT Received: by urchin.newbridge (5.0/SMI-SVR4) id AA05353; Tue, 20 Sep 1994 15:23:03 +0500 Date: Tue, 20 Sep 1994 15:23:03 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9409201923.AA05353@urchin.newbridge> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Learning Prefixes X-Sun-Charset: US-ASCII Content-Length: 4322 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM (I started this reply, and then the window system lost it. If a partial reply appears on the list, my apologies. I stopped to re-check the draft, so as to be certain that my response were based on Bill's current proposal rather than any previous version I might have remembered.) My main concern with the current proposal is the transmission and use of prefixes. I will attempt below to outline a proposed solution that might retain the preformance advantage apparently associated with prefix advertisement. Before doing so, I wish to make a more general point: When we have a sense of the direction the internet is going, even when such direction is not explicitly a goal of IPv6, it makes sense to give serious consideration to solutions which help us get there, and to be wary of solutions which ingrain the current approach. In this partiular context, mask and match has been a source of difficulty for the internet. Certainly advertising the masks from teh routers does somewhat ameliorate the problems. But it retains the paradigm. There is no need to retain it, and there are reasons not to, related to issues raised in many places. There are context where "multicast" is not the right way to reach things that are on the same "wire". Now, the basic difficulty I have with prefix advertisements is that they are simultaneously insufficent and limitting. They are insufficient in that they are no help finding destinations which are on remote wires. They are limiting in that they assume that the subnet is on the "wire" in the specific sense of multicast reachability. In many applications, this is not the case. (Cf. ROLC working group and related RFC from the IAB.) An approach: [ I have endevoured to retain as much of Bill Simpson's draft in the following as possible, on the presumtiont that most of the features were considered useful.] 1) Hosts run router discovery. If a host fails to find a router, it may multicast packets/queries on the wire to find hosts. 2) When a host wishes to communicate with a destination, it sends a query to an operating Router. 3) When a router receives a query, it answers with an indication of the correct path to the destination. This answer will include the IP address of the correct entity (destination or router) and the MAC address for that entity. (Responses clearly must contain a lifetime.) 4) Additional information: If the destination is directly reachable from the source, and there is a prefix all of whose elements are "multicast reachable" from the querying host, the response may contain a mask. If the response indicates a router, the set of known "cost" information for that router to reach the destination shall be included as additional information in the response. A mask shall not be included as knowing when such masks are superceded is difficult and would require the answerer to save state about what he sent. This will allow hosts to quickly find other hosts. In the "normal" case where subnets align with "wires", prefixes may be used for efficiency. In addition, enough information is provided that answers over multiple interfaces may be compared, to allow a host to select a good exit. This outline should serve to demonstrate that a more flexible solution is possible which avoids locking hosts into one model. I hope that this can be viewed as a small extension and improvement upon current work, rather than as the "derailing" that some responses seem to believe. I do not claim that this is a complete solution, as I have not had the time to work out all the issues. I was asked to provide a "solution", so I am providing what I can quickly. The key here will be to define the identification of the "cost" information in the first release, so it can be used. As a secondary matter, a responding router is not required to provide a mask for "local" destination, so as to allow cases where such a mask would be in-appropriate. The remote destination behavior is indeed an interaction with routing, but seems the cleanest and most direct way to do so. A hosts selection of exit interface (when there are multiple physical wires to choose from) is very definitely a routing decision. Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 13:34:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01863; Tue, 20 Sep 94 13:34:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01857; Tue, 20 Sep 94 13:34:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15999; Tue, 20 Sep 94 13:31:03 PDT Received: from venera.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA02222; Tue, 20 Sep 94 13:30:34 PDT Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-18) id ; Tue, 20 Sep 1994 13:29:59 -0700 From: bmanning@ISI.EDU Posted-Date: Tue, 20 Sep 1994 13:29:33 -0700 (PDT) Message-Id: <199409202029.AA02819@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 20 Sep 1994 13:29:34 -0700 Subject: Re: (IPng) Re: Automatic Renumbering To: ipng@sunroof.Eng.Sun.COM Date: Tue, 20 Sep 1994 13:29:33 -0700 (PDT) In-Reply-To: <3221.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Sep 20, 94 05:30:12 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 777 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > My Neighbor Discovery says a maximum of 18 hours for the route cache > update. Some want to extend that by the use of reverse traffic, > which is specifically prohibited in my drafts. We need a _hard_ limit. Sounds like a hard limit to me. But you seek validation... > But, many TCP sessions last longer than 18 hours, and we want to be able > to change providers based on time of day. Uh no, I don't want to change providers based on time of day. I want to change providers based on cost of service delivery. You are assuming too many things here. > Can we guarantee that no TCP session lasts longer than the DNS TTL, to > ensure that bogus but correct looking TCP packets don't show up? What happens when DNS changes the size or meaning of the TTL? -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 13:43:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01875; Tue, 20 Sep 94 13:43:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01869; Tue, 20 Sep 94 13:42:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16929; Tue, 20 Sep 94 13:39:38 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA04348; Tue, 20 Sep 94 13:38:59 PDT Received: from relay.imsi.com by wintermute.imsi.com id QAA08093 for ; Tue, 20 Sep 1994 16:38:48 -0400 Received: from snark.imsi.com by relay.imsi.com id QAA03573 for ; Tue, 20 Sep 1994 16:38:47 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA10883; Tue, 20 Sep 94 16:38:46 EDT Message-Id: <9409202038.AA10883@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: Automatic Renumbering In-Reply-To: Your message of "Tue, 20 Sep 1994 10:15:17 PDT." <199409201715.KAA08123@jurassic.Eng.Sun.COM> X-Reposting-Policy: redistribute only with permission Date: Tue, 20 Sep 1994 16:38:46 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob Hinden says: > My model for renumbering is that the routing for the old addresses would > stay around for a while. The steps would be [...] > 3) Wait until active connections using the old prefix(es) had closed and > the DNS and address caches had been updated (the latter will probably > take longer than the former). I have applications that leave TCP connections up for months on end. Now, if renumbering is sufficiently rare, I can just drop them and reconnect, but it would be nicer not to... Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 14:09:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01896; Tue, 20 Sep 94 14:09:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01890; Tue, 20 Sep 94 14:08:57 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19459; Tue, 20 Sep 94 14:05:45 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA09870; Tue, 20 Sep 94 14:05:09 PDT To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) Discovery Date: Tue, 20 Sep 94 20:01:06 GMT From: Ran Atkinson Message-Id: <9409202001.aa06537@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Valdis has a good point that there are generally at least 2 logical interfaces, but one of them (i.e. loopback) _can_ be handled by adding special case code into the host. More to the point is that my vendor has no way of knowing ahead of time how many interfaces I will be putting in my box (particularly since it varies as a function of time around here). It is also true that most hosts can also function as routers (e.g. using gated(8)). Most host vendors usually include a routing daemon with each host because customers want to have the ability to use workstations as routers. Hence, the host vendors will need to continue to ship implementations capable of IP forwarding and with IP forwarding enabled in the default kernel configuration. In turn, this means that the technique used must work for multi-homed hosts, single-homed hosts, and workstations which are also functioning as routers. If the workstation knows the prefix for each interface, all cases work. If the workstation does not know the prefix for each interface, the multi-homed and workstation-router cases do not work. For the case of hosts which are single-homed and are not running a routing protocol, they might optimise handling the local to the attached subnet destinations but do not have to. For my IP/Radio networks where bandwidth is always scarce, this optimisation is quite nice. I find it fascinating that this discussion is breaking out along product lines. So far, the router people push for no host knowledge of prefixes and the host people push for host knowledge of prefixes. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 15:00:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01922; Tue, 20 Sep 94 15:00:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01916; Tue, 20 Sep 94 15:00:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24208; Tue, 20 Sep 94 14:57:18 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA21283; Tue, 20 Sep 94 14:56:38 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA05133; Tue, 20 Sep 94 17:52:34 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9409202152.AA05133@pluto.dss.com> Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Tue, 20 Sep 1994 17:52:33 -0400 (EDT) Cc: ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: <9409202001.aa06537@sundance.itd.nrl.navy.mil> from "Ran Atkinson" at Sep 20, 94 08:01:06 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2434 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > In turn, this means that the technique used must work for > multi-homed hosts, single-homed hosts, and workstations which are also > functioning as routers. If the workstation knows the prefix for each > interface, all cases work. If the workstation does not know the > prefix for each interface, the multi-homed and workstation-router > cases do not work. As far as I am concerned routers are simply multihomed hosts which can perform network layer forwarding while single interface hosts are simply a degenerate case of an N-interface multihomed host where N is equal to 1. This continually resurfacing desire to treat end hosts as completely separate and distinct genera never ceases to amaze me. In general routers with which I am familiar support lots of typical end-host functionality (telnet, rlogin, ftp, tftp etc) and many common end-host implementations can function as routers when multiple network interfaces are installed and when ip-forwarding is enabled. > I find it fascinating that this discussion is breaking out along > product lines. So far, the router people push for no host knowledge > of prefixes and the host people push for host knowledge of prefixes. Any design which makes a hard and fast distinction between routers and end hosts is simply hideous. Fragmentation is another example of this mindlessness. Unless the situation has changed since I last checked up on IPV6, fragmentation is confined to end-hosts. Somehow the router's IP layer is going to know that a given packet has originated internally (in which case it can be fragmented) while another packet is simply being forwarded from another interface. In virtual device architectures of which the Constellation Series Bridge Routers are an example, a packet switching device may actually contain multiple IP layers (associated with either end-host or router functionalities) connected by internal virtual networks. Determining whether a packet is fragmentable according to IPV6 rules becomes an exercise in hideous medieval scholastic argumentation. But this situation is hardly surprising because practically everything I read about IPV6 is completely hideous. > Ran Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 15:00:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01932; Tue, 20 Sep 94 15:00:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01923; Tue, 20 Sep 94 15:00:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24220; Tue, 20 Sep 94 14:57:33 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA21397; Tue, 20 Sep 94 14:57:02 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA05133; Tue, 20 Sep 94 17:52:34 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9409202152.AA05133@pluto.dss.com> Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Tue, 20 Sep 1994 17:52:33 -0400 (EDT) Cc: ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: <9409202001.aa06537@sundance.itd.nrl.navy.mil> from "Ran Atkinson" at Sep 20, 94 08:01:06 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2434 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > In turn, this means that the technique used must work for > multi-homed hosts, single-homed hosts, and workstations which are also > functioning as routers. If the workstation knows the prefix for each > interface, all cases work. If the workstation does not know the > prefix for each interface, the multi-homed and workstation-router > cases do not work. As far as I am concerned routers are simply multihomed hosts which can perform network layer forwarding while single interface hosts are simply a degenerate case of an N-interface multihomed host where N is equal to 1. This continually resurfacing desire to treat end hosts as completely separate and distinct genera never ceases to amaze me. In general routers with which I am familiar support lots of typical end-host functionality (telnet, rlogin, ftp, tftp etc) and many common end-host implementations can function as routers when multiple network interfaces are installed and when ip-forwarding is enabled. > I find it fascinating that this discussion is breaking out along > product lines. So far, the router people push for no host knowledge > of prefixes and the host people push for host knowledge of prefixes. Any design which makes a hard and fast distinction between routers and end hosts is simply hideous. Fragmentation is another example of this mindlessness. Unless the situation has changed since I last checked up on IPV6, fragmentation is confined to end-hosts. Somehow the router's IP layer is going to know that a given packet has originated internally (in which case it can be fragmented) while another packet is simply being forwarded from another interface. In virtual device architectures of which the Constellation Series Bridge Routers are an example, a packet switching device may actually contain multiple IP layers (associated with either end-host or router functionalities) connected by internal virtual networks. Determining whether a packet is fragmentable according to IPV6 rules becomes an exercise in hideous medieval scholastic argumentation. But this situation is hardly surprising because practically everything I read about IPV6 is completely hideous. > Ran Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 19:48:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02074; Tue, 20 Sep 94 19:48:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02061; Tue, 20 Sep 94 19:47:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14897; Tue, 20 Sep 94 19:44:37 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA05595; Tue, 20 Sep 94 19:44:00 PDT Received: from Bill.Simpson.DialUp.Merit.edu (pm035-02.dialip.mich.net [141.211.7.13]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id WAA19253 for ; Tue, 20 Sep 1994 22:43:57 -0400 Date: Wed, 21 Sep 94 01:35:01 GMT From: "William Allen Simpson" Message-Id: <3227.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Cc: addrconf@cisco.com Subject: (IPng) Re: Automatic Renumbering Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Valdis.Kletnieks@vt.edu > > Can we guarantee that no TCP session lasts longer than the DNS TTL, to > > ensure that bogus but correct looking TCP packets don't show up? > > % finger valdis@vtaix.cc.vt.edu > Login name: valdis In real life: Valdis Kletnieks > Site Info: Computing Center,231-9509 > Directory: /home/spd/valdis Shell: /bin/ksh > On since Aug 23 15:20:50 on pts/3 from black-ice.cc.vt. > No Plan. > % > > Yes, that's a correct 'On since'. The wonders of xterm'ing between > two stable systems (black-ice has been up for 187 days, and vtaix for > 40). My DNS admin will have kittens if I tell him he has to run with > a TTL of a month. ;) > Thank you for the real life example. Fortunately for me, this is a job for the IPv6 Auto Address Configuration WG, or whatever they're going to call it. I Cc'd them, and they should take up the problem of maintaining long lived TCP connections in the face of changing addresses. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 19:48:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02073; Tue, 20 Sep 94 19:48:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02062; Tue, 20 Sep 94 19:47:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14900; Tue, 20 Sep 94 19:44:39 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA05613; Tue, 20 Sep 94 19:44:07 PDT Received: from Bill.Simpson.DialUp.Merit.edu (pm035-02.dialip.mich.net [141.211.7.13]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id WAA19259 for ; Tue, 20 Sep 1994 22:44:02 -0400 Date: Wed, 21 Sep 94 01:39:45 GMT From: "William Allen Simpson" Message-Id: <3229.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Learning Metrics Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I changed the Subject line, since Joel changed the subject focus.... > From: jhalpern@Newbridge.COM (Joel Halpern) > I stopped to re-check the draft, > so as to be certain that my response were based on Bill's current proposal > rather than any previous version I might have remembered.) > > Now, the basic difficulty I have with prefix advertisements is that they > are simultaneously insufficent and limitting. They are insufficient in > that they are no help finding destinations which are on remote wires. They > are limiting in that they assume that the subnet is on the "wire" in the > specific sense of multicast reachability. In many applications, this is > not the case. (Cf. ROLC working group and related RFC from the IAB.) > (1) Nobody is trying to use them to find remote wires. They _are_ sufficient for finding what is on local wires (we call these "links" in all of our drafts -- please reread the Terminology section in SIPP-16). (2) A prefix is always reachable in a multicast capability, by definition. If it does not, it MUST have a different cluster address! > An approach: [ I have endevoured to retain as much of Bill Simpson's > draft in the following as possible, on the presumtiont that most of > the features were considered useful.] > > 1) Hosts run router discovery. If a host fails to find a router, > it may multicast packets/queries on the wire to find hosts. > 2) When a host wishes to communicate with a destination, it sends a > query to an operating Router. > 3) When a router receives a query, it answers with an indication of the > correct path to the destination. This answer will include the IP > address of the correct entity (destination or router) and the MAC > address for that entity. (Responses clearly must contain a lifetime.) So far, this is exactly the same approach. > 4) Additional information: > If the destination is directly reachable from the source, and there > is a prefix all of whose elements are "multicast reachable" from the > querying host, the response may contain a mask. > Again, this is exactly the same as we are using, except that "mask" (generated from the prefix size) is sent in the router advertisement, not in the redirect. Pretty silly to wait for the redirect to find out that there _is_ a mask after all.... > If the response indicates a router, the set of known "cost" > information for that router to reach the destination shall be included > as additional information in the response. A mask shall not be > included as knowing when such masks are superceded is difficult > and would require the answerer to save state about what he sent. > Now this is where we depart. Does anybody else think we should be sending routing metrics to hosts? Why didn't the router calculate the best route for us? That's what routers are for! Or are you shoehorning policy-based routing in here, so that every response returns many routes with "cost" information? Way outside our scope. > This will allow hosts to quickly find other hosts. In the "normal" case > where subnets align with "wires", prefixes may be used for efficiency. Yes. That's what DEC, NRL, et cetera, have been asking for. > In addition, enough information is provided that answers over multiple > interfaces may be compared, to allow a host to select a good exit. > Are you saying that every host should send the same request to every router it has ever heard? Then, all the routers run a path cost calculation to the destination? Finally, all these routers send back "cost" information to the host, which then chooses among them? Let's call this the "Genius Host, Huge Router" model.... > The key here will be to define the > identification of the "cost" information in the first release, so it can > be used. I sort of agree about the "cost" estimation. The host tells the router what its perceived link transmission cost is with the Speed, MRU, Error Count, and Quality fields in the "Heard" extension. In our design, however, the cost is calculated by the one router which is queried, and a single correct redirect is then generated. Remember, this is _neighbor_ discovery, so the only "costs" we are concerned with are directly link related. Do you have any other link related costs we have forgotten? > As a secondary matter, a responding router is not required to > provide a mask for "local" destination, so as to allow cases where such a > mask would be in-appropriate. > That is also true in our design. The prefix size may be zero, which indicates that subnet inforamtion is not available. (Reread the repeated statement to that effect in every draft.) > The remote destination behavior is indeed an interaction with routing, > but seems the cleanest and most direct way to do so. A hosts selection > of exit interface (when there are multiple physical wires to choose from) > is very definitely a routing decision. > Hmmm, not the way I think of it. I think the routers have already told us (in their advertisements) enough information to pick one of them as a default. I think that prefix and preference is enough to do so. I want the routers to tell us which to use, and not have to do much host calculation. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 20 20:14:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02096; Tue, 20 Sep 94 20:14:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02090; Tue, 20 Sep 94 20:14:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15897; Tue, 20 Sep 94 20:10:56 PDT Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA09736; Tue, 20 Sep 94 20:10:37 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id UAA02112; Tue, 20 Sep 1994 20:10:36 -0700 Date: Tue, 20 Sep 1994 20:10:36 -0700 From: Dave Katz Message-Id: <199409210310.UAA02112@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "William Allen Simpson"'s message of Tue, 20 Sep 94 13:13:24 GMT <3218.bill.simpson@um.cc.umich.edu> Subject: (IPng) next hop resolution Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Alex correctly points out that if the code has to work in multi-homed > hosts, then all hosts will need the algorithm anyway, so we still have to > get it right. > > Advertising prefixes alone is insufficient for multihomed hosts to make > intelligent routing decisions, as the destination may well not have > anything in common with either prefix. NO. Because topology is encoded in the prefix, the destination has to have at least something in common with the prefix. Otherwise, the destination isn't reachable. When the destination gives the SAME match on more than one link, then the router Preference kicks in. I think that this is likely to be the case in most cases for which the destination is not topologically near, and the matched bits will effectively be the empty set (or something like "both are on planet earth", which is roughly the same thing). The prefix is not all topological, and not all topology is encoded in the prefix (if it were, we could have bitwise source routing and I could go back to being a musician). Furthermore, router preference is of dubious value because it is far too coarse--it is not coupled to any particular destination. Multihoming seems to have a couple of flavors--in one, the subnets are there for redundancy, and have paths that eventually merge somewhere off in the distance (we have scads of servers that have both FDDI and backup Ethernet interfaces, for example), and in the other the host straddles distinct disconnected internetworks (often the case for "security" purposes). Let's take the disconnected case first. Prefix-match-length testing could work in this case if the destination is local enough and addresses were assigned carefully. If the unconnected internets are sufficiently large and the destination isn't very local, the match lengths may end up the same (the destination is on another provider, for example, and there's essentially no overlap other than the admin bits at the top). Relatively unlikely, granted. If they are equal, however, the preferences announced by the router will do you no good, since they cannot tell you which side of the fence the destination is on. So which way do you go? If you guess wrong, the packets go down the toilet. Now to the connected case. In my ether/FDDI example, the prefix-match length would almost certainly be equal for any destination that doesn't share a wire with the host; however, here the preference value could tell you that you should prefer FDDI (better to be told than to guess, I suppose). However, for the connected case where the merge point is topologically further off, the router preference doesn't really help. Imagine the case where the multihomed host is attached to two networks, each of which is connected to a different provider. The destination is on a third provider. The prefixes have equal length. Which is the right path? How do you set router preferences in this case? Automatic propagation of prefixes (as described in my first discovery draft long ago, and currently in my deployment draft), guarantees that longest match prefixes are unique on different links within a site. > The multihomed host needs to > get real routing information (and even then ultimately has to make an > educated guess, especially in the face of aggregation.) In such cases > I advocate a route-request model; the host asks for route information > out each of its interfaces and the routing infrastructure gives it hints > (such as the length of the prefix that the route request matched, and > any metric information). Note that even this information may make it > impossible to make an informed decision (suppose it matched a zero-length > prefix on both sides...) It's a hard problem... > The fact that the destination isn't reachable is good information. Actually, I don't think this is a hard problem. Please give more examples. Picking the truly optimal path from a multihomed host is fundamentally impossible in the face of information hiding; at best you get an approximation. If information hiding is done particularly well (as must be the case if the internet will scale), the only way to tell which of several paths is the "best" is to transmit data and record where it went (with enough detail to determine link bandwidths, etc.) In the "both sides eventually connect" case, the packet will get there either way; in the "disconnected networks" case there may be no way of telling that the destination is unreachable on one side or the other short of sending data and seeing if there's any response. As far as a route request, that's a good idea, particularly for source determined policy-based routing. Join Nimrod. It's been in RIP since we've been in diapers, more or less. Not Rocket Science. I propose this particularly to avoid eavesdropping on routing protocols. For simple next hop resolution, we need a model that works when a router is not present. Use the multicast-and-pray model here. The case of a multihomed host on two routerless networks requires static configuration in any case, so automated discovery mechanisms are uninteresting. > And > I pointed out to Bill a mechanism whereby the possibility of prefixes > that span multiple wires could be supported without any cost to > networks that use a prefix-to-wire binding.) > The mechanism you suggested was all hosts sending periodic hellos. This was rejected over a year and a half ago. It resulted in the 2nd criteria (reduced net traffic), and specific language rejecting ES-IS. The mechanism I suggested was routers telling hosts how often to send hellos; a period of "0" would give us effectively the same mechanism you've described (the host's first hello is a solicitation; the router's hello [carrying the '0'] is the advertisement/reply; the host shuts up after that). No additional traffic for networks configured to use subnet-per-wire; expanding subnets across wires can be done if desired without changing anything on the hosts. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 21 02:20:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02203; Wed, 21 Sep 94 02:20:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02197; Wed, 21 Sep 94 02:20:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28169; Wed, 21 Sep 94 02:17:10 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA28289; Wed, 21 Sep 94 02:16:48 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Re: Automatic Renumbering To: ipng@sunroof.Eng.Sun.COM Date: Wed, 21 Sep 1994 10:14:48 +0200 (BST) In-Reply-To: <9409202038.AA10883@snark.imsi.com> from "Perry E. Metzger" at Sep 20, 94 04:38:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 911 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > stay around for a while. The steps would be > [...] > > 3) Wait until active connections using the old prefix(es) had closed and > > the DNS and address caches had been updated (the latter will probably > > take longer than the former). > > I have applications that leave TCP connections up for months on > end. Now, if renumbering is sufficiently rare, I can just drop them > and reconnect, but it would be nicer not to... This sounds an awful lot like trying to do things at too low a layer. If you change provider mid flight then all sorts of TCP parameters want to get discarded and recomputed. This sounds to me that it is fundamentally a TCP layer extension and not part of IPng. Having time limits on TCP connections would also be extremely inconvenient and for some applications totally undesirable and almost unusable without significant upper level protocol changes (eg for irc) Alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 21 02:35:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02221; Wed, 21 Sep 94 02:35:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02209; Wed, 21 Sep 94 02:35:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28723; Wed, 21 Sep 94 02:32:14 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA29837; Wed, 21 Sep 94 02:31:51 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Wed, 21 Sep 1994 10:29:46 +0200 (BST) Cc: ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: <9409202152.AA05133@pluto.dss.com> from "Joachim Martillo" at Sep 20, 94 05:52:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1963 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > In general routers with which I am familiar support lots of typical > end-host functionality (telnet, rlogin, ftp, tftp etc) and many common > end-host implementations can function as routers when multiple network > interfaces are installed and when ip-forwarding is enabled. Not only this but every single machine on the internet I know of has at least two interfaces (loopback + whatever). Nobody is shipping software that knows it will only ever have a maximum of one interface so the code will know about routing anyway - even on the most humble of PC's Therefore its silly having a host v router distinction. Prefixes should be done like the basic SIPP concepts were - simple to the point of stupidity and fast. Near-static prefixes will do for most users with fixed connections, for 99% of end users the ability to talk in terms of a magic local prefix is all they need. Let the local routers remap as appropriate. For a typical site that means you end up with address/netmasks in their IPv4 form dealing with routing internally, a magic prefix (say 0) that gets remapped by whichever box happens to be connected to remote sites and nobody else need worry. For DNS resolving there needs to be some more thought on prefixes. > Any design which makes a hard and fast distinction between routers and > end hosts is simply hideous. Seconded. > Fragmentation is another example of this mindlessness. > Unless the situation has changed since I last checked up on IPV6, > fragmentation is confined to end-hosts. I read this as a simplification of IPv4 fragmentation that will speed up routing. I think your complexity argument is questionable since you already have to know if a packet is local before fragmenting and you can sensibly fragment a packet before it meets the same point in your code that outgoing forwarded frames take. If your code internals are really so complex you can't make that decision fast it begs the question of Why ? Alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 21 02:35:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02222; Wed, 21 Sep 94 02:35:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02215; Wed, 21 Sep 94 02:35:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28729; Wed, 21 Sep 94 02:32:20 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA29841; Wed, 21 Sep 94 02:31:56 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Wed, 21 Sep 1994 10:29:46 +0200 (BST) Cc: ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: <9409202152.AA05133@pluto.dss.com> from "Joachim Martillo" at Sep 20, 94 05:52:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1963 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > In general routers with which I am familiar support lots of typical > end-host functionality (telnet, rlogin, ftp, tftp etc) and many common > end-host implementations can function as routers when multiple network > interfaces are installed and when ip-forwarding is enabled. Not only this but every single machine on the internet I know of has at least two interfaces (loopback + whatever). Nobody is shipping software that knows it will only ever have a maximum of one interface so the code will know about routing anyway - even on the most humble of PC's Therefore its silly having a host v router distinction. Prefixes should be done like the basic SIPP concepts were - simple to the point of stupidity and fast. Near-static prefixes will do for most users with fixed connections, for 99% of end users the ability to talk in terms of a magic local prefix is all they need. Let the local routers remap as appropriate. For a typical site that means you end up with address/netmasks in their IPv4 form dealing with routing internally, a magic prefix (say 0) that gets remapped by whichever box happens to be connected to remote sites and nobody else need worry. For DNS resolving there needs to be some more thought on prefixes. > Any design which makes a hard and fast distinction between routers and > end hosts is simply hideous. Seconded. > Fragmentation is another example of this mindlessness. > Unless the situation has changed since I last checked up on IPV6, > fragmentation is confined to end-hosts. I read this as a simplification of IPv4 fragmentation that will speed up routing. I think your complexity argument is questionable since you already have to know if a packet is local before fragmenting and you can sensibly fragment a packet before it meets the same point in your code that outgoing forwarded frames take. If your code internals are really so complex you can't make that decision fast it begs the question of Why ? Alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 21 03:13:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02246; Wed, 21 Sep 94 03:13:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02240; Wed, 21 Sep 94 03:13:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00236; Wed, 21 Sep 94 03:10:27 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA05921; Wed, 21 Sep 94 03:10:04 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Wed, 21 Sep 1994 11:08:43 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Wed, 21 Sep 1994 11:04:13 +0100 Date: Wed, 21 Sep 1994 11:04:13 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003747] Original-Encoded-Information-Types: ia5 text (2),undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3747 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3747*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM, /G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@pipex.net, BESBRODS , cassidy , colin.amor@intelsat.int, hvb@arch4.att.com, rpbrandt@attmail.com, alan@archway.demon.co.uk, lyman@BBN.com, danthine@vm1.ulg.ac.be, frommi@zfe.siemens.de, pag@mci.org.uk, JEAN-FRANCOIS.GORNET@PRINCE.atlas1.edf.fr, josef.haas@fh-aalen.de, jnk@cclab.cau.ac.kr, kino@nttmhs.ntt.jp, " (Keith G Knightson)" , lee@ntd.comsat.com, sleistner@attmail.com, bobl@tmx.mhs.oz.au, arne.litlere@ntra.telemax.no, bcshin@eekaist.kaist.ac.kr, Schulte W , gsmith@werple.apana.org.au, monicas@vnet.ibm.com, magnus@vnet.IBM.COM, bruce-steer@saa.sa.telememo.au, rjthomas@bnr.ca, /G=matti/S=vasara/O=sty/@elisa.fi, jwheel@attmail.com Subject: (IPng) Address MAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 Here is another mechanism along similar lines to that suggested by Alan Lloyd. This one is recursive but very simple. Jack Houldsworth ------------------------------ Start of body part 2 ---------- Forwarded message ---------- Date: Tue, 30 Aug 1994 17:19:41 +1000 (EST) From: Anand Kumria To: deering@parc.xerox.com Subject: SIPP Address Extensions... Dear Steve, I had a look at the SIPP specification that you wrote, and came up with an idea. I hope I'm not rehashing old-ground you may have already covered though. 4.X Address Extension Option Header 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Next Header | Bitwise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address Extension + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address Extension + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Next Header field in the SIPP header would contain a value (let's say) SAE (SIPP Address Extension), the Next Field in the SAE Header would contain the type of header following. The Bitwise Number is an 8-Bit unsinged number, that can never equal 0. The Zero-th part of the address is the address specified in the SIPP header. To find out an address you would put the original source address end-to-end with the Source address extension. This would give you a 256 bit address. When the bitwise Number field was set to FF (hex, 11111111 binary), it would indicate the end of the address extensions. Thus if you wanted a 1024 bit address you would have: SIPP Header + SAE (1) + SAE (2) + SAE (FF). where the bracketed numbers are the hex value in the Bitwise Number field of the SAE header. So why do this anyway? Surely 16 bytes is enough (8 could've done it), well basically it is to future proof the specification. By mandating (in this or future versions of IP) that it be able to cope with x number of SAEs then you can continue to extended the address space with minimal disruption (hopefully) to existing protocols. I hope this is food-for-thought, regards, Anand. ------------------------------ End of body part 2 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 21 03:56:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02265; Wed, 21 Sep 94 03:56:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02259; Wed, 21 Sep 94 03:56:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02090; Wed, 21 Sep 94 03:53:20 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA08579; Wed, 21 Sep 94 03:52:57 PDT Received: by rodan.UU.NET id QQxihn05522; Wed, 21 Sep 1994 06:52:56 -0400 Date: Wed, 21 Sep 1994 06:52:56 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Renumbering..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM While we are working hard to make renumbering straightforward and relatively painless, there is no requirement to make it completely transparent. The current model supports "flying cutovers" for a large part of the parameter space, but there comes a point where trying to maintain the fiction will fail, and that's just an engineering limit. A site can run dual routes for a month or so if it wishes, but when you kill the original route, any connection which has not changed over will die, pure and simple. There may be connections for which you cannot run dual-routed long enough to make survive. Tough noogies, folks. If you require fault-tolerant transport connections, do it with a session control layer. If you are doing zillion-dollar TCP streams I don't know why this hasn't occurred to you before now. The current infrastructure certainly isn't that robust, even in controlled environments. If connection life matters that much, then you should do something to control it at a level where you have some control. So let's stop wasting time and bandwidth here in some weird exercise of mathematical perfection which is hopeless and pointless in the first place. The model on the table makes a GIGANTIC improvement in the managability and operational robustness of IP6 networks, but it does NOT offer fault-tolerance, nor is such a promise remotely required by the stated requirements. If you need F/T, go look at adapting the simplified OSI session protocol. In its minimal form it's quite lightweight and *might* do what you want without including all the ugly stuff. Now let's get back to rational engineering, rather than creating the most complicated thing we *think* we might be able to make work. -Mike O'Dell Resident Crank ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 21 07:53:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02338; Wed, 21 Sep 94 07:53:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02332; Wed, 21 Sep 94 07:53:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12275; Wed, 21 Sep 94 07:50:15 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA03460; Wed, 21 Sep 94 07:49:49 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA27036; Wed, 21 Sep 94 10:45:41 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9409211445.AA27036@pluto.dss.com> Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Wed, 21 Sep 1994 10:45:40 -0400 (EDT) Cc: ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: from "Alan Cox" at Sep 21, 94 10:29:46 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2637 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Fragmentation is another example of this mindlessness. > > Unless the situation has changed since I last checked up on IPV6, > > fragmentation is confined to end-hosts. > > I read this as a simplification of IPv4 fragmentation that will speed up routing. > I think your complexity argument is questionable since you already have to know > if a packet is local before fragmenting and you can sensibly fragment a packet > before it meets the same point in your code that outgoing forwarded frames > take. If your code internals are really so complex you can't make that > decision fast it begs the question of Why ? > Alan Fragmentation only slows down a router when the router fragments. And routers fragment when there is a reason to fragment in which case there is a reason to pay the cost of fragmenting. This argument of removing fragmentation to speed up routing is completely bogus because the only time fragmenting slows down routing is when the router must fragment, but forbidding router fragmenting could make it impossible to route altogether which hardly seems like an improvement. (I know the end host is supposed to have determined the correct size for the routing path but that idea represents total fantasy because the actual maximum transmission size could easy change as the end-host is fragmenting the packet or after transmission from the end-host but before the fragments have reached some intermediate router.) The Constellations Series Bridge/Router network forwarding code is very simple which is why these Brouters are probably the highest performers in their class. Because of the code's simplicity the output routine simply does not know whether the packet is being forwarded from an external network interface, the current routing functionality's associated end-host functionality, the previous routing functionality's forwarding processes or the previous routing functionality's associated end host functionality. To carry this information along with the packet to the output routine and to check this information in order to determine whether the packet is fragmentable would be costly. As far as I can tell the only reason this stupidity is being foisted on us lies in Steve Deering's dislike of fragmentation. And after seeing Deering's presentation a few weeks ago, I see no obvious reason to care that he does not like fragmentation. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 21 07:54:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02350; Wed, 21 Sep 94 07:54:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02344; Wed, 21 Sep 94 07:53:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12323; Wed, 21 Sep 94 07:50:42 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA03503; Wed, 21 Sep 94 07:50:06 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA27036; Wed, 21 Sep 94 10:45:41 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9409211445.AA27036@pluto.dss.com> Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Wed, 21 Sep 1994 10:45:40 -0400 (EDT) Cc: ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: from "Alan Cox" at Sep 21, 94 10:29:46 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2637 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Fragmentation is another example of this mindlessness. > > Unless the situation has changed since I last checked up on IPV6, > > fragmentation is confined to end-hosts. > > I read this as a simplification of IPv4 fragmentation that will speed up routing. > I think your complexity argument is questionable since you already have to know > if a packet is local before fragmenting and you can sensibly fragment a packet > before it meets the same point in your code that outgoing forwarded frames > take. If your code internals are really so complex you can't make that > decision fast it begs the question of Why ? > Alan Fragmentation only slows down a router when the router fragments. And routers fragment when there is a reason to fragment in which case there is a reason to pay the cost of fragmenting. This argument of removing fragmentation to speed up routing is completely bogus because the only time fragmenting slows down routing is when the router must fragment, but forbidding router fragmenting could make it impossible to route altogether which hardly seems like an improvement. (I know the end host is supposed to have determined the correct size for the routing path but that idea represents total fantasy because the actual maximum transmission size could easy change as the end-host is fragmenting the packet or after transmission from the end-host but before the fragments have reached some intermediate router.) The Constellations Series Bridge/Router network forwarding code is very simple which is why these Brouters are probably the highest performers in their class. Because of the code's simplicity the output routine simply does not know whether the packet is being forwarded from an external network interface, the current routing functionality's associated end-host functionality, the previous routing functionality's forwarding processes or the previous routing functionality's associated end host functionality. To carry this information along with the packet to the output routine and to check this information in order to determine whether the packet is fragmentable would be costly. As far as I can tell the only reason this stupidity is being foisted on us lies in Steve Deering's dislike of fragmentation. And after seeing Deering's presentation a few weeks ago, I see no obvious reason to care that he does not like fragmentation. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 21 10:23:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00204; Wed, 21 Sep 94 10:23:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01993; Tue, 20 Sep 94 15:45:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28334; Tue, 20 Sep 94 15:42:40 PDT Received: from scratchy (scratchy.inner.net) by Sun.COM (sun-barr.Sun.COM) id AA29571; Tue, 20 Sep 94 15:42:00 PDT Received: from itchy by scratchy with smtp (Smail3.1.28.1 #6) id m0qn9pQ-00000NC; Tue, 20 Sep 94 18:22 Received: from itchy.inner.net by itchy with smtp (Smail3.1.28.1 #2) id m0qnACE-000FRRC; Tue, 20 Sep 94 18:45 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Learning who we are In-Reply-To: Your message of "Tue, 20 Sep 1994 15:36:03 +0200." X-Mailer: exmh version 1.5gamma 8/15/94 Date: Tue, 20 Sep 1994 14:45:41 -0400 From: Craig Metz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message , you write: >It's probably worth pointing out here that learning prefixes is not a massive >problem and IPX already does this to a limited extent by querying for >network numbers from the server. And when the server goes down? My experience is that you're hosed. Do we want IPv6 to work this way? -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 21 11:11:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00253; Wed, 21 Sep 94 11:11:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00247; Wed, 21 Sep 94 11:11:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29380; Wed, 21 Sep 94 11:07:51 PDT Received: from iifeak.swan.ac.uk ([137.44.100.1]) by Sun.COM (sun-barr.Sun.COM) id AA20737; Wed, 21 Sep 94 11:06:25 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Learning who we are To: ipng@sunroof.Eng.Sun.COM Date: Wed, 21 Sep 1994 19:02:55 +0200 (BST) In-Reply-To: from "Craig Metz" at Sep 20, 94 02:45:41 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 655 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >It's probably worth pointing out here that learning prefixes is not a massive > >problem and IPX already does this to a limited extent by querying for > >network numbers from the server. > > And when the server goes down? > > My experience is that you're hosed. Do we want IPv6 to work this way? A broadcast (or better still multicast 8)) query doesn't mean this. So long as one server (substitute the word router) is up you are ok. If you got no routers you're pretty hosed. Allowing a prefix of 'this network' would make things work in those cases and allow people to set up subnets and later join the internet would be of interest too. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 21 11:39:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00269; Wed, 21 Sep 94 11:39:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00263; Wed, 21 Sep 94 11:38:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02065; Wed, 21 Sep 94 11:35:41 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA26526; Wed, 21 Sep 94 11:34:34 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12347; Thu, 22 Sep 1994 04:21:10 +1000 (from kre@munnari.OZ.AU) To: martillo@pluto.dss.com (Joachim Martillo) Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Wed, 21 Sep 1994 10:45:40 -0400." <9409211445.AA27036@pluto.dss.com> Date: Thu, 22 Sep 1994 04:21:03 +1000 Message-Id: <6081.780171663@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 21 Sep 1994 10:45:40 -0400 (EDT) From: martillo@pluto.dss.com (Joachim Martillo) To: ipng@sunroof.Eng.Sun.COM cc: ip-ng@sunroof2.Eng.Sun.COM Message-ID: <9409211445.AA27036@pluto.dss.com> Please stop sending messages to both "ipng" and "ip-ng", they're the same list, everything you send is being duplicated. And now I know I'm going to regret this, but ... Fragmentation only slows down a router when the router fragments. That's true, router performance has nothing to do with this. The Constellations Series Bridge/Router network forwarding code is very simple ... It sounds way too simple to me. Because of the code's simplicity the output routine simply does not know whether the packet is being forwarded from an external network interface, ... To carry this information along with the packet to the output routine and to check this information in order to determine whether the packet is fragmentable would be costly. Huh? Balderdash. Carrying the info is cheap, the test on whether fragmentation can be done need only be done after its determined that fragmentation is (would be) needed, in which case the cost of the test is totally dwarfed by the cost of doing the fragmentation (if it were to be done) and doesn't matter at all. Whether carring the packet source info is cheap or not, its required, otherwise you have no way to know whether you should be sending a redirect - the fragmentation decision needs to be made at exactly the point where you need to decide on redirects (the information for both becomes available at the same instant). If your code is so simple that it doesn't have enough info to be able to work out if a redirect should be sent, its too simple to be useful. If it does have that info, then it can trivially decide whether it should fragment or not. But even beyond that, with IPv6, fragmentation is supposed to be an end host only function - that is, it shouldn't be at the IP level at all, the higher level (TCP, UDP, ...) that is sending the packet probably should be deciding whether fragmentation is needed. It needs access to the MTU, and MTU discovery for intelligent packet size selection in any case. As far as I can tell the only reason this stupidity is being foisted on us lies in Steve Deering's dislike of fragmentation. Just about everyone dislikes fragmentation - other than at the source - it's evil. A fragmented packet allows some of the data to be lost, but not all of it, meaning that the source ends up retransmitting data that has already arrived, and which ends up sitting uselessly at the receiver, consuming buffer space awaiting fragments which will never appear. In practice fragmentation is so evil that it very rarely happens. There is plenty of host level code around that simply dies if fragmented packets ever arrive (either literally crashes, or simply discards fragments unilaterally). That all that cheap crud code is still used (and sold) shows just how little fragmentation is actually used - other than for source generated fragmentation (eg: NFS) where at least the source knows that fragments are being used, and can adapt its behaviour to that. The reason that fragmentation is so little used is the mess it creates when it is used more, implementations go to all kinds of lengths (like not sending packets > 512 bytes whenever the destination is the other side of a router) to prevent it. kre ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 21 20:37:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00904; Wed, 21 Sep 94 20:37:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00898; Wed, 21 Sep 94 20:37:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12795; Wed, 21 Sep 94 20:34:03 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA27515; Wed, 21 Sep 94 20:33:38 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 22 Sep 94 12:25:17 +0900 From: Masataka Ohta Message-Id: <9409220325.AA00113@necom830.cc.titech.ac.jp> Subject: Re: (IPng) Re: Automatic Renumbering To: ipng@sunroof.Eng.Sun.COM Date: Thu, 22 Sep 94 12:25:16 JST In-Reply-To: <199409202029.AA02819@zed.isi.edu>; from "bmanning@ISI.EDU" at Sep 20, 94 1:29 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Can we guarantee that no TCP session lasts longer than the DNS TTL, to > > ensure that bogus but correct looking TCP packets don't show up? > > What happens when DNS changes the size or meaning of the TTL? >From the security point of view, any stale DNS data must be able to be revoked within a reasonable amount of time, perhaps, at most within a week. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 22 02:55:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01049; Thu, 22 Sep 94 02:55:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01031; Thu, 22 Sep 94 02:07:57 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21393; Thu, 22 Sep 94 02:04:41 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA24279; Thu, 22 Sep 94 02:03:38 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Thu, 22 Sep 1994 10:03:14 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Thu, 22 Sep 1994 10:00:15 +0100 Date: Thu, 22 Sep 1994 10:00:15 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003761] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3761 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3761*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re NSAP MAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Jack, >Should this be in an End-to-End option or a Hop-by- >Hop? i.e. where is it looked at. It would seem to me >that it would be looked at by the destination node and >is not needed by the routers along the way. >Scott You could well be right, what does everybody else think? Jack ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 22 21:12:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01481; Thu, 22 Sep 94 21:12:33 PDT Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01475; Thu, 22 Sep 94 21:12:22 PDT Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh) id VAA10026; Thu, 22 Sep 1994 21:09:07 -0700 Received: from scratchy (scratchy.inner.net) by Sun.COM (sun-barr.Sun.COM) id AA04977; Thu, 22 Sep 94 21:08:45 PDT Received: from itchy by scratchy with smtp (Smail3.1.28.1 #6) id m0qnxrk-00000OC; Thu, 22 Sep 94 23:47 Received: from itchy.inner.net by itchy with smtp (Smail3.1.28.1 #2) id m0qnyGB-000FRRC; Fri, 23 Sep 94 00:13 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Learning who we are In-Reply-To: Your message of "Wed, 21 Sep 1994 19:02:55 +0200." X-Mailer: exmh version 1.5gamma 8/15/94 Date: Thu, 22 Sep 1994 20:13:06 -0400 From: Craig Metz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message , you write: >> And when the server goes down? >> >> My experience is that you're hosed. Do we want IPv6 to work this way? > >A broadcast (or better still multicast 8)) query doesn't mean this. So long >as one server (substitute the word router) is up you are ok. If you got no >routers you're pretty hosed. Allowing a prefix of 'this network' would make >things work in those cases and allow people to set up subnets and later >join the internet would be of interest too. Consider the altogether common configuration: Host 1-| Host 2-| . |--router--WAN . . Host n-| My concern is with temporary loss of service in the router. Loss of router (where we make router = server for prefix configuration purposes) function should definitely not affect local communication. Local network addresses are a must here IMO (the ``this network'' prefix). The next question is with respect to learning the global prefix. If host m (m <= n) is just coming up and wants to get its prefix while the other hosts are up, should it be able to get prefix information from the other hosts, or should it defer a query to the router for that prefix? Even when communication can't actually happen because a router is down, there will probably be situations in which a host will need to know its global address. Having way for in which a host's peers can tell it what its global address is, ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 22 21:42:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01493; Thu, 22 Sep 94 21:42:53 PDT Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01487; Thu, 22 Sep 94 21:42:42 PDT Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh) id VAA10739; Thu, 22 Sep 1994 21:39:27 -0700 Received: from scratchy (scratchy.inner.net) by Sun.COM (sun-barr.Sun.COM) id AA07044; Thu, 22 Sep 94 21:38:58 PDT Received: from itchy by scratchy with smtp (Smail3.1.28.1 #6) id m0qnyKz-00000OC; Fri, 23 Sep 94 00:18 Received: from itchy.inner.net by itchy with smtp (Smail3.1.28.1 #2) id m0qnyjS-000FRzC; Fri, 23 Sep 94 00:43 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Learning who we are In-Reply-To: Your message of "Wed, 21 Sep 1994 19:02:55 +0200." Date: Thu, 22 Sep 1994 20:43:20 -0400 From: Craig Metz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message , you write: >> And when the server goes down? >> >> My experience is that you're hosed. Do we want IPv6 to work this way? >A broadcast (or better still multicast 8)) query doesn't mean this. So long >as one server (substitute the word router) is up you are ok. If you got no >routers you're pretty hosed. Allowing a prefix of 'this network' would make >things work in those cases and allow people to set up subnets and later >join the internet would be of interest too. Consider the very real scenario: Host 1-| Host 2-| . |--router--WAN . . Host i-| . . Host n-| If the router goes down, I think we will all agree that the hosts should be able to communicate within themselves, and this is assisted by a intra-link scope prefix[?] (the ``this network'' prefix). Let's say all hosts except Host i are up and know their global prefix and the global address of Host i. Host i is coming up and needs to autoconfigure its addresses. With the router down, is there a secure and manageable way in which Host i could get its global address from its peers, or must it defer a query to the router for when it comes up? It would seem to me that there would be value in Host i knowing its global address even when it cannot actually address things outside its local network. (As an aside, if it could get that information from its peers, how do we assure that we have no conflicts with automatic renumbering? This is something to consider with worst-case scenarios.) -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 23 00:45:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01554; Fri, 23 Sep 94 00:45:54 PDT Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01548; Fri, 23 Sep 94 00:45:46 PDT Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh) id AAA13742; Fri, 23 Sep 1994 00:42:30 -0700 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA25584; Fri, 23 Sep 94 00:42:09 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA26664; Fri, 23 Sep 1994 09:44:18 +0200 Message-Id: <199409230744.AA26664@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Learning who we are In-Reply-To: Your message of "Thu, 22 Sep 1994 20:13:06 EDT." Date: Fri, 23 Sep 1994 09:44:17 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, The protection against "temporary losses of a router" which you mention is a classic case of black-hole detection. The station heard a router advertisement from R some times ago; it sent the packets to destination FOO towards that router, R, accordingly; it has some reasons to believe that the packet did not make it towards FOO. A proper line of action (black hole detection) is to fall back to the default router (if R is not the default router), then to try a local access (if R was actually the default router). I will admit that this provides a longer response time than sending the packet to the proper destination in the first place. But that price will only be payed when the station believes that there is a router, then finds out that the router is not present; that should only last for the time to live of the router's advertisement. Moreover, once the black-hole is detected, it makes sense zap away the said advertisement and to reverse to a local strategy until the next advertisement is received. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 23 13:34:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00546; Fri, 23 Sep 94 13:34:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00540; Fri, 23 Sep 94 13:34:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27324; Fri, 23 Sep 94 13:31:15 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA20167; Fri, 23 Sep 94 13:29:17 PDT Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4961; Fri, 23 Sep 94 16:28:46 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 7471; Fri, 23 Sep 1994 16:28:44 EDT Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Fri, 23 Sep 94 16:28:39 EDT Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA25579; Fri, 23 Sep 1994 16:28:31 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9409232028.AA25579@hawpub1.watson.ibm.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Mobility support in IPv6 Date: Fri, 23 Sep 94 16:28:31 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I've submitted an Internet Draft detailing some ideas for supporting mobility under IPv6. My co-authors (Dave Johnson and Andrew Myles) and I think that the ideas in that draft fit naturally within the current specifications of IPv6, and with our understanding of the intentions of the designers. We also think that the IPv6 mobility support comes as a natural evolution of the IPv4 design, taking into account the assumed availability of authentication mechanisms. Comments are solicited; I expect to participate in the upcoming implementor's workshop in Cambridge next month, and development of mobility support for IPv6 at that workshop would be of great interest if there is time. The name of the draft is: draft-ietf-mobileip-ipv6-support-00.txt and it's available in the standard internet draft directories. We put an almost identical version of the draft out for consideration by the mobile-IP working group earlier this week. The previous version was changed to reflect more clearly that one natural way of sending location updates is to define another end-to-end option for the IPv6 header. I should explicitly mention that our draft is _not_ a product of the IPv4 mobile-IP working group. The following paragraph is taken from the announcement to the mobile-IP mailing list: The development of IPv6 presents a rare opportunity to consider in what ways mobility could explicitly be taken into account in the design of IPv6, and in what ways the current work on mobility within IPv4 can or should be changed to take advantage of IPv6. Mobile computers are very likely to account for a substantial fraction of the future population of the Internet during the lifetime of IPv6. We expect that the combination of a projected need for mobile computing, and clearly specified features within IPv6 to enable it, should make the necessary operations essentially automatic and universally available. Thanks. Charlie Perkins perk@watson.ibm.com Dave Johnson dbj@cs.cmu.edu Andrew Myles andrewm@mpce.mq.edu.au ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 24 03:22:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00804; Sat, 24 Sep 94 03:22:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00792; Sat, 24 Sep 94 03:22:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12311; Sat, 24 Sep 94 03:18:52 PDT Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA20601; Sat, 24 Sep 94 03:18:32 PDT Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id DAA29218; Sat, 24 Sep 1994 03:18:26 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 24 Sep 1994 04:18:30 -0600 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: (IPng) Discovery Cc: ipng@sunroof.Eng.Sun.COM, ip-ng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joachim, At 7:45 AM 9/21/94, Joachim Martillo wrote: >As far as I can tell the only reason this stupidity is being foisted >on us lies in Steve Deering's dislike of fragmentation. And after >seeing Deering's presentation a few weeks ago, I see no obvious reason >to care that he does not like fragmentation. Sorry, sir, but there's LOTS of folks who don't like fragmentation and there's something like 3-5 years of effort by them -- yes, including Dr. Steve -- to remove the need for it. Fragmentation is an extremely good idea, trying to solve problems with differential MTUs. The fact that end-system reassembly is specified, rather than "last router in the net causing the fragmentation" is because the fragmentation might be caused in the last network, so that there's no router between the fragmenting router and the receiving host. Good idea, but lots of bad operational impact. IPv6 concessions in this matter were/are strictly to facilitate transition from IPv4. D/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 24 03:22:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00805; Sat, 24 Sep 94 03:22:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00793; Sat, 24 Sep 94 03:22:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12311; Sat, 24 Sep 94 03:18:52 PDT Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA20601; Sat, 24 Sep 94 03:18:32 PDT Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id DAA29218; Sat, 24 Sep 1994 03:18:26 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 24 Sep 1994 04:18:30 -0600 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: (IPng) Discovery Cc: ipng@sunroof.Eng.Sun.COM, ip-ng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joachim, At 7:45 AM 9/21/94, Joachim Martillo wrote: >As far as I can tell the only reason this stupidity is being foisted >on us lies in Steve Deering's dislike of fragmentation. And after >seeing Deering's presentation a few weeks ago, I see no obvious reason >to care that he does not like fragmentation. Sorry, sir, but there's LOTS of folks who don't like fragmentation and there's something like 3-5 years of effort by them -- yes, including Dr. Steve -- to remove the need for it. Fragmentation is an extremely good idea, trying to solve problems with differential MTUs. The fact that end-system reassembly is specified, rather than "last router in the net causing the fragmentation" is because the fragmentation might be caused in the last network, so that there's no router between the fragmenting router and the receiving host. Good idea, but lots of bad operational impact. IPv6 concessions in this matter were/are strictly to facilitate transition from IPv4. D/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 26 00:10:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01039; Mon, 26 Sep 94 00:10:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01033; Mon, 26 Sep 94 00:10:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12899; Mon, 26 Sep 94 00:07:20 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA22518; Mon, 26 Sep 94 00:06:57 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA04162; Mon, 26 Sep 1994 17:06:54 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA06446; Mon, 26 Sep 94 16:55:56 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT04999; Mon, 26 Sep 1994 16:55:55 EST Date: 26 Sep 94 17:05:41 +1100 To: /G=kim/S=fenley/OU2=dditcs/OU=cm-dimp/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@x400gw.datacraft.com.au, ipng@sunroof.Eng.Sun.COM Subject: (IPng) GENERAL IPNG ISSUES Ua-Content-Id: 940923 07:47:35 P1-Recipient: /G=kim/S=fenley/OU2=dditcs/OU=cm-dimp/O=hqadf/P=ausgovdefencenet/A=telememo/C=au/@x400gw.datacraft.com.au, ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940923 07:47:35 009 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TELEMEMO*DATACRAFT; arrival 940926170541+1100 deferred 940926170541+1100 action Relayed Message-Id: <"940923 07:47:35"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Forwarded to: x400@mis@dcpmel[c=au;a=telememo;p=ausgovdefencenet;o=hqadf;ou1=cm-dimp;ou2=dditcs;s=fenley;g=kim;] x400@mis@dcpmel[c=au;a=telememo;p=datacraft;o=smtp;s=ipng(a)sunroof.eng.sun.com;] cc: Comments by: Alan Lloyd@Marketing@DCTHQ Comments: anyone on the list... got any comments on this please... regards alan@Oz.. PS why do people say that 16 bytes is enough to address the people on the entire planet squillions of times over when addresses relate to location... geography? even more regards...... -------------------------- [Original Message] ------------------------- gday all Could some one enlighten me on the issues I have raised.. as they seem to be black holed! Flow Ids .. I do not see how this can work on a "user" basis because it relies on router latency (for that specfic user) and lots of management protocols to control it.. The bigger the network the worse it will be and therefore the slower the network will go! Self defeating flow control. I proposed that IP4 TOS was extended to permit easy migration.. The integrity issue.. It was unclear how this is processed.. Perhaps a separate Integrity option could be defined in Hop by Hop.. so that the SIPP fields incorporated could be specified eg. Option Integrity Type Lenght, Value = SIPP Header components (to be included in check) Hop by Hop Options ( ditto) End to End Options ( ditto) Sequence No / Checksum Authentication kept distinct. (Password / Signature) Ordering of Options to be removed. I suppose the other difficulty I have is the development "process" .. and this may be becuse of being in the Antipodes (and behind bars)..If SIPP addresses cover humungous networks, then the way the address is administered and "cut up" and applied across the planet will implicate the routing, discovery, automatic address reassignment and the management of the network...and therefore its protocol(s) design. This is probably understood.. but are there any docs or guidelines I could read on this..As I find it difficult to talk about discovery and automatic addressing and flow control without putting a few scenarios of network scale around them.. Looking forward to responses Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 26 03:17:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01180; Mon, 26 Sep 94 03:17:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01174; Mon, 26 Sep 94 03:17:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20750; Mon, 26 Sep 94 03:14:00 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA06633; Mon, 26 Sep 94 03:13:31 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA23950; Mon, 26 Sep 94 06:09:26 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9409261009.AA23950@pluto.dss.com> Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Mon, 26 Sep 1994 06:09:25 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo), mario@pluto.dss.com (Mario Savvides) In-Reply-To: from "Dave Crocker" at Sep 24, 94 04:18:30 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3617 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Joachim, > At 7:45 AM 9/21/94, Joachim Martillo wrote: > >As far as I can tell the only reason this stupidity is being foisted > >on us lies in Steve Deering's dislike of fragmentation. And after > >seeing Deering's presentation a few weeks ago, I see no obvious reason > >to care that he does not like fragmentation. > Sorry, sir, but there's LOTS of folks who don't like fragmentation and > there's something like 3-5 years of effort by them -- yes, including Dr. > Steve -- to remove the need for it. > Fragmentation is an extremely good idea, trying to solve problems with > differential MTUs. The fact that end-system reassembly is specified, > rather than "last router in the net causing the fragmentation" is because > the fragmentation might be caused in the last network, so that there's no > router between the fragmenting router and the receiving host. > Good idea, but lots of bad operational impact. But people who want to remove fragmentation must prove that the bad operational impact is due to fragmentation and reassembly rather than to bad implementations of fragmentation and reassembly. The mere fact that many software engineers are incompetent does not justify the removal of useful functionality. I have worked with too many important IETF contributors, and I have been contracted too often to fix the messes left by important IETF contributors to accept IETF pontification without question. As a sanity check on this IETF position, let's try the following three operational problems. 1) An internet grows so large (IPng is supposed to address the problem of humongous internets) that the path packets take between end-hosts changes on practically each packet with resultant changes in path MTU on each successive packet (or even during the process of end-host fragmentation). Compare and contrast the operational effects of IPv4 fragmentation procedures versus the operational effects of IPng MTU discovery procedures. 2) I have not worked with conferencing procedures over the internet but I assume this functionality make use of multicast capabilities. In any case, I could conceive of many applications besides conferencing which could make use of a multicast capability. As such there is a 1 -> N problem where the N endhosts may be on different networks with different MTU sizes across the path to each of the endhost. What is the operational effect for a multicast application of the elimination of router fragmentation? 3) A large internet contains an X.25 comms. subnet wherein every DTE is connected to a DCE via a satelite like with large packet size (4096) but small level three window (1 or 2) but common paths between end host cross a subnet whereon the MTU is 576 bytes. Assume that all the physical media are highly reliable. Compare and contrast the operational effects of IPv4 fragmentation procedures versus the operational effects of IPng MTU discovery procedurs. (Hint: Penril provides bridge routers for a very large network of this sort. The non-Penril engineers who manage the site want router reassembly as packets cross from LANs to the X.25 comms. subnet even though packets may have to be fragmented as the cross from the X.25 comms. subnet to a next-hop LAN.) > IPv6 concessions in this matter were/are strictly to facilitate transition > from IPv4. > -------------------- > Dave Crocker Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 26 03:38:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01204; Mon, 26 Sep 94 03:38:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01198; Mon, 26 Sep 94 03:38:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21149; Mon, 26 Sep 94 03:35:12 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA08799; Mon, 26 Sep 94 03:34:50 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Mon, 26 Sep 1994 11:32:25 +0200 (BST) In-Reply-To: <9409261009.AA23950@pluto.dss.com> from "Joachim Martillo" at Sep 26, 94 06:09:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2052 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 1) An internet grows so large (IPng is supposed to address the problem > of humongous internets) that the path packets take between end-hosts > changes on practically each packet with resultant changes in path MTU > on each successive packet (or even during the process of end-host > fragmentation). Compare and contrast the operational effects of IPv4 > fragmentation procedures versus the operational effects of IPng MTU > discovery procedures. If the discovery code is sane it will include enough reluctance to change up that it won't switch rapidly. That is stil more desirable than the fragmenting in IPv4. > 2) I have not worked with conferencing procedures over the internet > but I assume this functionality make use of multicast capabilities. > In any case, I could conceive of many applications besides > conferencing which could make use of a multicast capability. > As such there is a 1 -> N problem where the N endhosts may be on > different networks with different MTU sizes across the path to each of > the endhost. What is the operational effect for a multicast > application of the elimination of router fragmentation? 'Direct hit' is the phrase that sums that one up. Trying to reduce to the lowest mtu of all hosts for thousands of hosts is a nasty one. A question to raise it seems therefore is ways of making fragmentation efficient. One problem with IP is that you can't know the size of the entire buffer and preallocate a linear buffer to throw all the data in. Another speed up would be making the lowest legal MTU >= twice the max header length of the packet (eg 128 for IPv4). This allows people using linear buffers for speed or with fast non scatter/gather DMA drivers to fragment a frame making only one copy (ie copy the buffer and then interleave headers between the two), finally send out the chunks carved from the two buffers. The half of a fragmented frame getting lost argument is mostly crap - the IP spec provides for retransmits to use the same numbers so that fragments from two can be merged. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 26 04:29:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01221; Mon, 26 Sep 94 04:29:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01215; Mon, 26 Sep 94 04:29:33 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22437; Mon, 26 Sep 94 04:26:16 PDT Received: from atlas.xylogics.com by Sun.COM (sun-barr.Sun.COM) id AA11890; Mon, 26 Sep 94 04:25:51 PDT Received: from vulcan.xylogics.com by atlas.xylogics.com with SMTP id AA23219 (5.65c/UK-2.1-940401); Mon, 26 Sep 1994 07:29:57 -0400 Received: from localhost by vulcan.xylogics.com id AA17096 (4.1/UK-2.1-940201); Mon, 26 Sep 94 07:29:54 EDT Message-Id: <17096.9409261129@vulcan.xylogics.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) GENERAL IPNG ISSUES In-Reply-To: Your message of "26 Sep 1994 17:05:41 +1100." <"940923 07:47:35"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> Date: Mon, 26 Sep 1994 07:29:53 -0400 From: James Carlson Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au > Date: 26 Sep 94 17:05:41 +1100 > Subject: (IPng) GENERAL IPNG ISSUES > > Comments by: Alan Lloyd@Marketing@DCTHQ > Comments: > > anyone on the list... got any comments on this please... > > regards alan@Oz.. > > PS why do people say that 16 bytes is enough to address the people on the > entire planet squillions of times over when addresses relate to location... > geography? 16 bytes is 2^128, or 340,282,366,920,938,463,463,374,607,431,768,211,456. This is a humorously large address space. Taking a SWAG at the size of the Earth, about 201,062,400 square miles, this comes to around 1,692,421,690,584,308,470,720,406,239,216 addresses per square mile of Earth's surface, or about 421,578,297,421,497,485,189 addresses per square inch. Even if we chop off three bytes to indicate galaxy, solar system and planet, we'd still have 25,128,024 addresses per square *mil* here on Earth. Pathology will never be the same after every microbe has its own address ... (Special thanks to Lorinda Cherry and Robert Morris for "bc". Not to be misconstrued as a demand for the 8 byte version again! ;-}) --- James Carlson Tel: +1 617 272 8140 Annex Software Support / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 26 08:52:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01371; Mon, 26 Sep 94 08:52:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01365; Mon, 26 Sep 94 08:52:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04902; Mon, 26 Sep 94 08:48:45 PDT Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA13320; Mon, 26 Sep 94 08:48:24 PDT Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA06292; Mon, 26 Sep 1994 08:48:18 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Sep 1994 08:48:21 -0700 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: (IPng) Discovery Cc: ipng@sunroof.Eng.Sun.COM, martillo@pluto.dss.com (Joachim Martillo), mario@pluto.dss.com (Mario Savvides) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joachim, At 3:09 AM 9/26/94, Joachim Martillo wrote: >been contracted too often to fix the messes left by important IETF >contributors to accept IETF pontification without question. Overall, your note represents a new high in your learning curve. You almost managed to send a note which was neutral in personal tone and constructive in suggesting lines of inquiry. The above extract, however, shows that you still have some ways to go. The next step, is to have your messages show technical contribution, rather than just asking questions and offering technical challenges. Please keep trying. >1) An internet grows so large (IPng is supposed to address the problem >of humongous internets) that the path packets take between end-hosts >changes on practically each packet with resultant changes in path MTU changes that are that rapid do NOT reflect long-standing data on packet system behavior. Well-behaved packet systems have long shown relatively stable routing. Packet systems which are not well-behaved will show lots of problems and are not the systems for us to optimize against. >fragmentation). Compare and contrast the operational effects of IPv4 >fragmentation procedures versus the operational effects of IPng MTU >discovery procedures. I'd be glad to see you offer such a comparison. >3) A large internet contains an X.25 comms. subnet wherein every DTE >is connected to a DCE via a satelite like with large packet size >(4096) but small level three window (1 or 2) but common paths between A satellite channel that permits a only 1 or 2 outstanding packets is going to have far worse problems than we are talking about here. >end host cross a subnet whereon the MTU is 576 bytes. Assume that all >the physical media are highly reliable. Compare and contrast the >operational effects of IPv4 fragmentation procedures versus the >operational effects of IPng MTU discovery procedurs. Again, it would be great to see you do such work, rather than to assign it to others. >reassembly as packets cross from LANs to the X.25 comms. subnet even >though packets may have to be fragmented as the cross from the X.25 >comms. subnet to a next-hop LAN.) Nothing in IPv4 prevents a given lower-level technology (network or link-level) from providing entry/exit services below IP. In this case, there is nothing preventing a lower-level service from conducting fragmentation, as long as it also peforms the necessary reassembly before delivering the packet to the end-user system or a the next IPv6 router. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 26 09:30:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01408; Mon, 26 Sep 94 09:30:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01390; Mon, 26 Sep 94 09:30:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08390; Mon, 26 Sep 94 09:27:00 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA21561; Mon, 26 Sep 94 09:26:37 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm035-08.dialip.mich.net [141.211.7.19]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA15157; Mon, 26 Sep 1994 12:26:34 -0400 Date: Mon, 26 Sep 94 15:36:04 GMT From: "William Allen Simpson" Message-Id: <3248.bill.simpson@um.cc.umich.edu> To: mobile-ip@sunroof.Eng.Sun.COM Subject: (IPng) Re: Mobility Support in IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Majordomo blew up last week. Here is a message that I sent: Date: Wed, 21 Sep 94 15:44:31 GMT > The development of IPv6 presents a rare opportunity to consider in what > ways mobility could explicitly be taken into account in the design of IPv6, I'm sure that I will be delighted to look at what you have written, as soon as I shake this illness (I've been sick in bed for 5 days now). I tried mightily to get Mobile-IP to work on SIPP. You three protested. So, we did it without you. The IPv6 Mobility has been done for well over a year. Yes, we took a look at what was needed to support mobility, and it is already embedded in IPv6 Neighbor Discovery. You should not be surprised, since many (not all) of the IPv6 features have been been ported back to IPv4. Extensions, Authentication, et alia. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 26 09:30:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01409; Mon, 26 Sep 94 09:30:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01396; Mon, 26 Sep 94 09:30:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08398; Mon, 26 Sep 94 09:27:04 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA21585; Mon, 26 Sep 94 09:26:42 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm035-08.dialip.mich.net [141.211.7.19]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA15164 for ; Mon, 26 Sep 1994 12:26:39 -0400 Date: Mon, 26 Sep 94 15:45:47 GMT From: "William Allen Simpson" Message-Id: <3249.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Turning on and off host hello Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Majordomo self-destructed last week. Here's a message I sent: Date: Thu, 22 Sep 94 13:07:44 GMT > From: Dave Katz > The mechanism you suggested was all hosts sending periodic hellos. > > This was rejected over a year and a half ago. It resulted in the 2nd > criteria (reduced net traffic), and specific language rejecting ES-IS. > > The mechanism I suggested was routers telling hosts how often to send > hellos; a period of "0" would give us effectively the same mechanism > you've described (the host's first hello is a solicitation; the > router's hello [carrying the '0'] is the advertisement/reply; the host > shuts up after that). No additional traffic for networks configured > to use subnet-per-wire; expanding subnets across wires can be done if > desired without changing anything on the hosts. > I have re-read your private comments, and admit I was confused by the "solicit bit". You said: - the host sends a solicitation. - the router advertises, with a bit which says not to send any more solicitations. Since the current router advertisements already cause solicitations to stop, I didn't see anything new here. I don't see anything about "how often to send hellos". This is a novel approach. Are there any others out there who think we need a router advertisement field to turn on and off "host hellos"? What are the scenarios where this would be useful? Remember, we have previously rejected "expanding subnets across wires". Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 26 09:30:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01410; Mon, 26 Sep 94 09:30:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01402; Mon, 26 Sep 94 09:30:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08421; Mon, 26 Sep 94 09:27:10 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA21602; Mon, 26 Sep 94 09:26:47 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm035-08.dialip.mich.net [141.211.7.19]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA15167 for ; Mon, 26 Sep 1994 12:26:42 -0400 Date: Mon, 26 Sep 94 15:48:29 GMT From: "William Allen Simpson" Message-Id: <3250.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) next hop resolution Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Majordomo bit the dust last week. Here's a message I sent: Date: Thu, 22 Sep 94 13:18:00 GMT > From: Dave Katz > When the destination gives the SAME match on more than one link, then > the router Preference kicks in. > > I think that this is likely to be the case in most cases for which the > destination is not topologically near, and the matched bits will > effectively be the empty set (or something like "both are on planet earth", > which is roughly the same thing). I'm sorry, but you are wrong. If a host has two interfaces, and all routers say "I have the same match to the world", then by definition, they are equally as good for reaching the destination. Preferences are to break the tie. > The prefix is not all topological, > and not all topology is encoded in the prefix (if it were, we could > have bitwise source routing and I could go back to being a musician). > The prefix is _entirely_ topological, and all topology _is_ encoded in the prefix. If you want this to change, then please re-open that on big-internet, not here. > Furthermore, router preference is of dubious value because it is far > too coarse--it is not coupled to any particular destination. > Since the host doesn't bloody well care which interface or router is used, as long as the packet reaches the destination, then this is a non-sequitor. We are deeply sorry you don't like the ICMP Router Advertisements mechanisms. However, after _years_ of discussion, this is what we are doing. > Let's take the disconnected case first. Prefix-match-length testing > could work in this case if the destination is local enough and > addresses were assigned carefully. If the unconnected internets are > sufficiently large and the destination isn't very local, the match > lengths may end up the same (the destination is on another provider, > for example, and there's essentially no overlap other than the admin > bits at the top). Relatively unlikely, granted. Wrong. Impossible. See draft-simpson-ipv6-deploy-00.txt, section 5. > Now to the connected case. In my ether/FDDI example, the prefix-match > length would almost certainly be equal for any destination that > doesn't share a wire with the host; Wrong. See draft-simpson-ipv6-deploy-00.txt, sections 4, 5, 6. > however, here the preference value > could tell you that you should prefer FDDI (better to be told than to > guess, I suppose). > Of course. > However, for the connected case where the merge point is topologically > further off, the router preference doesn't really help. Imagine > the case where the multihomed host is attached to two networks, each > of which is connected to a different provider. The destination is > on a third provider. The prefixes have equal length. Which is the > right path? How do you set router preferences in this case? > Since by your statement the prefixes are equal, the preference indicates the local administration's desire to use one provider over the other. Of course, your statement may represent the incorrect assumption that there are not topological relationships between the providers. These would be reflected in the prefix. Dave, your further statements that the topology might somehow be hidden are at variance to the principles that were clearly stated in the rationale for having silly-16 addresses. You agreed to take a WG Chair in the IPng Area. If you don't agree with encoding topology in the addresses, why did you accept a WG Chair in the Area? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 26 10:58:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01653; Mon, 26 Sep 94 10:58:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01603; Mon, 26 Sep 94 10:54:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17217; Mon, 26 Sep 94 10:50:50 PDT Received: from epilogue.com (quern.epilogue.com) by Sun.COM (sun-barr.Sun.COM) id AA05107; Mon, 26 Sep 94 10:46:06 PDT From: Dave Bridgham To: ipng@sunroof.Eng.Sun.COM In-Reply-To: William Allen Simpson's message of Mon, 26 Sep 94 15:48:29 GMT <3250.bill.simpson@um.cc.umich.edu> Subject: (IPng) next hop resolution Date: Mon, 26 Sep 94 13:44:54 -0400 Message-Id: <9409261344.aa04637@quern.epilogue.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 26 Sep 94 15:48:29 GMT From: William Allen Simpson The prefix is _entirely_ topological, and all topology _is_ encoded in the prefix. The first part of your statement is clearly true but the second is severely limiting. The prefix only holds the routing heirarchy. The total topology will be much more complex even though the routing system can only see it as a simple heirarchy as seen in the prefix. If you want this to change, then please re-open that on big-internet, not here. No, those of us who wanted a flexible enough architecture to allow non-heirarchical routing lost big time. No need to do that again. Dave ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 26 16:11:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00584; Mon, 26 Sep 94 16:11:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00578; Mon, 26 Sep 94 16:11:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28697; Mon, 26 Sep 94 16:07:52 PDT Received: from avalon.mpce.mq.edu.au by Sun.COM (sun-barr.Sun.COM) id AA18535; Mon, 26 Sep 94 16:07:22 PDT Message-Id: <9409262307.AA18535@Sun.COM> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA12026; Tue, 27 Sep 94 09:06:59 est From: Andrew Myles Subject: Re: (IPng) Re: Mobility Support in IPv6 To: ipng@sunroof.Eng.Sun.COM Date: Tue, 27 Sep 94 9:06:57 EST In-Reply-To: <3248.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Sep 26, 94 3:36 pm Mailer: Elm [revision: 64.9] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM G'day Bill, We meet again. :) > > The development of IPv6 presents a rare opportunity to consider in what > > ways mobility could explicitly be taken into account in the design of IPv6, > > I tried mightily to get Mobile-IP to work on SIPP. That was a noble task you took on. :) > You three protested. So, we did it without you. I do not recall protesting against anything to do with IPv6. You must be mistaken. :) > The IPv6 Mobility has been done for well over a year. Yes, we took a > look at what was needed to support mobility, and it is already embedded > in IPv6 Neighbor Discovery. I am very surprised to hear you say that IPv6 mobility is complete as my evaluation of IPv6, as currently documented, is that it is deficient in a number of areas concerning mobility. A number of these issues are discussed in the Perkins, Johnson, Myles document. > You should not be surprised, since many (not all) of the IPv6 features > have been been ported back to IPv4. Extensions, Authentication, et alia. That is a rather unusual view of history. It sounds like you are claiming to have designed IPv4 mobility all by yourself. :) It should also be noted that the current IPv4 mobility document (if it is ever released - how many weeks late is it now?) uses a very poor model of mobility. This was recognised in San Diego when it was decided that route optimisation should become an extension to the basic document. If IPv6 is similar to IPv4 in this respect then there is a lot of work to get IPv6 up to scratch. Charlie, Dave and myself would like to contribute to that task. Andrew -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: Electronics Dept., Macquarie University 2109, Sydney, Australia. Telephone : +61 2 8509071 (W), +61 2 8509128 (Fax), +61 2 8786060 (H). ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 26 16:47:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00678; Mon, 26 Sep 94 16:47:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00666; Mon, 26 Sep 94 16:47:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03144; Mon, 26 Sep 94 16:44:23 PDT Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA26627; Mon, 26 Sep 94 16:44:01 PDT Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id TAA10987 for ipng@sunroof.Eng.Sun.COM; Mon, 26 Sep 1994 19:43:59 -0400 Date: Mon, 26 Sep 1994 19:43:59 -0400 From: Vadim Antonov Message-Id: <199409262343.TAA10987@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >changes that are that rapid do NOT reflect long-standing data on packet >system behavior. Well-behaved packet systems have long shown relatively >stable routing. Packet systems which are not well-behaved will show lots >of problems and are not the systems for us to optimize against. Internet is not a well-behaving system (and probably never will be). Our boxes are getting about 50 routing updates a second. A prudent engineering approach would be to design for the worst case. Climbing back on my internet operator's tree... --vadim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 26 20:20:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00788; Mon, 26 Sep 94 20:20:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00782; Mon, 26 Sep 94 20:19:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14529; Mon, 26 Sep 94 20:16:36 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA22353; Mon, 26 Sep 94 20:16:03 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA12212; Tue, 27 Sep 1994 13:15:53 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA07517; Tue, 27 Sep 94 10:36:29 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT04999; Tue, 27 Sep 1994 10:36:26 EST Date: 27 Sep 94 10:47:23 +1100 To: ipng@sunroof.Eng.Sun.COM, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au Subject: (IPng) DAMAGED THINKING Ua-Content-Id: 940927 09:22:46 P1-Recipient: ipng@sunroof.eng.sun.com, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940927 09:22:46 014 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TELEMEMO*DATACRAFT; arrival 940927104723+1100 deferred 940927104723+1100 action Relayed Message-Id: <"940927 09:22:46"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday, I thank John Carlson for his view that a mil of the earth can have 25m addresses.. Such comments do indicate the level of understanding on this issue.. When I do talk about addresses and their administration, and their impact on commercial boundaries, and their impact on routing protocols, and their impact on mobility (and security) and their impact on network scale and the networks overall management.. and quality of service .... It all goes quiet.. It is nice to now that 16 bytes can cover the planet.. but designing a 16 byte protocol does NOT make a global, commercially acceptable network that can be administered.. Said this already.. Perhaps John can inform me how this address space will be administered and how routing protocols are being designed to cope with its administration policy...? After all 25m addresses on a mil .. will require the ants to be recruited.. Perhaps someone would like to answer "In Engineering Terms" the other issues raised re flow control, integrity, option methodology...etc. Perhaps someone in the know can tell me that when a user puts up SIPPV4 with his/ two addresses in a mixed form across his/her enterprise how he/she knows the versions of all the destinations he/she has to deal with (across this planet) and both of their addresses... "global address administration".. I really thought we were over the crap responses... And as the Internet gets commercial pressure applied to it it will need those addressing and related issues (such as commercial administration) attended to.. Oh Well! As the govts and industries (aviation, maritime, defence and govts) scale up their networks (in the commercial env) they will require the same tools as provided by those embedded in commercial carrier systems..eg BILLING (I think this is good because I already work on them (X.500, X.400, X.700, TMN and IN, etc) ).... Thought for the Day... "If the brain was that simple we could understand it we would be so simple we could'nt" Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 26 21:28:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00836; Mon, 26 Sep 94 21:28:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00830; Mon, 26 Sep 94 21:28:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16929; Mon, 26 Sep 94 21:25:21 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AB26750; Mon, 26 Sep 94 21:25:00 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm035-21.dialip.mich.net [141.211.7.32]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id AAA18943 for ; Tue, 27 Sep 1994 00:24:58 -0400 Date: Tue, 27 Sep 94 03:57:59 GMT From: "William Allen Simpson" Message-Id: <3255.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) next hop resolution Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Dave Bridgham > The prefix is _entirely_ topological, and all topology _is_ encoded > in the prefix. > > The first part of your statement is clearly true but the second is > severely limiting. The prefix only holds the routing heirarchy. The > total topology will be much more complex even though the routing > system can only see it as a simple heirarchy as seen in the prefix. > Yes, I agree. > If you want this to change, then please re-open that on > big-internet, not here. > > No, those of us who wanted a flexible enough architecture to allow > non-heirarchical routing lost big time. No need to do that again. > Not _HERE_! But if we can show that many or all of the Chairs of the IPng effort now think that wasting all those silly-16 bits with heirarchy information is a bad idea, we could probably make a good case that the IPng recommendation is flawed, and go back to 8 byte EIDs (or Identifying-Addresses, as SIPP called them). Just pointing to the appropriate list for the discussion. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 00:39:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00882; Tue, 27 Sep 94 00:39:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00876; Tue, 27 Sep 94 00:39:07 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22440; Tue, 27 Sep 94 00:35:48 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA12152; Tue, 27 Sep 94 00:35:27 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm002-24.dialip.mich.net [35.1.48.105]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id DAA02148 for ; Tue, 27 Sep 1994 03:35:24 -0400 Date: Tue, 27 Sep 94 04:21:08 GMT From: "William Allen Simpson" Message-Id: <3257.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: Mobility Support in IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Andrew Myles > G'day Bill, > > We meet again. :) > Just what we need, another verbose Aussie.... > > The IPv6 Mobility has been done for well over a year. Yes, we took a > > look at what was needed to support mobility, and it is already embedded > > in IPv6 Neighbor Discovery. > > I am very surprised to hear you say that IPv6 mobility is complete as > my evaluation of IPv6, as currently documented, is that it is deficient > in a number of areas concerning mobility. A number of these issues are > discussed in the Perkins, Johnson, Myles document. > Really? Well, I'll try to read it on the plane tomorrow. > > You should not be surprised, since many (not all) of the IPv6 features > > have been been ported back to IPv4. Extensions, Authentication, et alia. > > That is a rather unusual view of history. It sounds like you are claiming > to have designed IPv4 mobility all by yourself. :) > They certainly don't look like the formats I inherited from the previous editor, and look remarkably like the ones I designed in 1992-93 for SIP. Most of the mechanisms, too. But then, there is extra unneeded cruft asked for by all the myriad onlookers. We hope to avoid that kind of committee design here. "Build one to throw away." > It should also be noted that the current IPv4 mobility document (if it is > ever released - how many weeks late is it now?) uses a very poor model of > mobility. Months late. It was essentially finished in May. It does? That's a surprise to those of us who think that's all we need! > This was recognised in San Diego when it was decided that route > optimisation should become an extension to the basic document. It was? That's a surprise to those of us who thought we _removed_ "route optimization" from the base spec, into a separate experimental spec. You were supposed to PROVE the workability of the concept. I ain't seen no proof. In the meantime, IPv6 has built-in required authentication, and the remote redirect (which is required to be authenticated). No fancy distributed mobility foreign agent forwarding caches are needed in IPv6 to eliminate triangular routes. > Charlie, Dave and myself would like to contribute to that task. When you've finished your multiple interoperable implementations of IPv4 Mobility, I'm sure we'll be happy to add the lessons you learned to IPv6. First, demonstrate the code.... Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 01:46:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00971; Tue, 27 Sep 94 01:46:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00933; Tue, 27 Sep 94 01:44:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28409; Tue, 27 Sep 94 01:41:32 PDT Received: from avalon.mpce.mq.edu.au by Sun.COM (sun-barr.Sun.COM) id AA16144; Tue, 27 Sep 94 01:40:55 PDT Message-Id: <9409270840.AA16144@Sun.COM> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA12524; Tue, 27 Sep 94 18:23:44 est From: Andrew Myles Subject: Re: (IPng) Re: Mobility Support in IPv6 To: ipng@sunroof.Eng.Sun.COM Date: Tue, 27 Sep 94 18:23:42 EST Cc: mobile-ip@sunroof.Eng.Sun.COM In-Reply-To: <3257.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Sep 27, 94 4:21 am Mailer: Elm [revision: 64.9] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM G'day Bill, > Just what we need, another verbose Aussie.... Do you always have to be so rude. > > It sounds like you are claiming > > to have designed IPv4 mobility all by yourself. :) > > > They certainly don't look like the formats I inherited from the previous > editor, and look remarkably like the ones I designed in 1992-93 for SIP. > > Most of the mechanisms, too. But then, there is extra unneeded cruft > asked for by all the myriad onlookers. We hope to avoid that kind of > committee design here. This is one of the silliest claims I have seen for a long time. Almost everything pre-dates your invlovement although I have to admit that you did design the details of the packets. Wopee!!!! :) > > It should also be noted that the current IPv4 mobility document (if it is > > ever released - how many weeks late is it now?) uses a very poor model of > > mobility. > > It does? That's a surprise to those of us who think that's all we need! It is not a surprise to those of us for which it is inadequate. You might like to consider the requirements of others at some time. > In the meantime, IPv6 has built-in required authentication, and the > remote redirect (which is required to be authenticated). No fancy > distributed mobility foreign agent forwarding caches are needed in IPv6 > to eliminate triangular routes. You obviously have not read any of our work. Nothing fancy is required. Even less is required when you translate it to IPv6 which is generally a nicer environment. Maybe I have been reading the wrong IPv6 specs, because as far as I can tell it is somewhat crippled with reagard to mobility. Which documents would you recommend? > > Charlie, Dave and myself would like to contribute to that task. > > When you've finished your multiple interoperable implementations of IPv4 Actually, I already have that on a number of platforms. Do you? > Mobility, I'm sure we'll be happy to add the lessons you learned to IPv6. Thank you, god! :) Andrew -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: Electronics Dept., Macquarie University 2109, Sydney, Australia. Telephone : +61 2 8509071 (W), +61 2 8509128 (Fax), +61 2 8786060 (H). ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 01:57:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00999; Tue, 27 Sep 94 01:57:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00993; Tue, 27 Sep 94 01:57:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29052; Tue, 27 Sep 94 01:54:31 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA17055; Tue, 27 Sep 94 01:54:09 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA13330; Tue, 27 Sep 1994 09:56:29 +0100 Message-Id: <199409270856.AA13330@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Joachim Martillo' message of "Mon, 26 Sep 1994 06:09:25 -0400." <9409261009.AA23950@pluto.dss.com> Date: Tue, 27 Sep 1994 09:56:27 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joachim, The problem with fragmentation/reassembly is not fragmentation, which can indeed be done relatively quickly, but reassembly. The problem with reasssembly have been exposed in a number of research papers, but can be resumed by the simple argument that "the unit of transmission should be the same as the unit of control". The classical failure mode of reassembly is that all but one fragments make it to the destination. In that case, the missing fragment is waited for the "time to live" of the packet (e.g. 2 minutes), freezing memory buffers during that interval. It is not very hard to observe repeated failures of that kind, and to have all the buffer pool filled with partially reassembled packets. One will then have to drop partially reconstructed packets, etc. This failure mode disappears entirely if one resorts to TCP level fragmentation, which is thus encouraged. When we reach the point where every TCP does "MTU discovery" and sets the DF bit, fragmentation stops being used as a regular feature. The "fast path" selection kicks in: if it is not used in the majority of packets, it is removed from the routers' "fast paths", which becomes a further reason not to use it. One step further, and you just remove it from the spec, as in IPv6. This is not to say that we should not investigate hop-by-hop reassembly procedures for use on some networks where the MTU is "way to low". AAL-5 is one such procedure; the X.25 "packet sequence" mechanism is another; we will perhaps have to use something like that for radio links. In each case, however, we have to well understand the implications of using a transmission unit different from the control unit; see Romanow's and Floyd's paper in the last SIGCOMM for an example of what you can expect... Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 02:15:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01026; Tue, 27 Sep 94 02:15:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01011; Tue, 27 Sep 94 02:15:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29938; Tue, 27 Sep 94 02:12:13 PDT Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA18393; Tue, 27 Sep 94 02:11:51 PDT Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id FAA13002 for ipng@sunroof.Eng.Sun.COM; Tue, 27 Sep 1994 05:11:51 -0400 Date: Tue, 27 Sep 1994 05:11:51 -0400 From: Vadim Antonov Message-Id: <199409270911.FAA13002@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From: Christian Huitema >When we reach the point where >every TCP does "MTU discovery" and sets the DF bit, fragmentation stops >being used as a regular feature. The world is not only TCP... In fact, _the_ badwidth hog of the near future will be video and it definitely won't run on top of TCP. I wouldn't bet on fragmentation going away any time soon (providing nice variety of MTUs on FDDI, Ethernet and HSSI, not to mention hidden treasures of dial-up and ISDN). Regards, --vadim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 02:27:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01059; Tue, 27 Sep 94 02:27:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01053; Tue, 27 Sep 94 02:27:46 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00397; Tue, 27 Sep 94 02:24:27 PDT Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA19416; Tue, 27 Sep 94 02:24:04 PDT Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 27 Sep 1994 10:23:52 +0100 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Tue, 27 Sep 94 05:11:51 EDT." <199409270911.FAA13002@titan.sprintlink.net> Date: Tue, 27 Sep 94 10:23:42 +0100 Message-Id: <795.780657822@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>When we reach the point where >>every TCP does "MTU discovery" and sets the DF bit, fragmentation stops >>being used as a regular feature. >The world is not only TCP... >In fact, _the_ badwidth hog of the near future will be video and >it definitely won't run on top of TCP. >I wouldn't bet on fragmentation going away any time soon (providing >nice variety of MTUs on FDDI, Ethernet and HSSI, not to mention >hidden treasures of dial-up and ISDN). vadim well, we run video on RTP on UDP. we use an MTU that so far needs no fragmentation anywhere - apropos nothing at all, but it also has to be said that the idea of multicast fragmentation discovery is a nono, since icmp's in response to outbound multicast packets are verboten for lots of good implosive reasons... jon ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 04:34:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01173; Tue, 27 Sep 94 04:34:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01167; Tue, 27 Sep 94 04:34:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03662; Tue, 27 Sep 94 04:31:05 PDT Received: from atlas.xylogics.com by Sun.COM (sun-barr.Sun.COM) id AA00108; Tue, 27 Sep 94 04:30:39 PDT Received: from vulcan.xylogics.com by atlas.xylogics.com with SMTP id AA08751 (5.65c/UK-2.1-940401); Tue, 27 Sep 1994 07:34:46 -0400 Received: from localhost by vulcan.xylogics.com id AA09392 (4.1/UK-2.1-940201); Tue, 27 Sep 94 07:34:44 EDT Message-Id: <9392.9409271134@vulcan.xylogics.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) DAMAGED THINKING In-Reply-To: Your message of "27 Sep 1994 10:47:23 +1100." <"940927 09:22:46"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> Date: Tue, 27 Sep 1994 07:34:43 -0400 From: James Carlson Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au > Date: 27 Sep 94 10:47:23 +1100 > To: ipng@sunroof.eng.sun.com, > /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au > Subject: (IPng) DAMAGED THINKING > > gday, I thank John Carlson for his view that a mil of the earth can have 25m > addresses.. Such comments do indicate the level of understanding on this > issue.. If you're going to launch an ad-hominem attack rather than attempt to discuss ideas, you could at LEAST get my name right! It's James. Your original question, in all of its loopy glory was this: > PS why do people say that 16 bytes is enough to address the people on the > entire planet squillions of times over when addresses relate to location... > geography? And, for a silly question, devoid of any hint of anything other than address density, I feel perfectly justified in giving a silly answer. That's all it was; a silly answer. You're reading far too much into it. Everyone here knows that there are routing problems to be solved. Everyone here knows that mobility and security are non-trivial issues and might constrain the addressing, and may even lead to not-strictly-geographical addressing. And everyone here knows that there are many competing interests, not all of whom are so enamored of geographic addressing. > When I do talk about addresses and their administration, and their impact on > commercial boundaries, and their impact on routing protocols, and their > impact on mobility (and security) and their impact on network scale and the > networks overall management.. and quality of service .... It all goes quiet.. You weren't talking about that at all, but thanks for bringing it up. I agree that we've got problems there. This was obvious at the IETF! If you know how to do authentication correctly in this environment -- without precluding mobility -- please speak up. The proposal at the IETF was based on tunnelling to a "home" site with a number of cache sites and a cache-coherency protocol. I doubt that I'm alone in thinking that this is the best possible idea. Please tell us how you would solve this problem. > It is nice to now that 16 bytes can cover the planet.. but designing a 16 > byte protocol does NOT make a global, commercially acceptable network that > can be administered.. Said this already.. Said, but completely unproven. We already have a 4 byte global, commercially acceptable and administratable address space in place. We're building on that experience. We're willing to learn from mistakes, but simply making overly broad assertions isn't helping anyone. What would your ideal administration environment (given that we're stuck with the too-long 16 byte addresses) be? How would you take into consideration the conflicting goals of (1) reducing routing table sizes, (2) multiple service providers and (3) portable (non-provider-based) addressing? [... portion of crap response deleted ...] > I really thought we were over the crap responses... > And as the Internet gets commercial pressure applied to it it will need those > addressing and related issues (such as commercial administration) attended > to.. Oh Well! I'm so very sorry I bothered to post in the first place. Your offensively worded response rather forcefully reminds me that not everyone is interested in working together, despite any charter for this group. --- James Carlson Tel: +1 617 272 8140 Annex Software Support / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 05:10:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01230; Tue, 27 Sep 94 05:10:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01224; Tue, 27 Sep 94 05:09:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04451; Tue, 27 Sep 94 05:06:32 PDT Received: from carmen.logica.co.uk by Sun.COM (sun-barr.Sun.COM) id AA02133; Tue, 27 Sep 94 05:06:00 PDT Received: from smtpmail.logica.com (mssmtp.logica.com) by carmen.logica.co.uk (4.1/SMI-4.1) id AA00157; Tue, 27 Sep 94 13:06:41 BST Received: by smtpmail.logica.com with Microsoft Mail id <2E881924@smtpmail.logica.com>; Tue, 27 Sep 94 13:07:48 bst From: Fieldhouse Dirk To: 'IPng mailing list' Subject: FW: (IPng) Re NSAP MAPs Date: Tue, 27 Sep 94 12:55:00 bst Message-Id: <2E881924@smtpmail.logica.com> Encoding: 43 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Apparently this response got lost last week. > >Jack, > >Should this ie, the proposed NSAP-address-extension option as suggested by several contributors >> be in an End-to-End option or a Hop-by- > >Hop? i.e. where is it looked at. It would seem to me > >that it would be looked at by the destination node and > >is not needed by the routers along the way. > > >Scott > > > You could well be right, what does everybody else > think? > > Jack This surely depends on what the address extension is used for. In other words, whether it is going to be used by routers to deliver packets (oops, almost said NPDUs) to hosts. If there are IPng end systems that have NSAP addresses, then the option needs to be a hop-by-hop option. If the extension is only used to tunnel NSAP addresses through IPng (ie, there will always be an IPng-CLNP gateway between any IPng router and the destination NSAP-addressed host), the option should be an end-to-end one. I originally had the only second case in mind, but on reflection, why not the first? But to route on NSAP addresses for delivery to a host would require an enhanced IPng router. Have I got this right? Dirk Fieldhouse Logica UK Ltd fieldhouse@lgwct.logica.com 68 Newman St c=gb;a=tmailuk;p=logica; London W1A 4SE ou1=lgwct;s=fieldhouse UK +44 (171) 637 9111 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 05:25:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01242; Tue, 27 Sep 94 05:25:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01236; Tue, 27 Sep 94 05:25:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04922; Tue, 27 Sep 94 05:22:06 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA03182; Tue, 27 Sep 94 05:21:41 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA14172; Tue, 27 Sep 1994 13:23:57 +0100 Message-Id: <199409271223.AA14172@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: FW: (IPng) Re NSAP MAPs In-Reply-To: Dirk Fieldhouse's message of "Tue, 27 Sep 1994 12:55:00 -0000." <2E881924@smtpmail.logica.com> Date: Tue, 27 Sep 1994 13:23:56 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >If the extension is only used to tunnel NSAP addresses through IPng (ie, >there will always be an IPng-CLNP gateway between any IPng router and the >destination NSAP-addressed host), the option should be an end-to-end one. > >I originally had the only second case in mind, but on reflection, why not >the first? But to route on NSAP addresses for delivery to a host would >require an enhanced IPng router. If this is what you have in mind, did you compare the use of end to end option with sheer encapsulation of a CLNP datagrams? It seems that you are buying the problems of translation while only getting a limited advantage, i.e. a slightly reduced overhead. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 05:36:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01254; Tue, 27 Sep 94 05:36:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01248; Tue, 27 Sep 94 05:36:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05171; Tue, 27 Sep 94 05:33:30 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA04069; Tue, 27 Sep 94 05:32:35 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27687; Tue, 27 Sep 1994 21:49:34 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) next hop resolution In-Reply-To: Your message of "Mon, 26 Sep 1994 15:48:29 GMT." <3250.bill.simpson@um.cc.umich.edu> Date: Tue, 27 Sep 1994 21:48:23 +1000 Message-Id: <6901.780666503@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 26 Sep 94 15:48:29 GMT From: "William Allen Simpson" Message-ID: <3250.bill.simpson@um.cc.umich.edu> If a host has two interfaces, and all routers say "I have the same match to the world", then by definition, they are equally as good for reaching the destination. Preferences are to break the tie. Bill, this is only true from a very limited perspective. From the router's point of view, this may very well be correct. >From the hosts' its simply not so. Consider a simple example (which is actually a nearly minimal example of a slightly more complex topology which is exactly how my local net is set up) ... Imagine a router with an outgoing interface to the world (all no local traffic is going to go that way), and two local ethernets. Then place two multi homed hosts, each connected to the both of the ethernets. I hate ascii diagrams in mail, as I read mail using a non constant width font, and they all look like gibberish, but for those who like pictures, this is it ... A --------+------------+-------------| __|__ __|__ |------| |_H1_| |_H2_| | Rtr |------- world | | |------| B --------+------------+-------------| Using your scheme, I see no way at all that all traffic going externally will not travel from both hosts to the world over one of the two ethernets. That's not what I want - if for no other reason than to spread the load over the two nets (for this purpose you can imagine no other hosts on the two ethernets if you want, with the idea being that each host will have one dedicated net, and another interface for backup use in case the first net dies). There's no way the router can say anything in any kind of multicast or broadcast message that will result in this behaviour, as the result depends on the host, not the router. If hosts are truly dumb, which in general is the design I prefer, then I see no way out of this. The only solution I see at the minute is for multi-homed hosts not to be truly dumb, which in reflection is what most sites probably want anyway. "Not to be truly dumb" in this translates into "be a router" - that is, most sites with multi homed hosts either actually use them as routers, or at least want them to be able to serve in that role should real routers be down. To act as a backup router means running the routing protocols all the time. With that info, the hosts can learn that the route to the world is equal out each interface, then use local interface knowledge - either administrator preference, or knowledge that one interface has better performance than the other, to choose between equal interfaces. "Be a router" does not mean "actively route packets". The effect will be that host vendors are going to have to ship routing protocol code on systems that can conceivably be routers, which means just about everything of workstation status or above, even many X terminals - but probably doesn't include light bulbs, toasters, or snmp capable power baords, and all the future internet devices of that kind. That's OK, everyone ships at least routed now - one freely available implementation is all that's really required. Once one admits that multi-homed hosts really need to at least be able to act as routers, since many users want that in any case, whether we like it or not, then almost all the arguments against making other hosts be dumb go away. I really want to be able to make very simple hosts - that means routers have to have the necessary support. Dumb routers simply won't work - even in IPv4 where hosts in general are supposed to be fairly smart, no-one makes dumb routers, because everyone wants their routers to be able to do almost everything. Most hosts have only one interface, those don't need to run the routing protocols, and in fact shouldn't. The code should check for that and simply no-op itself if its not required. kre ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 05:56:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01270; Tue, 27 Sep 94 05:56:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01262; Tue, 27 Sep 94 05:56:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05723; Tue, 27 Sep 94 05:53:04 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA05855; Tue, 27 Sep 94 05:52:42 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA05726; Tue, 27 Sep 1994 13:52:40 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA00391; Tue, 27 Sep 1994 13:52:38 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409271252.AA00391@dxcoms.cern.ch> Subject: Re: FW: (IPng) Re NSAP MAPs To: ipng@sunroof.Eng.Sun.COM Date: Tue, 27 Sep 1994 13:52:37 +0100 (MET) In-Reply-To: <2E881924@smtpmail.logica.com> from "Fieldhouse Dirk" at Sep 27, 94 12:55:00 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1596 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dirk, > If there are IPng end systems that have NSAP addresses, then the option > needs to be a hop-by-hop option. > > If the extension is only used to tunnel NSAP addresses through IPng (ie, > there will always be an IPng-CLNP gateway between any IPng router and the > destination NSAP-addressed host), the option should be an end-to-end one. > > I originally had the only second case in mind, but on reflection, why not > the first? But to route on NSAP addresses for delivery to a host would > require an enhanced IPng router. > I believe that your logic is correct. If we consider the form of the proposal where the IPv6 address is the NSAP without the ID and Selector fields, and the full NSAP is carried as an option, then the only boxes that require to look at the option are the last one or two routers on the path (the ones handling the area containing the host, in US-GOSIP terminology). It would be a violation of the definition of end-to-end options, but it seems perfectly algorithmic to specify that the full NSAP is carried in an end-to-end option, but is examined by these routers. However, yes, all this means that IPv6 routers have to route on NSAP address formats. This must be true in general, for any usage of NSAP addresses except tunnels. The question of principle is whether we want to make this an (elective) standard mechanism or not. The reason to do so is to allow people to keep their NSAP allocation schemes. Does this justify the added complexity? Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 06:01:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01283; Tue, 27 Sep 94 06:01:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01277; Tue, 27 Sep 94 06:01:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05868; Tue, 27 Sep 94 05:58:05 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA06382; Tue, 27 Sep 94 05:57:43 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA06719; Tue, 27 Sep 1994 13:57:40 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA00485; Tue, 27 Sep 1994 13:57:38 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409271257.AA00485@dxcoms.cern.ch> Subject: Re: FW: (IPng) Re NSAP MAPs To: ipng@sunroof.Eng.Sun.COM Date: Tue, 27 Sep 1994 13:57:38 +0100 (MET) In-Reply-To: <199409271223.AA14172@mitsou.inria.fr> from "Christian Huitema" at Sep 27, 94 01:23:56 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1163 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian, It seems to me that if the goal is tunnels, then NextHeader = CLNP is a necessary and sufficient definition of the format. Brian >--------- Text sent by Christian Huitema follows: > > > >If the extension is only used to tunnel NSAP addresses through IPng (ie, > >there will always be an IPng-CLNP gateway between any IPng router and the > >destination NSAP-addressed host), the option should be an end-to-end one. > > > >I originally had the only second case in mind, but on reflection, why not > >the first? But to route on NSAP addresses for delivery to a host would > >require an enhanced IPng router. > > If this is what you have in mind, did you compare the use of end to end > option with sheer encapsulation of a CLNP datagrams? It seems that you are > buying the problems of translation while only getting a limited > advantage, i.e. a slightly reduced overhead. > > Christian Huitema > ------------------------------------------------------------------------------ > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 07:01:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01360; Tue, 27 Sep 94 07:01:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01348; Tue, 27 Sep 94 07:00:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08007; Tue, 27 Sep 94 06:57:36 PDT Received: from ftp.com by Sun.COM (sun-barr.Sun.COM) id AA12631; Tue, 27 Sep 94 06:57:08 PDT Received: from ftp.com by ftp.com ; Tue, 27 Sep 1994 09:56:59 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 27 Sep 1994 09:56:59 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA26153; Tue, 27 Sep 94 09:53:55 EDT Date: Tue, 27 Sep 94 09:53:55 EDT Message-Id: <9409271353.AA26153@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery From: kasten@ftp.com (Frank Kastenholz) Content-Length: 896 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >>When we reach the point where > >>every TCP does "MTU discovery" and sets the DF bit, fragmentation stops > >>being used as a regular feature. > >In fact, _the_ badwidth hog of the near future will be video and > >it definitely won't run on top of TCP. > > well, we run video on RTP on UDP. we use an MTU that so far needs no > fragmentation anywhere - > > apropos nothing at all, but it also has to be said that the idea of > multicast fragmentation > discovery is a nono, since icmp's in response to outbound multicast > packets are verboten for lots of good implosive reasons... I'd also add that video-transmission, using UDP, is not guaranteed so the other effect of non-reassembled fragments (retransmitting data that successfully made it to the other end but couldn't be reassembled) won't happen when fragments don't get reassembled. -- Frank Kastenholz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 07:01:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01361; Tue, 27 Sep 94 07:01:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01354; Tue, 27 Sep 94 07:00:57 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08012; Tue, 27 Sep 94 06:57:39 PDT Received: from ftp.com by Sun.COM (sun-barr.Sun.COM) id AA12639; Tue, 27 Sep 94 06:57:12 PDT Received: from ftp.com by ftp.com ; Tue, 27 Sep 1994 09:57:11 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 27 Sep 1994 09:57:11 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA26156; Tue, 27 Sep 94 09:53:57 EDT Date: Tue, 27 Sep 94 09:53:57 EDT Message-Id: <9409271353.AA26156@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery From: kasten@ftp.com (Frank Kastenholz) Content-Length: 947 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Christian Huitema > > Joachim, > > The problem with fragmentation/reassembly is not fragmentation, which > can indeed be done relatively quickly, but reassembly. The problem with > reasssembly have been exposed in a number of research papers, but can be > resumed by the simple argument that "the unit of transmission should be > the same as the unit of control". The other effect is un-necessary consumption of network resources. If a TCP segment is composed of fragments 1, 2, 3, and 4 and fragment 4 doesn't make it then all four fragments would need to be retransmitted. Even though fragments 1, 2, and 3 got successfully to the destination, they will be sent again, consuming network bandwidth that really didn't have to be consumed... This can lead to congestion, which causes more fragments to be dropped which causes more tcp-retranmissions etc etc etc. -- Frank Kastenholz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 08:38:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01415; Tue, 27 Sep 94 08:38:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01409; Tue, 27 Sep 94 08:38:26 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14134; Tue, 27 Sep 94 08:35:08 PDT Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA29553; Tue, 27 Sep 94 08:34:46 PDT Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id LAA25652; Tue, 27 Sep 1994 11:34:45 -0400 Message-Id: <199409271534.LAA25652@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Mon, 26 Sep 1994 19:43:59 EDT." <199409262343.TAA10987@titan.sprintlink.net> From: Valdis.Kletnieks@vt.edu Date: Tue, 27 Sep 1994 11:34:45 +22306356 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Mon, 26 Sep 1994 19:43:59 EDT, you said: > >changes that are that rapid do NOT reflect long-standing data on packet > >system behavior. Well-behaved packet systems have long shown relatively > >stable routing. Packet systems which are not well-behaved will show lots > >of problems and are not the systems for us to optimize against. > > Internet is not a well-behaving system (and probably never will be). > Our boxes are getting about 50 routing updates a second. A prudent > engineering approach would be to design for the worst case. Umm.. Let's see.. 50 routing updates a second.. for some 19,000 (or whatever it is now) networks. Now, of course some of these updates reflect incidents of the "Everything upstream of NEARNet just fell off" variety, but in general we are *not* seeing major routing flaps *for individual connections*. It's still pretty safe to bet that if my last 5 packets took a particular path through the network, that the next 5 or 10 will go the same way. If we get into a scenario where individual connections are flapping badly, many things are going to break in subtle ways - for instance, Dave Mills and company are going to get to re-design the NTP specs.... Valdis Kletnieks Computer Systems Engineer Virginia Tech ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 11:04:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01581; Tue, 27 Sep 94 11:04:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01575; Tue, 27 Sep 94 11:04:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00633; Tue, 27 Sep 94 11:00:43 PDT Received: from epilogue.com (quern.epilogue.com) by Sun.COM (sun-barr.Sun.COM) id AA29483; Tue, 27 Sep 94 10:59:28 PDT From: Dave Bridgham To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) fragmentation and multicast Date: Tue, 27 Sep 94 13:57:51 -0400 Message-Id: <9409271357.aa11805@quern.epilogue.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Fragmentation with multicast is an interesting problem to contemplate. How about a fragmentation model where fragments, instead of being held in the network layer until reassembly is complete, are passed on to teh transport layer (and perhaps application) as soon as they arrive. Real-time, non-reliable applications can make use of what data does get through without worrying about retransmitting those fragments that get lost. Reliable transports can collect the fragments and selectively fill in the holes with retransmissions. This requires that some amount of the transport header be copied into each fragment. The network header could have a small field that tells network layer forwarders how many bytes of the payload to duplicate in each fragment. The API up from the network layer would have to include fragmentation information for the transport to know how to position data from fragments. The API down to the network layer needs to supply the information about how many bytes of the payload need to be duplicated upon fragmentation. TCP could be re-written to use this capability or it could use a micro-layer on top of the network layer which provided the reassembly model of IPv4. Dave Bridgham ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 11:21:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01601; Tue, 27 Sep 94 11:21:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01595; Tue, 27 Sep 94 11:21:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02163; Tue, 27 Sep 94 11:18:01 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA02437; Tue, 27 Sep 94 11:16:38 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA00591; Tue, 27 Sep 94 11:08:15 -0700 Received: by xirtlu.zk3.dec.com; id AA28065; Tue, 27 Sep 1994 14:08:12 -0400 Message-Id: <9409271808.AA28065@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Discovery (Clusters vs Prefixes) Date: Tue, 27 Sep 94 14:08:06 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi Bill, I have read your discovery-reqs, deploy-IPv6, discovery-processing, and discovery-icmp-formats. I am using them to design at this point in time exactly what this means to an IPv6 host code base. I want to give you some input based on that work thus far (which is just a beginning OK). In addition I have come to a complete stop regarding inter-related designs for autoconfiguration, mobility, and transition (for IPv6). Prefixes: This is unclear to me in the spec because of the recent discussions between you and Dave Katz, Yakov's discussion on Clusters, and the IPv6 base architecture spec. This needs to be resolved. Could you define in your mind the technical use of a Cluster Address for lets say a site like XYZ company? But so I do some of the work and not just poke you let me state how I read Clusters right now and how I see prefixes. The Cluster address is only used by the routing topology within a site to propogate packets out of an AS domain (or into). When the IPv6 address is used in this manner it is of no value to a host (end-system), unless that host is also a router (I agree with Kre's recent analysis of a multihome host most of the time is really a router, which is why we need routed or someithing in IPv6). But what is the differentiator in the IPv6 address which tells me this is a Cluster Address? Has this been defined, if so, I have missed it? The other question is should an AS domain have multiple Cluster addresses (especially a large one that is an international company)? Now more important to my host design. What in the IPv6 address in your discovery mechanism tells me the prefix of my "subnet". I agree with you per the Dave Katz discussion I don't want this prefix to span multiple wires. I thought we had agreed too that each wire has its own prefix within the address for the host. In other words I can know that a host is on the same wire via the address. Hence you see my confusion as the discovery specs speak off and on of Cluster and then Prefix address. I need some clarity. Preferences: I think this is very important and will be needed during transition from IPv4 to IPv6, to determine how I stage my transition on hosts as they are deployed as a user. I gave you input on this on the ngtrans list and I vision using preferences to help with router selection during transition to set the switches during various stages during transition. Path MTU: Do you need to provide MTU information in the discovery methods for the host from the router? And an ICMP message format? Do we need a separate Path MTU document. I think PMTU strategy in IPv6 is the right thing to do for the Internet of tomorrow. I am unclear how PMTU discovery will work with Multicast and trying to understand that now. Services: This is very important and forward thinking. It would be good if we selected a few codes for those services like DNS, DHCPng, BOOTPng, etc. I am sure based on the recent IPv6 mobile spec from Charle et al. that the optional service formats would be very useful. Inter-related Specs: I think the Discovery specifications being complete and consensus achieved on them before we can really put down in concrete autoconfiguration, autoregistration, transition, routing, and most likely mobile. The reason is that the discovery method is at the core of the IPv6 design process for a host because it communicates information about where "stuff" is on the local wire. During design I see a difference between the grand host view vs the grand router view in autoconfiguration. This needs to be resolved, I will have more input (to both autoconfig and discovery) once I am more clear on Cluster and Prefix addresses. It might be we need an addressing plan to complete that discussion too. I think a document on Cluster and Prefix addresses, and PATH MTU discovery needs to be developed or incorporated into the Discovery spec or further defined in the base architecture spec. I am willing to do some of this work (as I am working on it now) but my previous needs must be met first regarding clarity on the address nature in IPv6 for discovery. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 11:55:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01671; Tue, 27 Sep 94 11:55:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01665; Tue, 27 Sep 94 11:55:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06817; Tue, 27 Sep 94 11:52:25 PDT Received: from emory.mathcs.emory.edu by Sun.COM (sun-barr.Sun.COM) id AA09809; Tue, 27 Sep 94 11:52:01 PDT Received: by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.5) via UUCP id AA00469 ; Tue, 27 Sep 94 14:51:55 -0400 Received: by shlep.sware.com (5.65/2.0) from paradox.sware.com id AA06519; Tue, 27 Sep 94 14:50:24 -0400 Received: from (localhost) by paradox.sware.com with SMTP (5.59/ CMW+ v2.3-eef) id AA01541; Tue, 27 Sep 94 14:50:53 EDT Date: Tue, 27 Sep 94 14:50:53 EDT Message-Id: <9409271850.AA01541@paradox.sware.com> From: Ed Sale X-Mailer: InterMail/CMW [1.3.1] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) fragmentation and multicast In-Reply-To: Your message of Tue, 27 Sep 94 13:57:51 -0400. <9409271357.aa11805@quern.epilogue.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ipng@sunroof.Eng.Sun.COM writes: > Fragmentation with multicast is an interesting problem to contemplate. > How about a fragmentation model where fragments, instead of being held > in the network layer until reassembly is complete, are passed on to > teh transport layer (and perhaps application) as soon as they arrive. > > Real-time, non-reliable applications can make use of what data does > get through without worrying about retransmitting those fragments that > get lost. Reliable transports can collect the fragments and > selectively fill in the holes with retransmissions. > > This requires that some amount of the transport header be copied into > each fragment. The network header could have a small field that tells > network layer forwarders how many bytes of the payload to duplicate in > each fragment. > > The API up from the network layer would have to include fragmentation > information for the transport to know how to position data from > fragments. The API down to the network layer needs to supply > the information about how many bytes of the payload need to be > duplicated upon fragmentation. > > TCP could be re-written to use this capability or it could use a > micro-layer on top of the network layer which provided the reassembly > model of IPv4. One would also require a per-fragment checksum in the fragment header for reliable transports if data integrity were an issue. It sounds like you're getting around to putting a TCP header into each fragment, which is what was suggested in the first place -- let TCP fragment the data on a best-guess at network MTU. -- Ed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ed Sale SecureWare, Inc. email: sale@sware.com 2957 Clairmont Rd. #200 phone: (404) 315-6296 x124 Atlanta, GA 30329-1647 fax: (404) 315-0293 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 12:11:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01708; Tue, 27 Sep 94 12:11:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01372; Tue, 27 Sep 94 07:14:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08654; Tue, 27 Sep 94 07:11:06 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA14677; Tue, 27 Sep 94 07:10:28 PDT Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id <18771-0@relay1.pipex.net>; Tue, 27 Sep 1994 15:09:58 +0100 Received: by widow.spider.co.uk; Tue, 27 Sep 94 15:10:37 +0100 From: Gerry Meyer Date: Tue, 27 Sep 94 15:07:17 +0100 Message-Id: <16512.9409271407@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Tue, 27 Sep 94 15:07:17 +0100 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re NSAP MAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) wrote: >It seems to me that if the goal is tunnels, then NextHeader = CLNP >is a necessary and sufficient definition of the format. Ah. Its been a long time coming. I've never understood the reasons for attempting to get a quart into a pint pot. Doing it any other way cannot be consistent with [the number 1 goal (?) of] achieving efficient address aggregation. Gerry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 12:12:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01737; Tue, 27 Sep 94 12:12:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01398; Tue, 27 Sep 94 07:43:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10317; Tue, 27 Sep 94 07:39:42 PDT Received: from ftp.std.com by Sun.COM (sun-barr.Sun.COM) id AA19166; Tue, 27 Sep 94 07:39:17 PDT Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0) id KAA21363; Tue, 27 Sep 1994 10:39:02 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA16261; Tue, 27 Sep 1994 10:39:00 -0400 Message-Id: <199409271439.AA16261@world.std.com> To: ipng@sunroof.Eng.Sun.COM Cc: martillo@pluto.dss.com (Joachim Martillo), mario@pluto.dss.com (Mario Savvides) Subject: Re: (IPng) Discovery In-Reply-To: Your message of Mon, 26 Sep 1994 06:09:25 -0400. <9409261009.AA23950@pluto.dss.com> Date: Tue, 27 Sep 1994 10:38:59 -0400 From: Craig Partridge Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM But people who want to remove fragmentation must prove that the bad operational impact is due to fragmentation and reassembly rather than to bad implementations of fragmentation and reassembly. The mere fact that many software engineers are incompetent does not justify the removal of useful functionality. This was done nearly 8 years ago -- read "Fragmentation Considered Harmful" by Mogul and Kent in Proceedings of ACM SIGCOMM '87. Craig ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 12:37:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01768; Tue, 27 Sep 94 12:37:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01762; Tue, 27 Sep 94 12:37:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11592; Tue, 27 Sep 94 12:34:21 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA02817; Tue, 27 Sep 94 11:18:30 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA00851; Tue, 27 Sep 94 11:12:03 -0700 Received: by xirtlu.zk3.dec.com; id AA28376; Tue, 27 Sep 1994 14:12:01 -0400 Message-Id: <9409271812.AA28376@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 Mobile Date: Tue, 27 Sep 94 14:11:56 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Charlie..et al.. Just read your spec. It seems clear to me and some of the forward thinking things like billing and when to tunnel I need to give more thought. But for now some input I can give you is that I think the end-to-end option will work in your spec rather than a new optional extended header. I had to work a bit in the spec to figure out when the binding update let me avoid the home base and when only the home base had the binding update. But I parsed it out at the end of the day. Just as some input per readability. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 13:18:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01807; Tue, 27 Sep 94 13:18:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01801; Tue, 27 Sep 94 13:18:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AB16558; Tue, 27 Sep 94 13:14:44 PDT Received: from epilogue.com (quern.epilogue.com) by Sun.COM (sun-barr.Sun.COM) id AA28885; Tue, 27 Sep 94 13:14:14 PDT From: Dave Bridgham To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Ed Sale's message of Tue, 27 Sep 94 14:50:53 EDT <9409271850.AA01541@paradox.sware.com> Subject: (IPng) fragmentation and multicast Date: Tue, 27 Sep 94 16:13:30 -0400 Message-Id: <9409271613.aa12310@quern.epilogue.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Tue, 27 Sep 94 14:50:53 EDT From: Ed Sale One would also require a per-fragment checksum in the fragment header for reliable transports if data integrity were an issue. Didn't think of that one. That hurts. It sounds like you're getting around to putting a TCP header into each fragment, Yes, I'd include the TCP header in each fragment. But I was trying to be general about it so it would be useful for trasnports other than TCP. In fact, I thought of this while thinking about fragmenting multicast traffic which certainly isn't using TCP. which is what was suggested in the first place -- let TCP fragment the data on a best-guess at network MTU. The difference between what I proposed and letting "TCP fragment the data on a best-guess at network MTU" is this fragmentation still happens at the network layer and so can happen in the forwarders if the TCP, or other transport, guesses wrong. And it works for multicast where you don't want to be sending at an MTU which is the smallest of anywhere in the multicast tree. Dave Bridgham ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 14:37:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01841; Tue, 27 Sep 94 14:37:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01835; Tue, 27 Sep 94 14:37:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25950; Tue, 27 Sep 94 14:33:56 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA18472; Tue, 27 Sep 94 14:33:30 PDT Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA08507; Tue, 27 Sep 1994 17:33:26 -0400 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA10451; Tue, 27 Sep 1994 17:33:24 -0400 Received: by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA07433; Tue, 27 Sep 1994 17:10:05 -0400 Date: Tue, 27 Sep 1994 17:10:05 -0400 From: alex conta Message-Id: <9409272110.AA07433@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) next hop resolution - clarification Cc: conta@zk3.dec.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In a previous mail message, Bill Simpson mentioned: > > Alex cites his experience with DECnet ES-IS. There were problems > getting the redirect to work. Some of that may have had to do with >... This needs clarification, since it may be interpreted as the malfunction of a product; "there are NO KNOWN problems with the DECnet ES-IS implementations". In fact, there are DECnet customers that use its features to an extent that would like to see them implemented in IP. I would like to mention that Bill wanted to help - thanks Bill. For several days random problems plagued my mail - the mail server at my new location and the old server forwarding from my old location - which culminated with the need to resubscribe to the IPng list. As consequence, we spoke over the phone to confirm that my comments finally got to him, after several trials. In my comments I stressed a list of 'things' which in my and others opinion makes "hellos and redirects" LESS EFFICIENT than other media address resolution mechanisms. In summary, the list was: 1. "hellos" fill an address mapping cache with information about ALL hosts that participate. A router has to have ENOUGH MEMORY for an "all hosts cache", which in case of a large number of participants can be significntly larger, than an "active hosts cache". This means ADDITIONAL MEMORY. 2. searching in a cache which has a large population of entries is SLOWER than a cache that has only the entries that are relevant to the active communications - relative to the address mapping cache. 3. involving a router in media address resolution takes processing cycles away from other functions that the router perfoms, creating an ADIITIONAL and AVOIDABLE LOAD 4. involving a router in media address resolution takes packet receiving and forwarding cycles that the router could use for its main function, creating an ADDITIONAL and AVOIDABLE LOAD 5. using redirects for media address resolution, implies ADDITIONAL PACKETS on the wire. 6. using one system - a router - for media address resolution is LESS RELIABLE than allowing hosts to do their own address resolution - one point of failure, with (fatal) implication on all hosts. Bill wanted to get the main idea out to the list quickly, and because my mail server was flaky, he wrote and sent out a message, that contained a misquotation, which I didn't have a chance to review and filter. At any rate, in my conversation with Bill, I assured him that feedback from collegues with extended working experience with ES-IS will help us improve the IPv6 discovery mechanisms. In line with that, I should mention that one of my collegues, Mike Shand, described a case, in which 'hellos' are efficient - spare router taking over a crashed router, with all information already cached. It is true that the same effect could be achieved with a different mechanism, involving multicasting on reply. Back to hellos, an acceptable variant would be perhaps - someone if I rememeber correctly mentioned it on the mailing list, and Bill may have already picked it up - to have the "hello" timer set to infinity by default, but setable to a different value by the router, in case the router wants to hear host information periodically. Thanks, Alex ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 16:11:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01929; Tue, 27 Sep 94 16:11:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01821; Tue, 27 Sep 94 14:07:29 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23290; Tue, 27 Sep 94 14:04:10 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA10665; Tue, 27 Sep 94 14:03:34 PDT Received: by rodan.UU.NET id QQxjfg10895; Tue, 27 Sep 1994 17:03:24 -0400 Message-Id: To: ipng@sunroof.Eng.Sun.COM From: "Louis A. Mamakos" Subject: Re: (IPng) fragmentation and multicast In-Reply-To: Your message of "Tue, 27 Sep 1994 16:13:30 EDT." <9409271613.aa12310@quern.epilogue.com> Date: Tue, 27 Sep 1994 17:03:24 -0400 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > It sounds like you're getting around to putting a TCP header into > each fragment, > > Yes, I'd include the TCP header in each fragment. But I was trying to > be general about it so it would be useful for trasnports other than > TCP. In fact, I thought of this while thinking about fragmenting > multicast traffic which certainly isn't using TCP. Bogon alert! The TCP checksum is a transport protocol issue, and protects data end-to-end. I really don't like the idea of routers mucking about with MY end-to-end data integrity assurance. This is the reason why Van Jacobson's TCP header compression algorithm doesn't just "reconstruct" the TCP checksum at the other end of the link. Louis A. Mamakos louie@alter.net Backbone Architecture & Engineering Guy uunet!louie AlterNet / UUNET Technologies, Inc. 3110 Fairview Park Drive., Suite 570 Voice: +1 703 204 8023 Falls Church, Va 22042 Fax: +1 703 204 8001 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 16:21:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02005; Tue, 27 Sep 94 16:21:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01999; Tue, 27 Sep 94 16:21:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07546; Tue, 27 Sep 94 16:17:45 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA09360; Tue, 27 Sep 94 16:17:20 PDT To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) Discovery Date: Wed, 28 Sep 94 0:14:57 GMT From: Ran Atkinson Message-Id: <9409280014.aa01001@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Let me try to refocus a bit in this note and see if there aren't some areas that are less controversial... 1) I would like to eliminate ARP, Reverse ARP, and Proxy ARP for IPv6. ARP relies on link-layer broadcast (not good), is currently insecure (bad), and is hard to secure (not good). By contrast an approach using ICMP messages to a well known multicast address (with clear IP mcast to link mcast address mapping) eliminates the first and third problems. Also, the IPv6 Auth Header can be used to add security (assuming key mgmt, which seems to be progressing nicely by the way for example in the Eastlake/Kaufman proposal to move host keys into the DNS). 2) I would like to have much improved service/server discovery capabilities. It would be nice if my host could sent out an ICMP Print Server solicit (or the moral equivalent) to the intra-link all-nodes multicast address and get back information on remote printers that I can access. Ditto for DNS service, POP3/IMAP service, etc. This mechanism should not depend on a router being on the local subnet in order that the mechanism will work in the "Dentist's Office without external connectivity" scenario. I'd like to be able to avoid use of a fixed server for this information to avoid critical failure points. What do folks think about these two goals for Discovery ?? Ran, atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 16:37:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02101; Tue, 27 Sep 94 16:37:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02095; Tue, 27 Sep 94 16:37:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09015; Tue, 27 Sep 94 16:33:57 PDT Received: from avalon.mpce.mq.edu.au by Sun.COM (sun-barr.Sun.COM) id AA12051; Tue, 27 Sep 94 16:33:26 PDT Message-Id: <9409272333.AA12051@Sun.COM> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA12883; Wed, 28 Sep 94 09:33:22 est From: Andrew Myles Subject: Re: (IPng) IPv6 Mobile To: ipng@sunroof.Eng.Sun.COM Date: Wed, 28 Sep 94 9:33:21 EST In-Reply-To: <9409271812.AA28376@xirtlu.zk3.dec.com>; from "bound@zk3.dec.com" at Sep 27, 94 2:11 pm Mailer: Elm [revision: 64.9] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM G'day Jim, > Just read your spec. It seems clear to me and some of the forward > thinking things like billing and when to tunnel I need to give more > thought. Thank you for taking the trouble to consider our efforts. I encourage others to do the same. Charlie, Dave and I have significant implementation experience of Mobility that we would like to feed into the IPv6 process. > But for now some input I can give you is that I think the end-to-end > option will work in your spec rather than a new optional extended header. This is a particular area where we have been looking for comments from others. There seems to be a range of opinions here. > Just as some input per readability. We will definitely work on the readability. Thanks again, Andrew -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: Electronics Dept., Macquarie University 2109, Sydney, Australia. Telephone : +61 2 8509071 (W), +61 2 8509128 (Fax), +61 2 8786060 (H). ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 20:16:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02225; Tue, 27 Sep 94 20:16:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02219; Tue, 27 Sep 94 20:15:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22412; Tue, 27 Sep 94 20:12:28 PDT Received: from scratchy (scratchy.inner.net) by Sun.COM (sun-barr.Sun.COM) id AA09646; Tue, 27 Sep 94 20:12:05 PDT Received: from itchy by scratchy with smtp (Smail3.1.28.1 #6) id m0qplK3-000017C; Tue, 27 Sep 94 22:48 Received: from itchy.inner.net by itchy with smtp (Smail3.1.28.1 #2) id m0qplmB-000FRaC; Tue, 27 Sep 94 23:17 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Wed, 28 Sep 1994 00:14:57 GMT." <9409280014.aa01001@sundance.itd.nrl.navy.mil> Date: Tue, 27 Sep 1994 19:17:33 -0400 From: Craig Metz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In message <9409280014.aa01001@sundance.itd.nrl.navy.mil>, you write: >2) I would like to have much improved service/server discovery capabilities. > It would be nice if my host could sent out an ICMP Print Server solicit > (or the moral equivalent) to the intra-link all-nodes multicast address > and get back information on remote printers that I can access. Ditto > for DNS service, POP3/IMAP service, etc. This mechanism should not > depend on a router being on the local subnet in order that the mechanism > will work in the "Dentist's Office without external connectivity" > scenario. I'd like to be able to avoid use of a fixed server for this > information to avoid critical failure points. If I am not mistaken, Paul Vixie and the DNS WG are working on a generic look-up-a-server record for DNS. It would seem to me that DNS would be a more appropriate place to do this than ICMP. The only place where ICMP multicast would then be necessary is to find the DNS server itself. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 27 20:59:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02246; Tue, 27 Sep 94 20:59:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02240; Tue, 27 Sep 94 20:59:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23848; Tue, 27 Sep 94 20:55:58 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA13257; Tue, 27 Sep 94 20:55:35 PDT Received: by rodan.UU.NET id QQxjgh04153; Tue, 27 Sep 1994 23:55:34 -0400 Date: Tue, 27 Sep 1994 23:55:34 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) eliminating ARP..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM careful going here, folks..... one of the things which has made IP successful is that it is a VIRTUAL network layered atop physical links of almost every possible construction. And given that it is a virtual network with virtual addresses (IP4 addresses), there must be some way to resolve a virtual address to a physical address (or MAC address if you choose). There are two fundamental ways to do that - easy way and hard way. In cases where the MAC address fit within an IP4 "local portion", the simple solution was "easy way" using Direct Mapping. In cases where the mapping won't fit, then we must resort to the hard way - ie, dynamic address translation using a distributed associative lookup - aka ARP. the fact that ARP and ARP-like things have appeared so widely in the IP4 world should tell you something very significant is going on here. If we remove ARP, then we remove one level of indirection between the IP* addresses and the physical addresses. More than a few times I have wished for such an indirection doing other things, and I think that removing it now is a very, very tricky decision. yes there are problems, but boy, are there some advantages. I'm not arguing the decision cannot go either way, but that this is NOT a simple decision. =Mike O'Dell "Give me a pointer to stand on and I'll GC the Earth..." ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 00:35:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02300; Wed, 28 Sep 94 00:35:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02294; Wed, 28 Sep 94 00:35:12 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01321; Wed, 28 Sep 94 00:31:53 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA29469; Wed, 28 Sep 94 00:31:29 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA01468; Wed, 28 Sep 1994 08:31:28 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA23615; Wed, 28 Sep 1994 08:31:25 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409280731.AA23615@dxcoms.cern.ch> Subject: Re: (IPng) Re NSAP MAPs To: ipng@sunroof.Eng.Sun.COM Date: Wed, 28 Sep 1994 08:31:25 +0100 (MET) In-Reply-To: <16512.9409271407@orbweb.spider.co.uk> from "Gerry Meyer" at Sep 27, 94 03:07:17 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 874 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Gerry, it says "IF the goal is tunnels". This is not the only possible goal - we don't have consensus on the goals yet. Brian >--------- Text sent by Gerry Meyer follows: > > > brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) wrote: > > >It seems to me that if the goal is tunnels, then NextHeader = CLNP > >is a necessary and sufficient definition of the format. > > Ah. Its been a long time coming. I've never understood the reasons > for attempting to get a quart into a pint pot. > > Doing it any other way cannot be consistent with [the number 1 goal (?) of] > achieving efficient address aggregation. > > Gerry > ------------------------------------------------------------------------------ > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 02:08:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02420; Wed, 28 Sep 94 02:08:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02414; Wed, 28 Sep 94 02:08:26 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07952; Wed, 28 Sep 94 02:05:06 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA06653; Wed, 28 Sep 94 02:04:43 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA18495; Wed, 28 Sep 1994 10:06:59 +0100 Message-Id: <199409280906.AA18495@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) fragmentation and multicast In-Reply-To: Your message of "Tue, 27 Sep 1994 16:13:30 -0400." <9409271613.aa12310@quern.epilogue.com> Date: Wed, 28 Sep 1994 10:06:56 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dave, The "multicast" case has a very simple mathematical analysis. Suppose that you know the distribution of MTUs over the Internet links, and can express it as a function: p(x) = probability that MTU be larger than x. If you take N links at random, then the probability that the MTU of the most constraint link be larger than x is: P(N,x) = p(x)**N If N grows large, P(N,x) tends towards a step function. If there is a "minimal MTU", imposed by the protocol, then P(N,x) is 1 for all values lower than or equal to that minimum, tends quite rapidly towards 0 for all other values. You may quickly get to the point: there is no good reason to use anything but that minimal value when you are multicasting to a large group. As for "real-time, non-reliable applications", they certainly would not deal easily with receiving random fragments. Look at vat, nv, ivs and their bethren. They all need to insert control information in each packet, if only to properly compute the play-out point; they are certainly not sending a "continuous signal" that could be chopped at will into little pieces.. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 02:20:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02432; Wed, 28 Sep 94 02:20:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02426; Wed, 28 Sep 94 02:20:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08412; Wed, 28 Sep 94 02:17:29 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA07560; Wed, 28 Sep 94 02:16:54 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 28 Sep 94 18:09:13 +0900 From: Masataka Ohta Message-Id: <9409280909.AA14092@necom830.cc.titech.ac.jp> Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Wed, 28 Sep 94 18:09:11 JST In-Reply-To: <9409280014.aa01001@sundance.itd.nrl.navy.mil>; from "Ran Atkinson" at Sep 28, 94 12:14 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Let me try to refocus a bit in this note and see if there aren't > some areas that are less controversial... > > 1) I would like to eliminate ARP, Reverse ARP, and Proxy ARP for IPv6. > ARP relies on link-layer broadcast (not good), is currently insecure (bad), > and is hard to secure (not good). Why do you think we need secure ARP, when security is provided at the network layer and above? The only possible reason, I think of, to have secure ARP is to protect the link from certain type of denial of service attacks. But anyone who can inject poisoned ARP to the link can perform a lot more straight- forward denial of service attack by generating a lot of packets to overload the link. > Also, the IPv6 Auth Header can be used to add security (assuming > key mgmt, which seems to be progressing nicely by the way for example > in the Eastlake/Kaufman proposal to move host keys into the DNS). You can't. You can't access DNS, unless you can resolve MAC addresses. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 02:33:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02447; Wed, 28 Sep 94 02:33:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02441; Wed, 28 Sep 94 02:33:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08773; Wed, 28 Sep 94 02:30:05 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA08284; Wed, 28 Sep 94 02:29:17 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 28 Sep 94 18:21:36 +0900 From: Masataka Ohta Message-Id: <9409280921.AA14141@necom830.cc.titech.ac.jp> Subject: Re: (IPng) fragmentation and multicast To: ipng@sunroof.Eng.Sun.COM Date: Wed, 28 Sep 94 18:21:34 JST In-Reply-To: <199409280906.AA18495@mitsou.inria.fr>; from "Christian Huitema" at Sep 28, 94 10:06 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > If N grows large, P(N,x) tends towards a step function. If there is a > "minimal MTU", imposed by the protocol, then P(N,x) is 1 for all > values lower than or equal to that minimum, tends quite rapidly towards 0 > for all other values. You may quickly get to the point: there is no good > reason to use anything but that minimal value when you are multicasting > to a large group. You have proved that the large scale multicast MTU for the current Internet is 8. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 03:09:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02460; Wed, 28 Sep 94 03:09:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02454; Wed, 28 Sep 94 03:09:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09936; Wed, 28 Sep 94 03:06:04 PDT Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA14203; Wed, 28 Sep 94 03:05:42 PDT Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 28 Sep 1994 11:05:34 +0100 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) fragmentation and multicast In-Reply-To: Your message of "Wed, 28 Sep 94 18:21:34 +0200." <9409280921.AA14141@necom830.cc.titech.ac.jp> Date: Wed, 28 Sep 94 11:05:28 +0100 Message-Id: <1639.780746728@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> If N grows large, P(N,x) tends towards a step function. If there is a >> "minimal MTU", imposed by the protocol, then P(N,x) is 1 for all >> values lower than or equal to that minimum, tends quite rapidly towards 0 >> for all other values. You may quickly get to the point: there is no good >> reason to use anything but that minimal value when you are multicasting >> to a large group. >You have proved that the large scale multicast MTU for the current >Internet is 8. Masataka ? its either 576, or in practice (including some really really stupid IP over x.25) 128 bytes for multicast audio, this is ok - for video, it'd be nice if everyone convereged on 1024, but we can live with 512... jon ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 03:48:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02479; Wed, 28 Sep 94 03:48:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02473; Wed, 28 Sep 94 03:48:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11091; Wed, 28 Sep 94 03:44:43 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA16741; Wed, 28 Sep 94 03:44:16 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 28 Sep 94 19:35:07 +0900 From: Masataka Ohta Message-Id: <9409281035.AA14474@necom830.cc.titech.ac.jp> Subject: Re: (IPng) fragmentation and multicast To: ipng@sunroof.Eng.Sun.COM Date: Wed, 28 Sep 94 19:35:06 JST In-Reply-To: <1639.780746728@cs.ucl.ac.uk>; from "Jon Crowcroft" at Sep 28, 94 11:05 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >> If N grows large, P(N,x) tends towards a step function. If there is a > >> "minimal MTU", imposed by the protocol, then P(N,x) is 1 for all > >> values lower than or equal to that minimum, tends quite rapidly towards 0 > >> for all other values. You may quickly get to the point: there is no good > >> reason to use anything but that minimal value when you are multicasting > >> to a large group. > > >You have proved that the large scale multicast MTU for the current > >Internet is 8. > > Masataka > > ? Oops, 68 including a header, not 8. > its either 576, That's minimal reassembly buffer size, not minimal MTU. > or in practice (including some really really stupid IP > over x.25) 128 bytes In practice, we can almost always use MTU of 1500 for large scale multicast. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 07:21:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02528; Wed, 28 Sep 94 07:21:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02522; Wed, 28 Sep 94 07:21:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19716; Wed, 28 Sep 94 07:18:16 PDT Received: from ftp.com by Sun.COM (sun-barr.Sun.COM) id AA05575; Wed, 28 Sep 94 07:17:55 PDT Received: from ftp.com by ftp.com ; Wed, 28 Sep 1994 10:17:49 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 28 Sep 1994 10:17:49 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA07882; Wed, 28 Sep 94 10:14:44 EDT Date: Wed, 28 Sep 94 10:14:44 EDT Message-Id: <9409281414.AA07882@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery From: kasten@ftp.com (Frank Kastenholz) Content-Length: 1069 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 1) I would like to eliminate ARP, Reverse ARP, and Proxy ARP for IPv6. > ARP relies on link-layer broadcast (not good), is currently insecure (bad), > and is hard to secure (not good). By contrast an approach using ICMP > messages to a well known multicast address (with clear IP mcast to > link mcast address mapping) eliminates the first and third problems. Are you suggesting that the 'query-response' model use by ARP be eliminated or are you keeping the model and just packaging the query and response in a different packet? > 2) I would like to have much improved service/server discovery capabilities. > It would be nice if my host could sent out an ICMP Print Server solicit... There is a Service (or resource?) Discovery Working Group that is developing (has developed) a protocol to do exactly this. It runs over UDP/IP. No doubt it will run over UDP/IP6. It would then have all the benefits of IP6 (eg security). Why re-invent the wheel? If there is a problem with their work I suggest you bring it up with them... -- Frank Kastenholz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 07:23:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02547; Wed, 28 Sep 94 07:23:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02535; Wed, 28 Sep 94 07:23:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19824; Wed, 28 Sep 94 07:20:07 PDT Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA05869; Wed, 28 Sep 94 07:19:45 PDT Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id HAA18803; Wed, 28 Sep 1994 07:19:41 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Sep 1994 07:19:45 -0700 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: (IPng) eliminating ARP..... Cc: ip-ng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 8:55 PM 9/27/94, Mike O'Dell wrote: >careful going here, folks..... strong concurrence with Mike. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 07:23:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02546; Wed, 28 Sep 94 07:23:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02534; Wed, 28 Sep 94 07:23:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19824; Wed, 28 Sep 94 07:20:07 PDT Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA05869; Wed, 28 Sep 94 07:19:45 PDT Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id HAA18803; Wed, 28 Sep 1994 07:19:41 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Sep 1994 07:19:45 -0700 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: (IPng) eliminating ARP..... Cc: ip-ng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 8:55 PM 9/27/94, Mike O'Dell wrote: >careful going here, folks..... strong concurrence with Mike. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 07:44:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02576; Wed, 28 Sep 94 07:44:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02570; Wed, 28 Sep 94 07:44:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21131; Wed, 28 Sep 94 07:40:42 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA08874; Wed, 28 Sep 94 07:40:20 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA28671; Wed, 28 Sep 94 07:35:17 -0700 Received: by xirtlu.zk3.dec.com; id AA06263; Wed, 28 Sep 1994 10:35:14 -0400 Message-Id: <9409281435.AA06263@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Wed, 28 Sep 94 00:14:57 GMT." <9409280014.aa01001@sundance.itd.nrl.navy.mil> Date: Wed, 28 Sep 94 10:35:07 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, >What do folks think about these two goals for Discovery ?? I think these two goals are good ones. For link layer multicast I hope you mean the security is "optional" though. The reason is that most Dentists offices don't need security with 4 PCs and a server for accounting or purchasing for their business. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 07:57:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02588; Wed, 28 Sep 94 07:57:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02582; Wed, 28 Sep 94 07:57:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21995; Wed, 28 Sep 94 07:53:44 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA10942; Wed, 28 Sep 94 07:53:22 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA29960; Wed, 28 Sep 94 07:48:41 -0700 Received: by xirtlu.zk3.dec.com; id AA06803; Wed, 28 Sep 1994 10:48:33 -0400 Message-Id: <9409281448.AA06803@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Mobile In-Reply-To: Your message of "Wed, 28 Sep 94 09:33:21 EST." <9409272333.AA12051@Sun.COM> Date: Wed, 28 Sep 94 10:48:27 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Andrew, > Thank you for taking the trouble to consider our efforts. I encourage >others to do the same. Charlie, Dave and I have significant implementation >experience of Mobility that we would like to feed into the IPv6 process. You said the magic word Andrew )---> "implementation experience". I would really find it helpful if you folks looked at discovery from the mobile perspective and told us if you think it will work. I have not had the time to even think about mobile for this type of advanced development on IPv6 yet. Clearly if we can provide more efficient and functional mobility, and better network performance with IPv6 then we have another "carrot" for the market and vendors to move to IPv6. Being an engineer as opposed to a scientist I am concerned why users will buy this work as it becomes a product so I apologize to the list for putting the word "market" in this note to Andrew. So don't beat me up. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 08:11:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02604; Wed, 28 Sep 94 08:11:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02598; Wed, 28 Sep 94 08:11:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23183; Wed, 28 Sep 94 08:08:12 PDT Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA13256; Wed, 28 Sep 94 08:07:41 PDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04914; 28 Sep 94 10:57 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-simpson-ipv6-discov-formats-00.txt Date: Wed, 28 Sep 94 10:56:56 -0400 Message-Id: <9409281057.aa04914@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Neighbor Discovery -- ICMP Message Formats Author(s) : W. Simpson Filename : draft-simpson-ipv6-discov-formats-00.txt Pages : 33 Date : 09/27/1994 This document specifies ICMP messages for the identification and location of adjacent IPv6 nodes. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-simpson-ipv6-discov-formats-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-simpson-ipv6-discov-formats-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940927105247.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-ipv6-discov-formats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-ipv6-discov-formats-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940927105247.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 09:20:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02677; Wed, 28 Sep 94 09:20:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02671; Wed, 28 Sep 94 09:19:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00964; Wed, 28 Sep 94 09:16:38 PDT Received: from epilogue.com (quern.epilogue.com) by Sun.COM (sun-barr.Sun.COM) id AA26277; Wed, 28 Sep 94 09:16:13 PDT From: Dave Bridgham To: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Louis A. Mamakos"'s message of Tue, 27 Sep 1994 17:03:24 -0400 Subject: (IPng) fragmentation and multicast Date: Wed, 28 Sep 94 12:15:59 -0400 Message-Id: <9409281216.aa18947@quern.epilogue.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: "Louis A. Mamakos" Date: Tue, 27 Sep 1994 17:03:24 -0400 Bogon alert! The TCP checksum is a transport protocol issue, and protects data end-to-end. I really don't like the idea of routers mucking about with MY end-to-end data integrity assurance. This is the reason why Van Jacobson's TCP header compression algorithm doesn't just "reconstruct" the TCP checksum at the other end of the link. Slow down. I never proposed allowing routers to modify TCP or any other transport level checksum or anything else. I'm not completely daft :-). I missed this point in my first thinking and so I think my fragmentation model is no better than IPv4 for TCP. Oh well. I think it still might have some merit if it's useful for multicast applications and isn't any worse for anything else, like TCP. Dave Bridgham ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 09:28:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02689; Wed, 28 Sep 94 09:28:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02683; Wed, 28 Sep 94 09:28:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02067; Wed, 28 Sep 94 09:24:55 PDT Received: from epilogue.com (quern.epilogue.com) by Sun.COM (sun-barr.Sun.COM) id AA28130; Wed, 28 Sep 94 09:24:29 PDT From: Dave Bridgham To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Christian Huitema's message of Wed, 28 Sep 1994 10:06:56 +0100 <199409280906.AA18495@mitsou.inria.fr> Subject: (IPng) fragmentation and multicast Date: Wed, 28 Sep 94 12:24:09 -0400 Message-Id: <9409281224.aa18964@quern.epilogue.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 28 Sep 1994 10:06:56 +0100 From: Christian Huitema If N grows large, P(N,x) tends towards a step function. If there is a "minimal MTU", imposed by the protocol, then P(N,x) is 1 for all values lower than or equal to that minimum, tends quite rapidly towards 0 for all other values. You may quickly get to the point: there is no good reason to use anything but that minimal value when you are multicasting to a large group. I think you only get to that point if you don't have fragmentation that can cope. Or are you arguing that you should use the tiny effective MTU even if the fragmentation can cope? That seems rather sad but maybe networks are migrating to larger MTUs fast enough that this will soon be moot. As for "real-time, non-reliable applications", they certainly would not deal easily with receiving random fragments. Look at vat, nv, ivs and their bethren. They all need to insert control information in each packet, if only to properly compute the play-out point; they are certainly not sending a "continuous signal" that could be chopped at will into little pieces.. That's why I said you had to copy some of the transport header into each fragment and pass up the fragmentation information to the transport layer when receiving packets. You'd design the real-time transport header to put the sequence number and multiplexing inforamtion near the front and that's what gets copied to each fragment. That sequence number plus the fragment offset ought to be sufficient to compute the play-point. Dave Bridgham ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 10:17:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02909; Wed, 28 Sep 94 10:17:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02903; Wed, 28 Sep 94 10:16:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08619; Wed, 28 Sep 94 10:13:32 PDT Received: from ceres.fokus.gmd.de by Sun.COM (sun-barr.Sun.COM) id AA09674; Wed, 28 Sep 94 10:12:51 PDT Message-Id: <9409281712.AA09674@Sun.COM> Received: from fokus.gmd.de by ceres.fokus.gmd.de id <17504-0@ceres.fokus.gmd.de>; Wed, 28 Sep 1994 18:14:49 +0100 Subject: Re: (IPng) fragmentation and multicast To: ipng@sunroof.Eng.Sun.COM Date: Wed, 28 Sep 1994 18:14:49 +0100 From: Henning Schulzrinne Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > As for "real-time, non-reliable applications", they certainly would > not deal easily with receiving random fragments. Look at vat, nv, > ivs and their bethren. They all need to insert control information > in each packet, if only to properly compute the play-out point; > they are certainly not sending a "continuous signal" that could be > chopped at will into little pieces.. > > That's why I said you had to copy some of the transport header into > each fragment and pass up the fragmentation information to the > transport layer when receiving packets. You'd design the real-time > transport header to put the sequence number and multiplexing > inforamtion near the front and that's what gets copied to each > fragment. That sequence number plus the fragment offset ought to be > sufficient to compute the play-point. > > Dave Bridgham Unfortunately, not quite. It's (mostly) true for non-compressed audio, and waveform-compressed audio (IDVI, ADPCM) but more compressed audio and video are structured and can only be broken apart at very few spots in the original packet, if any. Thus, copying the transport header is not sufficient. In other words, only high-rate audio would seem a likely candidate. Low-rate audio has short packets and video is structured. However, you still win if you have the first fragment, or group of fragments, so the OS should pass up the incomplete fragment before giving up on it. Traditional reassembly also has rather bad delay characteristics: if you wait until you are sure you won't get more fragments, the data will be stale and the set of fragments you got won't do you much good either. -- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 219 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin URL: http://www.fokus.gmd.de/htbin/info/minos/hgs ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 10:23:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02921; Wed, 28 Sep 94 10:23:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02167; Tue, 27 Sep 94 18:38:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17705; Tue, 27 Sep 94 18:34:46 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA29788; Tue, 27 Sep 94 18:32:48 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA24502; Wed, 28 Sep 1994 11:32:40 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA01631; Wed, 28 Sep 94 11:21:28 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00451; Wed, 28 Sep 1994 11:21:27 EST Date: 28 Sep 94 11:33:42 +1100 To: ipng@sunroof.Eng.Sun.COM, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au Subject: (IPng) MOBILITY..SOME INPUT Ua-Content-Id: 940928 11:01:54 P1-Recipient: ipng@sunroof.eng.sun.com, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 940928 11:01:54 032 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TELEMEMO*DATACRAFT; arrival 940928113342+1100 deferred 940928113342+1100 action Relayed Message-Id: <"940928 11:01:54"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday.. re the security, authentication and mobility stuff.. I may be repeating work already done/published.. but can I offer some details on the IN concepts that may move things along.. This is just to bounce ideas off.. The IN and Mobiles Requirements: Terminal Mobility, Personal Mobility and Security / Privacy.. Terminal Mobility Location Registration Terminal Service Profile Management FLPMTS Number recognition Terminal Paging/Alerting Terminal Attach / Detach Personal Mobility Incall / Outcall Registration User Service Profile Mgt UPT Number Recognition UPT Number Translation FLPMTS Number Recognition Security / Privacy Terminal Authentication Terminal Equipment Validation Service Authorisation CypherKey Management User Authentication User Verification (FPLMTS = Future Public Land Mobile Telecoms..Service) (UPT = Universal Personalised Telecoms..) These are the characteristics required.. they define the components of terminal, user and service and implicitly a network centre control function(s). The next IN concept is that of "core procedures" and "system service procedures" eg. core procedures.. terminal/user registration and profile management..system service (dependent) procedures.. eg authentication, terminal mgt, identity mgt.. ie the functionality to support the above requirements is defined as base core and service dependent..These communicate via signalling protocols. Next the overall IN concept(ie its Big Model). IN has a Service Plane at the top on which the big "service" definition fits..eg Mobile Phones. the Global Functional Plane is next and Distributed Service Logic Plane which sits on top of the physical network.. In the GFP... call processing (mobility), call screening, credit checks and security , etc functions are performed.. which are (from a modelling point) dispersed into the Distributed Service Logic.. and will be implementation dependent.. So the point of all the above is that the model for security and mobility and authorisation, etc.. for big networks could follow the above.. unfortunately.. if one has "service planes" and GFPs and DSL levels.. the operational management of the network is affected..and this has to be designed.. If we are just trying to develop protocols which permit such mechanisms.. then please advise..because the other direction will require "agents" and "managers" for specific features. Also if there a base list of requirements for mobility..please send. Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 11:41:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03113; Wed, 28 Sep 94 11:41:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03107; Wed, 28 Sep 94 11:41:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18626; Wed, 28 Sep 94 11:37:54 PDT Received: from mailhost.wco.ftp.com (kingkong.wco.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA24103; Wed, 28 Sep 94 11:36:32 PDT Date: Wed, 28 Sep 94 11:06:31 PDT Message-Id: <9409281806.AA23847@mailhost.wco.ftp.com> Received: from zoi (zoi.wco.ftp.com) by mailhost.wco.ftp.com; Wed, 28 Sep 94 11:06:31 PDT X-Sender: veizades@wco.ftp.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.Eng.Sun.COM From: veizades@ftp.com (John Veizades) Subject: Re: (IPng) Discovery X-Mailer: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >2) I would like to have much improved service/server discovery capabilities. > It would be nice if my host could sent out an ICMP Print Server solicit > (or the moral equivalent) to the intra-link all-nodes multicast address > and get back information on remote printers that I can access. Ditto > for DNS service, POP3/IMAP service, etc. This mechanism should not > depend on a router being on the local subnet in order that the mechanism > will work in the "Dentist's Office without external connectivity" > scenario. I'd like to be able to avoid use of a fixed server for this > information to avoid critical failure points. The Service Location Workign Group has been looking at this problem for quite a while and has an internet-draft that describes a proposal for doing this work (draft-ietf-svrloc-protocol-04.txt). The next version of this document (clarification and formating issues) will be put forth as a proposed standard and placed into the IPv6 document pool as a draft for service discovery for IPv6. This protocol is UDP/TCP multicast based and is designed with secutity, multilingual, and transport independence in mind. This means that in has an optional mechanism for including authentication information, it supports character sets other than ASCII for the representation of languages other than english, it has an address representation that allows for the inclusion of address format other than IPv4 and IPv6. Its transport requirements are a datagram delivery and sequenced byte stream protocols so that it can exist over other network protocols (AppleTalk, OSI, etc). This protocol is a bit more flexible than what Bill has proposed. The protocol was designed with human interaction as well as programmed control. With human interaction as a need system advertisements can contain natural language representations of the end systems. With this in mind the protocol also supports a grammer for the solicitation of systems that support a certain needed set of characteristics. This protocol could also be used for the discovery of network services under program control. The protocol also support the updating of a central cache of service information to allow for scaling ot a campus environment. Detection of the central cache is done by both hosts and servers and there is a fall back to a serverless mechanism. The central cache has an information consistency checking mechanism. A design pricipal of the protocol was that it was to work in the dentist office situation (the working group coined this term) where the size, connectivity and sophistication of the end users was taken into consideration. Question and comments are always accepted. John Veizades... CoChair Service Location Working Group. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 13:20:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03235; Wed, 28 Sep 94 13:20:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03229; Wed, 28 Sep 94 13:20:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28644; Wed, 28 Sep 94 13:17:08 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA13669; Wed, 28 Sep 94 13:16:15 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA10671; Wed, 28 Sep 94 13:10:12 -0700 Received: by xirtlu.zk3.dec.com; id AA25114; Wed, 28 Sep 1994 16:09:59 -0400 Message-Id: <9409282009.AA25114@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Wed, 28 Sep 94 11:06:31 PDT." <9409281806.AA23847@mailhost.wco.ftp.com> Date: Wed, 28 Sep 94 16:09:53 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM John, I will add this to my to-do list right away for IPv6. Sounds like it might work and prevent overloading the DNS which was another idea proposed (we have to stop dumping on DNS as our catch all database in the IETF IMHO). Can the services be known prior to the network layer via ICMP messages in the host network kernel or is the proposal that they will not be known until the message is received by the application above UDP and TCP? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 13:37:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03282; Wed, 28 Sep 94 13:37:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03276; Wed, 28 Sep 94 13:37:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00722; Wed, 28 Sep 94 13:34:24 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA17183; Wed, 28 Sep 94 13:33:21 PDT Subject: (IPng) Auto-config in a UNIX environment To: IPng Mailing list Date: Wed, 28 Sep 1994 16:33:50 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2011 Message-Id: <9409282133.aa00566@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM IPv6 is bringing auto-configuration to us. Happy happy, joy joy, etc. We've heard the good news. I have two questions relating to this, though. 1. Given the godawful sick amount of address space we have, should we bootstrap into auto-configuration with the following address per interface configured at boot-time (or near boot-time): fe00:: ? Where is either: MAC (Ethernet/Token Ring/FDDI) address X.25 address Other unique identification For example, I'd like on my BSD boxes to create a local-use address per Ethernet card. If card A has MAC address 02:40:00:08:20:69, I'd like that card to have IPv6 LOCAL-USE (local == intra-link only) address of fe00:0000:0000:0000:0000:0240:0008:2069 Is this the right approach. If not, tell me why. If so, tell others why. (As well as me.) 2. Assuming we can do some kind of per-machine auto-config as in #1, on a UNIX box, when do we do it? The possibilities are: 1. Kernel initialization time. Advantages: Truest sense of "plug-n-play" Disadvantages: Kernel bloat 2. Make new ioctl() that tells interface to configure IPv6 addr. Advantages: Makes for an easy 10-line program that drops into ALL /etc/netstart files identically. Disadvantages: Kernel bloat, and yet another ioctl() 3. Make easy-to-do, hard to program, user-level command, or add universal flag to something like ifconfig. This might involve adding one or two new ioctl()'s, unless the facilities for finding out HW addresses (or other cookie determinations) exist already. Advantages: Less kernel bloat, simple command brings up things, regardless of configuration, identical /etc/netstart files Disadvantages: Hard to program, some users still forget command, and some say scripts like /etc/netstart are not true "plug-n-play". Well, any takers? I lean toward either 1 or 3, because I don't like adding ioctl()'s unless I have to. Dan McD. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 15:07:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03419; Wed, 28 Sep 94 15:07:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03413; Wed, 28 Sep 94 15:06:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09807; Wed, 28 Sep 94 15:03:30 PDT Received: from sundance.itd.nrl.navy.mil ([132.250.92.89]) by Sun.COM (sun-barr.Sun.COM) id AA02684; Wed, 28 Sep 94 15:01:53 PDT To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) Discovery Date: Wed, 28 Sep 94 21:00:03 GMT From: Ran Atkinson Message-Id: <9409282100.aa00514@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Masataka, The response to an ICMP request for link address most certainly could be authenticated in many cases. This is highly desirable in some environments. ARP can't do this nearly as easily. Frank, I have _no_ problems with the "ARP request/response model". I'd like to try to move away from link-layer broadcast to link-layer multicast if possible. Moving to ICMP does permit authenticated responses in many cases (using the IPv6 Auth Header and suitable key mgmt; many of the sites that care already have ways of doing key mgmt). I am insufficiently informed about the Service Location work but am usually inclined to re-use existing technology that works well rather than invent new technology. If that WG can be cajoled into writing up how to use that protocol over IPv6 (preferably using multicast :-), then great. Let us see what they come up with. I'm eager to read the IPv6 variant in I-D form. Regards, Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 15:59:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03501; Wed, 28 Sep 94 15:59:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03463; Wed, 28 Sep 94 15:47:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14728; Wed, 28 Sep 94 15:43:54 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA10521; Wed, 28 Sep 94 15:42:26 PDT Received: by rodan.UU.NET id QQxjje21453; Wed, 28 Sep 1994 18:41:28 -0400 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: Re: (IPng) Auto-config in a UNIX environment To: ipng@sunroof.Eng.Sun.COM Date: Wed, 28 Sep 1994 18:41:28 -0400 (EDT) In-Reply-To: <9409282133.aa00566@sundance.itd.nrl.navy.mil> from "Dan McDonald" at Sep 28, 94 04:33:50 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...] >2. Assuming we can do some kind of per-machine auto-config as in #1, on a > UNIX box, when do we do it? The possibilities are: > > 1. Kernel initialization time. [...] > 2. Make new ioctl() that tells interface to configure IPv6 addr. [...] > 3. Make easy-to-do, hard to program, user-level command, or add [...] One more option presents itself, but it is harder to implment. 4. In the boot ROM. Advantages: *real* plug and play for clients, they can boot "the right kernel" without being configured. (this applies to diskful and diskless machines) (this also assumes the presence of a BOOTP like protocall server, and a client in the boot ROM) Disadvantages: Well, exparamenting with new boot ROMs is non-trivial (even on a PC). Defineing a way for the boot strap loader to tell the kernel it's IP address feels unclean. Secondary Advantages: Less kernel bloat - since we move the bloat to the boot ROM. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 28 20:59:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03676; Wed, 28 Sep 94 20:59:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03670; Wed, 28 Sep 94 20:59:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15778; Wed, 28 Sep 94 20:55:48 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA08574; Wed, 28 Sep 94 20:55:16 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 29 Sep 94 12:48:01 +0900 From: Masataka Ohta Message-Id: <9409290348.AA18297@necom830.cc.titech.ac.jp> Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Thu, 29 Sep 94 12:48:00 JST In-Reply-To: <9409282100.aa00514@sundance.itd.nrl.navy.mil>; from "Ran Atkinson" at Sep 28, 94 9:00 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Masataka, > > The response to an ICMP request for link address most certainly could be > authenticated in many cases. Through configured shared secret, yes. But it's a lot easier to directly configure MAC address instead. > This is highly desirable in some environments. No. Authentication at and above IP layer is enough. > ARP can't do this nearly as easily. I think this statement is also untrue. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 29 04:17:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03857; Thu, 29 Sep 94 04:17:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03851; Thu, 29 Sep 94 04:17:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06064; Thu, 29 Sep 94 04:13:40 PDT Received: from carmen.logica.co.uk by Sun.COM (sun-barr.Sun.COM) id AA18348; Thu, 29 Sep 94 04:12:50 PDT Received: from smtpmail.logica.com (mssmtp.logica.com) by carmen.logica.co.uk (4.1/SMI-4.1) id AA18708; Thu, 29 Sep 94 12:13:20 BST Received: by smtpmail.logica.com with Microsoft Mail id <2E8AAFA4@smtpmail.logica.com>; Thu, 29 Sep 94 12:14:28 bst From: Fieldhouse Dirk To: 'IPng mailing list' Subject: re: FW: (IPng) Re NSAP MAPs Date: Thu, 29 Sep 94 12:11:00 bst Message-Id: <2E8AAFA4@smtpmail.logica.com> Encoding: 58 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Apparently this response sent to sunroof2 on 27 September 1994 19:43 did not make it through the list server. [Brian said] > > However, yes, all this ie, an NSAP-address-extension end-to-end IPv6 option that can be routed on > means that IPv6 routers have to route on NSAP > address formats. This must be true in general, for any usage of NSAP > addresses except tunnels. The question of principle is whether we want to > make this an (elective) standard mechanism or not. The reason to do > so is to allow people to keep their NSAP allocation schemes. Does > this justify the added complexity? Brian, This is the $64k question. But the reason is not only what you say. #define ISO-politics-flame off It would be very good for all sorts of reasons, some admittedly not directly related to the goals of the IETF, to have IPv6 recognised or adopted by ISO. But IPv6 is unlikely to be acceptable to ISO if there is no visible upgrade path from NSAP addressing. So, there is a reason to go for some mechanism that would support full NSAP addressing even if such addresses will never need to be used with IPv6 - as Phil Royse and others have indicated, the number of deployed NSAP addresses is probably small enough that renumbering or address translation (or indeed, address compression) would be more effective for existing users than the additional cost of special routers. #define ISO-politics-flame on Despite that, it would be pointless to incorporate a mechanism that could not work or would be too complex to implement. So ... It appears that the impact of the NSAP-option on the specification is not too great (a few paragraphs and some fudged semantics?): presumably this added complexity is acceptable? So what would be the impact of the proposal on (a) a basic IPv6 router design (ie, delivering only to proper IPv6 addresses), built so as to be able to be enhanced to (b) (b) an extended IPv6 router design (ie, fully routing on both proper IPv6 addresses and NSAP addresses in the NSAP-option)? Here I'd like to call for input from people who are actually involved in building routers to assess the impact, because this is outside my detailed experience. Thx, Dirk Dirk Fieldhouse Logica UK Limited fieldhouse@lgwct.logica.com 68 Newman St c=gb;a=tmailuk;p=logica; London W1A 4SE ou1=lgwct;s=fieldhouse UK +44 (171) 637 9111 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 29 05:36:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03891; Thu, 29 Sep 94 05:36:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03885; Thu, 29 Sep 94 05:36:47 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10254; Thu, 29 Sep 94 05:33:27 PDT Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA23740; Thu, 29 Sep 94 05:32:41 PDT Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5465; Thu, 29 Sep 94 08:32:44 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 3505; Thu, 29 Sep 1994 08:32:43 EDT Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Thu, 29 Sep 94 08:32:42 EDT Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA30288; Thu, 29 Sep 1994 08:32:35 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9409291232.AA30288@hawpub1.watson.ibm.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) MOBILITY..SOME INPUT In-Reply-To: (Your message of 28 Sep 94 11:33:42 X.) <9409290104.AA29785@hawpub1.watson.ibm.com> Date: Thu, 29 Sep 94 08:32:35 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Terminal Mobility, Personal Mobility and Security / Privacy.. I assume that you equate "terminal" with "mobile thing that has a network-layer address". Certain aspects of the problem of mobility can (and, I think should) be solved at the network layer, but most of them probably should not. The best we can hope for is that a good network layer solution will simplify the overall solution, and my criterion for network layer goodness is whether packets addressed to a mobile network entity will be routed through the correct(*) intermediate routers. Thus, I believe that almost all of the requirements you identify should be solved in ways not directly relevant to the design of IPv6. Things that I think should NOT be solved at the network layer: > Terminal Mobility > Terminal Service Profile Management > FLPMTS Number recognition > Terminal Paging/Alerting > > Personal Mobility > Incall / Outcall Registration > User Service Profile Mgt > UPT Number Recognition > UPT Number Translation > FLPMTS Number Recognition > > Security / Privacy > Terminal Equipment Validation > Service Authorisation > CypherKey Management > User Authentication > User Verification > Things that I think might be solved at the network layer, depending on exactly how one defines the terms: > Terminal Mobility > Location Registration > Terminal Attach / Detach > ..... > Security / Privacy > Terminal Authentication > > These are the characteristics required.. they define the components of > terminal, user and service and implicitly a network centre control > function(s). I don't think that there's a simple relationship between the requirements for a network control center, and the requirements for a network layer protocol. > > The next IN concept is that of "core procedures" and "system service > procedures" What is IN? > eg. core procedures.. terminal/user registration and profile > management..system service (dependent) procedures.. eg authentication, > terminal mgt, identity mgt.. > ie the functionality to support the above requirements is defined as base > core and service dependent..These communicate via signalling protocols. O.K., but the protocols are most likely not operating at the network layer. ........... > > If we are just trying to develop protocols which permit such mechanisms.. > then please advise..because the other direction will require "agents" and > "managers" for specific features. > Yes, there will be hopefully a market for network agents and managers that is so huge it will make us all rich and technically employed for many years. But I don't think that market will be made up of products implementing network layer functions. > Also if there a base list of requirements for mobility..please send. (paraphrasing) The wonderful thing about lists of requirements, is that there are so many to choose from :-) Charlie P. (*) ahh... but who defines "correct" :-? ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 29 07:00:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03909; Thu, 29 Sep 94 07:00:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03903; Thu, 29 Sep 94 07:00:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15862; Thu, 29 Sep 94 06:57:17 PDT Received: from ftp.com (wd40.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA03662; Thu, 29 Sep 94 06:56:56 PDT Received: from ftp.com by ftp.com ; Thu, 29 Sep 1994 09:56:52 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 29 Sep 1994 09:56:52 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA20315; Thu, 29 Sep 94 09:53:46 EDT Date: Thu, 29 Sep 94 09:53:46 EDT Message-Id: <9409291353.AA20315@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Security and Discovery From: kasten@ftp.com (Frank Kastenholz) Cc: atkinson@sundance.itd.nrl.navy.mil Content-Length: 2385 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Ran Atkinson > Frank, > > I have _no_ problems with the "ARP request/response model". Neither do I -- just wanted to know what you were saying before I commented on it :-) > I'd like to try to move ... to link-layer multicast if possible. Yup. > Moving to ICMP does permit authenticated responses in many cases (using the > IPv6 Auth Header and suitable key mgmt; many of the sites that care already > have ways of doing key mgmt). This assumes that the node doing the "ARP-ICMP-6" already knows some keys without doing an ARP/ICMP. I believe that authenticated ICMP-ARP would work if and only if you have some out-of-band key distribution scheme. Consider - assume that a node, N, has just come up and the user types "telnet foo". The first thing that N will do is try to resolve 'foo' to an IP address. It have to do a DNS lookup using DNS server S. In order to send the DNS request, N will have to resolve the S's IP address (preconfigured) to a MAC address. N does this by issuing an ICMP-ARP request. N can sign the request using N's private key and S can then verify the signature using S's public key. Now S is going to send the ICMP-ARP response. S wishes to secure the response so S signs it using S's private key. N receives the response, which is signed with S's private key. How does N get S's public key in a secure manner? It can't use the ICMP-ARP response that it just got since it is trying to verify that the response is legitimate. You can't rely on S to give you the correct keys -- if there is a 'bad guy' attempting to masquerade as the local DNS server, then he can sign the ICMP-ARP response with any private key he wishes, and then when you ask, he'll give you a public key that corresponds to that private key. You have no way of verifying that the node that is answering the ICMP-ARP request for the DNS server is truly the DNS server... Now, suppose that there is a router between N and the DNS server S. In this case, I have to ICMP-ARP for the router, R. If I wish to do this in an authenticated manner, I need to get to the DNS server to get R's public key. But to get to the DNS server to authenticate the ICMP-ARP response, I have to go through R but the box that purports to be R could be a bad guy who is going to take my DNS requests and then feed me bad information... -- Frank Kastenholz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 29 14:39:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04201; Thu, 29 Sep 94 14:39:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04195; Thu, 29 Sep 94 14:39:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01910; Thu, 29 Sep 94 14:36:18 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA06963; Thu, 29 Sep 94 14:35:54 PDT Subject: (IPng) Creating local-use addresses To: IPng Mailing list Date: Thu, 29 Sep 1994 17:35:50 -0500 (EST) From: Dan McDonald Cc: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3394 Message-Id: <9409292235.aa02176@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yesterday I posed the question about using fe00:: ? as an IPv6 intra-link-use address for bootstrapping into some sort of auto-configuration scheme. Let's say I want to do this. Now, the SIPP (now IPv6) addressing architecture document states the following: > 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 > "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. Now, how do the ideas of "subnet" and "node id" fit into what I mentioned above? Here's MY TAKE on it... 1. For the purposes of an intra-link-use address, ignore any concept of a subnet ID. That is, for m bits of subnet ID, m = 0. 2. Fine, this means that there are all zero bits between the first byte (fe) and the beginning of the cookie. Given that, what would be the network mask for an intra-link-use address? My first thought was the bits up to the cookie, so for an 802.x MAC address, this would be something like: fe00::xxxx:xxxx:xxxx/80 (Notation compliments of Tony Li.) but not every piece of networking hardware is 802.x based. PPP links, SLIP(v6) links, ATM, all use different hardware addresses, and furthermore, they may be (GASP) _variable length_! My followup question is, what should be the subnet? It could be either: 1. One size fits all, i.e. a "Fixed cookie length". ADVANTAGES: Very simple solution. DISADVANTAGES: May waste bits by assigning too short of a netmask, or may force some kind of hashing scheme to smaller cookie size. Address collision possibilities if latter happens. 2. Cookie size per networking technology. ADVANTAGES: Takes into account varying sizes of network technologies' address size. DISADVANTAGES: Initialization agent {kernel, program, etc.} must be updated to reflect new HW address types. My own choice would be to have a "maximum cookie size" per networking technology. So for example, any 802.x network would have a netmask of 80 bits, and the last 48 would be the 802.x address. I don't know enough about other networking technologies to know how they'd fit, but if a networking technology had variable-length addresses up to, say, 8 bytes, then the netmask would be 64 bits, even if a certain node has a 2-byte HW address. I want to hear what the community has to say about this, especially those who'll be writing code! -- Daniel L. McDonald | Mail: danmcd@itd.nrl.navy.mil -------------------------+ Computer Scientist | WWW: http://wintermute.itd.nrl.navy.mil/danmcd.html | Naval Research Lab | Phone: (202) 404-7122 #include | Washington, DC | "Rise from the ashes, A blaze of everyday glory" - Rush + ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 29 15:11:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04231; Thu, 29 Sep 94 15:11:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04225; Thu, 29 Sep 94 15:11:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06051; Thu, 29 Sep 94 15:07:53 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA14712; Thu, 29 Sep 94 15:07:25 PDT Subject: (IPng) While I've got your attention... To: IPng Mailing list Date: Thu, 29 Sep 1994 18:06:57 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 545 Message-Id: <9409292306.aa02322@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I figured I'd spew out another question. This one is specifically for implementors. If I'm a user-level program that constructs ICMP packets (like ping(8)), how do I determine the SOURCE address I'll be using, given a destination? I need to know this because, in IPv6, the ICMP checksum includes the pseudo-header. The ICMP checksum is determined by the user-level program in my case, so I can't just count on the kernel to do it for me, like it would with TCP or UDP. Should this be an ioctl(), [gs]etsockopt(), or some other kludge? Dan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 29 16:49:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04437; Thu, 29 Sep 94 16:49:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04431; Thu, 29 Sep 94 16:49:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16531; Thu, 29 Sep 94 16:46:26 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA02143; Thu, 29 Sep 94 16:46:03 PDT Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA20357; Thu, 29 Sep 1994 19:45:52 -0400 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA19733; Thu, 29 Sep 1994 19:45:47 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA00627; Thu, 29 Sep 1994 19:22:27 -0400 Message-Id: <9409292322.AA00627@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: veizades@ftp.com, atkinson@sundance.itd.nrl.navy.mil, conta@zk3.dec.com Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Wed, 28 Sep 94 11:06:31 PDT." <9409281806.AA23847@mailhost.wco.ftp.com> Date: Thu, 29 Sep 94 19:22:27 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM X-Sender: veizades@wco.ftp.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reply-To: ipng@sunroof.eng.sun.com >2) I would like to have much improved service/server discovery capabilities. > It would be nice if my host could sent out an ICMP Print Server solicit > (or the moral equivalent) to the intra-link all-nodes multicast address > and get back information on remote printers that I can access. Ditto > .... > information to avoid critical failure points. The Service Location Workign Group has been looking at this problem for quite a while and has an internet-draft that describes a proposal for doing this work (draft-ietf-svrloc-protocol-04.txt). The next version of this document (clarification and formating issues) will be put forth as a proposed standard and placed into the IPv6 document pool as a draft for service discovery for IPv6. This protocol is UDP/TCP multicast based and is designed with secutity, multilingual, and transport independence in mind. .... This protocol is a bit more flexible than what Bill has proposed. The protocol was designed with human interaction as well as programmed control. With human interaction as a need system advertisements can contain natural ... scaling ot a campus environment. Detection of the central cache is done by both hosts and servers and there is a fall back to a serverless mechanism. The central cache has an information consistency checking mechanism. I am from the camp that prefers service query/reply addressed directly to the service, versus a service query/reply (solicitation/advertisment) addressed to the ICMP sublayer. For reasons that have to do with flexibility and cost, which are very good reasons for people that write applications: 1. in case the Service solicitation/advertisment is fully implemented in the application layer (control and transmit/receive) then the following applies: 1.1 the control mechanism is implementing directly in the application and no special provisions apply. 1.2 transmit/receive 1.2.1. transmitting ICMP Service solicitation/advertisment packets by an application is more complex in programming terms than transmitting a TCP or UDP message - the application must build a correct ICMP packet and header, and must employ a routine that correctly calculates the ICMP checksum. Additionally, in some multi-user systems, access directly to the IP layer - through a RAW socket type of interface - is subject to specific restrictions, which could be an additional obstacle both in implementing and managing such an application. 1.2.2. receiving ICMP Service solicitation/advertisment packets by an application is more complex than receiving a TCP or UDP message - the application will listen on a RAW socket which would most likely pass up all ICMP messages, so the application must filter the Service packets from the others, and most likely do validation before processing of actual Service information. The multi-user system restriction applies to receive as well, if it applies to transmit. 2. in case the Service solicitation/advertisment is partly implemented in the application layer (control) and partly in the ICMP sublayer (transmit/receive) then the following applies: 2.1 implementing a control mechanism, i.e. specific networking system calls to transmit/receive ICMP Service packets - implies a specific API that allows the application to ICMP sublayer communication, which is more complex, and thus more expensive than (1.). 2.2. implementing a transmit/receive of ICMP Service packets implies more code in the ICMP sublayer, which is usually subject to system specific space constraints (code and data). Alex ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 29 17:40:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04504; Thu, 29 Sep 94 17:40:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04498; Thu, 29 Sep 94 17:40:46 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20410; Thu, 29 Sep 94 17:37:25 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA10085; Thu, 29 Sep 94 17:37:01 PDT Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA22533; Thu, 29 Sep 1994 20:36:58 -0400 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA20559; Thu, 29 Sep 1994 20:36:57 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA00672; Thu, 29 Sep 1994 20:13:38 -0400 Message-Id: <9409300013.AA00672@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: danmcd@sundance.itd.nrl.navy.mil, conta@zk3.dec.com Subject: Re: (IPng) Creating local-use addresses In-Reply-To: Your message of "Thu, 29 Sep 94 17:35:50 CDT." <9409292235.aa02176@sundance.itd.nrl.navy.mil> Date: Thu, 29 Sep 94 20:13:38 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM To: IPng Mailing list cc: Dan McDonald From: Dan McDonald Subject: (IPng) Creating local-use addresses Dan, Here is my interpretation. The local address is for local purposes only, i.e. links (media) that your host is directly connected to. The subnet part can be defined manually if you wish to have a subnet, or multiple subnets on a certain medium (wire), but for the case in which there is no manual intervention, there are no subnets - which means one subnet - and the address will carry only host information in its entirety of 128 bits. Which means no mask, or a mask with all 128 bits set to 0. The IPv6 address is a function of the media address - where there is a media address, use that, where there is none, it does most likely not count. Alex ===================== So Yesterday I posed the question about using fe00:: ? as an IPv6 intra-link-use address for bootstrapping into some sort of auto-configuration scheme. Let's say I want to do this. Now, the SIPP (now IPv6) addressing architecture document states the following: > 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 > "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. Now, how do the ideas of "subnet" and "node id" fit into what I mentioned above? Here's MY TAKE on it... 1. For the purposes of an intra-link-use address, ignore any concept of a subnet ID. That is, for m bits of subnet ID, m = 0. 2. Fine, this means that there are all zero bits between the first byte (fe) and the beginning of the cookie. Given that, what would be the network mask for an intra-link-use address? My first thought was the bits up to the cookie, so for an 802.x MAC address, this would be something like: fe00::xxxx:xxxx:xxxx/80 (Notation compliments of Tony Li.) but not every piece of networking hardware is 802.x based. PPP links, SLIP(v6) links, ATM, all use different hardware addresses, and furthermore, they may be (GASP) _variable length_! My followup question is, what should be the subnet? It could be either: 1. One size fits all, i.e. a "Fixed cookie length". ADVANTAGES: Very simple solution. DISADVANTAGES: May waste bits by assigning too short of a netmask, or may force some kind of hashing scheme to smaller cookie size. Address collision possibilities if latter happens. 2. Cookie size per networking technology. ADVANTAGES: Takes into account varying sizes of network technologies' address size. DISADVANTAGES: Initialization agent {kernel, program, etc.} must be updated to reflect new HW address types. My own choice would be to have a "maximum cookie size" per networking technology. So for example, any 802.x network would have a netmask of 80 bits, and the last 48 would be the 802.x address. I don't know enough about other networking technologies to know how they'd fit, but if a networking technology had variable-length addresses up to, say, 8 bytes, then the netmask would be 64 bits, even if a certain node has a 2-byte HW address. I want to hear what the community has to say about this, especially those who'll be writing code! -- Daniel L. McDonald | Mail: danmcd@itd.nrl.navy.mil ------------------------- ***+ Computer Scientist | WWW: http://wintermute.itd.nrl.navy.mil/danmcd.html ***| Naval Research Lab | Phone: (202) 404-7122 #include ***| Washington, DC | "Rise from the ashes, A blaze of everyday glory" - Rush ***+ ----------------------------------------------------------------------------- ***- IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 29 17:52:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04518; Thu, 29 Sep 94 17:52:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04512; Thu, 29 Sep 94 17:52:46 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21141; Thu, 29 Sep 94 17:49:25 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA11735; Thu, 29 Sep 94 17:49:03 PDT Subject: Re: (IPng) Creating local-use addresses To: conta@zk3.dec.com Date: Thu, 29 Sep 1994 20:48:59 -0500 (EST) From: Dan McDonald Cc: IPng Mailing list , Dan McDonald In-Reply-To: <9409300013.AA00672@brigit.zk3.dec.com> from "conta@zk3.dec.com" at Sep 29, 94 08:13:38 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 528 Message-Id: <9409300149.aa02561@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alex, (and the list) Or would it be a mask of all 1's, seeing as how I don't want to have any random packets go out an interface just by matching. (With all 0's ANY ADDRESS matches the prefix mask.) Also, what about the dentist's office case? I'll need to send out packets to unicast destinations without ever finding an actualy netmask. Do I just use a default next hop? And what about a multi-homed node in a dentist's office? Default next hop won't work there. Ouch. This is going to be harder than I thought. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 29 17:55:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04530; Thu, 29 Sep 94 17:55:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04524; Thu, 29 Sep 94 17:55:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21285; Thu, 29 Sep 94 17:51:59 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA12112; Thu, 29 Sep 94 17:51:35 PDT Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA23364; Thu, 29 Sep 1994 20:51:32 -0400 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA20982; Thu, 29 Sep 1994 20:51:31 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA00704; Thu, 29 Sep 1994 20:28:12 -0400 Message-Id: <9409300028.AA00704@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, danmcd@sundance.itd.nrl.navy.mil Subject: Re: (IPng) While I've got your attention... In-Reply-To: Your message of "Thu, 29 Sep 94 18:06:57 CDT." <9409292306.aa02322@sundance.itd.nrl.navy.mil> Date: Thu, 29 Sep 94 20:28:12 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Good question. You really need this only for multiple IPv6 addresses/interfaces. On a single interface/single IPv6 address, a 'gethost' address would do. A function source = get_source (destination,...) which will return the source address for a certain destination, will do. WHich could be very a well a 'getsockopt'. Alex ============ From: Dan McDonald Subject: (IPng) While I've got your attention... I figured I'd spew out another question. This one is specifically for implementors. If I'm a user-level program that constructs ICMP packets (like ping(8)), how do I determine the SOURCE address I'll be using, given a destination? I need to know this because, in IPv6, the ICMP checksum includes the pseudo-header. The ICMP checksum is determined by the user-level program in my case, so I can't just count on the kernel to do it for me, like it would with TCP or UDP. Should this be an ioctl(), [gs]etsockopt(), or some other kludge? Dan ----------------------------------------------------------------------------- ***- IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 30 01:43:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04619; Fri, 30 Sep 94 01:43:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04613; Fri, 30 Sep 94 01:42:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08994; Fri, 30 Sep 94 01:39:37 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA21191; Fri, 30 Sep 94 01:38:52 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Fri, 30 Sep 1994 09:38:05 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; Relayed; Fri, 30 Sep 1994 09:36:25 +0100 Date: Fri, 30 Sep 1994 09:36:25 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003782] X400-Content-Type: P2-1984 (2) Content-Identifier: 3782 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3782*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 Relayed by Jack Houldsworth ------------------------------ Start of forwarded message 1 Delivery-Date: Mon, 26 Sep 1994 07:53:08 +0100 X400-Content-Type: P2-1984 (2) X400-Originator: /G=MATTI/S=VASARA/O=STY/@elisa.fi Original-Encoded-Information-Types: ia5 text (2) X400-Recipients: J.Houldsworth@ste0906.wins.icl.co.uk Date: Mon, 26 Sep 1994 07:46:12 +0100 From: Matti Vasara (Tel 90-685 1305 koti: 90-384589) Message-ID: <"6:2991029:6:1*/G=MATTI/S=VASARA/O=STY/ADMD=ELISA/C=FI/"@MHS> To: J.Houldsworth@ste0906.wins.icl.co.uk In-Reply-To: "6:2912845": Subject: > NSAP Addresses Hello Jack! This is our survey of the use of NSAP:s. The situation is the same as in US. Gentlemen The situation regarding NSAP addresses in Finland is as follows: DCC-format is preferred. The Finnish Data Communication Association has, as of today, issued 103 Org Ids. In order to find out more about their use, we conducted a survey. From 101 organisations 48 answered (47,5 %). According to these answers, sel-field is often used for varying purposes, for instance to show that ID = IP or ID = Decnet or with whom of the many possible network operators that particular NSAP is operating. Therefore it is not a part of the address itself, but software now used needs it. DCC-format is used = 3 octets Ver = 1 octet (not in use) Org Id = 3 octets Reserved = 2 octets (not in use) RD = 2 octets Area = 2 octets ID = 6 octets sel = 1 octet (in use) Total = 20 octets ------------------------------ End of forwarded message 1 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 30 01:49:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04631; Fri, 30 Sep 94 01:49:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04625; Fri, 30 Sep 94 01:48:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09151; Fri, 30 Sep 94 01:45:32 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA21558; Fri, 30 Sep 94 01:45:09 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) While I've got your attention... To: ipng@sunroof.Eng.Sun.COM Date: Fri, 30 Sep 1994 09:43:09 +0200 (BST) In-Reply-To: <9409292306.aa02322@sundance.itd.nrl.navy.mil> from "Dan McDonald" at Sep 29, 94 06:06:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 575 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > If I'm a user-level program that constructs ICMP packets (like ping(8)), how > do I determine the SOURCE address I'll be using, given a destination? I > need to know this because, in IPv6, the ICMP checksum includes the > pseudo-header. The ICMP checksum is determined by the user-level program in > my case, so I can't just count on the kernel to do it for me, like it would > with TCP or UDP. Should this be an ioctl(), [gs]etsockopt(), or some other > kludge? bind() the socket to one of your known addresses first ? or have I missed something obvious here ? Alan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 30 02:11:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04668; Fri, 30 Sep 94 02:11:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04662; Fri, 30 Sep 94 02:11:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09984; Fri, 30 Sep 94 02:08:29 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA22988; Fri, 30 Sep 94 02:07:59 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Fri, 30 Sep 1994 10:07:08 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Fri, 30 Sep 1994 09:51:12 +0100 Date: Fri, 30 Sep 1994 09:51:12 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003786] Original-Encoded-Information-Types: ia5 text (2),undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3786 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3786*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 Relayed by Jack Houldsworth ------------------------------ Start of body part 2 ----------------------- Mail item text follows --------------- To: I1015269--IBMMAIL *** Reply to note of 09/24/94 03:06 From: Monica Stahl Tel 46 8 7931372 Int Mail 6-02 Adress: IBM Svenska AB, 164 92 Stockholm SEC: U ----Unclassified---- Subject: RE: NSAP and ATM Jack, What you can tell the IPNG is that one af the possible ATM addresses are binary 20 bytes NSAP. But don't use the rest. I have too much to do for the moment. Again electronic hugs. Halsningar/Regards Monica ------------------------------ End of body part 2 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 30 15:05:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00224; Fri, 30 Sep 94 15:05:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04723; Fri, 30 Sep 94 05:30:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14897; Fri, 30 Sep 94 05:26:53 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA08478; Fri, 30 Sep 94 05:26:30 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22700; Fri, 30 Sep 1994 13:26:27 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA25436; Fri, 30 Sep 1994 13:26:25 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9409301226.AA25436@dxcoms.cern.ch> Subject: Re: (IPng) NSAPs To: ipng@sunroof.Eng.Sun.COM Date: Fri, 30 Sep 1994 13:26:25 +0100 (MET) In-Reply-To: <"3786*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> from "J.Houldsworth@ste0906.wins.icl.co.uk" at Sep 30, 94 09:51:12 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 534 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, 1. I have already had unofficial indications that the Finnish NSAP scheme could readily be compressed into the 16-byte format; in fact I told them to slow down because nothing is decided yet. 2. I suspect the ATM Forum will be looking very closely indeed at IPv6 addressing. In fact they could trivially use the proposed IPv6-in-NSAP embedding without changing much at all. (It remains a mystery to me why the ATM Forum chose to copy a Level 3 address format for Level 2 addressing, but that is another discussion.) Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 30 15:06:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00238; Fri, 30 Sep 94 15:06:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04736; Fri, 30 Sep 94 06:37:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17333; Fri, 30 Sep 94 06:33:44 PDT Received: from carmen.logica.co.uk by Sun.COM (sun-barr.Sun.COM) id AA15304; Fri, 30 Sep 94 06:33:03 PDT Received: from smtpmail.logica.com (mssmtp.logica.com) by carmen.logica.co.uk (4.1/SMI-4.1) id AA18239; Fri, 30 Sep 94 14:32:20 BST Received: by smtpmail.logica.com with Microsoft Mail id <2E8C21B8@smtpmail.logica.com>; Fri, 30 Sep 94 14:33:28 bst From: Fieldhouse Dirk To: 'IPng mailing list' Cc: "'Carpenter Brian (CERN-CN)'" Subject: (IPng) Re NSAP MAPs Date: Fri, 30 Sep 94 14:29:00 bst Message-Id: <2E8C21B8@smtpmail.logica.com> Encoding: 59 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Apparently this response sent to sunroof2 on 27 September 1994 19:43 did not make it through the list server. [Brian said] > > However, yes, all this ie, an NSAP-address-extension end-to-end IPv6 option that can be routed on > means that IPv6 routers have to route on NSAP > address formats. This must be true in general, for any usage of NSAP > addresses except tunnels. The question of principle is whether we want to > make this an (elective) standard mechanism or not. The reason to do > so is to allow people to keep their NSAP allocation schemes. Does > this justify the added complexity? Brian, This is the $64k question. But the reason is not only what you say. #define ISO-politics-flame off It would be very good for all sorts of reasons, some admittedly not directly related to the goals of the IETF, to have IPv6 recognised or adopted by ISO. But IPv6 is unlikely to be acceptable to ISO if there is no visible upgrade path from NSAP addressing. So, there is a reason to go for some mechanism that would support full NSAP addressing even if such addresses will never need to be used with IPv6 - as Phil Royse and others have indicated, the number of deployed NSAP addresses is probably small enough that renumbering or address translation (or indeed, address compression) would be more effective for existing users than the additional cost of special routers. #define ISO-politics-flame on Despite that, it would be pointless to incorporate a mechanism that could not work or would be too complex to implement. So ... It appears that the impact of the NSAP-option on the specification is not too great (a few paragraphs and some fudged semantics?): presumably this added complexity is acceptable? So what would be the impact of the proposal on (a) a basic IPv6 router design (ie, delivering only to proper IPv6 addresses), built so as to be able to be enhanced to (b) (b) an extended IPv6 router design (ie, fully routing on both proper IPv6 addresses and NSAP addresses in the NSAP-option)? Here I'd like to call for input from people who are actually involved in building routers to assess the impact, because this is outside my detailed experience. Thx, Dirk Dirk Fieldhouse Logica UK Limited fieldhouse@lgwct.logica.com 68 Newman St c=gb;a=tmailuk;p=logica; London W1A 4SE ou1=lgwct;s=fieldhouse UK +44 (171) 637 9111 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com