From owner-ipng Sun Jun 4 10:46:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17650; Sun, 4 Jun 95 10:46:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17644; Sun, 4 Jun 95 10:45:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27265; Sun, 4 Jun 1995 10:36:30 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id KAA02165; Sun, 4 Jun 1995 10:36:30 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id TAA11390 for ; Sun, 4 Jun 1995 19:36:28 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id TAA00832 for ; Sun, 4 Jun 1995 19:36:27 +0200 Message-Id: <199506041736.TAA00832@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 154) some details to fix Date: Sun, 04 Jun 1995 19:36:24 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I'd like to know the status of the incoming drafts about some details: - strict/loose bits of routing header (better explanation and I believe there is a missing bit: with N intermediate hops there are N+1 steps and N+2 involved hosts... Something really needs to be fixed there !) - Ethernet encapsulation (what is the decision and eventually what is the new "ethertype" to use ?) - multicast MAC addresses (there is no word about the MAC multicast addresses...) - destination header (there are two different types of destination headers, perhaps we need to split them into two different headers ?) - error ICMP packets (is it legal to strip option header before returning something like a port unreachable ?) Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 5 01:19:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17785; Mon, 5 Jun 95 01:19:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17779; Mon, 5 Jun 95 01:18:53 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23147; Mon, 5 Jun 1995 01:09:20 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id BAA05651; Mon, 5 Jun 1995 01:09:15 -0700 Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA10569; Mon, 5 Jun 1995 18:09:11 +1000 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA16734; Mon, 5 Jun 95 17:48:54 +1000 Received: by dcthq2.datacraft.com.au; Mon, 5 Jun 95 18:22:37 +1100 Date: Mon, 5 Jun 95 18:16:39 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 155) neutral neurals X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk re the IP addressing architecture doc. If I offer a beer (or two) in stockholm for the first (correct) response can anyone inform me what Neutral Interconnect addresses are used for. also does any one have experience or thoughts about the use of E.164 address being embeded in IP6 forms. eg routing, administration, format detection, switched ISDN use... regards alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 5 14:35:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18337; Mon, 5 Jun 95 14:35:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18331; Mon, 5 Jun 95 14:35:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01916; Mon, 5 Jun 1995 14:26:03 -0700 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id OAA24307; Mon, 5 Jun 1995 14:25:56 -0700 Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29941 Tue, 6 Jun 1995 07:25:52 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 156) IPv6 address notation Date: Tue, 06 Jun 1995 07:24:30 +1000 Message-Id: <2236.802387470@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk This is from the DRUMS mailing list. While it has been hinted at often enough, the people there who care about this don't seem inclined to send anything to the ipng list ... DRUMS is (going to) clean up the e-mail standards - rewrite the rfcs so they're compatible with each other etc, but not add anything (or that's the theory). One of the first issues to arise has been simplifying the syntax of valid addresses (and make 822 and 821 equivalent). In that regard the use of the ':' character came up, and someone (sorry, I've forgotten who, speak up if you're here and care) indicated that ':'s would start to appear inside domain-literals, once they started carrying IPv6 addresses with the current defined notation for transcribing IPv6 addresses. After a few exchanges, the following appeared ... ------- Forwarded Message From: John Gardiner Myers Date: Mon, 5 Jun 1995 16:44:20 -0400 (EDT) To: drums@CS.UTK.EDU Subject: Re: address syntax Robert Elz writes: > You're right, it is syntactically illegal now, and you can > I suppose parse it however you like, but generating an "address > error" message would be much more intelligent. There are situations when generating any sort of error is simply not possible. > However, the IPng group will write a new RFC (when they get > around to going through all of the RFCs - or at least all > of the standards RFCs, and making changes to anything that > refers to "IP address" or its syntax, anywhere). When > that happens that address (modulo the bogus characters) will > be legal, and you'll have to parse it the way it is obviously > intended. If they try to get a document on the standards track which attempts to permit ":" characters in rfc822 domains, I and others who deal with mail systems will strenuously object on the grounds that the change will break a significant portion of the installed base. Breaking the installed base is simply unacceptable. If the IPng wants to use an address syntax that cannot be used in RFC 822 addresses, I consider that their business. - -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------- End of Forwarded Message In a later part of the message I sent which was quoted above, and in an earlier message, I suggested three courses of action that they could follow if they wanted to avoid problems. 1) fix their parsers now, in the years available before any realistic use of IPv6 domain literals starts to occur. 2) convince the IPng group to alter the notation, so that the ':' isn't used 3) delete domain literals completely, so the issue doesn't arise It doesn't appear that any of those three (or other possible methods) is finding any great favour. Beats me why. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 5 15:00:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18373; Mon, 5 Jun 95 15:00:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18367; Mon, 5 Jun 95 15:00:01 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06082; Mon, 5 Jun 1995 14:50:24 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id OAA27966; Mon, 5 Jun 1995 14:50:23 -0700 Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA07194; Tue, 6 Jun 1995 07:50:19 +1000 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA18391; Tue, 6 Jun 95 07:29:29 +1000 Received: by dcthq2.datacraft.com.au; Tue, 6 Jun 95 8:03:12 +1100 Date: Tue, 6 Jun 95 7:47:27 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: mankin@isi.edu Cc: ipng@sunroof.Eng.Sun.COM, brian%dxcoms.cern.ch%DCTHQ@datacraft.com.au Subject: (IPng 157) re: Re: neutral neurals X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk alison, thanks for the response. I am pleased the term is going back to geographic' cos I understand that! re the E.164 formats. I think we will be doing much the same. The other difficulty I have is that the IP6 addr doc (hinden) describes that the LS end of the IP6 address can be 802. or E.164 but no indication of saying how one determines this. Given also there is a move in the ITU to incorporate TOA/NPI (type of address / numbering plan indicators (X.300, Q.2931/3 and X.25/121)) we seem to have a range of formats to contend with. Perhaps I would like to see an IP6 address format that does deal with E.164 and its associated formats. EG> E.164 FORM Form 1 NSAP - E.164 Form 2 Native E.164 Form 3 TOA/NPI E.164, X.121 TOA/NPI being available where interworking between X.25/121 and Frame Relay is needed. Also the use of Escape codes is still being demanded by some networks so these can be accomodated in the native form. As the 15 digit address form will hit in 1997, IP6 should be engineering itself to meet this. regards and thanks alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 5 15:16:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18410; Mon, 5 Jun 95 15:16:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18404; Mon, 5 Jun 95 15:16:33 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08584; Mon, 5 Jun 1995 15:07:04 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id PAA00237; Mon, 5 Jun 1995 15:06:57 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id PAA03707; Mon, 5 Jun 1995 15:05:50 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Jun 1995 15:07:26 -0700 To: Robert Elz From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 158) Re: IPv6 address notation Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Robert, >In a later part of the message I sent which was quoted above, >and in an earlier message, I suggested three courses of action >that they could follow if they wanted to avoid problems. > >1) fix their parsers now, in the years available before any >realistic use of IPv6 domain literals starts to occur. > >2) convince the IPng group to alter the notation, so that the >':' isn't used > >3) delete domain literals completely, so the issue doesn't arise > > >It doesn't appear that any of those three (or other possible >methods) is finding any great favour. Beats me why. I think that typing IP addresses (IPv4, IPv6, etc.) in email addresses (e.g., hinden@[127.0.0.1] ) is not a useful feature. I would suggest that the email folks remove this "capability". Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 5 15:40:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18474; Mon, 5 Jun 95 15:40:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18468; Mon, 5 Jun 95 15:40:34 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12226; Mon, 5 Jun 1995 15:31:02 -0700 Received: from BBN.COM by mercury.Sun.COM (Sun.COM) id PAA03399; Mon, 5 Jun 1995 15:31:02 -0700 Received: from aland.bbn.com by BBN.COM id aa26389; 5 Jun 95 18:27 EDT Received: by aland.bbn.com (8.6.12/3.1.090690-BBN) id PAA03085; Mon, 5 Jun 1995 15:25:52 -0700 Message-Id: <199506052225.PAA03085@aland.bbn.com> To: hinden@Ipsilon.COM (Bob Hinden) Cc: Robert Elz , ipng@sunroof.Eng.Sun.COM Subject: (IPng 159) Re: Re: IPv6 address notation In-Reply-To: Your message of Mon, 05 Jun 95 15:07:26 -0700. Date: Mon, 05 Jun 95 15:25:52 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >In a later part of the message I sent which was quoted above, >and in an earlier message, I suggested three courses of action >that they could follow if they wanted to avoid problems. > >1) fix their parsers now, in the years available before any >realistic use of IPv6 domain literals starts to occur. > >2) convince the IPng group to alter the notation, so that the >':' isn't used > >3) delete domain literals completely, so the issue doesn't arise > > >It doesn't appear that any of those three (or other possible >methods) is finding any great favour. Beats me why. I think that typing IP addresses (IPv4, IPv6, etc.) in email addresses (e.g., hinden@[127.0.0.1] ) is not a useful feature. I would suggest that the email folks remove this "capability". Bob (and Robert): Domain literals show up in two places in e-mail. One as addresses in TO and FROM fields. The other place is in RECEIVED lines. While one may not like domain literals in TO and FROM fields, they are sometimes essential in RECEIVED lines and should not be deleted from the spec. Craig PS: This caused me to go back and re-read RFC 822 parsing rules and I discovered a fun one. As I read them, the rules still permit a sub-domain (something between dots, to be a string or a domain literal). E.g. the following appears to be valid under RFC 822 munnari.[128.89.0.124].oz.au Probably RFC 1123 has fixed this (I didn't check) but idea has some ghastly charm... ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 5 15:51:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18494; Mon, 5 Jun 95 15:51:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18488; Mon, 5 Jun 95 15:51:20 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13863; Mon, 5 Jun 1995 15:41:52 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id PAA04858; Mon, 5 Jun 1995 15:41:50 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id PAA04095; Mon, 5 Jun 1995 15:40:17 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Jun 1995 15:41:53 -0700 To: Craig Partridge From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 160) Re: Re: IPv6 address notation Cc: hinden@Ipsilon.COM (Bob Hinden), Robert Elz , ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Craig, > Domain literals show up in two places in e-mail. One as addresses in >TO and FROM fields. The other place is in RECEIVED lines. While one may >not like domain literals in TO and FROM fields, they are sometimes essential >in RECEIVED lines and should not be deleted from the spec. Good point. I think that address in the RECEIVED lines would be ok because machines do not have to parse these lines. They are read by people. Bob >PS: This caused me to go back and re-read RFC 822 parsing rules and I >discovered >a fun one. As I read them, the rules still permit a sub-domain (something >between dots, to be a string or a domain literal). E.g. the following appears >to be valid under RFC 822 > > munnari.[128.89.0.124].oz.au Also, I wonder what happens if someone tries to send email to a valid multicast address..... Again, I think the capability in email to type in an IP address [in TO or FROM fields] is a bad idea. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 5 16:01:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18506; Mon, 5 Jun 95 16:01:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18500; Mon, 5 Jun 95 16:00:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15483; Mon, 5 Jun 1995 15:51:21 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id PAA06043; Mon, 5 Jun 1995 15:51:21 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id PAA04250; Mon, 5 Jun 1995 15:50:24 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 Jun 1995 15:52:01 -0700 To: ipng@sunroof.Eng.Sun.COM From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 161) Updated to IPng WWW Pages Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The IPng working group WWW pages have been updated. The URL is: http://playground.sun.com/pub/ipng/html/ipng-main.html Check out the implementation status page. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 5 16:06:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18522; Mon, 5 Jun 95 16:06:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18516; Mon, 5 Jun 95 16:05:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16501; Mon, 5 Jun 1995 15:56:25 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id PAA06639; Mon, 5 Jun 1995 15:56:13 -0700 Received: from relay.imsi.com by wintermute.imsi.com id SAA23175; Mon, 5 Jun 1995 18:54:19 -0400 Received: from snark.imsi.com by relay.imsi.com id SAA15610; Mon, 5 Jun 1995 18:54:19 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA27955; Mon, 5 Jun 95 18:54:18 EDT Message-Id: <9506052254.AA27955@snark.imsi.com> To: hinden@Ipsilon.COM (Bob Hinden) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 162) Re: Re: IPv6 address notation In-Reply-To: Your message of "Mon, 05 Jun 1995 15:07:26 PDT." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 05 Jun 1995 18:54:18 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Bob Hinden writes: > I think that typing IP addresses (IPv4, IPv6, etc.) in email addresses > (e.g., hinden@[127.0.0.1] ) is not a useful feature. I would suggest that > the email folks remove this "capability". Unfortunately, I have cause to use this feature on virtually a monthly basis. For instance, I was recently forced to configure a mail system to punt to an absolute addresses because of braindead DNS setups on firewalls. Its easy to say "Perry, why don't you just get them to fix the DNS in those situations" but its not always possible. Lets not break things. The proposal I'd like to make, which I've already made to the DRUMS mailing list, is that mail to absolute addresses take the form of domain names in the .ip6.int domain. It has the advantage of allowing MXes to permit mailing to such addresses on the IPv4 side of the fence. Its sick, but it would preserve the functionality without forcing a change in syntax for the IPv6 people or a change in syntax for the mail folks, and it would address an important backwards compatibility problem. However, if people reject this modest proposal, I would again ask that we NOT NOT NOT break mailing to IP addresses. Some of us are forced to do these things periodically whether we like it or not. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 5 16:26:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18549; Mon, 5 Jun 95 16:26:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18543; Mon, 5 Jun 95 16:25:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20325; Mon, 5 Jun 1995 16:16:25 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id QAA09175; Mon, 5 Jun 1995 16:16:11 -0700 Received: from relay.imsi.com by wintermute.imsi.com id TAA23242; Mon, 5 Jun 1995 19:14:23 -0400 Received: from snark.imsi.com by relay.imsi.com id TAA15881; Mon, 5 Jun 1995 19:14:23 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA28007; Mon, 5 Jun 95 19:14:22 EDT Message-Id: <9506052314.AA28007@snark.imsi.com> To: hinden@Ipsilon.COM (Bob Hinden) Cc: Craig Partridge , ipng@sunroof.Eng.Sun.COM Subject: (IPng 163) Re: Re: Re: IPv6 address notation In-Reply-To: Your message of "Mon, 05 Jun 1995 15:41:53 PDT." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 05 Jun 1995 19:14:22 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Bob Hinden writes: > Also, I wonder what happens if someone tries to send email to a valid > multicast address. The TCP stack should refuse to try to open a connection to a multicast address, for this and many other reasons. Hmmm... has anyone thought of that before, or is this old hat? .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 5 16:33:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18571; Mon, 5 Jun 95 16:33:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18565; Mon, 5 Jun 95 16:33:09 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21450; Mon, 5 Jun 1995 16:23:41 -0700 Received: from BBN.COM by mercury.Sun.COM (Sun.COM) id QAA10121; Mon, 5 Jun 1995 16:23:42 -0700 Received: from aland.bbn.com by BBN.COM id aa29770; 5 Jun 95 19:20 EDT Received: by aland.bbn.com (8.6.12/3.1.090690-BBN) id QAA03347; Mon, 5 Jun 1995 16:19:23 -0700 Message-Id: <199506052319.QAA03347@aland.bbn.com> To: perry@imsi.com Cc: hinden@Ipsilon.COM (Bob Hinden), Craig Partridge , ipng@sunroof.Eng.Sun.COM Subject: (IPng 164) Re: Re: Re: IPv6 address notation In-Reply-To: Your message of Mon, 05 Jun 95 19:14:22 -0400. <9506052314.AA28007@snark.imsi.com> Date: Mon, 05 Jun 95 16:19:22 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The TCP stack should refuse to try to open a connection to a multicast address, for this and many other reasons. Hmmm... has anyone thought of that before, or is this old hat? I thought it got fixed about 12 years ago. I remember a report of someone accidentally telnetting to the local broadcast address around 1984 with bizarre results. Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 5 16:46:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18619; Mon, 5 Jun 95 16:46:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18613; Mon, 5 Jun 95 16:46:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23455; Mon, 5 Jun 1995 16:36:38 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id QAA11537; Mon, 5 Jun 1995 16:36:36 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12871; Tue, 6 Jun 1995 09:35:49 +1000 (from kre@munnari.OZ.AU) To: hinden@Ipsilon.COM (Bob Hinden) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 165) Re: Re: Re: IPv6 address notation In-Reply-To: Your message of "Mon, 05 Jun 1995 15:41:53 MST." Date: Tue, 06 Jun 1995 09:35:44 +1000 Message-Id: <2266.802395344@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Mon, 5 Jun 1995 15:41:53 -0700 From: hinden@Ipsilon.COM (Bob Hinden) Message-ID: I think that address in the RECEIVED lines would be ok Yes, I doubt there would be a problem there. Even if there were, the address could always just be stuck in a comment, and would be just as useful. >As I read them, the rules still permit a sub-domain (something >between dots, to be a string or a domain literal). E.g. the following appears >to be valid under RFC 822 > munnari.[128.89.0.124].oz.au Yes, DRUMS has already noted that, and will probably legislate it out of existance - 822 & 821 were clearly written before much was known about domain addressing. Incidentally, the 822 domain-literal definition is not a problem, it permits almost anything, (which also solves the Received header issue) its just 821 that has a restricted syntax. One answer to this might be for IPv6 to use a new SMTP, on a new port, that would avoid breaking these old implementations. Also, I wonder what happens if someone tries to send email to a valid multicast address..... Errors I hope, TCP shouldn't be attempting to connect to multicast addresses. Again, I think the capability in email to type in an IP address [in TO or FROM fields] is a bad idea. Unfortunately, not. Its almost essential. I do DNS delegations for people, they send me requests by e-mail, from their undelegated names. If all is OK, their delegation gets done, their name is visible, and everything works. But if anything is wrong, being able to send them mail, to their address, really is handy. I for one use this at least once a month. Incidentally, one solution suggested, which may placate those whose parsers might break because of the ':' would be to prohibit domain-literals (or IPv6 domain literals) in the leading route of a route-addr. That I would have no problem with. The parser problem they have, is (seems to me to be) that they want to obey 1123, and delete the route part of a route addr. They do that by simply deleting all from the leading '@', up to, and including, the first ':'. In a normal IPv4 route-addr (with or without domain-literals) this works fine (assuming the address is correctly formed, which is what the first paragraph in that message I forwarded was about - without context that must have seemed a bit meaningless). But if the address is of the form <@[0::1.2.3.4]:user@domain> that strategy breaks badly, leaving <:1.2.3.4]:user@domain> which is not very useful... My fundamental problem is, however, the "that's their problem" attitude, along with "I'll wait till its finished, then object" which I thought was pretty disgusting - I just wanted to let the IPng people, which seems to have a very small intersect with DRUMS know what was brewing. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 5 16:51:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18642; Mon, 5 Jun 95 16:51:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18603; Mon, 5 Jun 95 16:45:30 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23397; Mon, 5 Jun 1995 16:36:03 -0700 Received: from rodan.UU.NET by mercury.Sun.COM (Sun.COM) id QAA11468; Mon, 5 Jun 1995 16:36:03 -0700 Received: by rodan.UU.NET id QQyswk11320; Mon, 5 Jun 1995 19:36:01 -0400 Message-Id: To: perry@imsi.com Cc: hinden@Ipsilon.COM (Bob Hinden), ipng@sunroof.Eng.Sun.COM From: "Louis A. Mamakos" Subject: (IPng 166) Re: Re: Re: IPv6 address notation In-Reply-To: Your message of "Mon, 05 Jun 1995 18:54:18 EDT." <9506052254.AA27955@snark.imsi.com> Date: Mon, 05 Jun 1995 19:36:00 -0400 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > The proposal I'd like to make, which I've already made to the DRUMS > mailing list, is that mail to absolute addresses take the form of > domain names in the .ip6.int domain. It has the advantage of allowing > MXes to permit mailing to such addresses on the IPv4 side of the > fence. Its sick, but it would preserve the functionality without > forcing a change in syntax for the IPv6 people or a change in syntax > for the mail folks, and it would address an important backwards > compatibility problem. This works now if you configuration your sendmail or whatever correctly. My april fool's stunt year before last was MX and A records in 202.144.in-addr.arpa, and with a one line tweak in the MTA, it works just fine. louie ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 5 16:52:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18654; Mon, 5 Jun 95 16:52:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18648; Mon, 5 Jun 95 16:52:26 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24225; Mon, 5 Jun 1995 16:42:57 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id QAA12210; Mon, 5 Jun 1995 16:42:56 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13279; Tue, 6 Jun 1995 09:42:42 +1000 (from kre@munnari.OZ.AU) To: Alan.Lloyd@datacraft.com.au Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 167) Re: re: Re: neutral neurals In-Reply-To: Your message of "Tue, 06 Jun 1995 07:47:27 +1100." Date: Tue, 06 Jun 1995 09:42:37 +1000 Message-Id: <2269.802395757@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Tue, 6 Jun 95 7:47:27 +1100 From: Alan.Lloyd@datacraft.com.au Message-ID: the IP6 addr doc (hinden) describes that the LS end of the IP6 address can be 802. or E.164 but no indication of saying how one determines this. Because its at the LS end its a local matter - the decision is only needed when that part of the address is significant. I would assume that if your local net is based on 802.x then the local end will probably contain 802.x addresses, if its based upon something addressed with E.164, then that's what you would expect to find (can you really cram an E.164 addr in the available space? I guess so if there's no subnetting) If you really needed to for some reason, you could locally define a couple of bits to indicate what kind of addressing was in use, but I doubt anything you could buy would have support for that - the addressing will typically match the hardware. Given also there is a move in the ITU to incorporate TOA/NPI (type of address / numbering plan indicators (X.300, Q.2931/3 and X.25/121)) we seem to have a range of formats to contend with. If you want to put this stuff in the most significant end of the addresses, this is exactly what we don't want, and what makes nsap's so evil. This means that there are a whole bunch of parallel naming schemes, which to be useful, all have to be globally routed. this is nightmare territory. Even Brian Carpenter's messages on the NSAP address formats hint very strongly that though the address format will be defined, its unlikely that the addresses will actually be useful on a global scale, as no-one is likely to be carrying routing information for them (you'll be able to use them locally, for all the use that really is). kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 6 01:00:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18941; Tue, 6 Jun 95 01:00:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18933; Tue, 6 Jun 95 01:00:50 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26093; Tue, 6 Jun 1995 00:51:23 -0700 Received: from bells.cs.ucl.ac.uk by mercury.Sun.COM (Sun.COM) id AAA16840; Tue, 6 Jun 1995 00:51:21 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Jun 1995 08:49:38 +0100 To: Craig Partridge Cc: perry@imsi.com, hinden@Ipsilon.COM (Bob Hinden), ipng@sunroof.Eng.Sun.COM Subject: (IPng 168) Re: Re: Re: Re: IPv6 address notation In-Reply-To: Your message of "Mon, 05 Jun 95 16:19:22 PDT." <199506052319.QAA03347@aland.bbn.com> Date: Tue, 06 Jun 95 08:49:31 +0100 Message-Id: <541.802424971@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > The TCP stack should refuse to try to open a connection to a multicast > address, for this and many other reasons. > Hmmm... has anyone thought of that before, or is this old hat? >I thought it got fixed about 12 years ago. I remember a report of someone >accidentally telnetting to the local broadcast address around 1984 with >bizarre results. Craig it used to work quite neatly the first TCP listen to syn ack, got the connection - the problem is that the others started resetting things... zheng wang, ian wakeman and i wrote a proposal on how to make this (very limited and not terribly useful) form of multicast TCP actually work right....its been totally subsumed by RMP and Wb style reliable multicast work... cheers jon oh, that old proposal is on ftp://cs.ucl.ac.uk/darpa/tcp-multicast.lp ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 6 07:50:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19202; Tue, 6 Jun 95 07:50:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19196; Tue, 6 Jun 95 07:50:43 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14782; Tue, 6 Jun 1995 07:41:11 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id HAA11448; Tue, 6 Jun 1995 07:41:11 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14421(6)>; Tue, 6 Jun 1995 07:40:40 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 6 Jun 1995 07:40:25 -0700 To: Craig Partridge Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 169) Re: IPv6 address notation In-Reply-To: J.Crowcroft's message of Tue, 06 Jun 95 00:49:31 -0800. <541.802424971@cs.ucl.ac.uk> Date: Tue, 6 Jun 1995 07:40:25 PDT From: Steve Deering Message-Id: <95Jun6.074025pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Craig, > I thought it got fixed about 12 years ago. I remember a report of someone > accidentally telnetting to the local broadcast address around 1984 with > bizarre results. The way it got fixed, in BSD, was to prevent replying to a broadcast SYN packet, not to prevent sending a broadcast SYN packet. I didn't learn that until a couple years ago, when Ron Frederick telnetted to a multicast address and found to his amazement that a connection was successfully established -- the multicast group happened to have only one member at the time, and that member was sending back TCP packets with a multicast source address! So we looked through the TCP code, discovered the "if (IN_BROADCAST(addr))" test and changed it to "if (IN_BROADCAST(addr) || IN_MULTICAST(addr))" in the more recent multicast releases. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 6 09:25:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19299; Tue, 6 Jun 95 09:25:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19186; Tue, 6 Jun 95 07:38:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13830; Tue, 6 Jun 1995 07:28:40 -0700 Received: from po6.andrew.cmu.edu by mercury.Sun.COM (Sun.COM) id HAA09999; Tue, 6 Jun 1995 07:28:37 -0700 Received: (from postman@localhost) by po6.andrew.cmu.edu (8.6.12/8.6.12) id KAA05753 for ipng@sunroof.eng.sun.com; Tue, 6 Jun 1995 10:28:27 -0400 Received: via switchmail; Tue, 6 Jun 1995 10:28:22 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 6 Jun 1995 10:28:10 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 6 Jun 1995 10:28:08 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 6 Jun 1995 10:28:03 -0400 (EDT) Message-Id: Date: Tue, 6 Jun 1995 10:28:03 -0400 (EDT) From: John Gardiner Myers To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 170) Re: Re: Re: Re: IPv6 address notation In-Reply-To: <2266.802395344@munnari.OZ.AU> References: <2266.802395344@munnari.OZ.AU> Beak: is Not Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Robert Elz writes: > My fundamental problem is, however, the "that's their problem" > attitude, along with "I'll wait till its finished, then object" > which I thought was pretty disgusting - I just wanted to let > the IPng people, which seems to have a very small intersect with > DRUMS know what was brewing. The statement I was reacting to was one of the form "the IPng group is going to write an RFC to change the mail address syntax to make IPv6 addresses legal". That's not going to happen--such a move would be unlikely to get through public review, much less a Last Call. I'm not going to come to this group and say that IPng has to pick a different network address syntax because the colons would cause untold problems in mail addresses. The feedback I've given to the IPngers who've mentioned it in the mail groups is that the consequence of such a network address format is that it will not be usable verbatim in mail domain-literals. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 6 11:04:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19470; Tue, 6 Jun 95 11:04:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19464; Tue, 6 Jun 95 11:03:50 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10080; Tue, 6 Jun 1995 10:54:21 -0700 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id KAA13523; Tue, 6 Jun 1995 10:54:16 -0700 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 171) Re: Re: Re: Re: IPv6 address notation To: craig@aland.bbn.com (Craig Partridge) Date: Tue, 6 Jun 1995 18:40:16 +0100 (BST) Cc: perry@imsi.com, hinden@Ipsilon.COM, craig@aland.bbn.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: <199506052319.QAA03347@aland.bbn.com> from "Craig Partridge" at Jun 5, 95 04:19:22 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I thought it got fixed about 12 years ago. I remember a report of someone > accidentally telnetting to the local broadcast address around 1984 with > bizarre results. It is not fully fixed in any kernel I know. Try... ifconfig eth0 netmask 255.255.0.0 telnet x.y.1.255 ^Z ifconfig eth0 netmask 255.255.255.0 fg Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 6 19:11:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20046; Tue, 6 Jun 95 19:11:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20040; Tue, 6 Jun 95 19:11:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13938; Tue, 6 Jun 1995 19:02:15 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id TAA11865; Tue, 6 Jun 1995 19:02:14 -0700 Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA20780; Wed, 7 Jun 1995 12:01:55 +1000 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA23798; Wed, 7 Jun 95 11:41:08 +1000 Received: by dcthq2.datacraft.com.au; Wed, 7 Jun 95 12:15:16 +1100 Date: Wed, 7 Jun 95 12:04:57 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: kre@munnari.OZ.AU Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 172) re: Re: re: Re: neutral neurals X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk thanks robert, NSAPs are so evil with that AFI up the front, I even keep the sunlight constantly on my NSAP diagram in case it bites my neck! IP6 has a format prefix doesnt it, something similar to AFI codes. oh well! Has any one put any thought to how mobile IP6 devices will work over the telecom mobile net numbering plans (global roaming) and how IP/E.164 addresses are related, mapped, discovered, administered and published? Because I tend to think that there would be a demand for this. just a thought. regards alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 8 00:28:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20867; Thu, 8 Jun 95 00:28:00 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20861; Thu, 8 Jun 95 00:27:52 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id AAA01745; Thu, 8 Jun 1995 00:18:20 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id AAA17967; Thu, 8 Jun 1995 00:18:06 -0700 Date: Thu, 8 Jun 1995 00:18:06 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199506080718.AAA17967@bobo.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng 173) New Neighbor Discovery draft available Cc: nordmark@jurassic-248, narten@vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk A new revision of the protocol specified in the two documents , and has been developed under the supervision of the WG editor. The document is available as: ftp://playground.sun.com/pub/ipngwg/draft-ietf-ipngwg-discovery-00.txt It will be submitted as an I-D tomorrow morning (after some sleep) and also be made available as ftp://ftp.ipsilon.com/pub/ipng/draft-ietf-ipngwg-discovery-00.txt The document contains a fairly substantial OPEN ISSUES section which will serves as a starting point for discusions at next week's interim WG meeting. Please send comments to either ipng@sunroof.eng.sun.com or both nordmark@eng.sun.com and narten@vnet.ibm.com. Erik & Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 8 08:54:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21045; Thu, 8 Jun 95 08:54:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21039; Thu, 8 Jun 95 08:54:16 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27766; Thu, 8 Jun 1995 08:44:37 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id IAA25283; Thu, 8 Jun 1995 08:44:35 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id IAA09466; Thu, 8 Jun 1995 08:43:18 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Jun 1995 08:44:57 -0700 To: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 174) Re: New Neighbor Discovery draft available Cc: ipng@sunroof.Eng.Sun.COM, nordmark@jurassic-248.Eng.Sun.COM, narten@vnet.ibm.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >It will be submitted as an I-D tomorrow morning (after some sleep) >and also be made available as > ftp://ftp.ipsilon.com/pub/ipng/draft-ietf-ipngwg-discovery-00.txt It is now available at ftp.ipsilon.com. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 8 11:43:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21184; Thu, 8 Jun 95 11:43:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21178; Thu, 8 Jun 95 11:43:28 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22633; Thu, 8 Jun 1995 11:33:51 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id LAA25431; Thu, 8 Jun 1995 11:33:41 -0700 From: conta@zk3.dec.com Received: from fwasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA01839; Thu, 8 Jun 1995 14:33:29 -0400 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA20037; Thu, 8 Jun 1995 14:31:51 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/24Apr95-0109PM) id AA07256; Thu, 8 Jun 1995 14:30:20 -0400 Message-Id: <9506081830.AA07256@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 175) ICMPv6 (IPv6 ICMP) draft available Cc: deering@parc.xerox.com, conta@zk3.dec.com Date: Thu, 08 Jun 95 14:30:19 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk An updated revision of the ICMPv6 (IPv6 ICMP) specifications has been submitted as an I-D: draft-ietf-ipngwg-icmp-02.txt The document is also made iavailable after midnight today as: ftp://gatekeeper.dec.com/pub/DEC/IPv6/draft-ietf-ipngwg-icmp-02.txt Please send comments to either ipng@sunroof.eng.sun.com or both conta@zk3.dec.com, and deering@parc.xerox.com Thanks, Alex & Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 8 11:56:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21199; Thu, 8 Jun 95 11:56:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21193; Thu, 8 Jun 95 11:56:04 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AC24419; Thu, 8 Jun 1995 11:46:33 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id LAA27380; Thu, 8 Jun 1995 11:46:30 -0700 From: conta@zk3.dec.com Received: from fwasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA02632; Thu, 8 Jun 1995 14:46:23 -0400 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA27003; Thu, 8 Jun 1995 14:46:20 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/24Apr95-0109PM) id AA07325; Thu, 8 Jun 1995 14:46:00 -0400 Message-Id: <9506081846.AA07325@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 176) addendum to ICMPv6 (IPv6 ICMP) draft announcement Cc: deering@parc.xerox.com, conta@zk3.dec.com Date: Thu, 08 Jun 95 14:46:00 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The updated revision of the ICMPv6 (IPv6 ICMP) specifications which has been submitted as an I-D: draft-ietf-ipngwg-icmp-02.txt has the text that it has been agreed on at the 32th IETF IPngwg meeting in Danvers MA (April 1995). Additionally the draft has a merging of two paragraphs (b. and c.) in section "Message Source Address Determination" and a replacing of the "Region Address" term with "Anycast address" in the same section. The document is also made available after midnight as: ftp://gatekeeper.dec.com/pub/DEC/IPv6/draft-ietf-ipngwg-icmp-02.txt Thanks, Alex & Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 8 12:53:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21250; Thu, 8 Jun 95 12:53:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21244; Thu, 8 Jun 95 12:53:20 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02001; Thu, 8 Jun 1995 12:43:51 -0700 Received: from watson.ibm.com by mercury.Sun.COM (Sun.COM) id MAA05074; Thu, 8 Jun 1995 12:43:48 -0700 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4651; Thu, 08 Jun 95 15:43:02 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 3139; Thu, 8 Jun 1995 15:43:02 EDT Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Thu, 08 Jun 95 15:43:02 EDT Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA52207; Thu, 8 Jun 1995 15:43:00 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9506081943.AA52207@hawpub1.watson.ibm.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 177) draft-perkins-ipv6-mobility-sup-01.txt Date: Thu, 08 Jun 95 15:43:00 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I am submitting the abovementioned draft to the Internet Drafts directory tomorrow. However, it is available today from software.watson.ibm.com, in directory pub/mobile-ip. I'm sending this notice out so that people will have more time to look it over for next week. I hope to be able to make a short presentation about the proposal, and answer questions. If I do make any changes before submitting it tomorrow, it will only be to correct spelling or typographical errors. Overall, the differences between the new draft, and the translated IPv4 --> IPv6 draft I sent in earlier, are as follows: - We propose the use of routing headers instead of encapsulation for common traffic destined to a mobile node, since the problems with loose source routing in IPv4 are no longer present in IPv6 - We build upon the commonality between IPv4 registration and route optimization protocols to permit a cleaner and smaller mechanism for accomplishing the same things - We emphasize the need for distributing bindings to the entities that need them, in order to reduce drastically the role of the home agent in handling traffic destined for the mobile node - We build on the expected capability for mobile nodes to receive datagrams at several IPv6 addresses, to suggest the reduced need for foreign agents in some common circumstances. Thanks in advance, Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 8 21:25:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21586; Thu, 8 Jun 95 21:25:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21580; Thu, 8 Jun 95 21:25:14 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23205; Thu, 8 Jun 1995 21:15:43 -0700 Received: from inet-gw-1.pa.dec.com by mercury.Sun.COM (Sun.COM) id VAA27637; Thu, 8 Jun 1995 21:15:44 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA06357; Thu, 8 Jun 95 21:11:10 -0700 Received: by xirtlu.zk3.dec.com; id AA23750; Fri, 9 Jun 1995 00:11:02 -0400 Message-Id: <9506090411.AA23750@xirtlu.zk3.dec.com> To: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Cc: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Subject: (IPng 178) Re: New Neighbor Discovery draft available In-Reply-To: Your message of "Thu, 08 Jun 95 00:18:06 PDT." <199506080718.AAA17967@bobo.Eng.Sun.COM> Date: Fri, 09 Jun 95 00:10:56 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Eric/Tom/Bill, Looks really much more clearer. Lots of spec to read though prior to next week? But here is some initial input. I think a bit of liberty was taken to define how things are done without enough words stating this is opinion and theory, which was done in some places. The point is stating the standard is good but telling us how we implement it with MUSTs is unacceptable to challenge implementors to be creative across many platforms to implement ND for IPv6. I am sure others will flush this out quickly. > address - an IPv6-layer identifier for an interface or a set of > interfaces. When we permitted this in the IPng WG we were very careful to make sure that when the implementation passes an address to the application it is only for one interface. Hence, if multiple interfaces are provided for one address lets state clearly that the IPv6-layer identifier or address must present only 1 logical interface for an address. I think this terminology definition needs more words to that fact. This is what was agreed to in San Jose Dec 1994. > anycast address > - an identifier for a set of interfaces (typically > belonging to different nodes). A packet sent to an > anycast address is delivered to one of the interfaces > identified by that address (the "nearest" one, > according to the routing protocols' measure of > distance). See [ADDR-ARCH]. I think as I read this we need to put a health warning on anycast addresses that they may be off-link which for some applications is not good who assume responses to link-local addresses will work. > Inbound load balancing - Nodes with replicated interfaces may want > to load balance the reception of incoming packets across > multiple network interfaces on the same link. Routers may > omit the source link-layer address from Router Advertisement > packets, forcing neighbors to use Neighbor Solicitation > messages to learn the link-layer addresses. Returned Neighbor > Advertisement messages can then contain different link-layer > addresses dependent on who issued the query. Not sure this is clear but it appears we are talking again about an anycast address? But in IPv6 you can not use the same address for two interfaces on one node, has that been broken above. > variable MTU - Neighbor Discovery allows the routers to specify a > MTU for the link. This allows all nodes to use the > same MTU. Note: It is not possible to have each > node use a different MTU (or Maximum Receive Unit) > due to multicast. Then I think the router should have a message to determine the MTU of the link based on host suggestions. Classic case is Image Processing where one may want to use 8K MTU and MRU. If the router is going to determine this or suggest it then give it the means to ask hosts about the MTU they want to use on the link automatically as opposed to it being manual determined by sys admin folks. They will appreciate it. This would mean we have an MTU/MRU extension for ND. Probably could be used for many protocols too. It would be a nice network tool for sys admins. >Address Autoconfiguration information is also logically separate from >Router Discovery. To reduce network traffic, however, autoconfiguration >information is piggybacked on Router Discovery messages. This document >does not define how autoconfiguration information is processed. See >[ADDRCONF] for details. Not a very good argument for overloading Autoconfig with ND but I will take this to addr conf. If this argument is valid in our IPv6 thinking then many other arguments would have been won by the savings of 1 or even 2 packets in some other ND suggestions in the past year. I suggest not using this argument or you let us use it in other places as a precedent. > Authentication Header > If a security association exists between the sender > and the destination the sender SHOULD include this > header. The message only enters the IPv6 layer. How is it determined whether there is a security association and in what spec is that defined so it can be known by the IPv6 layer? Also the IPv6 layer or internetwork layer cannot be guranteed to do anything in a standard unless we specify it clearly. What if the user is not using authentication and gets an authentication payload in the ND packet? What should happen? Destination Ureachable? > MTU SHOULD be sent on links that do not have a well- > defined MTU. MAY be sent on links with a well- > defined, standard MTU. How does the router know the link has a well defined MTU? > - if the message includes an Authentication Header, the message is > correctly authenticated. As of when did authentication get into ND? This has never been the case and there should have been WG discussion on this and there will be for sure. >scanned for valid extensions. If the advertisement contains a source >link-layer address extension the link-layer address MUST be recorded in >the Neighbor Cache entry for the router and the "is_router" flag in the >Neighbor Cache entry be set to true. This flag is used by Neighbor >Unreachability Detection to determine when a router changes to being a >host (i.e. no longer capable of forwarding packets). This is implementation defined "how we implement" flags etc. Just state the function to be completed for interoperability and not How to Do it. OK to put more words that say "it could be done this way". It was only stated in one section and either we need a statement up front in the spec or in each place where implementations details are specified as opposed to what the standard is for interoperability. Another example was referring to its in this queue and moved out of this queue etc. Who knows at this point maybe its better off on a ring using queue/dequeue or some bright programmer figured out a nifty red/black or AVL tree or even a RADIX tree. Point is to be careful to not make it seem that the spec is defining the implementation. Only the standard to achieve interoperability. Its up to implementors to make that work and not authors of specs. No issue with suggestions but make them that or put them in an appendix. >It MUST be possible for the system administrator to configure a node to >ignore any Neighbor Discovery messages that are not authenticated using >either the Authentication Header or Encapsulating Security Payload. The >configuration technique for this MUST be documented. Make the above a SHOULD and I am being generous with a SHOULD and it should be a MAY. MOST LANS are not connected to any Internet at all. They are totally isolated. Do not regulate security in ND IPng. And again this was never discussed in any WG meeting. There were issues of securing ICMP and that is most likely a valid technical discussion but not by authenticating at the IP layer there is no way to do key management without going up to the transport and above layer that is efficient and fast. There are ways to do this but they are not specified in any spec I am familiar with so far. Good Job more later, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 9 02:17:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21716; Fri, 9 Jun 95 02:17:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21710; Fri, 9 Jun 95 02:17:20 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03437; Fri, 9 Jun 1995 02:07:50 -0700 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id CAA13253; Fri, 9 Jun 1995 02:07:47 -0700 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA09389; Fri, 9 Jun 1995 11:07:43 +0200 Received: by dxcoms.cern.ch id AA09245; Fri, 9 Jun 1995 11:07:40 +0200 Message-Id: <9506090907.AA09245@dxcoms.cern.ch> Subject: (IPng 179) RFC 821 syntax To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Fri, 9 Jun 1995 11:07:40 +0200 (MET DST) From: "Brian Carpenter CERN-CN" X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In the RFC821 syntax an address literal ( in the BNF) can only occur inside square brackets, where the ":" could not be confused with the ":" in a return-path. Unless the syntax checker is very deeply broken. Brian >--------- Text sent by Mail Delivery Subsystem follows: > From MAILER-DAEMON Fri Jun 9 11:00:57 1995 > X-Delivered: at request of brian on dxcoms.cern.ch > Date: Fri, 9 Jun 1995 11:00:57 +0200 > From: MAILER-DAEMON (Mail Delivery Subsystem) > Subject: Returned mail: Host unknown > To: brian > > ----- Transcript of session follows ----- > 554 brian@[::128.141.201.96]... Invalid numeric domain spec "[::128.141.201.96]" > 550 [::128.141.201.96] (tcp)... 550 Host unknown > 550 brian@[::128.141.201.96]... Host unknown > > ----- Unsent message follows ----- > Subject: test > To: brian@[::128.141.201.96] > Date: Fri, 9 Jun 1995 11:00:56 +0200 (MET DST) > From: "Brian Carpenter CERN-CN" > X-Mailer: ELM [version 2.4 PL23 DXCOMS1] > Mime-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Content-Length: 42 > > this is a test of rfc 821 syntax checking > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 9 09:32:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21857; Fri, 9 Jun 95 09:32:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21851; Fri, 9 Jun 95 09:32:28 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28490; Fri, 9 Jun 1995 09:22:54 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id JAA17550; Fri, 9 Jun 1995 09:22:54 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06042; 9 Jun 95 11:08 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US@mercury Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 180) I-D ACTION:draft-ietf-ipngwg-discovery-00.txt Date: Fri, 09 Jun 95 11:08:15 -0400 Message-Id: <9506091108.aa06042@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Neighbor Discovery Author(s) : T. Narten, E. Nordmark, W. Simpson Filename : draft-ietf-ipngwg-discovery-00.txt Pages : 68 Date : 06/08/1995 This document specifies the Neighbor Discovery protocol for the IP Version 6 protocol. IPv6 nodes on a single link use Neighbor Discovery to discover each other's presence and to determine each other's link-layer addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-discovery-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-discovery-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-discovery-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: <19950608141847.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-discovery-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-discovery-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950608141847.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jun 11 05:43:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22499; Sun, 11 Jun 95 05:43:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22493; Sun, 11 Jun 95 05:42:55 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20386; Sun, 11 Jun 1995 05:33:22 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id FAA12102; Sun, 11 Jun 1995 05:33:18 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Sun, 11 Jun 1995 21:30:34 +0900 From: Masataka Ohta Message-Id: <199506111230.VAA00587@necom830.cc.titech.ac.jp> Subject: (IPng 181) Provider-based and/or Geographical Addressing To: ipng@sunroof2.Eng.Sun.COM Date: Sun, 11 Jun 95 21:30:32 JST X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Before the interim meeting, I'd like to explain on my idea on addressing architecture. For hierarchical, that is, scalable, routing, we, obviously, need an IPv6 addressing format of . For provider-based addressing, must be able to identify a provider. Without provider-based addressing, we need inter-provider exchange points in every region with the same . On the other hand, for geographical addressing, must be able to identify a small geographical region. Without geographical addressing, to prevent provider lock-in, we need inter-provider exchange points in every geographically small region. The geographical optimal routing is important to suppress wiring cost, which is important for the global scalability of the Internet. So, what we need is a provider-based geographical addressing. And, if can identify both providers and geographical region, we can have a provider-based geographical addressing architecture. Now, the problem is that, if we have a lot of providers, must have internal provider based structure. Or, if we have a lot of geographically small regions, must have internal geographical structure. Then, as the provider hierarchy and geographical hierarchy is not compatible, we can't have a provider-based geographical addressing architecture. But, fortunately enough, to support the limited (e.g. 10**12~10**15) number of hosts for the limited number of world population (e.g. 10**11), which is bounded by the finite amount of resource of Earth, we don't need any provider nor geographical hierarchy. Considering that, we, even today with CIDR, have hundreds of thousands of top level addressing regions, a proposal and the analysis on a provider-based geographical addressing architecture in draft-ohta-ipv6-addr-arch-00.txt which only needs tens or, at most, hundreds of thousands of top level addressing regions should work well. Any counter arguments? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jun 11 06:07:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22532; Sun, 11 Jun 95 06:07:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22526; Sun, 11 Jun 95 06:06:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20664; Sun, 11 Jun 1995 05:57:19 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id FAA12556; Sun, 11 Jun 1995 05:57:09 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Sun, 11 Jun 1995 21:54:26 +0900 From: Masataka Ohta Message-Id: <199506111254.VAA00652@necom830.cc.titech.ac.jp> Subject: (IPng 182) Multicast addressing architecture To: ipng@sunroof2.Eng.Sun.COM Date: Sun, 11 Jun 95 21:54:24 JST X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk As I explained in the Danvers meeting, random allocation of IP addresses won't scale as the Internet-wide broadcast is necessary to confirm the global uniqueness or to map description of it's content to the Ip address. So, for unicast addressing, we have been using HOSTS.TXT or DNS. With DNS delegation mechanism we have uniqueness-assured scalable addressing space. Thus, there is no reason not to use DNS for multicast addressing. And, of course, DNS A record is directly usable for the name->address mapping. The problem is that, we need an Internet-wide, unique address->name mapping to assure uniqueness of addresses. For IPv4 unicasting, we have in-addr.arpa. delegation tree. But, for IPv4 multicasing, we have to delegate different subtree of in-addr.arpa. so that we need duplicated delegation. So, I'd like to propose that, we should 1) distinguish uni- and multi- cast addresses with the first few prefix bits of IPv6 addresses. 2) Make the size of uni- and multi- cast address spaces equal. 3) mask the prefix bits, for address->name mapping, so that uni- and multi- cast tree can share the same DNS space with a single delegation tree. It is a delegatees problem not to have uni- and multi- cast addresses with the identical non-prefix parts. As for the effect on draft-ietf-ipngwg-ipv6-addr-arch-00.txt, we should not make it: Allocation Prefix Fraction of (binary) Address Space ------------------------------- -------- ------------- Provider-Based Unicast Address 010 1/8 Multicast Addresses 1111 1111 1/256 but, for example, Allocation Prefix Fraction of (binary) Address Space ------------------------------- -------- ------------- Provider-Based Unicast Address 010 1/8 Multicast Addresses 110 1/8 and let 8000:0:1:2:3:4:5:6 and C000:0:1:2:3:4:5:6 share the same DNS leaf of: 6.5.4.3.2.1.0.0.ipv6.int. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jun 11 19:59:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22782; Sun, 11 Jun 95 19:59:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22776; Sun, 11 Jun 95 19:59:51 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06512; Sun, 11 Jun 1995 19:50:15 -0700 Received: from dylan.mindspring.com by mercury.Sun.COM (Sun.COM) id TAA09969; Sun, 11 Jun 1995 19:50:17 -0700 Received: from sthomas.mindspring.com [168.121.37.118] by dylan.mindspring.com with SMTP id WAA08138 for ; Sun, 11 Jun 1995 22:50:11 -0400 Message-Id: <199506120250.WAA08138@dylan.mindspring.com> X-Sender: sthomas@mindspring.com (Unverified) X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 11 Jun 1995 22:42:48 -0400 To: ipng@sunroof.Eng.Sun.COM From: sthomas@mindspring.com (Stephen Thomas) Subject: (IPng 183) Optional Upper Level Checksums and Authentication Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Gentle Readers: I hope I'm not resurrecting an issue that's already been covered. (If so, just tell me to shut up, and I will.) With IPv6, all upper level protocols are required to calculate a checksum. Yet, IPv6 now mandates support for authentication and security, both of which are (or certainly should be) stronger guarantees of message integrity than the checksum. Given that, it is worthwhile to consider allowing upper levels to omit the checksum (set it to zero) if authentication and/or ESP are in use? Both AH and ESP are going to be a noticeable hit in performance for systems that use them. Omitting the checksum would at least allow those systems to recover some of that performance. Thanks for listening. --Stephen ________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: s.thomas@acm.org ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jun 11 20:28:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22811; Sun, 11 Jun 95 20:28:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22805; Sun, 11 Jun 95 20:28:22 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07175; Sun, 11 Jun 1995 20:18:46 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id UAA10860; Sun, 11 Jun 1995 20:18:48 -0700 Received: from relay.imsi.com by wintermute.imsi.com id XAA29337; Sun, 11 Jun 1995 23:18:37 -0400 Received: from snark.imsi.com by relay.imsi.com id XAA24567; Sun, 11 Jun 1995 23:18:37 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA09814; Sun, 11 Jun 95 23:18:36 EDT Message-Id: <9506120318.AA09814@snark.imsi.com> To: sthomas@mindspring.com (Stephen Thomas) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 184) Re: Optional Upper Level Checksums and Authentication In-Reply-To: Your message of "Sun, 11 Jun 1995 22:42:48 EDT." <199506120250.WAA08138@dylan.mindspring.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sun, 11 Jun 1995 23:18:35 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Stephen Thomas writes: > I hope I'm not resurrecting an issue that's already been covered. > (If so, just tell me to shut up, and I will.) With IPv6, all > upper level protocols are required to calculate a checksum. Yet, > IPv6 now mandates support for authentication and security, both of > which are (or certainly should be) stronger guarantees of message > integrity than the checksum. > > Given that, it is worthwhile to consider allowing upper levels > to omit the checksum (set it to zero) if authentication and/or > ESP are in use? Both AH and ESP are going to be a noticeable hit > in performance for systems that use them. Omitting the checksum > would at least allow those systems to recover some of that performance. Given the orders of magnitude of the costs of the calculations, I think the performance gained by omitting checksums when AH is in use (negligible) isn't even remotely worth the large scale added complexity to the code that it would entail in typical implementations. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 12 02:26:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22945; Mon, 12 Jun 95 02:26:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22927; Mon, 12 Jun 95 02:26:24 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16236; Mon, 12 Jun 1995 02:16:49 -0700 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id CAA22228; Mon, 12 Jun 1995 02:16:45 -0700 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 185) Re: Multicast addressing architecture To: mohta@necom830.cc.titech.ac.jp (Masataka Ohta) Date: Mon, 12 Jun 1995 09:52:49 +0100 (BST) Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: <199506111254.VAA00652@necom830.cc.titech.ac.jp> from "Masataka Ohta" at Jun 11, 95 09:54:24 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > The problem is that, we need an Internet-wide, unique address->name > mapping to assure uniqueness of addresses. For multicast it only needs to be unique within its range. With the new address space that suggests allocation of addresses for specific services internet wide, and a block that is reused per organisational boundary. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 12 14:45:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23300; Mon, 12 Jun 95 14:45:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23294; Mon, 12 Jun 95 14:44:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26992; Mon, 12 Jun 1995 14:35:08 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id OAA14407; Mon, 12 Jun 1995 14:34:56 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03527; 12 Jun 95 17:29 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US@mercury Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 186) I-D ACTION:draft-ietf-ipngwg-icmp-02.txt Date: Mon, 12 Jun 95 17:29:22 -0400 Message-Id: <9506121729.aa03527@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-02.txt Pages : 20 Date : 06/09/1995 This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). The Internet Group Management Protocol (IGMP) messages specified in RFC-1112 have been merged into ICMP, for IPv6, and are included in this document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-icmp-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950609131716.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950609131716.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 12 23:08:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23481; Mon, 12 Jun 95 23:08:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23475; Mon, 12 Jun 95 23:08:50 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09135; Mon, 12 Jun 1995 22:59:12 -0700 Received: from aristo.tau.ac.il by mercury.Sun.COM (Sun.COM) id WAA17973; Mon, 12 Jun 1995 22:59:09 -0700 Received: from gandalf (world.lannet.com) by aristo.tau.ac.il with SMTP id AA10651 (5.67b/IDA-1.5 for ); Tue, 13 Jun 1995 08:58:55 +0300 Received: from moon.lannet.com by gandalf (4.1/SMI-4.1) id AA17904; Tue, 13 Jun 95 08:59:59 IDT Received: from smtplink.lannet.com by moon.lannet.com (4.1/SMI-4.1) id AA11667; Tue, 13 Jun 95 08:57:30 IDT Message-Id: <9506130557.AA11667@moon.lannet.com> From: LEONIDS@lannet.com (LEONID SHUSTERMAN) To: ipng@sunroof.Eng.Sun.COM (ipng) Subject: (IPng 187) IPng and routing protocols. Date: Tue, 13 Jun 95 08:26 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dear collegues, Forgive me if I rise an issue nobody is interested in. My question is about possible routing protocols to be used with future IP. It is well-known that shortest path protocols (like OSPF) are not terribly effective if a cost of a link is a dynamic measure of the link's load. Some researchers have shown that maximum flow routing protocols better suit dynamic routing. So I wonder if there are any plans to introduce more sophisticated routing protocols with the new IP. I will appreciate any comment on the matter. Leonid. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 13 18:53:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23912; Tue, 13 Jun 95 18:53:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23906; Tue, 13 Jun 95 18:53:51 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28554; Tue, 13 Jun 1995 18:44:13 -0700 Received: from ns.newbridge.com by mercury.Sun.COM (Sun.COM) id SAA00428; Tue, 13 Jun 1995 18:44:12 -0700 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id VAA02872; Tue, 13 Jun 1995 21:43:59 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma002868; Tue Jun 13 21:43:52 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id VAA21875; Tue, 13 Jun 1995 21:43:51 -0400 Received: by mako.us.Newbridge.com (4.1/SMI-4.0) id AA05464; Tue, 13 Jun 95 21:42:08 EDT From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9506140142.AA05464@mako.us.Newbridge.com> Subject: (IPng 188) Re: IPng and routing protocols. To: LEONIDS@lannet.com (LEONID SHUSTERMAN) Date: Tue, 13 Jun 1995 21:42:08 -0400 (EDT) Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9506130557.AA11667@moon.lannet.com> from "LEONID SHUSTERMAN" at Jun 13, 95 08:26:00 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > Dear collegues, > > Forgive me if I rise an issue nobody is interested in. My > question is about possible > routing protocols to be used with future IP. It is well-known that > shortest path protocols (like OSPF) > are not terribly effective if a cost of a link is a dynamic measure of > the link's load. Some researchers > have shown that maximum flow routing protocols better suit dynamic > routing. So I wonder if there > are any plans to introduce more sophisticated routing protocols with the > new IP. I will appreciate > any comment on the matter. > > Leonid. > I have copied Leonid's whole note above to provide clear context for this reply. The note evinces a mixture of elements of technologies which the IETF comminuty has experience with and has carefully kept separate. Dynamic, load sensitive, connectionless routing is indeed well known to be unstable when done using the kinds of technologies we deploy. In fact, various analysis show that in general such a problem, with any non-infinitesmal propagation time, is unstable. Techniques used in circuit switched networks rely on the fact that one is actually routing a bandwidth reservation based on other bandwidth reservations, not on the dynamically observed traffic. Now, as to what the IETF is doing: 1) We are enhancing most of our base, useful, routing protocols to be able to route IPv6. This does not imply any support for resource reservation, flows, or other enhancements. 2) We are, in the transport area, investigating/developing methods for communicating resource requirements (RSVP and IntServ). These developments are largely orthoganol to the IPng effort. 3) Also, orthoganolly, people are investigating routing techniques, based on link state and hierarchy, for handling resource reservations. Work in this area includes NIMROD and the ATM Forum I-PNNI (which is in preliminary investigation). Another way to put this is that we are doing to initially focus on getting what we understand to continue to work. Only then will new features actually be deployed. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 14 23:13:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24391; Wed, 14 Jun 95 23:13:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24385; Wed, 14 Jun 95 23:13:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05064; Wed, 14 Jun 1995 23:03:21 -0700 Received: from aristo.tau.ac.il by mercury.Sun.COM (Sun.COM) id XAA07471; Wed, 14 Jun 1995 23:03:20 -0700 Received: from gandalf (world.lannet.com) by aristo.tau.ac.il with SMTP id AA14768 (5.67b/IDA-1.5 for ); Thu, 15 Jun 1995 09:03:04 +0300 Received: from moon.lannet.com by gandalf (4.1/SMI-4.1) id AA22576; Thu, 15 Jun 95 09:04:07 IDT Received: from smtplink.lannet.com by moon.lannet.com (4.1/SMI-4.1) id AA08432; Thu, 15 Jun 95 09:01:39 IDT Message-Id: <9506150601.AA08432@moon.lannet.com> From: LEONIDS@lannet.com (LEONID SHUSTERMAN) To: jhalpern@newbridge.com (Joel Halpern) Cc: ipng@sunroof.Eng.Sun.COM (ipng) Subject: (IPng 189) Re: IPng and routing Date: Thu, 15 Jun 95 08:39 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >Another way to put this is that we are doing to initially focus on >getting what we understand to continue to work. Only then will new >features actually be deployed. Joel, You are right of course, things should be done in order. I just thought that potential ability to route connectionless traffic optimaly is a great advantage of IP and its like. If we do not use this potential native ATM (without any IP) seems to be more attractive. Regards, Leonid. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 15 15:00:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24997; Thu, 15 Jun 95 15:00:48 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24991; Thu, 15 Jun 95 15:00:39 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id OAA12989; Thu, 15 Jun 1995 14:50:58 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id OAA26760; Thu, 15 Jun 1995 14:50:43 -0700 Date: Thu, 15 Jun 1995 14:50:43 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199506152150.OAA26760@bobo.Eng.Sun.COM> To: ipng@sunroof, RLFink@lbl.gov Subject: (IPng 190) Neighbor Discovery slides from WG meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I've made the Neighbor Discovery slides that were used at this weeks interim WG meeting available as ftp://playground.sun.com/pub/ipngwg/nd-slides.ps The slides more or less follow the flow of the internet draft. Erik (& Thomas) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 16 11:17:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25511; Fri, 16 Jun 95 11:17:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25505; Fri, 16 Jun 95 11:17:39 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17419; Fri, 16 Jun 1995 11:07:57 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id LAA01440; Fri, 16 Jun 1995 11:07:59 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id LAA09683 for ; Fri, 16 Jun 1995 11:07:06 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Jun 1995 11:08:49 -0700 To: ipng@sunroof.Eng.Sun.COM From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 191) [The IESG: Last Call: Security Architecture for the Internet Protocol to Proposed Standard] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk FYI >Date: Fri, 16 Jun 1995 13:14:01 -0400 >From: The IESG >To: IETF-Announce: ; >cc: ipsec@ans.net >Subject: Last Call: Security Architecture for the Internet Protocol to Proposed > Standard > > >The IESG has received a request from the IP Security Protocol Working Group >to consider the followingt documents for the status of Proposed Standard: > >1. Security Architecture for the Internet Protocol > >2. IP Authentication Header >3. IP Encapsulating Security Payload (ESP) >4. IP Authentication using Keyed MD5 >5. The ESP DES-CBC Transform > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by >June 30, 1995. > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 16 18:42:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25737; Fri, 16 Jun 95 18:42:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25731; Fri, 16 Jun 95 18:42:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05880; Fri, 16 Jun 1995 18:33:06 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id SAA17797; Fri, 16 Jun 1995 18:33:07 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14730(3)>; Fri, 16 Jun 1995 18:32:53 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Fri, 16 Jun 1995 18:32:44 -0700 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng 192) IPv6 ethertype, multicast address mapping, etc. Date: Fri, 16 Jun 1995 18:32:30 PDT From: Steve Deering Message-Id: <95Jun16.183244pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk At the ipng working group meeting this week in Mountain View, we had a long discussion about the ethertype issue, and came (with much reluctance, for some of us) to the conclusion that we should indeed use a new ethertype for IPv6 to avoid causing problems for existing, IP-version-challenged devices. According to what Dimitry could learn about the ST-2 deployment experience, the troublesome devices were mostly not-exactly-IP devices, such as bridges and in-line packet encryptors that know just enough about IP to be dangerous. Much as we hated the idea of having to be backwards-compatible with devices that wantonly violated the IP specs, we realized that we would harm IPv6 deployment much more than we would harm the vendors of those braindamaged devices if we were to stand on principles, in this case. Also, the main reason we originally changed SIP from using its own ethertype to using IP's ethertype and a new IP version number was to make it possible to implement SIP without modifying the link-layer drivers to demultiplex on a new ethertype -- in the PC world, some IP stack vendors do not have access to the source code of the link-level drivers over which their stack operates. However, the PC world seems to have settled on some standard driver APIs, such as NDIS, that enable arbitrary new ethertypes to be supported without driver code modification, so it's likely this is not as serious a problem as we originally thought. SO, IPv6 will henceforth use ethertype 86DD (which was originally assigned to SIP by Xerox, the authority for assigning ethertypes) on all links for which IPv4 framing uses ethertype 0800, whether plain (as on Ethernet) or fancy (as on other media that use the gratuitous SNAP header). IPv6 continues to have a version field which all IPv6 implementations are required to test for equality to the value 6. Thus, if you have an integrated IPv4/v6 stack, you may have both ethertypes 0800 and 86DD demultiplex to the same piece of code, which then later uses the IP version field to demultiplex to v4 or v6. However, the alternative implementation is also permitted, where packets are demuxed by ethertype to separate v4 and v6 stacks. Therefore, IPv6 implementations MUST use ethertype 86DD when transmitting IPv6 packets over links that use ethertypes. One nasty consequence of this decision is that we really ought to obtain new code points to identify IPv6 on those media that do not use ethertypes, such as PPP and X.25. Would anyone like to volunteer to do the legwork associated with getting an official code-point assignment for one or more of those non-ethertype-using media? ---- On another Ethernet-related topic, we have never specified how IPv6 multicast addresses are to be mapped to Ethernet multicast addresses. I believe that some of the prototype IPv6 implementations are curently using the same mapping as IPv4, that is, replacing the low-order 23 bits of the ethernet address 01-00-5E-00-00-00 with the low-order 23 bits of the IP multicast address. It would be nice to use a slightly more efficient mapping for IPv6 (extracting 23 bits is sorta fiddly). I propose the following: replace the low-order 32 bits of the ethernet address 33-33-00-00-00-00 with the low-order 32 bits of the IPv6 multicast address. The 33-33- prefix has both the Group (Multicast) bit set and the Locally Administered bit set. (They are the lowest-order and second lowest-order bits, respectively, of the first octet, in the canonical address representation.) It would be more politically correct to use a Universally Administered prefix, but those are handed out by the IEEE at $1000 per 24-bit chunk, which would mean we'd have to pay a quarter of a million dollars to get 32 bits of ethernet multicast address space, even though almost all the the 46 bits of total ethernet multicast address space is unused and will never be used. If we instead use the locally- administered space, we don't have to pay anyone, but we run the hazard of colliding with some other local usage of that 33-33- prefix. I suspect that such collisions are highly improbable (I did check the database of known ethernet address usage maintained at MIT, and there was no known conflict recorded there), but if anyone knows of any existing use of that prefix, please speak up -- I'd like to settle this question before the end of the month. By the way, this mapping would apply to Ethernet and FDDI, but *not* to Token Ring, where most host adapters have insufficient multicast address filtering to deal with proper multicast addresses. Instead, on Token Rings, IPv6 multicast addresses would all be mapped to the single "functional" address already allocated to IP, that is 03-00-00-20-00-00 in canonical form (see RFC 1469, IP Multicast over Token-Ring LANs). ---- Speaking of insufficient multicast address filtering, another issue we discussed at this week's ipng meeting was the problem that Geert Jan de Groot identified of inadequate PC ethernet interfaces. IPv6 depends on ethernet multicast, rather than ethernet broadcast, for basic functions like address resolution and router discovery. If I recall correctly, the problem was that some old ethernet cards for IBM PC compatibles can only choose to hear all multicasts or none. If IPv6 requires them to use multicast, then they will be vulnerable to reception of all multicast traffic, some of which (e.g., audio or video) might cause them to consume all their cycles discarding unwanted multicast in software. (The same problem would, of course, occur if anyone used the broadcast address for high data rate traffic.) We talked about the possibility of requiring a configuration switch in all IPv6 implementations to map some applications' IPv6 multicasts (such as those of the Neighbor Discovery protocol) onto the ethernet broadcast address, while other (high data rate) applications would continue to map to ethernet multicast addresses, but the consensus was that that was just too complicated, and ultimately unworkable (the notion of what is a high data rate app is just too ill-defined). So we decided against such a configuration option. Existing IPv4 implementations on those PCs should not be bothered by the presence of IPv6 traffic on the same ethernets, as long as the PCs continue to disable multicast reception; adding IPv6 to those machines will require an upgrade of their ethernet interfaces (more likely, the machines will be thrown out in a few years anyway, and their replacements ought to be able to handle IPv6 just fine). ---- We need to add IP-over- specifications to the IPv6 document set, starting with IP-over-Ethernet, to cover the issues discussed above plus other link-specific issues, such as how IPv6 link-local addresses and statelessly-autoconfigured addresses are formed on each type of link. Volunteers to write such specifications are invited to get in touch with the chairs and the document editor (rcallon@baynetworks.com, deering@parc.xerox.com, hinden@ipsilon.com). This stuff isn't the only stuff we talked about at the meeting -- we spent most of the time going through the new Neighbor Discovery and Stateless Autoconf docs, plus an initial foray into mobility and alternate unicast addressing plans. Notes from the full meeting are in preparation. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Jun 17 02:06:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25923; Sat, 17 Jun 95 02:06:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25917; Sat, 17 Jun 95 02:06:39 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25404; Sat, 17 Jun 1995 01:56:59 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id BAA02779; Sat, 17 Jun 1995 01:56:55 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Sat, 17 Jun 1995 17:53:41 +0900 From: Masataka Ohta Message-Id: <199506170853.RAA22345@necom830.cc.titech.ac.jp> Subject: (IPng 193) Re: Re: Multicast addressing architecture To: iialan@iifeak.swan.ac.uk (Alan Cox) Date: Sat, 17 Jun 95 17:53:39 JST Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: ; from "Alan Cox" at Jun 12, 95 9:52 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > The problem is that, we need an Internet-wide, unique address->name > > mapping to assure uniqueness of addresses. Note, I said "address->name" mapping. > For multicast it only needs to be unique within its range. What is the "range"? Scalable multicast is intended to be support Internet-wide sparse multicast. For example, 1,000 or 10,000 receivers distributed all over the world. > With the new > address space that suggests allocation of addresses for specific services > internet wide, and a block that is reused per organisational boundary. I can't understand why organisational boundary is related to multicast. And, finally, how can you know the name of the multicast from its address without DNS address->name mapping? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 19 01:23:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26227; Mon, 19 Jun 95 01:23:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26221; Mon, 19 Jun 95 01:22:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22671; Mon, 19 Jun 1995 01:13:16 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id BAA27746; Mon, 19 Jun 1995 01:13:15 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15290(3)>; Mon, 19 Jun 1995 01:13:08 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 19 Jun 1995 01:12:59 -0700 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng 194) updated IPv6 base spec Date: Mon, 19 Jun 1995 01:12:52 PDT From: Steve Deering Message-Id: <95Jun19.011259pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I finally got around to updating the base IPv6 spec with the miscellaneous small changes agreed in Danvers. The updated version will appear shortly as in Internet Draft, and will be forwarded to the IESG with the working group chairs' recommendation that it become a Proposed Standard, as also agreed in Danvers. The list of changes from the previous draft is as follows: o Added a list of all required extension headers to the introduction to section 4. o Added the Encapsulating Security Payload (ESP) header to the recommended header order in section 4.1, with a pointer to the ESP specification for further discussion of ordering for ESP and Authentication headers. o Deleted description of the Authentication Header, to avoid redundancy and/or inconsistency with the separate document(s) that define that header, and updated the "Security Considerations" section accordingly. o Specified that the Length field in the Jumbo Payload option must be greater than 65,535, thus restricting the use of that option to only those packets that actually need it. Also pointed out that implementations that don't support the Jumbo Payload option cannot have interfaces to links with jumbo MTUs. o Changed the layout of the upper-layer checksum pseudo-header to allow for payload lengths greater than 65,535. o Fixed an off-by-one error in the algorithm for processing the Strict/Loose bit map in the Routing header. Bit number 0 now corresponds to the hop from the originator to the initial address in the Destination Address field, and the Routing header is limited to 23 addresses instead of 24. o Specified that the Destination Options Header is identified by a Next Header value of 60. o Changed mention of "region address" to "anycast address". o Changed "IPv6 nodes are expected to implement Path MTU Discovery..." to "It is strongly recomended that IPv6 nodes implement Path MTU Discovery...". o Deleted a reference to the IPv6 Transition Mechanisms spec. and updated several other references. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 19 01:34:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26239; Mon, 19 Jun 95 01:34:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26233; Mon, 19 Jun 95 01:34:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22996; Mon, 19 Jun 1995 01:25:05 -0700 Received: from mitsou.inria.fr by mercury.Sun.COM (Sun.COM) id BAA28303; Mon, 19 Jun 1995 01:25:03 -0700 Received: by mitsou.inria.fr (8.6.12/8.6.12) id KAA17530; Mon, 19 Jun 1995 10:24:15 +0200 Message-Id: <199506190824.KAA17530@mitsou.inria.fr> To: Steve Deering Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 195) The jumbogram option Date: Mon, 19 Jun 1995 10:24:14 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Steve, When reading the jumbogram part of the specs, I could not be sure on what value the jumbogram option would encode. Suppose the following packet: +----------+----------+---------.............--------+ | IPv6 |H/H(Jumbo)| many many many bytes of data | +----------+----------+---------.............--------+ <----- L1 = length of IPv6 payload ------> <----- L2 = H/H payload ------> If L1 was lower than 64K, we would not use the Hop by hop option, and the length L1 would be encoded in the main header. In a jumbogram, L1 is larger than 64K, we add an hop by hop option. If the h/H only contains the jumbogram length, it is encoded on 8 bytes and we have according to my disgram L1=100008 and L2 = 100000. Now, what value shall we encode in the jumbolength? 100000 or 100008? Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 19 02:34:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26328; Mon, 19 Jun 95 02:34:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26322; Mon, 19 Jun 95 02:34:28 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24437; Mon, 19 Jun 1995 02:24:41 -0700 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id CAA00728; Mon, 19 Jun 1995 02:24:31 -0700 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 196) Re: IPv6 ethertype, multicast address mapping, etc. To: deering@parc.xerox.com (Steve Deering) Date: Mon, 19 Jun 1995 10:12:42 +0100 (BST) Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com In-Reply-To: <95Jun16.183244pdt.75270@digit.parc.xerox.com> from "Steve Deering" at Jun 16, 95 06:32:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > like address resolution and router discovery. If I recall correctly, the > problem was that some old ethernet cards for IBM PC compatibles can only > choose to hear all multicasts or none. If IPv6 requires them to use And also some of the newest ones. The filtering on cards like the 3c509 is 'not brilliant'. > multicast, then they will be vulnerable to reception of all multicast > traffic, some of which (e.g., audio or video) might cause them to consume > all their cycles discarding unwanted multicast in software. (The same > problem would, of course, occur if anyone used the broadcast address for > high data rate traffic.) Which for those who have experienced broadcast storms should be adequate reason. > a configuration option. Existing IPv4 implementations on those PCs should > not be bothered by the presence of IPv6 traffic on the same ethernets, > as long as the PCs continue to disable multicast reception; adding IPv6 > to those machines will require an upgrade of their ethernet interfaces > (more likely, the machines will be thrown out in a few years anyway, > and their replacements ought to be able to handle IPv6 just fine). Alas not. In the drive for single chip NIC controllers PC hardware is going down two roads. Firstly hash based solutions secondly multicast as a yes/no. A hash based solution is no help either in all cases unless there is a standard hash (which is actually pretty true), and the allocation of multicast addresses and choice of mapping to MAC multicast is such that high bandwidth service hits specific hash buckets. In addition IPv6 has address space for everything and I don't want my light switches having to cope with a video feed. I offer an alternative idea. Let embedded controllers and other small end hosts that have this potential problem is to permit them to proxy for their multicast reception needs and have a gateway host willing to convert their multicast receives into host specific copies. This shouldnt cause problems as the proxy can avoid loops by never sending proxy frames to the source address on the packet. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 19 02:46:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26348; Mon, 19 Jun 95 02:46:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26342; Mon, 19 Jun 95 02:46:11 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24759; Mon, 19 Jun 1995 02:36:20 -0700 Received: from mitsou.inria.fr by mercury.Sun.COM (Sun.COM) id CAA01287; Mon, 19 Jun 1995 02:36:18 -0700 Received: by mitsou.inria.fr (8.6.12/8.6.12) id LAA17706; Mon, 19 Jun 1995 11:36:07 +0200 Message-Id: <199506190936.LAA17706@mitsou.inria.fr> To: iialan@iifeak.swan.ac.uk (Alan Cox) Cc: deering@parc.xerox.com (Steve Deering), ipng@sunroof.Eng.Sun.COM Subject: (IPng 197) Re: Re: IPv6 ethertype, multicast address mapping, etc. In-Reply-To: Your message of "Mon, 19 Jun 1995 10:12:42 BST." Date: Mon, 19 Jun 1995 11:36:06 +0200 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > The filtering on cards like the 3c509 > is 'not brilliant'. OK. Last time I checked, the "not brillant" filtering was based on some hash algorithm. Is there any way we could check that the multicast address which we allocate are "well behaved" according to this algorithm? For example, could we check that the hash signatures of the "well known" multicast addresses are disjoint from those of "short lived" multicast groups? Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 19 04:54:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26384; Mon, 19 Jun 95 04:54:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26378; Mon, 19 Jun 95 04:53:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27208; Mon, 19 Jun 1995 04:44:04 -0700 Received: from rodan.UU.NET by mercury.Sun.COM (Sun.COM) id EAA06541; Mon, 19 Jun 1995 04:44:04 -0700 Received: by rodan.UU.NET id QQyuug23318; Mon, 19 Jun 1995 07:43:14 -0400 Message-Id: To: iialan@iiit.swan.ac.uk (Alan Cox) Cc: deering@parc.xerox.com (Steve Deering), ipng@sunroof.Eng.Sun.COM From: "Louis A. Mamakos" Subject: (IPng 198) Re: Re: IPv6 ethertype, multicast address mapping, etc. In-Reply-To: Your message of "Mon, 19 Jun 1995 10:12:42 BST." Date: Mon, 19 Jun 1995 07:43:14 -0400 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > In addition IPv6 has address space for everything and I don't want my > light switches having to cope with a video feed. Don't put a multicast router on your light-switch-net? If the light-switch-net media had adequate bandwidth to support a multicast video feed, it's likely that the network interface in the light switch would reasonably support multicast filtering. louie ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 19 05:35:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26412; Mon, 19 Jun 95 05:35:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26406; Mon, 19 Jun 95 05:35:34 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28314; Mon, 19 Jun 1995 05:25:50 -0700 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id FAA08703; Mon, 19 Jun 1995 05:25:48 -0700 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 199) Re: Re: Re: IPv6 ethertype, multicast address mapping, etc. To: louie@uu.net (Louis A. Mamakos) Date: Mon, 19 Jun 1995 13:14:01 +0100 (BST) Cc: iialan@iiit.swan.ac.uk, deering@parc.xerox.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: from "Louis A. Mamakos" at Jun 19, 95 07:43:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Don't put a multicast router on your light-switch-net? If the > light-switch-net media had adequate bandwidth to support a multicast > video feed, it's likely that the network interface in the light switch > would reasonably support multicast filtering. That I seriously question. Its certainly not true of cheap and nasty single chip ethernet controllers. It was meant as an example. More conrete examples are factory floor where both dumb controllers and multicast video could do with sharing the same bus. We can either have poorer citizens with no multicast and force things like ARP , DHCP, Router discovery to be forever broadcast, or fix the problem from the start. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 19 07:48:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26459; Mon, 19 Jun 95 07:48:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26453; Mon, 19 Jun 95 07:48:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04903; Mon, 19 Jun 1995 07:38:15 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id HAA20348; Mon, 19 Jun 1995 07:38:16 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14976(5)>; Mon, 19 Jun 1995 07:37:56 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 19 Jun 1995 07:37:43 -0700 To: Christian Huitema Cc: iialan@iifeak.swan.ac.uk (Alan Cox), ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 200) Re: Re: IPv6 ethertype, multicast address mapping, etc. In-Reply-To: Christian.Huitema's message of Mon, 19 Jun 95 02:36:06 -0800. <199506190936.LAA17706@mitsou.inria.fr> Date: Mon, 19 Jun 1995 07:37:42 PDT From: Steve Deering Message-Id: <95Jun19.073743pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > OK. Last time I checked, the "not brillant" filtering was based on some > hash algorithm. Is there any way we could check that the multicast address > which we allocate are "well behaved" according to this algorithm? Different chips use different hash algorithms -- trying to avoid collisions on all of them is hopeless. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 19 07:53:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26471; Mon, 19 Jun 95 07:53:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26465; Mon, 19 Jun 95 07:53:17 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05291; Mon, 19 Jun 1995 07:43:32 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id HAA20961; Mon, 19 Jun 1995 07:43:32 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14914(6)>; Mon, 19 Jun 1995 07:43:16 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 19 Jun 1995 07:43:06 -0700 To: ipng@sunroof.Eng.Sun.COM Cc: Christian Huitema , deering@parc.xerox.com Subject: (IPng 201) Re: The jumbogram option In-Reply-To: Christian.Huitema's message of Mon, 19 Jun 95 01:24:14 -0800. <199506190824.KAA17530@mitsou.inria.fr> Date: Mon, 19 Jun 1995 07:43:00 PDT From: Steve Deering Message-Id: <95Jun19.074306pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > When reading the jumbogram part of the specs, I could not be sure on what > value the jumbogram option would encode. Suppose the following packet: >From the spec (previous version as well as new version): The Jumbo Payload Length is the length of the packet in octets, excluding the IPv6 header. That is, L1 in your example. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 19 09:19:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26538; Mon, 19 Jun 95 09:19:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25463; Fri, 16 Jun 95 07:28:07 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20529; Fri, 16 Jun 1995 07:18:26 -0700 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id HAA27275; Fri, 16 Jun 1995 07:18:19 -0700 Subject: (IPng 202) Am I a router or host if... To: IPng Mailing list Date: Fri, 16 Jun 1995 10:18:15 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9506161518.aa13734@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Silly question, and I can't find the answer in the archives. A HOST cannot forward packets not explicitly addressed for yourself. That's clear when the IPv6 header's destination field value is not one of my addresses. If that is true, I drop the packet. If the IPv6 header destination field is one of my addresses, but then there is a source routing header which has someone else as the FINAL destination, must I as a host forward the packet? Or do I drop the packet because I'm a host, not a router? I know this question has been asked before. I cannot remember the answer. As with all source-routing issues, there is security to consider. (Source routing attacks exist!) Thanks for your answers! Dan McD. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 19 09:58:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26673; Mon, 19 Jun 95 09:58:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26667; Mon, 19 Jun 95 09:58:16 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18431; Mon, 19 Jun 1995 09:48:30 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id JAA06322; Mon, 19 Jun 1995 09:48:31 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id JAA17212; Mon, 19 Jun 1995 09:47:35 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Jun 1995 09:49:21 -0700 To: Dan McDonald From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 203) Re: Am I a router or host if... Cc: IPng Mailing list Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dan, >A HOST cannot forward packets not explicitly addressed for yourself. That's >clear when the IPv6 header's destination field value is not one of my >addresses. If that is true, I drop the packet. > >If the IPv6 header destination field is one of my addresses, but then there >is a source routing header which has someone else as the FINAL destination, >must I as a host forward the packet? Or do I drop the packet because I'm a >host, not a router? I think in this case, the host should drop the packet. >As with all source-routing issues, there is security to consider. (Source >routing attacks exist!) > As with "everything", there is security to consider :-) Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 01:47:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28660; Tue, 20 Jun 95 01:47:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28654; Tue, 20 Jun 95 01:47:47 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23104; Tue, 20 Jun 1995 01:38:02 -0700 Received: from ns1.digital.fr by mercury.Sun.COM (Sun.COM) id BAA15693; Tue, 20 Jun 1995 01:37:58 -0700 Received: by inet-gw-1.digital.fr (5.65/VBE-jep-20mar95) id AA11496; Tue, 20 Jun 95 10:38:27 +0200 Received: from nestvx.enet by vbormc.vbo.dec.com (5.65/rmc-umc-16jun95) id AA24421; Tue, 20 Jun 95 10:18:12 +0200 Message-Id: <9506200818.AA24421@vbormc.vbo.dec.com> Received: from nestvx.enet; by vbormc.enet; Tue, 20 Jun 95 10:18:14 MET DST Date: Tue, 20 Jun 95 10:18:14 MET DST From: Markus Jork To: deering@parc.xerox.com (steve deering) Cc: jork@nestvx.ENET.dec.com, ipng@sunroof.Eng.Sun.COM Apparently-To: ipng@sunroof.eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 204) Re: updated IPv6 base spec Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I just came across a minor point worth updating. The current spec says: > All packets belonging to the same flow must be sent with the same source > address, same destination address, and same non-zero flow label. [... more about Hop-by-Hop and Routing header ...] Shouldn't that read: "All packets belonging to the same flow must be sent with the same source address, same destination address, same priority field, and same non-zero flow label." It seems the above sentence was updated only half-way when the idea of a 28-bit flow ID was abandoned in favor of two always distinct priority and flow label fields. Or is there any reason not to include the priority field in the list of fixed fields for a flow? Markus ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 06:49:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28805; Tue, 20 Jun 95 06:49:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28799; Tue, 20 Jun 95 06:48:58 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB03421; Tue, 20 Jun 1995 06:39:12 -0700 Received: from calypso.urec.fr by mercury.Sun.COM (Sun.COM) id GAA03177; Tue, 20 Jun 1995 06:39:10 -0700 From: Bernard.Tuy@urec.fr Received: from ns.urec.fr by calypso.urec.fr (8.6.10/urec-1.0) with ESMTP; Tue, 20 Jun 1995 15:39:18 +0200 Received: by ns.urec.fr (8.6.9/urec-0.9); Tue, 20 Jun 1995 15:38:12 +0200 Date: Tue, 20 Jun 1995 15:38:12 +0200 Message-Id: <199506201338.PAA03531@ns.urec.fr> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 205) Re: Re: updated IPv6 base spec Cc: jla@imag.fr X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, I hope to write to the right list...otherwise please tell me -without flaming (I can't support shouting guys : =)> A colleague of mine is looking for someone able / willing ... to give a lecture at the Interop meeting in Paris (3rd week of september) on RSVP. I guess recents works, documentation (I-Drafts, RFC's ...) will have to be sum up for participating people. More details by Jean-Luc.Archimbaud@imag.fr (or simply jla@imag.fr). Thank you for your time, +Bernard Tuy. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 06:50:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28817; Tue, 20 Jun 95 06:50:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28811; Tue, 20 Jun 95 06:49:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03484; Tue, 20 Jun 1995 06:40:08 -0700 Received: from inet-gw-1.pa.dec.com by mercury.Sun.COM (Sun.COM) id GAA03256; Tue, 20 Jun 1995 06:40:06 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA21219; Tue, 20 Jun 95 06:33:39 -0700 Received: by xirtlu.zk3.dec.com; id AA22621; Tue, 20 Jun 1995 09:33:34 -0400 Message-Id: <9506201333.AA22621@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: sthomas@mindspring.com, bound@zk3.dec.com Subject: (IPng 206) Re: Re: Optional Upper Level Checksums and Authentication In-Reply-To: Your message of "Sun, 11 Jun 95 23:18:35 EDT." <9506120318.AA09814@snark.imsi.com> Date: Tue, 20 Jun 95 09:33:28 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk WG, From: "Perry E. Metzger" >Stephen Thomas writes: >> I hope I'm not resurrecting an issue that's already been covered. >> (If so, just tell me to shut up, and I will.) With IPv6, all >> upper level protocols are required to calculate a checksum. Yet, >> IPv6 now mandates support for authentication and security, both of >> which are (or certainly should be) stronger guarantees of message >> integrity than the checksum. >> >> Given that, it is worthwhile to consider allowing upper levels >> to omit the checksum (set it to zero) if authentication and/or >> ESP are in use? Both AH and ESP are going to be a noticeable hit >> in performance for systems that use them. Omitting the checksum >> would at least allow those systems to recover some of that performance. >Given the orders of magnitude of the costs of the calculations, I >think the performance gained by omitting checksums when AH is in use >(negligible) isn't even remotely worth the large scale added >complexity to the code that it would entail in typical >implementations. I think Stephen's idea is valid and it has not been discussed before. So IPv6 implementors can we discuss this. I agreed with Perry at first but then looking at the checksum routines a global could be set to by-pass them and there would be a performance gain. I have asked one of our check-sum wizards to look at what kind of gain as he has been able to really gain performance in IPv4 with our implementation of new checksum code years back. We are going to have some testing I hope at TCP/IP WORLD and we can test this real time to see the gain. Other comments? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 07:22:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28881; Tue, 20 Jun 95 07:22:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28875; Tue, 20 Jun 95 07:21:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05616; Tue, 20 Jun 1995 07:11:58 -0700 Received: from research.att.com by mercury.Sun.COM (Sun.COM) id HAA06470; Tue, 20 Jun 1995 07:11:59 -0700 From: smb@research.att.com Message-Id: <199506201411.HAA06470@mercury.Sun.COM> Received: by gryphon; Tue Jun 20 10:11:23 EDT 1995 To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, sthomas@mindspring.com Subject: (IPng 207) Re: Re: Re: Optional Upper Level Checksums and Authentication Date: Tue, 20 Jun 95 10:11:22 EDT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk WG, From: "Perry E. Metzger" >Stephen Thomas writes: >> I hope I'm not resurrecting an issue that's already been covered. >> (If so, just tell me to shut up, and I will.) With IPv6, all >> upper level protocols are required to calculate a checksum. Yet, >> IPv6 now mandates support for authentication and security, both of >> which are (or certainly should be) stronger guarantees of message >> integrity than the checksum. >> >> Given that, it is worthwhile to consider allowing upper levels >> to omit the checksum (set it to zero) if authentication and/or >> ESP are in use? Both AH and ESP are going to be a noticeable hit >> in performance for systems that use them. Omitting the checksum >> would at least allow those systems to recover some of that performa nce. >Given the orders of magnitude of the costs of the calculations, I >think the performance gained by omitting checksums when AH is in use >(negligible) isn't even remotely worth the large scale added >complexity to the code that it would entail in typical >implementations. I think Stephen's idea is valid and it has not been discussed before. So IPv6 implementors can we discuss this. I agreed with Perry at first but then looking at the checksum routines a global could be set to by-pass them and there would be a performance gain. I have asked one of our check-sum wizards to look at what kind of gain as he has been able to really gain performance in IPv4 with our implementation of new checksum code years back. The idea only works if the receiving site *knows* that the cryptographic header is end-to-end, rather than gateway-to-host. In the latter case, the checksum provided isn't end-to-end, which contradicts one of the goals of the transport layer checksum. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 09:03:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28994; Tue, 20 Jun 95 09:03:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28988; Tue, 20 Jun 95 09:03:32 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16264; Tue, 20 Jun 1995 08:53:38 -0700 Received: from inet-gw-2.pa.dec.com by mercury.Sun.COM (Sun.COM) id IAA17240; Tue, 20 Jun 1995 08:52:29 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA22191; Tue, 20 Jun 95 08:47:01 -0700 Received: by xirtlu.zk3.dec.com; id AA26244; Tue, 20 Jun 1995 11:47:00 -0400 Message-Id: <9506201547.AA26244@xirtlu.zk3.dec.com> To: Dan McDonald Cc: IPng Mailing list Subject: (IPng 208) Re: Re: Am I a router or host if... In-Reply-To: Your message of "Mon, 19 Jun 95 09:49:21 PDT." Date: Tue, 20 Jun 95 11:46:54 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dan, >>A HOST cannot forward packets not explicitly addressed for yourself. That's >>clear when the IPv6 header's destination field value is not one of my >>addresses. If that is true, I drop the packet. >> >>If the IPv6 header destination field is one of my addresses, but then there >>is a source routing header which has someone else as the FINAL destination, >>must I as a host forward the packet? Or do I drop the packet because I'm a >>host, not a router? >I think in this case, the host should drop the packet. I think in "ALL" cases you should drop the packet unless the "node" is configured as a router. Anyone DISAGREE? If so WHY? (thx).... BUT..................... I am not sure what the "RULES" are if a "node" is acting as both a router and a host for IPv6? Anyone else know of any RULES here or can we use our freedom and creativity as implementors to build both functions in one machine? >>As with all source-routing issues, there is security to consider. (Source >>routing attacks exist!) >> >As with "everything", there is security to consider :-) Not sure what your question is Dan? I will accept a packet that comes to my IPv6 node via source route. If the user is using IPv6 security (MAY USE) then I will not accept any packets if they do not have auth or esp IPv6 layer packets, but if the user is not using security (MAY NOT USE) then I will accept a source route packet is it comes into our IPv6 implementation. What else are you or may be asking? Good points to bring up Dan (thx). thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 09:26:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29016; Tue, 20 Jun 95 09:26:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29010; Tue, 20 Jun 95 09:26:00 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18699; Tue, 20 Jun 1995 09:13:57 -0700 Received: from inet-gw-2.pa.dec.com by venus.Sun.COM (Sun.COM) id JAA00279; Tue, 20 Jun 1995 09:13:57 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA23972; Tue, 20 Jun 95 09:09:28 -0700 Received: by xirtlu.zk3.dec.com; id AA26888; Tue, 20 Jun 1995 12:09:23 -0400 Message-Id: <9506201609.AA26888@xirtlu.zk3.dec.com> To: smb@research.att.com Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, sthomas@mindspring.com Subject: (IPng 209) Re: Re: Re: Optional Upper Level Checksums and Authentication In-Reply-To: Your message of "Tue, 20 Jun 95 10:11:22 EDT." <9506201416.AA20110@decvax.dec.com> Date: Tue, 20 Jun 95 12:09:17 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >The idea only works if the receiving site *knows* that the cryptographic >header is end-to-end, rather than gateway-to-host. In the latter case, >the checksum provided isn't end-to-end, which contradicts one of the >goals of the transport layer checksum. WHen the idea works then lets use it. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 10:06:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29180; Tue, 20 Jun 95 10:06:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29174; Tue, 20 Jun 95 10:06:38 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB24684; Tue, 20 Jun 1995 09:56:51 -0700 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id JAA26289; Tue, 20 Jun 1995 09:56:52 -0700 Subject: (IPng 210) Re: Re: Am I a router or host if... To: bound@zk3.dec.com Date: Tue, 20 Jun 1995 12:56:45 -0500 (EST) From: Dan McDonald Cc: danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506201547.AA26244@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jun 20, 95 11:46:54 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9506201756.aa08616@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I think in "ALL" cases you should drop the packet unless the "node" is > configured as a router. Anyone DISAGREE? If so WHY? (thx).... Oh, I don't disagree at all. > I am not sure what the "RULES" are if a "node" is acting as both a > router and a host for IPv6? Anyone else know of any RULES here or can Jim, if a node has both host and router functionality, it is considered (according to the IPv6 spec definition) a router. Sure, you can telnet, ftp, run X, run Y (if such a beast exists), run talk/talkd, multicast tools, etc., but if that node (which may be your desktop box) forwards packets, it is considered a router! If my node is acting as a router, I have a bit turned on somewhere that says it's a router. This means I still get all-NODES multicast, but I don't get all-HOSTS multicast. This doesn't eliminate host functionality, but if my node is acting as a router, it had better send out router advertisements, etc. It also means it (being a router) knows a bit more about topology than a host does. >From what I have read, nodes come in exactly TWO varieties, hosts, and routers, where routers quite possibly provide all of the functionality your hosts do. > we use our freedom and creativity as implementors to build both functions > in one machine? I'm COUNTING on being able to build both functions into one machine. My plan is to have a dumb-as-hell "stub router" running on one of my BSD boxes which tunnels packets not on my subnet to fire out into the world. That machine will probably be used as someone's desktop box. According to the IPv6 specification, however, it is a router. A rule of thumb is that a router can (should?) do anything a host can do, but not the other way around. Perhaps viewing a router as a superset of a host? Steve, Bob, anyone? Am I understanding this? > What else are you or may be asking? Nothing else, actually. I'm just chanting the NRL security mantra! > Good points to bring up Dan (thx). Your welcome. I brought it up because in 4.4-Lite, the IPv4 code forwards source routing packets while not forwarding normal packets. This is not good, because it's inconsistent. My v6 code will not make such a mistake. Dan McD. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 10:14:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29213; Tue, 20 Jun 95 10:14:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28924; Tue, 20 Jun 95 07:46:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07703; Tue, 20 Jun 1995 07:36:44 -0700 Received: from usr.com by mercury.Sun.COM (Sun.COM) id HAA09132; Tue, 20 Jun 1995 07:36:38 -0700 Received: from robogate.usr.com ([149.112.2.203]) by usr.com (4.1/3.1.090690-US Robotics ) id AA11878; Tue, 20 Jun 95 09:32:05 CDT Received: from cc:Mail by robogate.usr.com id AA803666262; Tue, 20 Jun 95 09:26:47 CST Date: Tue, 20 Jun 95 09:26:47 CST From: "Pat Calhoun" Message-Id: <9505208036.AA803666262@robogate.usr.com> To: ipng@sunroof2.Eng.Sun.COM, tsocolof@usr.com, dschoo@usr.com Subject: (IPng 211) Congestion Indication Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Just as you thought this subject was dead... I am formally submitting this draft for your review and comments. I have included two internet drafts (a text and PS version, I recommend the PS version since the graphics are much better). This proposal defines ONE (1) bit in the IPv6 Header which would be used for Congestion Management. The proposal defines how Frame Relay routers/switches would use this bit, and goes on to explain how other WAN/slow link routers could use this bit. This bit, although in the IPv6 header, is actually managed by the higher layer protocol. This draft defines how TCP should react, but also states that any higher layer protocol could easily support it as well (both windowing and non-windowing). Please contact me if you have any questions/concerns. Thanks, Pat R. Calhoun Lan Access R&D US Robotics Access Corp. pcalhoun@usr.com (708) 933-5181 Frame Relay Forum Member IPNG Working Group Pat R. Calhoun Internet Draft US Robotics Access Corp. Updates: RFC896 May 1995 Category: Standards Track Congestion Control in IPV6 Internetworks Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 1. Introduction This memo discusses Congestion Management in the IPV6 Internetworks. This memo is intended to update RFC 896. As the Internet network becomes more complex and more WAN connections are being used, it is absolutely necessary that we attempt to minimize problems related to congestion. In Wide Are Networks, such as Frame Relay, packet drops are a result of network resource congestion. RFC896 discusses two methods of Congestion Control; one known as TCP slow start, and the second is source quench. Source quenches are used today in order to notify the endpoint that a frame has been lost. Although the primary problem with source quench is its lack of support on end-stations, there is the additional problem that some Wide Area Networks (such as Frame Relay) drop packets without external notification. Furthermore, if x endpoints are routing through a central router and any of the packets are being dropped by the network, sending source quenches packets to each endpoint would create additional traffic which may cause further congestion if the path to the source included another WAN or slow link. Slow Start is also used when TCP packets have been dropped (i.e. unacknowledged within the TTL). The windows are then reduced by half for every loss, to a minimum of one. For each acknowledge received from the remote endpoint, the window is increased by one. Calhoun [Page 1] Internet Draft Congestion Indication in IP V6 May 1995 Slow Start can be considered as an implicit congestion indication. This document will provide explicit congestion indication to the endpoint by sending indication that a network resource is becoming congested. RFC 1016 showed a model where source quenches were used in order to notify the endpoint prior to congestion. Such an algorithm proved to increase the effective throughput. The RFC states the following: "Our algorithm should try to push the network congestion out to the extremities and keep the interior network congestion free" Therefore, a solution must be found where the endpoints are notified PRIOR to network congestion, yet additional traffic must be kept to a minimum. For this reason, this document is intended to propose a method which would avoid the use of the source quench by notifying the remote end-nodes prior to congestion, and thereby minimize packet drops. 2. Congestion Indication Bit This memo attempts to resolve the problems regarding Congestion Management. In order to manage Wide Area (or slow links) congestion, a Congestion Indication bit should exist in the IP version 6 header. The Congestion Indication bit is used in order to determine if there is any network resource congestion. This bit should be set by routers and intelligent WAN switches, when the network (or the switch) enters congestion point B (see diagram 1). In a Frame Relay network, routers would set the bit when a frame is received with the BECN (Backward Congestion) bit set. This bit indicates that congestion occurs in the reverse direction. In non Frame-Relay networks, such as X.25 or ISDN, the router design should take into account the maximum throughput of a port. When outgoing traffic on the port exceeds a low water mark the router should mark the congestion bit of all incoming frames on that port. Figure 2 shows an example of a 56Kb line and how the water marks could be determined (note that each WAN protocol could potentially have different water marks). Calhoun [Page 2] Internet Draft Congestion Indication in IP V6 May 1995 No Mild Severe Congestion Congestion Congestion | | | | .......... | | /\. | /| \ . | | / \ . | / | \ . | | / \ . | / | \ | | / \ | / | \ | | / network | / | | | / throughput | / | | |/ | / | | / | / | | | / | / | | | / | / | | | / | / | | | / | / A | B | C | / |/ | | +------------------------------------- Offered Load Upon reception of this bit, the endpoint is responsible for slowing down the data injected into the network. By reducing the traffic destined for the congested WAN link, the network, or switch, should never enter congestion condition C (called congestion collapse, where packet loss is inevitable). This method will allow the network resources to be freed which would cause the switch or network to fall back in condition A (No Congestion). The IP layer would be responsible for notifying the TCP layer when a frame with congestion indication has been received. This API would also be available to any additional higher level protocol stacks over Ipv6. Other windowing protocols could react in the manner described above. Since the higher layer protocol is responsible for responding to this bit, time sensitive protocols (i.e. video) may wish to ignore this bit or react in a different manner (i.e. drop packets locally). Calhoun [Page 3] Internet Draft Congestion Indication in IP V6 May 1995 +--------------------------+ | Condition C | 56Kb.|- - - High Water Mark- - -| | Condition B | 50Kb.|- - - Low Water Mark - - -| | | | | | Condition A | | | | | 0Kb.+--------------------------+ Non-windowing protocols must be examined in order to determine the best method of controlling the data injected into the network when the path has a congestion condition. The API would have to allow for the congestion indication to be sent up with the packet's data in order for TCP (or the higher layer protocol) to identify the session where the congestion occurred. 3. Expected Response to Congestion Indication A measurement interval of one window turn should be used by the remote endpoint. If within this timeframe, a packet is received with the CI bit set, the endpoint shall reduce its working transmission window to .625 of it's previous value, or one (whichever is greater). If within two interval, no frames are received with the CI bit set, the endpoint shall increase the window by one, up to the maximum for the session. At any time an adjustment to the window is made, the set/clear counters should be reset. For non-windowing protocols, a recommended response to the congestion indication bit would be as follow (note that further study must be done in order to ensure that the algorithm is correct). If within x frames, if a frame with the CI bit set is received , the protocol should reduce it's offered data to the next step. the step rates are: .625 of the throughput .5 of the throughput .25 of the throughput For each two intervals (2 * x frames), no frames are received with the CI bit set, the protocol could increment it's offered data rate by .125. Calhoun [Page 4] Internet Draft Congestion Indication in IP V6 May 1995 4. Congestion Indication Bit in the IP V6 Header There are two current possibilities in adding the Congestion Indication bit in the IP V6 header. The first is to add an option in the destination options. However, the problem with this solution is that router and intelligent switch manufacturers would probably not be willing to split an existing packet and add a new header to a packet during congestion. This seems like extra overhead which many manufacturers may be reluctant to do. The second solution would be to have the CI bit be an integral part of the IP V6 header. Although this means changing the IP V6 header, it seems like a much cleaner implementation. An easy solution must be found where most manufacturer would be willing to support. Otherwise, the same problem as the source quench frame would occur where it is virtually never implemented / supported. 5. Conclusion By reducing the risk of creating network congestion on a WAN (or slow link), the following benefits would be gained: - Minimize frame loss - Minimize the possibility that one end host can monopolize network resources at the expense of others. - Create minimal additional network traffic. - Limit the spread of congestion to other networks and elements within the network. - Maximize throughput of IP data stream on WAN links. 6. References [1] John Nagle, "Congestion Control in IP/TCP Internetworks", RFC 896, FACC Palo Alto, January 1984 [2] W. Prue / J. Postel, "Source Quench Introduced Delay - SQuID", RFC 1016, ISI, July 1987 [3] ITU Recommendation I.370 "ISDN - Congestion Management for the ISDN Frame Relaying Bearer Service", 1991 [4] ITU Recommendation Q.922 "DSS 1 Data Link Layer - ISDN Data Link Layer Specifications for Frame Mode Bearer Services", 1992 7. Acknowledgments Many thanks to Dan Schoo, Ted Socolofsky, Larry Samberg and Ed Fedemeyer for their valuable comments. Calhoun [Page 5] Internet Draft Congestion Indication in IP V6 May 1995 8. Author's Address Pat R. Calhoun US Robotics Access Corp. 8100 N. McCormick Blvd. Skokie, IL 60076 Phone: (708) 933-5181 Fax: (708) 982-1348 Email: pcalhoun@usr.com Calhoun [Page 6] %!PS-Adobe-3.0 %%Creator: Windows PSCRIPT %%Title: Microsoft Word - CONGEST2.TXT %%BoundingBox: 18 19 593 774 %%DocumentNeededResources: (atend) %%DocumentSuppliedResources: (atend) %%Pages: (atend) %%BeginResource: procset Win35Dict 3 1 /Win35Dict 290 dict def Win35Dict begin/bd{bind def}bind def/in{72 mul}bd/ed{exch def}bd/ld{load def}bd/tr/translate ld/gs/gsave ld/gr /grestore ld/M/moveto ld/L/lineto ld/rmt/rmoveto ld/rlt/rlineto ld /rct/rcurveto ld/st/stroke ld/n/newpath ld/sm/setmatrix ld/cm/currentmatrix ld/cp/closepath ld/ARC/arcn ld/TR{65536 div}bd/lj/setlinejoin ld/lc /setlinecap ld/ml/setmiterlimit ld/sl/setlinewidth ld/scignore false def/sc{scignore{pop pop pop}{0 index 2 index eq 2 index 4 index eq and{pop pop 255 div setgray}{3{255 div 3 1 roll}repeat setrgbcolor}ifelse}ifelse}bd /FC{bR bG bB sc}bd/fC{/bB ed/bG ed/bR ed}bd/HC{hR hG hB sc}bd/hC{ /hB ed/hG ed/hR ed}bd/PC{pR pG pB sc}bd/pC{/pB ed/pG ed/pR ed}bd/sM matrix def/PenW 1 def/iPen 5 def/mxF matrix def/mxE matrix def/mxUE matrix def/mxUF matrix def/fBE false def/iDevRes 72 0 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt def/fPP false def/SS{fPP{ /SV save def}{gs}ifelse}bd/RS{fPP{SV restore}{gr}ifelse}bd/EJ{gsave showpage grestore}bd/#C{userdict begin/#copies ed end}bd/FEbuf 2 string def/FEglyph(G )def/FE{1 exch{dup 16 FEbuf cvrs FEglyph exch 1 exch putinterval 1 index exch FEglyph cvn put}for}bd/SM{/iRes ed/cyP ed /cxPg ed/cyM ed/cxM ed 72 100 div dup scale dup 0 ne{90 eq{cyM exch 0 eq{cxM exch tr -90 rotate -1 1 scale}{cxM cxPg add exch tr +90 rotate}ifelse}{cyP cyM sub exch 0 ne{cxM exch tr -90 rotate}{cxM cxPg add exch tr -90 rotate 1 -1 scale}ifelse}ifelse}{pop cyP cyM sub exch 0 ne{cxM cxPg add exch tr 180 rotate}{cxM exch tr 1 -1 scale}ifelse}ifelse 100 iRes div dup scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itransform translate}bd/SJ{1 index 0 eq{pop pop/fBE false def}{1 index/Break ed div/dxBreak ed/fBE true def}ifelse}bd/ANSIVec[ 16#0/grave 16#1/acute 16#2/circumflex 16#3/tilde 16#4/macron 16#5/breve 16#6/dotaccent 16#7/dieresis 16#8/ring 16#9/cedilla 16#A/hungarumlaut 16#B/ogonek 16#C/caron 16#D/dotlessi 16#27/quotesingle 16#60/grave 16#7C/bar 16#82/quotesinglbase 16#83/florin 16#84/quotedblbase 16#85 /ellipsis 16#86/dagger 16#87/daggerdbl 16#88/circumflex 16#89/perthousand 16#8A/Scaron 16#8B/guilsinglleft 16#8C/OE 16#91/quoteleft 16#92/quoteright 16#93/quotedblleft 16#94/quotedblright 16#95/bullet 16#96/endash 16#97 /emdash 16#98/tilde 16#99/trademark 16#9A/scaron 16#9B/guilsinglright 16#9C/oe 16#9F/Ydieresis 16#A0/space 16#A1/exclamdown 16#A4/currency 16#A5/yen 16#A6/brokenbar 16#A7/section 16#A8/dieresis 16#A9/copyright 16#AA/ordfeminine 16#AB/guillemotleft 16#AC/logicalnot 16#AD/hyphen 16#AE/registered 16#AF/macron 16#B0/degree 16#B1/plusminus 16#B2/twosuperior 16#B3/threesuperior 16#B4/acute 16#B5/mu 16#B6/paragraph 16#B7/periodcentered 16#B8/cedilla 16#B9/onesuperior 16#BA/ordmasculine 16#BB/guillemotright 16#BC/onequarter 16#BD/onehalf 16#BE/threequarters 16#BF/questiondown 16#C0/Agrave 16#C1/Aacute 16#C2/Acircumflex 16#C3/Atilde 16#C4/Adieresis 16#C5/Aring 16#C6/AE 16#C7/Ccedilla 16#C8/Egrave 16#C9/Eacute 16#CA /Ecircumflex 16#CB/Edieresis 16#CC/Igrave 16#CD/Iacute 16#CE/Icircumflex 16#CF/Idieresis 16#D0/Eth 16#D1/Ntilde 16#D2/Ograve 16#D3/Oacute 16#D4 /Ocircumflex 16#D5/Otilde 16#D6/Odieresis 16#D7/multiply 16#D8/Oslash 16#D9/Ugrave 16#DA/Uacute 16#DB/Ucircumflex 16#DC/Udieresis 16#DD/Yacute 16#DE/Thorn 16#DF/germandbls 16#E0/agrave 16#E1/aacute 16#E2/acircumflex 16#E3/atilde 16#E4/adieresis 16#E5/aring 16#E6/ae 16#E7/ccedilla 16#E8 /egrave 16#E9/eacute 16#EA/ecircumflex 16#EB/edieresis 16#EC/igrave 16#ED/iacute 16#EE/icircumflex 16#EF/idieresis 16#F0/eth 16#F1/ntilde 16#F2/ograve 16#F3/oacute 16#F4/ocircumflex 16#F5/otilde 16#F6/odieresis 16#F7/divide 16#F8/oslash 16#F9/ugrave 16#FA/uacute 16#FB/ucircumflex 16#FC/udieresis 16#FD/yacute 16#FE/thorn 16#FF/ydieresis ] def/reencdict 12 dict def/IsChar{basefontdict/CharStrings get exch known}bd/MapCh{dup IsChar not{pop/bullet}if newfont/Encoding get 3 1 roll put}bd/MapDegree{16#b0 /degree IsChar{/degree}{/ring}ifelse MapCh}bd/MapBB{16#a6/brokenbar IsChar{/brokenbar}{/bar}ifelse MapCh}bd/ANSIFont{reencdict begin/newfontname ed/basefontname ed FontDirectory newfontname known not{/basefontdict basefontname findfont def/newfont basefontdict maxlength dict def basefontdict{exch dup/FID ne{dup/Encoding eq{exch dup length array copy newfont 3 1 roll put}{exch newfont 3 1 roll put}ifelse}{pop pop}ifelse}forall newfont /FontName newfontname put 127 1 159{newfont/Encoding get exch/bullet put}for ANSIVec aload pop ANSIVec length 2 idiv{MapCh}repeat MapDegree MapBB newfontname newfont definefont pop}if newfontname end}bd/SB{FC /ULlen ed/str ed str length fBE not{dup 1 gt{1 sub}if}if/cbStr ed /dxGdi ed/y0 ed/x0 ed str stringwidth dup 0 ne{/y1 ed/x1 ed y1 y1 mul x1 x1 mul add sqrt dxGdi exch div 1 sub dup x1 mul cbStr div exch y1 mul cbStr div}{exch abs neg dxGdi add cbStr div exch}ifelse/dyExtra ed/dxExtra ed x0 y0 M fBE{dxBreak 0 BCh dxExtra dyExtra str awidthshow}{dxExtra dyExtra str ashow}ifelse fUL{x0 y0 M dxUL dyUL rmt ULlen fBE{Break add}if 0 mxUE transform gs rlt cyUL sl [] 0 setdash st gr}if fSO{x0 y0 M dxSO dySO rmt ULlen fBE{Break add}if 0 mxUE transform gs rlt cyUL sl [] 0 setdash st gr}if n/fBE false def}bd/font{/name ed/Ascent ed 0 ne/fT3 ed 0 ne/fSO ed 0 ne/fUL ed/Sy ed/Sx ed 10.0 div/ori ed -10.0 div/esc ed/BCh ed name findfont/xAscent 0 def/yAscent Ascent def/ULesc esc def ULesc mxUE rotate pop fT3{/esc 0 def xAscent yAscent mxUE transform /yAscent ed/xAscent ed}if [Sx 0 0 Sy neg xAscent yAscent] esc mxE rotate mxF concatmatrix makefont setfont [Sx 0 0 Sy neg 0 Ascent] mxUE mxUF concatmatrix pop fUL{currentfont dup/FontInfo get/UnderlinePosition known not{pop/Courier findfont}if/FontInfo get/UnderlinePosition get 1000 div 0 exch mxUF transform/dyUL ed/dxUL ed}if fSO{0 .3 mxUF transform /dySO ed/dxSO ed}if fUL fSO or{currentfont dup/FontInfo get/UnderlineThickness known not{pop/Courier findfont}if/FontInfo get/UnderlineThickness get 1000 div Sy mul/cyUL ed}if}bd/min{2 copy gt{exch}if pop}bd/max{2 copy lt{exch}if pop}bd/CP{/ft ed{{ft 0 eq{clip}{eoclip}ifelse}stopped{currentflat 1 add setflat}{exit}ifelse}loop}bd/patfont 10 dict def patfont begin /FontType 3 def/FontMatrix [1 0 0 -1 0 0] def/FontBBox [0 0 16 16] def/Encoding StandardEncoding def/BuildChar{pop pop 16 0 0 0 16 16 setcachedevice 16 16 false [1 0 0 1 .25 .25]{pat}imagemask}bd end/p{ /pat 32 string def{}forall 0 1 7{dup 2 mul pat exch 3 index put dup 2 mul 1 add pat exch 3 index put dup 2 mul 16 add pat exch 3 index put 2 mul 17 add pat exch 2 index put pop}for}bd/pfill{/PatFont patfont definefont setfont/ch(AAAA)def X0 64 X1{Y1 -16 Y0{1 index exch M ch show}for pop}for}bd/vert{X0 w X1{dup Y0 M Y1 L st}for}bd/horz{Y0 w Y1{dup X0 exch M X1 exch L st}for}bd/fdiag{X0 w X1{Y0 M X1 X0 sub dup rlt st}for Y0 w Y1{X0 exch M Y1 Y0 sub dup rlt st}for}bd/bdiag{X0 w X1{Y1 M X1 X0 sub dup neg rlt st}for Y0 w Y1{X0 exch M Y1 Y0 sub dup neg rlt st}for}bd/AU{1 add cvi 15 or}bd/AD{1 sub cvi -16 and}bd/SHR{pathbbox AU/Y1 ed AU/X1 ed AD/Y0 ed AD/X0 ed}bd/hfill{/w iRes 37.5 div round def 0.1 sl [] 0 setdash n dup 0 eq{horz}if dup 1 eq{vert}if dup 2 eq{fdiag}if dup 3 eq{bdiag}if dup 4 eq{horz vert}if 5 eq{fdiag bdiag}if}bd/F{/ft ed fm 256 and 0 ne{gs FC ft 0 eq{fill}{eofill}ifelse gr}if fm 1536 and 0 ne{SHR gs HC ft CP fm 1024 and 0 ne{/Tmp save def pfill Tmp restore}{fm 15 and hfill}ifelse gr}if}bd/S{PenW sl PC st}bd/m matrix def/GW{iRes 12 div PenW add cvi}bd/DoW{iRes 50 div PenW add cvi}bd/DW{iRes 8 div PenW add cvi}bd/SP{/PenW ed/iPen ed iPen 0 eq iPen 6 eq or{[] 0 setdash}if iPen 1 eq{[DW GW] 0 setdash}if iPen 2 eq{[DoW GW] 0 setdash}if iPen 3 eq{[DW GW DoW GW] 0 setdash}if iPen 4 eq{[DW GW DoW GW DoW GW] 0 setdash}if}bd/E{m cm pop tr scale 1 0 moveto 0 0 1 0 360 arc cp m sm}bd /AG{/sy ed/sx ed sx div 4 1 roll sy div 4 1 roll sx div 4 1 roll sy div 4 1 roll atan/a2 ed atan/a1 ed sx sy scale a1 a2 ARC}def/A{m cm pop tr AG m sm}def/P{m cm pop tr 0 0 M AG cp m sm}def/RRect{n 4 copy M 3 1 roll exch L 4 2 roll L L cp}bd/RRCC{/r ed/y1 ed/x1 ed/y0 ed/x0 ed x0 x1 add 2 div y0 M x1 y0 x1 y1 r arcto 4{pop}repeat x1 y1 x0 y1 r arcto 4{pop}repeat x0 y1 x0 y0 r arcto 4{pop}repeat x0 y0 x1 y0 r arcto 4{pop}repeat cp}bd/RR{2 copy 0 eq exch 0 eq or{pop pop RRect}{2 copy eq{pop RRCC}{m cm pop/y2 ed/x2 ed/ys y2 x2 div 1 max def/xs x2 y2 div 1 max def/y1 exch ys div def/x1 exch xs div def/y0 exch ys div def/x0 exch xs div def/r2 x2 y2 min def xs ys scale x0 x1 add 2 div y0 M x1 y0 x1 y1 r2 arcto 4{pop}repeat x1 y1 x0 y1 r2 arcto 4{pop}repeat x0 y1 x0 y0 r2 arcto 4{pop}repeat x0 y0 x1 y0 r2 arcto 4{pop}repeat m sm cp}ifelse}ifelse}bd/PP{{rlt}repeat}bd/OB{gs 0 ne{7 3 roll/y ed /x ed x y translate ULesc rotate x neg y neg translate x y 7 -3 roll}if sc B fill gr}bd/B{M/dy ed/dx ed dx 0 rlt 0 dy rlt dx neg 0 rlt cp}bd /CB{B clip n}bd/ErrHandler{errordict dup maxlength exch length gt dup{errordict begin}if/errhelpdict 12 dict def errhelpdict begin/stackunderflow(operand stack underflow)def /undefined(this name is not defined in a dictionary)def/VMerror(you have used up all the printer's memory)def /typecheck(operator was expecting a different type of operand)def /ioerror(input/output error occured)def end{end}if errordict begin /handleerror{$error begin newerror{/newerror false def showpage 72 72 scale/x .25 def/y 9.6 def/Helvetica findfont .2 scalefont setfont x y moveto(Offending Command = )show/command load{dup type/stringtype ne{(max err string)cvs}if show}exec/y y .2 sub def x y moveto(Error = )show errorname{dup type dup( max err string )cvs show( : )show/stringtype ne{( max err string )cvs}if show}exec errordict begin errhelpdict errorname known{x 1 add y .2 sub moveto errhelpdict errorname get show}if end /y y .4 sub def x y moveto(Stack =)show ostack{/y y .2 sub def x 1 add y moveto dup type/stringtype ne{( max err string )cvs}if show}forall showpage}if end}def end}bd end %%EndResource /SVDoc save def %%EndProlog %%BeginSetup Win35Dict begin ErrHandler statusdict begin 0 setjobtimeout end statusdict begin statusdict /jobname (Microsoft Word - CONGEST2.TXT) put end /oldDictCnt countdictstack def {statusdict begin 0 setpapertray end }stopped { countdictstack oldDictCnt lt { Win35Dict begin } {1 1 countdictstack oldDictCnt sub {pop end } for } ifelse } if /oldDictCnt countdictstack def {letter }stopped { countdictstack oldDictCnt lt { Win35Dict begin } {1 1 countdictstack oldDictCnt sub {pop end } for } ifelse } if [{} /exec load currenttransfer /exec load] cvx settransfer %%EndSetup %%Page: 1 1 %%PageResources: (atend) SS 0 0 25 25 798 1100 300 SM 32 0 0 50 50 0 0 0 40 /Courier /font0 ANSIFont font 0 0 0 fC 225 2825 2040 (Calhoun [Page ) 2040 SB 2265 2825 30 (1) 30 SB 2295 2825 30 (]) 30 SB 225 375 1950 (IPNG Working Group Pat R. Calhoun) 1950 SB 225 425 1950 (Internet Draft US Robotics Access Corp.) 1950 SB 225 475 1950 (Updates: RFC896 May 1995) 1950 SB 225 525 750 (Category: Standards Track) 750 SB 600 675 1200 (Congestion Control in IPV6 Internetworks) 1200 SB 225 775 570 (Status of this Memo) 570 SB 281 875 1800 (This document specifies an Internet standards track protocol) 1800 SB 281 925 1650 (for the Internet community, and requests discussion and) 1650 SB 281 975 1710 (suggestions for improvements. Please refer to the current) 1710 SB 281 1025 450 (edition of the ) 450 SB 731 1025 30 (\223) 30 SB 761 1025 1080 (Internet Official Protocol Standards) 1080 SB 1841 1025 30 (\224) 30 SB 1871 1025 240 ( \(STD 1\)) 240 SB 281 1075 1740 (for the standardization state and status of this protocol.) 1740 SB 281 1125 1170 (Distribution of this memo is unlimited.) 1170 SB 225 1225 450 (1. Introduction) 450 SB 281 1325 1590 (This memo discusses Congestion Management in the IPV6) 1590 SB 281 1375 1650 (Internetworks. This memo is intended to update RFC 896.) 1650 SB 281 1475 1710 (As the Internet network becomes more complex and more WAN) 1710 SB 281 1525 1860 (connections are being used, it is absolutely necessary that we) 1860 SB 281 1575 1530 (attempt to minimize problems related to congestion.) 1530 SB 281 1675 1830 (In Wide Are Networks, such as Frame Relay, packet drops are a) 1830 SB 281 1725 1140 (result of network resource congestion.) 1140 SB 281 1825 1830 (RFC896 discusses two methods of Congestion Control; one known) 1830 SB 281 1875 1530 (as TCP slow start, and the second is source quench.) 1530 SB 281 1975 1860 (Source quenches are used today in order to notify the endpoint) 1860 SB 281 2025 840 (that a frame has been lost. ) 840 SB 1121 2025 990 (Although the primary problem with) 990 SB 281 2075 1860 (source quench is its lack of support on end-stations, there is) 1860 SB 281 2125 1800 (the additional problem that some Wide Area Networks \(such as) 1800 SB 281 2175 1680 (Frame Relay\) drop packets without external notification.) 1680 SB 281 2275 1710 (Furthermore, if x endpoints are routing through a central) 1710 SB 281 2325 1890 (router and any of the packets are being dropped by the network,) 1890 SB 281 2375 1830 (sending source quenches packets to each endpoint would create) 1830 SB 281 2425 1800 (additional traffic which may cause further congestion if the) 1800 SB 281 2475 1590 (path to the source included another WAN or slow link.) 1590 SB 281 2575 1740 (Slow Start is also used when TCP packets have been dropped) 1740 SB 281 2625 1740 (\(i.e. unacknowledged within the TTL\). The windows are then) 1740 SB 281 2675 1830 (reduced by half for every loss, to a minimum of one. For each) 1830 SB 281 2725 1800 (acknowledge received from the remote endpoint, the window is) 1800 SB 1 #C statusdict begin /manualfeed false store end EJ RS %%PageTrailer %%PageResources: font Courier %%Page: 2 2 %%PageResources: (atend) SS 0 0 25 25 798 1100 300 SM 32 0 0 50 50 0 0 0 40 /Courier /font0 ANSIFont font 0 0 0 fC 225 225 2100 (Internet Draft Congestion Indication in IP V6 May 1995) 2100 SB 225 2875 2010 (Calhoun [Page ) 2010 SB 2235 2875 30 (2) 30 SB 2265 2875 30 (]) 30 SB 281 375 510 (increased by one.) 510 SB 281 475 1620 (Slow Start can be considered as an implicit congestion) 1620 SB 281 525 1740 (indication. This document will provide explicit congestion) 1740 SB 281 575 1890 (indication to the endpoint by sending indication that a network) 1890 SB 281 625 930 (resource is becoming congested.) 930 SB 281 725 1740 (RFC 1016 showed a model where source quenches were used in) 1740 SB 281 775 1710 (order to notify the endpoint prior to congestion. Such an) 1710 SB 281 825 1860 (algorithm proved to increase the effective throughput. The RFC) 1860 SB 281 875 630 (states the following:) 630 SB 375 925 30 (\223) 30 SB 405 925 1770 (Our algorithm should try to push the network congestion out) 1770 SB 281 975 1890 ( to the extremities and keep the interior network congestion) 1890 SB 281 1025 240 ( free) 240 SB 521 1025 30 (\224) 30 SB 281 1125 1770 (Therefore, a solution must be found where the endpoints are) 1770 SB 281 1175 1800 (notified PRIOR to network congestion, yet additional traffic) 1800 SB 281 1225 1800 (must be kept to a minimum. For this reason, this document is) 1800 SB 281 1275 1830 (intended to propose a method which would avoid the use of the) 1830 SB 281 1325 1680 (source quench by notifying the remote end-nodes prior to) 1680 SB 281 1375 1380 (congestion, and thereby minimize packet drops.) 1380 SB 225 1475 840 (2. Congestion Indication Bit) 840 SB 281 1575 1890 (This memo attempts to resolve the problems regarding Congestion) 1890 SB 281 1625 1680 (Management. In order to manage Wide Area \(or slow links\)) 1680 SB 281 1675 1860 (congestion, a Congestion Indication bit should exist in the IP) 1860 SB 281 1725 1740 (version 6 header. The Congestion Indication bit is used in) 1740 SB 281 1775 1890 (order to determine if there is any network resource congestion.) 1890 SB 281 1875 1890 (This bit should be set by routers and intelligent WAN switches,) 1890 SB 281 1925 1890 (when the network \(or the switch\) enters congestion point B \(see) 1890 SB 281 1975 330 (diagram 1\).) 330 SB 281 2025 1320 ( No Mild Severe) 1320 SB 525 2075 1140 ( Congestion Congestion Congestion) 1140 SB 281 2225 210 (network) 210 SB 281 2275 300 (throughput) 300 SB 281 2425 1260 ( A B C) 1260 SB 281 2575 1020 ( Offered Load) 1020 SB 281 2675 1740 (In a Frame Relay network, routers would set the bit when a) 1740 SB 281 2725 1860 (frame is received with the BECN \(Backward Congestion\) bit set.) 1860 SB 1 lc 1 lj 0 0 0 pC 0 4 SP 592 2170 M 0 366 1 PP S n 592 2539 M 1101 -1 1 PP S n 0 0 0 fC /fm 256 def 930 2160 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2182 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2204 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2226 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2248 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2270 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2292 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2314 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2336 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2358 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2380 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2402 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2424 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2446 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2468 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2490 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2512 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 930 2534 M 0 -2 -2 0 0 2 2 0 4 PP 1 F n /fm 256 def 1337 2161 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1337 2183 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1337 2205 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1337 2227 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1337 2249 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1337 2271 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1337 2293 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1337 2315 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1337 2337 M -1 -15 -2 0 1 15 2 0 4 PP 1 F n /fm 256 def 1338 2360 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1338 2382 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1338 2404 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1338 2426 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1338 2448 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1338 2470 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1338 2492 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n /fm 256 def 1338 2514 M 0 -14 -2 0 0 14 2 0 4 PP 1 F n 0 4 SP 255 255 255 fC /fm 256 def 0 0 1 -314 0 0 -773 773 314 1368 2498 A S n /fm 256 def 0 0 1 0 274 -208 0 273 208 1283 2392 A S n 0 2 SP /fm 256 def 0 0 1 0 381 -4 380 380 162 1306 2346 A S n /fm 256 def 0 0 1 -12 378 -16 377 380 162 1306 2346 A S n /fm 256 def 0 0 1 -24 375 -28 374 380 162 1306 2346 A S n /fm 256 def 0 0 1 -35 370 -39 368 380 162 1306 2346 A S n /fm 256 def 0 0 1 -45 363 -49 361 380 162 1306 2346 A S n /fm 256 def 0 0 1 -55 356 -59 354 380 162 1306 2346 A S n /fm 256 def 0 0 1 -64 348 -67 345 380 162 1306 2346 A S n /fm 256 def 0 0 1 -72 338 -75 335 380 162 1306 2346 A S n /fm 256 def 0 0 1 -80 329 -83 325 380 162 1306 2346 A S n /fm 256 def 0 0 1 -88 319 -90 315 380 162 1306 2346 A S n /fm 256 def 0 0 1 -94 308 -96 305 380 162 1306 2346 A S n /fm 256 def 0 0 1 -100 298 -101 294 380 162 1306 2346 A S n /fm 256 def 0 0 1 -105 287 -107 284 380 162 1306 2346 A S n /fm 256 def 0 0 1 -111 277 -113 273 380 162 1306 2346 A S n /fm 256 def 0 0 1 -113 273 -114 269 380 162 1306 2346 A S n /fm 256 def 0 0 1 -117 261 -119 258 380 162 1306 2346 A S n /fm 256 def 0 0 1 -121 250 -123 246 380 162 1306 2346 A S n /fm 256 def 0 0 1 -126 238 -127 234 380 162 1306 2346 A S n /fm 256 def 0 0 1 -130 227 -131 223 380 162 1306 2346 A S n /fm 256 def 0 0 1 -134 215 -135 211 380 162 1306 2346 A S n /fm 256 def 0 0 1 -137 203 -138 199 380 162 1306 2346 A S n /fm 256 def 0 0 1 -139 191 -140 187 380 162 1306 2346 A S n /fm 256 def 0 0 1 -142 179 -143 175 380 162 1306 2346 A S n /fm 256 def 0 0 1 -145 167 -146 163 380 162 1306 2346 A S n /fm 256 def 0 0 1 -148 155 -149 151 380 162 1306 2346 A S n /fm 256 def 0 0 1 -150 143 -150 139 380 162 1306 2346 A S n /fm 256 def 0 0 1 -151 131 -152 127 380 162 1306 2346 A S n /fm 256 def 0 0 1 -153 119 -154 115 380 162 1306 2346 A S n /fm 256 def 0 0 1 -155 107 -155 103 380 162 1306 2346 A S n /fm 256 def 0 0 1 -157 95 -157 91 380 162 1306 2346 A S n /fm 256 def 0 0 1 -158 83 -158 79 380 162 1306 2346 A S n /fm 256 def 0 0 1 -159 71 -159 67 380 162 1306 2346 A S n /fm 256 def 0 0 1 -159 59 -160 55 380 162 1306 2346 A S n /fm 256 def 0 0 1 -160 47 -160 43 380 162 1306 2346 A S n /fm 256 def 0 0 1 -161 35 -161 31 380 162 1306 2346 A S n /fm 256 def 0 0 1 -161 23 -162 19 380 162 1306 2346 A S n /fm 256 def 0 0 1 -162 11 -162 6 380 162 1306 2346 A S n /fm 256 def 0 0 1 0 398 -3 396 397 56 1289 2240 A S n /fm 256 def 0 0 1 -10 391 -12 387 397 56 1289 2240 A S n /fm 256 def 0 0 1 -15 380 -17 377 397 56 1289 2240 A S n /fm 256 def 0 0 1 -20 369 -21 365 397 56 1289 2240 A S n /fm 256 def 0 0 1 -24 357 -25 353 397 56 1289 2240 A S n /fm 256 def 0 0 1 -28 345 -28 344 397 56 1289 2240 A S n /fm 256 def 0 0 1 -28 344 -29 341 397 56 1289 2240 A S n /fm 256 def 0 0 1 -30 333 -31 329 397 56 1289 2240 A S n /fm 256 def 0 0 1 -33 321 -33 317 397 56 1289 2240 A S n /fm 256 def 0 0 1 -35 309 -36 305 397 56 1289 2240 A S n /fm 256 def 0 0 1 -37 297 -38 293 397 56 1289 2240 A S n /fm 256 def 0 0 1 -39 285 -39 281 397 56 1289 2240 A S n /fm 256 def 0 0 1 -41 272 -41 268 397 56 1289 2240 A S n /fm 256 def 0 0 1 -42 260 -43 256 397 56 1289 2240 A S n /fm 256 def 0 0 1 -44 248 -44 244 397 56 1289 2240 A S n /fm 256 def 0 0 1 -45 236 -45 232 397 56 1289 2240 A S n /fm 256 def 0 0 1 -46 224 -46 220 397 56 1289 2240 A S n /fm 256 def 0 0 1 -47 212 -47 208 397 56 1289 2240 A S n /fm 256 def 0 0 1 -48 200 -48 199 397 56 1289 2240 A S n /fm 256 def 0 0 1 -48 199 -48 196 397 56 1289 2240 A S n /fm 256 def 0 0 1 -49 188 -49 184 397 56 1289 2240 A S n /fm 256 def 0 0 1 -50 176 -50 172 397 56 1289 2240 A S n /fm 256 def 0 0 1 -51 163 -51 159 397 56 1289 2240 A S n /fm 256 def 0 0 1 -52 151 -52 147 397 56 1289 2240 A S n /fm 256 def 0 0 1 -53 139 -53 136 397 56 1289 2240 A S n /fm 256 def 0 0 1 -53 136 -53 135 397 56 1289 2240 A S n /fm 256 def 0 0 1 -53 127 -53 123 397 56 1289 2240 A S n /fm 256 def 0 0 1 -54 115 -54 111 397 56 1289 2240 A S n /fm 256 def 0 0 1 -54 102 -54 98 397 56 1289 2240 A S n /fm 256 def 0 0 1 -54 90 -54 86 397 56 1289 2240 A S n /fm 256 def 0 0 1 -55 78 -55 74 397 56 1289 2240 A S n /fm 256 def 0 0 1 -55 66 -55 62 397 56 1289 2240 A S n /fm 256 def 0 0 1 -55 54 -55 50 397 56 1289 2240 A S n /fm 256 def 0 0 1 -55 42 -55 38 397 56 1289 2240 A S n /fm 256 def 0 0 1 -56 29 -56 25 397 56 1289 2240 A S n /fm 256 def 0 0 1 -56 17 -56 13 397 56 1289 2240 A S n /fm 256 def 0 0 1 -56 5 -56 1 397 56 1289 2240 A S n 1 #C statusdict begin /manualfeed false store end EJ RS %%PageTrailer %%PageResources: font Courier %%Page: 3 3 %%PageResources: (atend) SS 0 0 25 25 798 1100 300 SM 32 0 0 50 50 0 0 0 40 /Courier /font0 ANSIFont font 0 0 0 fC 225 225 2100 (Internet Draft Congestion Indication in IP V6 May 1995) 2100 SB 225 2875 2010 (Calhoun [Page ) 2010 SB 2235 2875 30 (3) 30 SB 2265 2875 30 (]) 30 SB 281 375 1680 (This bit indicates that congestion occurs in the reverse) 1680 SB 281 425 300 (direction.) 300 SB 281 525 1830 (In non Frame-Relay networks, such as X.25 or ISDN, the router) 1830 SB 281 575 1770 (design should take into account the maximum throughput of a) 1770 SB 281 625 1770 (port. When outgoing traffic on the port exceeds a low water) 1770 SB 281 675 1860 (mark the router should mark the congestion bit of all incoming) 1860 SB 281 725 1830 (frames on that port. Figure 2 shows an example of a 56Kb line) 1830 SB 281 775 1890 (and how the water marks could be determined \(note that each WAN) 1890 SB 281 825 1650 (protocol could potentially have different water marks\).) 1650 SB 281 975 990 ( Condition C) 990 SB 281 1025 1080 ( 56Kb. High Water Mark) 1080 SB 281 1075 990 ( Condition B) 990 SB 281 1125 1050 ( 50Kb. Low Water Mark) 1050 SB 281 1275 990 ( Condition A) 990 SB 281 1425 420 ( 0Kb.) 420 SB 281 1525 1770 (Upon reception of this bit, the endpoint is responsible for) 1770 SB 281 1575 1800 (slowing down the data injected into the network. By reducing) 1800 SB 281 1625 1830 (the traffic destined for the congested WAN link, the network,) 1830 SB 281 1675 1800 (or switch, should never enter congestion condition C \(called) 1800 SB 281 1725 1770 (congestion collapse, where packet loss is inevitable\). This) 1770 SB 281 1775 1890 (method will allow the network resources to be freed which would) 1890 SB 281 1825 1770 (cause the switch or network to fall back in condition A \(No) 1770 SB 281 1875 360 (Congestion\).) 360 SB 281 1975 1830 (The IP layer would be responsible for notifying the TCP layer) 1830 SB 281 2025 1890 (when a frame with congestion indication has been received. This) 1890 SB 281 2075 1740 (API would also be available to any additional higher level) 1740 SB 281 2125 1740 (protocol stacks over Ipv6. Other windowing protocols could) 1740 SB 281 2175 1770 (react in the manner described above. Since the higher layer) 1770 SB 281 2225 1680 (protocol is responsible for responding to this bit, time) 1680 SB 281 2275 1890 (sensitive protocols \(i.e. video\) may wish to ignore this bit or) 1890 SB 281 2325 1680 (react in a different manner \(i.e. drop packets locally\).) 1680 SB 281 2425 1860 (Non-windowing protocols must be examined in order to determine) 1860 SB 281 2475 1710 (the best method of controlling the data injected into the) 1710 SB 281 2525 1470 (network when the path has a congestion condition.) 1470 SB 281 2625 1890 (The API would have to allow for the congestion indication to be) 1890 SB 281 2675 1860 (sent up with the packet\222s data in order for TCP \(or the higher) 1860 SB 0 lc 0 lj 0 0 0 pC 0 3 SP 799 505 720 953 B S n 0 0 0 fC /fm 256 def 916 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 904 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 892 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 880 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 868 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 856 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 844 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 832 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 820 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 808 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 796 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 784 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 772 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 760 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 748 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 736 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 724 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1519 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1507 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1495 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1483 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1471 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1459 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1447 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1435 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1423 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1411 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1399 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1387 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1375 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1363 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1351 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1339 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1327 1147 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 914 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 902 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 890 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 878 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 866 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 854 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 842 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 830 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 818 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 806 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 794 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 782 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 770 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 758 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 746 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 734 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 722 1044 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1522 1045 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1510 1045 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1498 1045 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1486 1045 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1474 1045 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1462 1045 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1450 1045 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1437 1046 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1425 1046 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1413 1046 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1401 1046 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1389 1046 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1377 1046 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n /fm 256 def 1365 1046 M 4 0 0 -2 -4 0 0 2 4 PP 1 F n 1 #C statusdict begin /manualfeed false store end EJ RS %%PageTrailer %%PageResources: font Courier %%Page: 4 4 %%PageResources: (atend) SS 0 0 25 25 798 1100 300 SM 32 0 0 50 50 0 0 0 40 /Courier /font0 ANSIFont font 0 0 0 fC 225 225 2100 (Internet Draft Congestion Indication in IP V6 May 1995) 2100 SB 225 2875 2010 (Calhoun [Page ) 2010 SB 2235 2875 30 (4) 30 SB 2265 2875 30 (]) 30 SB 281 375 1800 (layer protocol\) to identify the session where the congestion) 1800 SB 281 425 270 (occurred.) 270 SB 225 525 1350 (3. Expected Response to Congestion Indication) 1350 SB 281 625 1770 (A measurement interval of one window turn should be used by) 1770 SB 281 675 1740 (the remote endpoint. If within this timeframe, a packet is) 1740 SB 281 725 1770 (received with the CI bit set, the endpoint shall reduce its) 1770 SB 281 775 1860 (working transmission window to .625 of it's previous value, or) 1860 SB 281 825 810 (one \(whichever is greater\).) 810 SB 281 925 1860 (If within two interval, no frames are received with the CI bit) 1860 SB 281 975 1830 (set, the endpoint shall increase the window by one, up to the) 1830 SB 281 1025 720 (maximum for the session.) 720 SB 281 1125 1860 (At any time an adjustment to the window is made, the set/clear) 1860 SB 281 1175 750 (counters should be reset.) 750 SB 281 1275 1740 (For non-windowing protocols, a recommended response to the) 1740 SB 281 1325 1890 (congestion indication bit would be as follow \(note that further) 1890 SB 281 1375 1770 (study must be done in order to ensure that the algorithm is) 1770 SB 281 1425 1890 (correct\). If within x frames, if a frame with the CI bit set is) 1890 SB 281 1475 1860 (received , the protocol should reduce it\222s offered data to the) 1860 SB 281 1525 900 (next step. the step rates are:) 900 SB 375 1625 660 (.625 of the throughput) 660 SB 375 1675 600 (.5 of the throughput) 600 SB 375 1725 630 (.25 of the throughput) 630 SB 281 1825 1830 (For each two intervals \(2 * x frames\), no frames are received) 1830 SB 281 1875 1860 (with the CI bit set, the protocol could increment it\222s offered) 1860 SB 281 1925 540 (data rate by .125.) 540 SB 225 2025 1440 (4. Congestion Indication Bit in the IP V6 Header) 1440 SB 281 2125 1800 (There are two current possibilities in adding the Congestion) 1800 SB 281 2175 1740 (Indication bit in the IP V6 header. The first is to add an) 1740 SB 281 2225 1800 (option in the destination options. However, the problem with) 1800 SB 281 2275 1530 (this solution is that router and intelligent switch) 1530 SB 281 2325 1650 (manufacturers would probably not be willing to split an) 1650 SB 281 2375 1650 (existing packet and add a new header to a packet during) 1650 SB 281 2425 1590 (congestion. This seems like extra overhead which many) 1590 SB 281 2475 1110 (manufacturers may be reluctant to do.) 1110 SB 281 2575 1860 (The second solution would be to have the CI bit be an integral) 1860 SB 281 2625 1830 (part of the IP V6 header. Although this means changing the IP) 1830 SB 281 2675 1890 (V6 header, it seems like a much cleaner implementation. An easy) 1890 SB 281 2725 1890 (solution must be found where most manufacturer would be willing) 1890 SB 1 #C statusdict begin /manualfeed false store end EJ RS %%PageTrailer %%PageResources: font Courier %%Page: 5 5 %%PageResources: (atend) SS 0 0 25 25 798 1100 300 SM 32 0 0 50 50 0 0 0 40 /Courier /font0 ANSIFont font 0 0 0 fC 225 225 2100 (Internet Draft Congestion Indication in IP V6 May 1995) 2100 SB 225 2875 2010 (Calhoun [Page ) 2010 SB 2235 2875 30 (5) 30 SB 2265 2875 30 (]) 30 SB 281 375 1800 (to support. Otherwise, the same problem as the source quench) 1800 SB 281 425 1770 (frame would occur where it is virtually never implemented /) 1770 SB 281 475 300 (supported.) 300 SB 225 575 390 (5. Conclusion) 390 SB 281 675 1800 (By reducing the risk of creating network congestion on a WAN) 1800 SB 281 725 1650 (\(or slow link\), the following benefits would be gained:) 1650 SB 281 825 780 ( - Minimize frame loss) 780 SB 281 875 1590 ( - Minimize the possibility that one end host can) 1590 SB 281 925 1830 ( monopolize network resources at the expense of others.) 1830 SB 281 975 1470 ( - Create minimal additional network traffic.) 1470 SB 281 1025 1770 ( - Limit the spread of congestion to other networks and) 1770 SB 281 1075 30 ( ) 30 SB 375 1075 960 ( elements within the network.) 960 SB 281 1125 1740 ( - Maximize throughput of IP data stream on WAN links.) 1740 SB 225 1225 390 (6. References) 390 SB 281 1325 480 ([1] John Nagle, ) 480 SB 761 1325 30 (\223) 30 SB 791 1325 1260 (Congestion Control in IP/TCP Internetworks) 1260 SB 2051 1325 30 (\224) 30 SB 2081 1325 30 (,) 30 SB 281 1375 1230 ( RFC 896, FACC Palo Alto, January 1984) 1230 SB 281 1475 750 ([2] W. Prue / J. Postel, ) 750 SB 1031 1475 30 (\223) 30 SB 1061 1475 960 (Source Quench Introduced Delay -) 960 SB 281 1525 270 ( SQuID) 270 SB 551 1525 30 (\224) 30 SB 581 1525 780 (, RFC 1016, ISI, July 1987) 780 SB 281 1625 870 ([3] ITU Recommendation I.370 ) 870 SB 1151 1625 30 (\223) 30 SB 1181 1625 960 (ISDN - Congestion Management for) 960 SB 281 1675 1260 ( the ISDN Frame Relaying Bearer Service) 1260 SB 1541 1675 30 (\224) 30 SB 1571 1675 180 (, 1991) 180 SB 281 1775 870 ([4] ITU Recommendation Q.922 ) 870 SB 1151 1775 30 (\223) 30 SB 1181 1775 990 (DSS 1 Data Link Layer - ISDN Data) 990 SB 281 1825 1800 ( Link Layer Specifications for Frame Mode Bearer Services) 1800 SB 2081 1825 30 (\224) 30 SB 2111 1825 30 (,) 30 SB 281 1875 240 ( 1992) 240 SB 225 1975 540 (7. Acknowledgments) 540 SB 281 2075 1860 (Many thanks to Dan Schoo, Ted Socolofsky, Larry Samberg and Ed) 1860 SB 281 2125 1140 (Fedemeyer for their valuable comments.) 1140 SB 225 2225 570 (8. Author\222s Address) 570 SB 281 2325 420 (Pat R. Calhoun) 420 SB 281 2375 720 (US Robotics Access Corp.) 720 SB 281 2425 690 (8100 N. McCormick Blvd.) 690 SB 281 2475 480 (Skokie, IL 60076) 480 SB 281 2575 630 (Phone: \(708\) 933-5181) 630 SB 281 2625 630 (Fax: \(708\) 982-1348) 630 SB 281 2675 690 (Email: pcalhoun@usr.com) 690 SB 1 #C statusdict begin /manualfeed false store end EJ RS %%PageTrailer %%PageResources: font Courier %%Trailer SVDoc restore end %%Pages: 5 % TrueType font name key: % MSTT31c1d3 = 1357DTimes New RomanF0000002a000001900000 %%DocumentSuppliedResources: procset Win35Dict 3 1 %%DocumentNeededResources: font Courier %%EOF  ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 10:22:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29248; Tue, 20 Jun 95 10:22:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29242; Tue, 20 Jun 95 10:22:44 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27298; Tue, 20 Jun 1995 10:12:52 -0700 Received: from inet-gw-2.pa.dec.com by mercury.Sun.COM (Sun.COM) id KAA28905; Tue, 20 Jun 1995 10:12:51 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA28711; Tue, 20 Jun 95 10:07:39 -0700 Received: by xirtlu.zk3.dec.com; id AA28765; Tue, 20 Jun 1995 13:07:39 -0400 Message-Id: <9506201707.AA28765@xirtlu.zk3.dec.com> To: Dan McDonald Cc: bound@zk3.dec.com, ipng@sunroof2.Eng.Sun.COM Subject: (IPng 212) Re: Re: Am I a router or host if... In-Reply-To: Your message of "Tue, 20 Jun 95 12:56:45 CDT." <9506201756.aa08616@cs.nrl.navy.mil> Date: Tue, 20 Jun 95 13:07:33 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dan, Thanks for the response and I agree with everything you said. I too want/need that dumb router for testing too but as you said it is a router. Now I need to go back to ND and figure out what the result is if any of not hearing the ALL-HOSTs if I am a router but as a superset can do all the host parts too. Did not catch that yet in 4.4-lite (---> thanks)..... thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 10:32:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29272; Tue, 20 Jun 95 10:32:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29266; Tue, 20 Jun 95 10:32:07 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29114; Tue, 20 Jun 1995 10:22:20 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id KAA00514; Tue, 20 Jun 1995 10:22:20 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA27355; Tue, 20 Jun 95 13:20:38 EDT Received: from karma.engeast by BayNetworks.com (4.1/SMI-4.1) id AA00883; Tue, 20 Jun 95 13:21:59 EDT Date: Tue, 20 Jun 95 13:21:59 EDT From: mdavis@BayNetworks.com (Mike Davis) Message-Id: <9506201721.AA00883@BayNetworks.com> Received: by karma.engeast (4.1/SMI-4.1) id AA03095; Tue, 20 Jun 95 13:21:56 EDT To: bound@zk3.dec.com Cc: danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506201547.AA26244@xirtlu.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng 213) Re: Re: Re: Am I a router or host if... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >>>>> "bound" == bound writes: bound> Dan, bound> I think in "ALL" cases you should drop the packet unless bound> the "node" is configured as a router. Anyone DISAGREE? If bound> so WHY? (thx).... bound> BUT..................... bound> I am not sure what the "RULES" are if a "node" is acting as bound> both a router and a host for IPv6? Anyone else know of any ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ bound> RULES here or can we use our freedom and creativity as bound> implementors to build both functions in one machine? The "RULES" are pretty clear that a node is exactly one of "host" or "router" at a time. There is no rule saying that this configuration cannot change over time, but your assumption above can never be true. . . . --mad Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 11:14:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29297; Tue, 20 Jun 95 11:14:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29291; Tue, 20 Jun 95 11:14:24 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06672; Tue, 20 Jun 1995 11:04:34 -0700 Received: from rodan.UU.NET by mercury.Sun.COM (Sun.COM) id LAA13603; Tue, 20 Jun 1995 11:04:30 -0700 Received: by rodan.UU.NET id QQyuyx27702; Tue, 20 Jun 1995 13:56:47 -0400 Message-Id: To: bound@zk3.dec.com Cc: smb@research.att.com, ipng@sunroof.Eng.Sun.COM, sthomas@mindspring.com Subject: (IPng 214) Re: Re: Re: Re: Optional Upper Level Checksums and Authentication In-Reply-To: Your message of "Tue, 20 Jun 1995 12:09:17 EDT." <9506201609.AA26888@xirtlu.zk3.dec.com> Date: Tue, 20 Jun 1995 13:56:47 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Jim, Remember how much trouble was caused when NFS turned-off UDP checksums (and it was even LEGAL)????? optional checksums are no checksum - just don't do it. "The best option is a missing option." cheers, =mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 11:48:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29390; Tue, 20 Jun 95 11:48:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29384; Tue, 20 Jun 95 11:47:52 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12963; Tue, 20 Jun 1995 11:38:03 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id LAA18524; Tue, 20 Jun 1995 11:38:01 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15034(3)>; Tue, 20 Jun 1995 11:36:52 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 20 Jun 1995 11:36:46 -0700 To: Dan McDonald Cc: ipng@sunroof2.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 215) Re: Re: Re: Am I a router or host if... In-Reply-To: danmcd's message of Tue, 20 Jun 95 10:56:45 -0800. <9506201756.aa08616@cs.nrl.navy.mil> Date: Tue, 20 Jun 1995 11:36:39 PDT From: Steve Deering Message-Id: <95Jun20.113646pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dan, > If the IPv6 header destination field is one of my addresses, but then there > is a source routing header which has someone else as the FINAL destination, > must I as a host forward the packet? Or do I drop the packet because I'm a > host, not a router? You forward the packet. All nodes forward source-routed packets explicitly addressed to themselves. Only routers forward packets not explicitly addressed to themselves. > As with all source-routing issues, there is security to consider. (Source > routing attacks exist!) It is the responsibility of the final destination to defend itself from those attacks, e.g., by not reversing a source route in an unauthenticated packet. > Jim, if a node has both host and router functionality, it is considered > (according to the IPv6 spec definition) a router. ... > > A rule of thumb is that a router can (should?) do anything a host can do, > but not the other way around. Perhaps viewing a router as a superset of a > host? > > Steve, Bob, anyone? Am I understanding this? Yes, Dan, you've got it. By the way, at the ipng meeting last week, we decided to get rid of the all-hosts (i.e., all-non-routers) multicast address. The only place where it could possibly have been used was in the neighbor discovery protocol, but it turned out to be unnecessary there. So, now there's just all-nodes and all-routers. > Your welcome. I brought it up because in 4.4-Lite, the IPv4 code forwards > source routing packets while not forwarding normal packets. This is not > good, because it's inconsistent. It is consistent with the IPv6 definitions. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 12:17:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29412; Tue, 20 Jun 95 12:17:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29406; Tue, 20 Jun 95 12:17:26 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17491; Tue, 20 Jun 1995 12:07:30 -0700 Received: from vangogh.CS.Berkeley.EDU by mercury.Sun.COM (Sun.COM) id MAA22259; Tue, 20 Jun 1995 12:07:28 -0700 Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Beta.2/8.7.Beta.2) id MAA07893; Tue, 20 Jun 1995 12:03:28 -0700 (PDT) Date: Tue, 20 Jun 1995 12:03:28 -0700 (PDT) From: Keith Sklower Message-Id: <199506201903.MAA07893@vangogh.CS.Berkeley.EDU> To: bound@zk3.dec.com, mdavis@BayNetworks.com Subject: (IPng 216) Re: Re: Re: Re: Am I a router or host if... Cc: danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >>>>> "bound" == Jim Bound writes: bound> Dan, bound> I think in "ALL" cases you should drop the packet unless bound> the "node" is configured as a router. Anyone DISAGREE? If bound> so WHY? (thx).... bound> BUT..................... bound> I am not sure what the "RULES" are if a "node" is acting as bound> both a router and a host for IPv6? Anyone else know of any ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ bound> RULES here or can we use our freedom and creativity as bound> implementors to build both functions in one machine? >>>>> "davis" =- Mike Davis davis> The "RULES" are pretty clear that a node is exactly one of "host" or davis> "router" at a time. There is no rule saying that this configuration davis> cannot change over time, but your assumption above can never be true. May I submit that that part of what helped make TCP/IPv4 pervasive was the fact that you **didn't** have to go out and buy a special purpose router in order to use it, and that in many situations, people started out with a single machine which acted both as a router and a host? This is still happening today -- (I have friends over in the San Francisco department of public health who have scads of PC's running Novell netware, and *one* vax with TGV multinet on it acting as both a router and a host). Of course, Mike and I have directly contrary interest since I (used to) build hosts that could act also as routers, and Mike sells routers. Once people get their feet wet, and decide they like it, and the network expands, then they can afford to buy a router. I'm not arguing that routers are unnecessary (some of my best friends work for router makers), but that *at the entry level* it is *desireable* that systems can function as both. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 12:35:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29429; Tue, 20 Jun 95 12:35:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29423; Tue, 20 Jun 95 12:34:47 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19596; Tue, 20 Jun 1995 12:24:53 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id MAA24251; Tue, 20 Jun 1995 12:24:49 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA01576; Tue, 20 Jun 95 15:20:33 EDT Received: from karma.engeast by BayNetworks.com (4.1/SMI-4.1) id AA06828; Tue, 20 Jun 95 15:21:53 EDT Date: Tue, 20 Jun 95 15:21:53 EDT From: mdavis@BayNetworks.com (Mike Davis) Message-Id: <9506201921.AA06828@BayNetworks.com> Received: by karma.engeast (4.1/SMI-4.1) id AA03481; Tue, 20 Jun 95 15:21:49 EDT To: sklower@CS.Berkeley.EDU Cc: bound@zk3.dec.com, danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <199506201903.MAA07893@vangogh.CS.Berkeley.EDU> (message from Keith Sklower on Tue, 20 Jun 1995 12:03:28 -0700 (PDT)) Subject: (IPng 217) Re: Re: Re: Re: Am I a router or host if... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >>>>> "davis" =- Mike Davis davis> The "RULES" are pretty clear that a node is exactly one of davis> "host" or "router" at a time. There is no rule saying that davis> this configuration cannot change over time, but your davis> assumption above can never be true. >>>>> "Keith" == Keith Sklower writes: Keith> May I submit that that part of what helped make TCP/IPv4 Keith> pervasive was the fact that you **didn't** have to go out Keith> and buy a special purpose router in order to use it, and Keith> that in many situations, people started out with a single Keith> machine which acted both as a router and a host? This is Keith> still happening today -- (I have friends over in the San Keith> Francisco department of public health who have scads of Keith> PC's running Novell netware, and *one* vax with TGV Keith> multinet on it acting as both a router and a host). You may submit it. I'll believe it. Entirely beside the point. The point is: Jim wanted to know whether an IPv6 node could be a host and a router at the same time. I said no, by our own definition. (Dan McD.'s recent post explains why *much* better than I did.) Now, the fact that these definitions don't accord with many people's a priori notions of what a "host" and a "router" are is just an artifact. People even tried to have the terms changed at the Cambridge IPng meeting, but they didn't succeed. The result is that we got what we got, along with all the implications pointed out by others. Keith> Of course, Mike and I have directly contrary interest since Keith> I (used to) build hosts that could act also as routers, and Keith> Mike sells routers. Sure I want to sell the products that I help engineer, but that makes none of what I say more or less true. But that's not what you were implying, I assume. Keith> Once people get their feet wet, and decide they like it, Keith> and the network expands, then they can afford to buy a Keith> router. I'm not arguing that routers are unnecessary (some Keith> of my best friends work for router makers), but that *at Keith> the entry level* it is *desireable* that systems can Keith> function as both. By the definitions in draft-ietf-ipngwg-ipv6-spec-02.txt, a $100 XT clone with the right software is a router *iff* it "forwards IPv6 packets not explicitly addressed to itself." If you need a lean, mean, forwardin' machine, call our sales force. But I agree, you don't need them to run IPv6. --mad Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 12:44:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29452; Tue, 20 Jun 95 12:44:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29445; Tue, 20 Jun 95 12:43:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20590; Tue, 20 Jun 1995 12:34:06 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id MAA25357; Tue, 20 Jun 1995 12:34:04 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09662; 20 Jun 95 14:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 218) I-D ACTION:draft-ietf-ipngwg-ipv6-spec-02.txt Date: Tue, 20 Jun 95 14:50:19 -0400 Message-Id: <9506201450.aa09662@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Internet Protocol, Version 6 (IPv6) Specification Author(s) : S. Deering, R. Hinden Filename : draft-ietf-ipngwg-ipv6-spec-02.txt Pages : 32 Date : 06/19/1995 This document specifies version 6 of the Internet Protocol, a proposed successor to IP version 4. Changes from the previous draft are listed in Appendix B. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-spec-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-spec-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-spec-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950619171655.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-spec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-spec-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950619171655.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 12:51:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29474; Tue, 20 Jun 95 12:51:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29468; Tue, 20 Jun 95 12:50:53 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21345; Tue, 20 Jun 1995 12:41:06 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id MAA26113; Tue, 20 Jun 1995 12:41:02 -0700 Received: from relay.imsi.com by wintermute.imsi.com id PAA15580; Tue, 20 Jun 1995 15:40:40 -0400 Received: from snark.imsi.com by relay.imsi.com id PAA22319; Tue, 20 Jun 1995 15:40:39 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02997; Tue, 20 Jun 95 15:40:39 EDT Message-Id: <9506201940.AA02997@snark.imsi.com> To: Keith Sklower Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 219) Re: Re: Re: Re: Re: Am I a router or host if... In-Reply-To: Your message of "Tue, 20 Jun 1995 12:03:28 PDT." <199506201903.MAA07893@vangogh.CS.Berkeley.EDU> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 20 Jun 1995 15:40:38 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Keith Sklower writes: > > davis> The "RULES" are pretty clear that a node is exactly one of "host" or > davis> "router" at a time. There is no rule saying that this configuration > davis> cannot change over time, but your assumption above can never be true. > > May I submit that that part of what helped make TCP/IPv4 pervasive > was the fact that you **didn't** have to go out and buy a special > purpose router in order to use it, and that in many situations, > people started out with a single machine which acted both as a router > and a host? Nothing in the IPv6 specs stops this. I expect that many operating systems will permit hosts to be routers optionally, but of course at that time the host should behave like a router, per the specs. A router is allowed to also act as a host, you know -- router is sort of a superset of host. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 14:03:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29585; Tue, 20 Jun 95 14:03:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29579; Tue, 20 Jun 95 14:03:26 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00749; Tue, 20 Jun 1995 13:53:37 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id NAA05166; Tue, 20 Jun 1995 13:53:35 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA05661; Tue, 20 Jun 95 16:52:01 EDT Received: from karma.engeast by BayNetworks.com (4.1/SMI-4.1) id AA11539; Tue, 20 Jun 95 16:53:22 EDT Date: Tue, 20 Jun 95 16:53:22 EDT From: mdavis@BayNetworks.com (Mike Davis) Message-Id: <9506202053.AA11539@BayNetworks.com> Received: by karma.engeast (4.1/SMI-4.1) id AA03491; Tue, 20 Jun 95 16:53:11 EDT To: perry@imsi.com Cc: sklower@CS.Berkeley.EDU, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506201940.AA02997@snark.imsi.com> (perry@imsi.com) Subject: (IPng 220) Re: Re: Re: Re: Re: Re: Am I a router or host if... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >>>>> "Perry" == Perry E Metzger writes: Perry> Nothing in the IPv6 specs stops this. I expect that many Perry> operating systems will permit hosts to be routers Perry> optionally, but of course at that time the host should Perry> behave like a router, per the specs. A router is allowed to Perry> also act as a host, you know -- router is sort of a Perry> superset of host. We continue to have this fallacy. Host means two different things that are getting conflated: 1) a device that runs telnet or ftp or Doom. 2) a device that runs IPv6 and is not a router. A router is a node that can forward packets not explictly addressed to itself. By simple thought experiment a device could do 1 & 2 together. By the definitions we have adopted, a device cannot simultaneously do 2 & still be called an IPv6 host. Perry> Perry --mad Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 14:11:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29616; Tue, 20 Jun 95 14:11:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29610; Tue, 20 Jun 95 14:11:25 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01850; Tue, 20 Jun 1995 14:01:39 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id OAA06212; Tue, 20 Jun 1995 14:01:37 -0700 Received: from relay.imsi.com by wintermute.imsi.com id QAA16339; Tue, 20 Jun 1995 16:59:46 -0400 Received: from snark.imsi.com by relay.imsi.com id QAA24126; Tue, 20 Jun 1995 16:59:45 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA03213; Tue, 20 Jun 95 16:59:45 EDT Message-Id: <9506202059.AA03213@snark.imsi.com> To: mdavis@BayNetworks.com (Mike Davis) Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 221) Re: Re: Re: Re: Re: Re: Am I a router or host if... In-Reply-To: Your message of "Tue, 20 Jun 1995 16:53:22 EDT." <9506202053.AA11539@BayNetworks.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 20 Jun 1995 16:59:44 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Mike Davis writes: > We continue to have this fallacy. Host means two different things > that are getting conflated: > > 1) a device that runs telnet or ftp or Doom. > 2) a device that runs IPv6 and is not a router. A router is a node > that can forward packets not explictly addressed to itself. > > By simple thought experiment a device could do 1 & 2 together. By the > definitions we have adopted, a device cannot simultaneously do 2 & > still be called an IPv6 host. True enough -- the point is that a unix box can qualify as a "router" and still run applications. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 15:49:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29657; Tue, 20 Jun 95 15:49:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29651; Tue, 20 Jun 95 15:49:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16893; Tue, 20 Jun 1995 15:39:55 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id PAA18991; Tue, 20 Jun 1995 15:39:50 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14971(4)>; Tue, 20 Jun 1995 15:39:39 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 20 Jun 1995 15:39:30 -0700 To: mankin@isi.edu, sob@ndtl.harvard.edu Cc: scoya@cnri.reston.va.us, ipng@sunroof.Eng.Sun.COM, rcallon@baynetworks.com, hinden@ipsilon.com, deering@parc.xerox.com Subject: (IPng 222) request for advancemment of initial IPng documents Date: Tue, 20 Jun 1995 15:39:28 PDT From: Steve Deering Message-Id: <95Jun20.153930pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dear Allison and Scott, The chairs and document editor of the IP Next Generation working group, on behalf of the working group, request that the following documents be published as RFCs with Proposed Standard status, after an IETF Last Call: (1) Internet Protocol, Version 6 (IPv6) Specification, draft-ietf-ipngwg-ipv6-spec-02.txt (2) IP Version 6 Addressing Architecture, draft-ietf-ipngwg-addr-arch-03.txt (3) Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6), draft-ietf-ipngwg-icmp-02.txt (4) DNS Extensions to Support IP Version 6, draft-ietf-ipngwg-dns-00.txt We also request that the following document be published as an RFC, preferably with the rumored new "Operational Practices" status or, less preferably, with Informational status: (5) An Architecture for IPv6 Unicast Address Allocation, draft-ietf-ipngwg-unicst-addr-allo-01.txt Steve Deering Ross Callon Bob Hinden ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 17:13:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29786; Tue, 20 Jun 95 17:13:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29780; Tue, 20 Jun 95 17:13:42 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29227; Tue, 20 Jun 1995 17:03:55 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id RAA28456; Tue, 20 Jun 1995 17:03:50 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15048(4)>; Tue, 20 Jun 1995 17:03:45 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 20 Jun 1995 17:03:41 -0700 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng 223) corrections to latest IPv6 spec Date: Tue, 20 Jun 1995 17:03:32 PDT From: Steve Deering Message-Id: <95Jun20.170341pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In the less-than-two days since I submitted the latest IPv6 spec as an Internet Draft, the following 3 bugs have been brought to my attention. Since these are relatively minor problems, I decided not to immediately update the internet draft, but rather to wait to see if the IETF Last Call turns up any additional problems, and then include all the fixes in the RFC version. - In the examples of how to lay out options, on page 29, two places where it says "Hdr Ext Len=1" should be "Hdr Ext Len=3" (reported by Hamid Asayesh). - In section 6, Flow Labels, I forgot to include the Priority field in the list of fields that must have the same value for all packets in the same flow (reported by Markus Jork). - The description of what the Jumbo Payload Length field covers should be made clearer (reported by Christian Huitema). Keep those cards and letters coming! Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 19:09:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29888; Tue, 20 Jun 95 19:09:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29882; Tue, 20 Jun 95 19:09:34 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09187; Tue, 20 Jun 1995 18:59:46 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id SAA09758; Tue, 20 Jun 1995 18:59:47 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28413; Wed, 21 Jun 1995 11:59:36 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 224) IPv6 payload header draft Date: Wed, 21 Jun 1995 11:59:27 +1000 Message-Id: <4579.803699967@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Back in March I submitted draft-kre-ipv6-payload-00.txt based on an idea formed in San Jose. It wasn't discussed in Danvers (IPngwg had better things to do with its time). So far there have been almost no comemnts at all. I'd appreciate some feedback, of whatever kind. If nothing further eventuates before the end of the Stockholm meeting I'll send it to the RFC editor as a proposed standard... kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 20:30:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29932; Tue, 20 Jun 95 20:30:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29926; Tue, 20 Jun 95 20:30:21 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13004; Tue, 20 Jun 1995 20:20:32 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id UAA15113; Tue, 20 Jun 1995 20:20:24 -0700 Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AB01887; Wed, 21 Jun 1995 13:20:13 +1000 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA16906; Wed, 21 Jun 95 12:59:09 +1000 Received: by dcthq2.datacraft.com.au; Wed, 21 Jun 95 13:22:56 +1100 Date: Wed, 21 Jun 95 13:13:16 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 225) comments on Sec arch for IP X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk this probably should be on the sec list is it ipsec? A text comment Page 6 S 1.4 Para after bullets. " A sending host uses userid and dest addr to select the SPI". ie it is source selected. Page 6 S 1.4 Two paras on from the above. "In the case of unicast traffic, the destination will normally select the SPI value.... and so on. The sentences after this do not make sense re automatic / manual configuration, if the Security Association is in fact just one way (intermediate para on P6). please clariy regards alan@oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 22:02:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00133; Tue, 20 Jun 95 22:02:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00127; Tue, 20 Jun 95 22:02:27 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16156; Tue, 20 Jun 1995 21:52:36 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id VAA20660; Tue, 20 Jun 1995 21:52:27 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Wed, 21 Jun 1995 13:44:52 +0859 From: Masataka Ohta Message-Id: <199506210445.NAA04326@necom830.cc.titech.ac.jp> Subject: (IPng 226) Re: Re: Re: Am I a router or host if... To: danmcd@cs.nrl.navy.mil (Dan McDonald) Date: Wed, 21 Jun 95 13:44:50 JST Cc: bound@zk3.dec.com, danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506201756.aa08616@cs.nrl.navy.mil>; from "Dan McDonald" at Jun 20, 95 12:56 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > If my node is acting as a router, I have a bit turned on somewhere that says > it's a router. This means I still get all-NODES multicast, but I don't get > all-HOSTS multicast. And, as briefly discussed in the interim meeting, there is an open issue on multi-interface nodes. To construct a routing table to choose an appropriate interface, it seems to me that multi-interface hosts should partially act as routers such as listening to all-router multicast. Or, should multi-interface nodes be requested to be routers? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 22:46:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00187; Tue, 20 Jun 95 22:46:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00181; Tue, 20 Jun 95 22:46:39 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17569; Tue, 20 Jun 1995 22:36:49 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id WAA23161; Tue, 20 Jun 1995 22:36:50 -0700 Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA07185; Wed, 21 Jun 1995 15:36:28 +1000 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA17453; Wed, 21 Jun 95 15:15:42 +1000 Received: by dcthq2.datacraft.com.au; Wed, 21 Jun 95 15:39:25 +1100 Date: Wed, 21 Jun 95 15:18:38 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 227) ipv6 spec X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk some thoughts on "conformance". Many of the IPng specs have put MUST, SHOULD, MAY..to clarify conformance levels and optionality. the IPv6 spec 02 does not do this. Should this be added. Specifically Origin and Receipt conformance world be useful. Conformance meaning the ability to process (not just set it to 0). eg FIELD ORIGIN RECEIPT Version M set to 6 M Priority O (can be 0) M (must be processed) Flow Label O M PayL Lenght M (unless jumbo used) M Next Hddr M M Hop Limit M M Src Adr M M Dst Adr M M Hop by Hop x O M Route Opt O M Frag Opt O M Auth Opt O M etc. thoughts please regards alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 20 23:25:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00226; Tue, 20 Jun 95 23:25:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00220; Tue, 20 Jun 95 23:25:27 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18757; Tue, 20 Jun 1995 23:15:40 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id XAA25231; Tue, 20 Jun 1995 23:15:39 -0700 Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA08518; Wed, 21 Jun 1995 16:14:49 +1000 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA17505; Wed, 21 Jun 95 15:26:01 +1000 Received: by dcthq2.datacraft.com.au; Wed, 21 Jun 95 15:49:41 +1100 Date: Wed, 21 Jun 95 15:47:30 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 228) ipv6 conformance - correction X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk my last post listed ipv6 fields and Mandatory and Optional conformance. I put flow id as M on receipt. naturally this should be O (but passed unchanged). whoops alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 00:14:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00320; Wed, 21 Jun 95 00:14:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00314; Wed, 21 Jun 95 00:14:16 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20722; Wed, 21 Jun 1995 00:04:29 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id AAA27980; Wed, 21 Jun 1995 00:04:28 -0700 Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA10381; Wed, 21 Jun 1995 17:04:12 +1000 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA17695; Wed, 21 Jun 95 16:43:46 +1000 Received: by dcthq2.datacraft.com.au; Wed, 21 Jun 95 17:07:32 +1100 Date: Wed, 21 Jun 95 16:42:13 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 229) comments on ESP draft X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk this is more of a question. Labeling and Tokens These terms are used as follows (I believe). Label to indicate the "nature" of the message with respect to the organisational policy for that data exchange. labels contain: Policy Ids, Message Classification (secret, etc), privacy mark and categories (for rules based access control) . see SDN701(MSP), X.411, X.509 enhancements). Tokens generally indicate the security parameters used to sign/and or encrypt, key the actual message. These in my mind are all very explicit terms and definitions and are used to define the security domains within which data is tranferred. See X.400, SDN701, etc. end of preamble In ESP S 3.2 "Security Labeling with ESP" the text mentions "implicit labels". These are also mentioned in the Sec Arch for IP doc. The ESP text says that implementations that claim MLS MUST support "implicit labels. I find this a curious concept. Conformance to something which is implicit. How is this tested, what are the benchmarks for MLS. What are the relationships to labels (if they are as identified above) and MLS? one still might support a single level label. and again if they are "implicit" who is to know? It seems that ESP can be limited to a header that provides and SPI folowedby the encrypted data. 2 modes of working namely transport and tunnel. a mandatory scheme namely DES CBC The rest is optional or implicit. Dont flame me on this. If people think this is useful, then OK However, with security, I would like to see things that are MUSTed in these docs relate to HARD data and provable implememtation. Having just two implemetations that just work on their own because of "implicit label" definitions is NOT proof that the build/design is useful, scaleable and reusable. thoughts please regards alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 00:23:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00336; Wed, 21 Jun 95 00:23:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00330; Wed, 21 Jun 95 00:23:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21087; Wed, 21 Jun 1995 00:13:26 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id AAA28511; Wed, 21 Jun 1995 00:13:25 -0700 Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA10718; Wed, 21 Jun 1995 17:13:17 +1000 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA17743; Wed, 21 Jun 95 16:52:47 +1000 Date: Wed, 21 Jun 95 16:52:47 +1000 Message-Id: <9506210652.AA17743@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au; Wed, 21 Jun 95 17:16:40 +1100 Resent-Date: Tue, 20 Jun 95 16:12:46 +1100 Resent-Message-Id: Resent-From: Alan.Lloyd@datacraft.com.au From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 230) comments on Routing aspects of ipv6 transition X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Forwarded to: internet[ipng@sunroof.eng.sun.com] cc: Comments by: Alan Lloyd@Marketing@DCTHQ -------------------------- [Original Message] ------------------------- This is a general comment. This document seems to repeat much of the text in the IPv6 transition mechanisms for H & R. Therefore title and structure come into question. Should the IPv6 transition spec cover Tunnels ICMP, SNMP, OSPF, API and DNS changes etc and describe how these things at ahigh level are being addressed and; Routing aspects be a subordinate document of that. As would be the others. OR should both documents just relate to tunnels and addressing and just be rolled into one. At least the tables from both docs should be drawn together. Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 06:00:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00502; Wed, 21 Jun 95 06:00:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00496; Wed, 21 Jun 95 06:00:07 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07497; Wed, 21 Jun 1995 05:50:19 -0700 Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM) id FAA15462; Wed, 21 Jun 1995 05:50:20 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 05:50:18 -0700 Posted-Date: Wed, 21 Jun 1995 05:48:17 -0700 (PDT) Message-Id: <199506211248.AA04034@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 21 Jun 1995 05:48:17 -0700 Subject: (IPng 231) Re: What is a Router? To: mdavis@baynetworks.com (Mike Davis) Date: Wed, 21 Jun 1995 05:48:17 -0700 (PDT) Cc: perry@imsi.com, sklower@CS.Berkeley.EDU, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506202053.AA11539@BayNetworks.com> from "Mike Davis" at Jun 20, 95 04:53:22 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > We continue to have this fallacy. Host means two different things > that are getting conflated: > > 1) a device that runs telnet or ftp or Doom. > 2) a device that runs IPv6 and is not a router. A router is a node > that can forward packets not explictly addressed to itself. > > By simple thought experiment a device could do 1 & 2 together. By the > definitions we have adopted, a device cannot simultaneously do 2 & > still be called an IPv6 host. > Hum. RFC 1009 and RFC 1716, along with their replacment, specify that a router (nee gateway) is a special purpose host. Of course they are only relevent to IPv4. If the IPv6 docs are changing this assumption, then the transition work has the potential to be "interesting". --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 06:36:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00530; Wed, 21 Jun 95 06:36:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00524; Wed, 21 Jun 95 06:35:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10014; Wed, 21 Jun 1995 06:26:02 -0700 Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM) id GAA18522; Wed, 21 Jun 1995 06:26:01 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 06:25:54 -0700 Posted-Date: Wed, 21 Jun 1995 06:23:52 -0700 (PDT) Message-Id: <199506211323.AA04132@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 21 Jun 1995 06:23:52 -0700 Subject: (IPng 232) Re: Re: Re: Re: Re: Am I a router or host if... To: mdavis@baynetworks.com (Mike Davis) Date: Wed, 21 Jun 1995 06:23:52 -0700 (PDT) Cc: sklower@CS.Berkeley.EDU, bound@zk3.dec.com, danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506201921.AA06828@BayNetworks.com> from "Mike Davis" at Jun 20, 95 03:21:53 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > You may submit it. I'll believe it. Entirely beside the point. The > point is: Jim wanted to know whether an IPv6 node could be a host and > a router at the same time. I said no, by our own definition. (Dan > McD.'s recent post explains why *much* better than I did.) Now, the > fact that these definitions don't accord with many people's a priori > notions of what a "host" and a "router" are is just an artifact. > People even tried to have the terms changed at the Cambridge IPng > meeting, but they didn't succeed. The result is that we got what we > got, along with all the implications pointed out by others. > > Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 > ------------------------------------------------------------------------------ Ur, this is wrong. Any router can function as a host (processing packets addressed to itself) while also acting as a router (processing packets -not- addressed to itself). Take a Wellfleet for example. It can be processing SNMP queries while forwarding packets. We have cisco 7000 routers acting as hosts on our test ATM net. (no they are not routing anything... in this capacity). Routers are hosts with special capabilities. Check out RFC 1716. However, I leave it to the good folks who are doing IPv6 implementations to break the model set with IPv4 in RFC 1009 and RFC 1716. I expect that unless done correctly, that this may kill IPv6. -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 06:55:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00556; Wed, 21 Jun 95 06:55:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00550; Wed, 21 Jun 95 06:55:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB11372; Wed, 21 Jun 1995 06:45:17 -0700 Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM) id GAA20253; Wed, 21 Jun 1995 06:45:17 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 06:44:57 -0700 Posted-Date: Wed, 21 Jun 1995 06:42:56 -0700 (PDT) Message-Id: <199506211342.AA04215@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 21 Jun 1995 06:42:57 -0700 Subject: (IPng 233) Re: Host? To: deering@parc.xerox.com (Steve Deering) Date: Wed, 21 Jun 1995 06:42:56 -0700 (PDT) Cc: danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM, deering@parc.xerox.com In-Reply-To: <95Jun20.113646pdt.75270@digit.parc.xerox.com> from "Steve Deering" at Jun 20, 95 11:36:39 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > A rule of thumb is that a router can (should?) do anything a host can do, > > but not the other way around. Perhaps viewing a router as a superset of a > > host? > > Very few routers have file systems, many do not support what are considered basic internet services (telnet, ftp, www, etc). They are special purpose hosts, along with things like RMON probes, Terminal Servers, etc. Except where specified (in RFC 1716) they should behave like hosts (RFC 1122/1123). -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 07:01:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00568; Wed, 21 Jun 95 07:01:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00562; Wed, 21 Jun 95 07:01:19 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11753; Wed, 21 Jun 1995 06:51:31 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id GAA20700; Wed, 21 Jun 1995 06:51:30 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA21625; Wed, 21 Jun 95 09:47:18 EDT Received: from karma.engeast by BayNetworks.com (4.1/SMI-4.1) id AA09272; Wed, 21 Jun 95 09:48:38 EDT Date: Wed, 21 Jun 95 09:48:38 EDT From: mdavis@BayNetworks.com (Mike Davis) Message-Id: <9506211348.AA09272@BayNetworks.com> Received: by karma.engeast (4.1/SMI-4.1) id AA03562; Wed, 21 Jun 95 09:48:35 EDT To: bmanning@ISI.EDU Cc: sklower@CS.Berkeley.EDU, bound@zk3.dec.com, danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <199506211323.AA04132@zed.isi.edu> (bmanning@ISI.EDU) Subject: (IPng 234) Re: Am I a router or host if... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >>>>> "bill" == bmanning writes: >> You may submit it. I'll believe it. Entirely beside the point. The >> point is: Jim wanted to know whether an IPv6 node could be a host and >> a router at the same time. I said no, by our own definition. (Dan >> McD.'s recent post explains why *much* better than I did.) Now, the >> fact that these definitions don't accord with many people's a priori >> notions of what a "host" and a "router" are is just an artifact. >> People even tried to have the terms changed at the Cambridge IPng >> meeting, but they didn't succeed. The result is that we got what we >> got, along with all the implications pointed out by others. >> bill> Ur, this is wrong. Any router can function as a host bill> (processing packets addressed to itself) while also acting bill> as a router (processing packets -not- addressed to itself). See one of my other notes on this topic. What labels we're putting on the box (host or router) is only dependent on whether that device forwards IPv6 packets not explicitly addressed to itself. bill> Take a Wellfleet for example. It can be processing SNMP bill> queries while forwarding packets. bill> We have cisco 7000 routers acting as hosts on our test ATM bill> net. (no they are not routing anything... in this capacity). bill> Routers are hosts with special capabilities. Check out RFC bill> 1716. All this is well and good and true WRT IPv4. IPv6 has a definition of what a router is (forwards packets not addressed to itself) and what a host is ({nodes} - {routers}). This is simply a matter of definition. This does not prevent a device that is an IPv6 router from processing SNMP packets. Both hosts and routers can run applications other than routing. Maybe some Venn Diagrams would help: nodes --------------------------- --------------------------- | hosts | | | | | ------------ | | | | | | routers | | | hosts | routers | | | | | | | | | ------------ | | | | | | | | | --------------------------- --------------------------- v4 v6 So, purely as a matter of terminology, we see that in IPv4, routers are a subset of hosts. In IPv6, hosts and routers are disjoint and exhaustive subsets of nodes. Check out draft-ietf-ipngwg-ipv6-spec-02.txt to see the precise wording of the definitions. bill> However, I leave it to the good folks who are doing IPv6 bill> implementations to break the model set with IPv4 in RFC 1009 bill> and RFC 1716. I expect that unless done correctly, that bill> this may kill IPv6. It's just a matter of terminology. We don't want to prevent functionality. bill> -- bill> --bill Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 07:47:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00610; Wed, 21 Jun 95 07:47:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00604; Wed, 21 Jun 95 07:47:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15702; Wed, 21 Jun 1995 07:37:20 -0700 Received: from inet-gw-3.pa.dec.com by mercury.Sun.COM (Sun.COM) id HAA24965; Wed, 21 Jun 1995 07:37:07 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA15183; Wed, 21 Jun 95 07:33:55 -0700 Received: by xirtlu.zk3.dec.com; id AA17910; Wed, 21 Jun 1995 10:32:53 -0400 Message-Id: <9506211432.AA17910@xirtlu.zk3.dec.com> To: "Mike O'Dell" Cc: bound@zk3.dec.com, smb@research.att.com, ipng@sunroof.Eng.Sun.COM, sthomas@mindspring.com Subject: (IPng 235) Re: Re: Re: Re: Optional Upper Level Checksums and Authentication In-Reply-To: Your message of "Tue, 20 Jun 95 13:56:47 EDT." Date: Wed, 21 Jun 95 10:32:47 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Mike, >Remember how much trouble was caused when NFS turned-off UDP checksums >(and it was even LEGAL)????? Well I have seen NFS work fine with UDP and no check-sums. So I guess we all have different experiences. Thats what so neat about all us folks being on this work effort. >optional checksums are no checksum - just don't do it. Not saying make it an option at all. If there is a security payload then you do not have to do the checksum. Thats the question on the table. I am not saying do it, but discuss it OK. > "The best option is a missing option." Yes but with all this security the cost is going to be high so I think an IETF WG discussion where we may gain performance is worth hearing. "Our job as a standards body is to create a flexible, but interoperable set of standards that can be used within product architectures to meet the needs of the buying public. These standards should not inhibit performance whenever possible, unless they have a great gain to the buying public, and can be implemented by that publics suppliers. When we create standards that may not be used by the public, and also cannot be implemeneted by that publics suppliers, we are simply in a folly and most likely some manner of politics is the root cause of that folly." /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 08:07:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00657; Wed, 21 Jun 95 08:07:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00651; Wed, 21 Jun 95 08:07:29 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17725; Wed, 21 Jun 1995 07:57:40 -0700 Received: from mail1.digital.com by venus.Sun.COM (Sun.COM) id HAA00670; Wed, 21 Jun 1995 07:57:39 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA04282; Wed, 21 Jun 1995 07:49:23 -0700 Received: by xirtlu.zk3.dec.com; id AA18315; Wed, 21 Jun 1995 10:49:14 -0400 Message-Id: <9506211449.AA18315@xirtlu.zk3.dec.com> To: mdavis@baynetworks.com (Mike Davis) Cc: perry@imsi.com, sklower@CS.Berkeley.EDU, ipng@sunroof2.Eng.Sun.COM, bound@zk3.dec.com Subject: (IPng 236) Re: Re: Re: Re: Re: Re: Re: Am I a router or host if... In-Reply-To: Your message of "Tue, 20 Jun 95 16:53:22 EDT." <9506202053.AA11539@BayNetworks.com> Date: Wed, 21 Jun 95 10:49:07 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Perry> Nothing in the IPv6 specs stops this. I expect that many Perry> operating systems will permit hosts to be routers Perry> optionally, but of course at that time the host should Perry> behave like a router, per the specs. A router is allowed to Perry> also act as a host, you know -- router is sort of a Perry> superset of host. Mike>We continue to have this fallacy. Host means two different things Mike>that are getting conflated: Mike>1) a device that runs telnet or ftp or Doom. Mike>2) a device that runs IPv6 and is not a router. A router is a node Mike> that can forward packets not explictly addressed to itself. Mike>By simple thought experiment a device could do 1 & 2 together. By the Mike>definitions we have adopted, a device cannot simultaneously do 2 & Mike>still be called an IPv6 host. If you build a router that does 1 & 2. Well thats just one hell of a router which is fine by me. I do concur with Keith on this too, and it appears I can build someday the product I have in mind so I am out of this loop as we had discussed these definitions but Dan's original question on the source route packet has been answered by Steve. I was surprised that as a host I should forward a source route packet I get to my address. But I think this is an optimal approach and can think of other good uses of this architectural approach. thanks all, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 08:15:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00676; Wed, 21 Jun 95 08:15:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00670; Wed, 21 Jun 95 08:15:28 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18703; Wed, 21 Jun 1995 08:05:40 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id IAA28186; Wed, 21 Jun 1995 08:05:38 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14958(1)>; Wed, 21 Jun 1995 08:05:18 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 21 Jun 1995 08:05:12 -0700 To: bmanning@isi.edu Cc: sklower@cs.berkeley.edu, ipng@sunroof2.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 237) Re: Re: What is a Router? In-Reply-To: bmanning's message of Wed, 21 Jun 95 05:48:17 -0800. <199506211248.AA04034@zed.isi.edu> Date: Wed, 21 Jun 1995 08:04:58 PDT From: Steve Deering Message-Id: <95Jun21.080512pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > RFC 1009 and RFC 1716, along with their replacment, specify that > a router (nee gateway) is a special purpose host. > Of course they are only relevent to IPv4. If the IPv6 docs are > changing this assumption, then the transition work has the potential > to be "interesting". The IPv6 docs are not changing any such assumptions. They are simply trying to use terminology more precisely. In the IPv4 specifications, the word "host" is used ambiguously: sometimes it means anything that runs IP, and sometimes it means not-a-router. In IPv6, in order to avoid that ambiguity, we introduced the term "node" for the first of those concepts (anything that runs IP), and we use the term "host" only for the second concept (not-a- router). So the above quoted text remains the same for IPv6, except you change the word "host" to "node". Restating this another way (since people obviously are struggling with this), the IPv6 specs have, in various places, the need to refer to three different sets of IPv6 devices. Those three sets are as follows, with the v4 and v6 terms indicated: IPv4 term IPv6 term --------- --------- forwarders routers routers non-forwarders hosts hosts U(forwarders, non-forwarders) hosts nodes where a "forwarder" is an IPv6 device that is configured to forward IPv6 packets not explicitly addressed to itself. Another source of confusion/ambiguity is the "colloquial" uses of these terms: a "router" is a device primarily intended to do packet forwarding (like a cisco) and a host is a device primarily intended to things other than packet forwarding (like a Sun workstation). But such a "router" can, of course, be used other than for packet forwarding (e.g., a cisco used only as a dialup terminal server), and such a "host" can be used for packet forwarding (such as a Sun workstation with multiple interfaces running routed). The IPv6 specs have no need to refer to the primary intended purpose of a device, so they do not use the terms "host" and "router" in those colloquial ways. About a year ago, we went through this same discussion, and we solicited proposals for alternative terminology that would avoid misunderstandings. No one could come up with better terms that would not themselves lead to other misunderstandings or confusion. So we decided (at an IPng meeting in Cambridge, MA) to stick with the node/router/hosts terms as defined in the IPv6 spec. OK? Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 08:31:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00700; Wed, 21 Jun 95 08:31:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00694; Wed, 21 Jun 95 08:31:16 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20202; Wed, 21 Jun 1995 08:21:25 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id IAA00101; Wed, 21 Jun 1995 08:21:22 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA24644; Wed, 21 Jun 95 11:16:49 EDT Received: from karma.engeast by BayNetworks.com (4.1/SMI-4.1) id AA14152; Wed, 21 Jun 95 11:18:08 EDT Date: Wed, 21 Jun 95 11:18:08 EDT From: mdavis@BayNetworks.com (Mike Davis) Message-Id: <9506211518.AA14152@BayNetworks.com> Received: by karma.engeast (4.1/SMI-4.1) id AA04338; Wed, 21 Jun 95 11:18:01 EDT To: nt@salford-software-services.co.uk Cc: bmanning@ISI.EDU, sklower@CS.Berkeley.EDU, bound@zk3.dec.com, danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506211420.AA13737@lightning.synoptics.com> (nt@salford-software-services.co.uk) Subject: (IPng 238) Re: Re: Am I a router or host if... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Niall, et al, >>>>> "Niall" == Niall Teasdale writes: (dueling diagrams deleted routers subset of hosts or hosts subset of routers) Niall> v4 hosts perform some of the functionality of a router. They receive Niall> packets, fragment and defragment them, route to higher level Niall> protocols, etc. In addition, routers dispatch packets received Niall> on one interface which are not destined for that interface and may Niall> dispatch certain ICMP messages which are not allowed to non-routing Niall> hosts. I based my original diagram on what Bill Manning reported as the case in RFCs 1009 and 1716. If I am in error, I'll sit corrected, but by calling a router a special purpose host we get the original diagram. Niall> Niall. --mad Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 08:40:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00725; Wed, 21 Jun 95 08:40:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00719; Wed, 21 Jun 95 08:40:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21302; Wed, 21 Jun 1995 08:30:19 -0700 Received: from BBN.COM by mercury.Sun.COM (Sun.COM) id IAA01408; Wed, 21 Jun 1995 08:30:18 -0700 Received: from aland.bbn.com by BBN.COM id aa02973; 21 Jun 95 11:21 EDT Received: by aland.bbn.com (8.6.12/3.1.090690-BBN) id IAA20766; Wed, 21 Jun 1995 08:19:44 -0700 Message-Id: <199506211519.IAA20766@aland.bbn.com> To: Alan.Lloyd@datacraft.com.au Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 239) Re: ipv6 spec In-Reply-To: Your message of Wed, 21 Jun 95 15:18:38 +1100. Date: Wed, 21 Jun 95 08:19:39 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Many of the IPng specs have put MUST, SHOULD, MAY..to clarify conformance levels and optionality. I think the development of a clear use of MUST, SHOULD and MAY has substantially improved many standards and expect IPv6 would benefit too. Note, however, the table below uses M (which could mean MUST or MAY...), so we need a new standard for MUST/MAY shorthand (MU and MA?). Craig the IPv6 spec 02 does not do this. Should this be added. Specifically Origin and Receipt conformance world be useful. Conformance meaning the ability to process (not just set it to 0). eg FIELD ORIGIN RECEIPT Version M set to 6 M Priority O (can be 0) M (must be processed) Flow Label O M PayL Lenght M (unless jumbo used) M Next Hddr M M Hop Limit M M Src Adr M M Dst Adr M M Hop by Hop x O M Route Opt O M Frag Opt O M Auth Opt O M ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 08:42:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00750; Wed, 21 Jun 95 08:42:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00744; Wed, 21 Jun 95 08:42:37 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21654; Wed, 21 Jun 1995 08:32:49 -0700 Received: from usr.com by mercury.Sun.COM (Sun.COM) id IAA01714; Wed, 21 Jun 1995 08:32:49 -0700 Received: from robogate.usr.com ([149.112.2.203]) by usr.com (4.1/3.1.090690-US Robotics ) id AA20129; Wed, 21 Jun 95 10:28:16 CDT Received: from cc:Mail by robogate.usr.com id AA803756047; Wed, 21 Jun 95 10:28:57 CST Date: Wed, 21 Jun 95 10:28:57 CST From: "Pat Calhoun" Message-Id: <9505218037.AA803756047@robogate.usr.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 240) Re: Congestion Indication Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I have received responses to my initial e-mail that I should have indicated where the files can be retrieved instead of attaching the files to my e-mail. So the two files can be downloaded from elroy.usr.com in the directory /pub/ietf. The two files are: ipv6cong.txt (Text version) ipv6cong.ps (Postscript version) I apologize for any inconvenience this has caused. Pat R. Calhoun Lan Access R&D US Robotics Access Corp. pcalhoun@usr.com (708) 933-5181 Frame Relay Forum Member ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 08:49:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00779; Wed, 21 Jun 95 08:49:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00773; Wed, 21 Jun 95 08:49:32 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22409; Wed, 21 Jun 1995 08:39:44 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id IAA02497; Wed, 21 Jun 1995 08:39:31 -0700 Received: from relay.imsi.com by wintermute.imsi.com id LAA19373 for ; Wed, 21 Jun 1995 11:38:35 -0400 Received: from snark.imsi.com by relay.imsi.com id LAA08356 for ; Wed, 21 Jun 1995 11:38:35 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA04467; Wed, 21 Jun 95 11:38:34 EDT Message-Id: <9506211538.AA04467@snark.imsi.com> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 241) Re: What is a Router? In-Reply-To: Your message of "Wed, 21 Jun 1995 08:04:58 PDT." <95Jun21.080512pdt.75270@digit.parc.xerox.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 21 Jun 1995 11:38:33 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I'd like to make a modest proposal. Lets change "host" in the specs to "non-router". Its a neologism, but it makes what we mean totally unambiguous. Then we have nodes that are routers and nodes that are non-routers and thats that -- both could be thought of as "hosts" by the confused. This is a purely cosmetic modification that wouldn't require a new set of drafts. Yes, I know something like it has been proposed several times, but it looks like this continues to be a problem. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 09:29:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00956; Wed, 21 Jun 95 09:29:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00950; Wed, 21 Jun 95 09:28:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27303; Wed, 21 Jun 1995 09:19:07 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id JAA07231; Wed, 21 Jun 1995 09:19:04 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA27978; Wed, 21 Jun 95 12:17:33 EDT Received: from karma.engeast by BayNetworks.com (4.1/SMI-4.1) id AA17162; Wed, 21 Jun 95 12:18:53 EDT Date: Wed, 21 Jun 95 12:18:53 EDT From: mdavis@BayNetworks.com (Mike Davis) Message-Id: <9506211618.AA17162@BayNetworks.com> Received: by karma.engeast (4.1/SMI-4.1) id AA05511; Wed, 21 Jun 95 12:18:50 EDT To: perry@imsi.com Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506211538.AA04467@snark.imsi.com> (perry@imsi.com) Subject: (IPng 242) Re: What is a Router? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >>>>> "Perry" == Perry E Metzger writes: Perry> I'd like to make a modest proposal. Lets change "host" in Perry> the specs to "non-router". 'IPv6 Non-routing host node'? :^) :^) :^) :^) :^) :^) :^) :^) Perry> Perry -mad Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 10:44:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01069; Wed, 21 Jun 95 10:44:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00578; Wed, 21 Jun 95 07:25:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13746; Wed, 21 Jun 1995 07:16:07 -0700 Received: from sun2.nsfnet-relay.ac.uk by mercury.Sun.COM (Sun.COM) id HAA22917; Wed, 21 Jun 1995 07:16:00 -0700 Message-Id: <199506211416.HAA22917@mercury.Sun.COM> Via: uk.co.salford-software-services.e; Wed, 21 Jun 1995 15:12:14 +0100 Received: from pc6.sss.co.uk by e.sss.co.uk with SMTP (PP); Wed, 21 Jun 1995 13:56:26 +0000 X-Sender: nt@e.sss.co.uk X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bmanning@ISI.EDU, deering@parc.xerox.com (Steve Deering) From: nt@salford-software-services.co.uk (Niall Teasdale) Subject: (IPng 243) Re: Re: Host? Cc: danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM, deering@parc.xerox.com Date: Wed, 21 Jun 1995 13:56:29 +0000 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk At 06:42 21/06/95 -0700, bmanning@EDU.ISI wrote: >> > A rule of thumb is that a router can (should?) do anything a host can do, >> > but not the other way around. Perhaps viewing a router as a superset of a >> > host? >> > > >Very few routers have file systems, many do not support what are considered >basic internet services (telnet, ftp, www, etc). > >They are special purpose hosts, along with things like RMON probes, Terminal >Servers, etc. Except where specified (in RFC 1716) they should behave >like hosts (RFC 1122/1123). > The alternative way of looking at it is that hosts perform a subset of the functionality of routers. This is often the way they are implemented, all the code is there and a switch controls whether the sytem is a router or a host. >-- >--bill Niall. **************************************************************************** Niall Teasdale. 3-S (Software) Ltd. nt@sss.co.uk. niall@hedgehog.demon.co.uk WWW Page - htp://mkn.co.uk/help/extra/people/Hedgehog.html The opinions expressed are mine, the mailbox belongs to my employer. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 10:48:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01095; Wed, 21 Jun 95 10:48:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01083; Wed, 21 Jun 95 10:47:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08287; Wed, 21 Jun 1995 10:38:05 -0700 Received: from titan.sprintlink.net by mercury.Sun.COM (Sun.COM) id KAA21752; Wed, 21 Jun 1995 10:38:05 -0700 Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id NAA09550; Wed, 21 Jun 1995 13:38:04 -0400 Date: Wed, 21 Jun 1995 13:38:04 -0400 From: Vadim Antonov Message-Id: <199506211738.NAA09550@titan.sprintlink.net> To: mdavis@BayNetworks.com, perry@imsi.com Subject: (IPng 244) Re: Re: What is a Router? Cc: ipng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Perry> I'd like to make a modest proposal. Lets change "host" in Perry> the specs to "non-router". mad>'IPv6 Non-routing host node'? :^) :^) :^) :^) :^) :^) :^) :^) IPV6NRHN Beats OSI's "ES". --vadim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 10:49:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01110; Wed, 21 Jun 95 10:49:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00594; Wed, 21 Jun 95 07:39:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14984; Wed, 21 Jun 1995 07:29:19 -0700 Received: from sun2.nsfnet-relay.ac.uk by mercury.Sun.COM (Sun.COM) id HAA24267; Wed, 21 Jun 1995 07:29:06 -0700 Message-Id: <199506211429.HAA24267@mercury.Sun.COM> Via: uk.co.salford-software-services.e; Wed, 21 Jun 1995 15:21:00 +0100 Received: from pc6.sss.co.uk by e.sss.co.uk with SMTP (PP); Wed, 21 Jun 1995 14:05:11 +0000 X-Sender: nt@e.sss.co.uk X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mdavis@BayNetworks.com (Mike Davis), bmanning@ISI.EDU From: nt@salford-software-services.co.uk (Niall Teasdale) Subject: (IPng 245) Re: Re: Am I a router or host if... Cc: sklower@CS.Berkeley.EDU, bound@zk3.dec.com, danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM Date: Wed, 21 Jun 1995 14:05:13 +0000 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk At 09:48 21/06/95 EDT, Mike Davis wrote: >Maybe some Venn Diagrams would help: > nodes >--------------------------- --------------------------- >| hosts | | | | >| ------------ | | | | >| | routers | | | hosts | routers | >| | | | | | | >| ------------ | | | | >| | | | | >--------------------------- --------------------------- > v4 v6 > >So, purely as a matter of terminology, we see that in IPv4, routers >are a subset of hosts. In IPv6, hosts and routers are disjoint and >exhaustive subsets of nodes. Check out draft-ietf-ipngwg-ipv6-spec-02.txt >to see the precise wording of the definitions. > I'd have to disagree: ---------------------------- | routers | As for v6, I believe you, | ------------ | I have no immediate proof otherwise. | | hosts | | | ------------ | | | ---------------------------- v4 v4 hosts perform some of the functionality of a router. They receive packets, fragment and defragment them, route to higher level protocols, etc. In addition, routers dispatch packets received on one interface which are not destined for that interface and may dispatch certain ICMP messages which are not allowed to non-routing hosts. >Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 Niall. **************************************************************************** Niall Teasdale. 3-S (Software) Ltd. nt@sss.co.uk. niall@hedgehog.demon.co.uk WWW Page - htp://mkn.co.uk/help/extra/people/Hedgehog.html The opinions expressed are mine, the mailbox belongs to my employer. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 11:03:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01135; Wed, 21 Jun 95 11:03:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01129; Wed, 21 Jun 95 11:03:05 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10403; Wed, 21 Jun 1995 10:53:15 -0700 Received: from alpha.xerox.com by venus.Sun.COM (Sun.COM) id KAA13378; Wed, 21 Jun 1995 10:53:12 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15342(6)>; Wed, 21 Jun 1995 10:51:40 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 21 Jun 1995 10:51:36 -0700 To: perry@imsi.com Cc: ipng@sunroof2.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 246) Re: Re: What is a Router? In-Reply-To: perry's message of Wed, 21 Jun 95 08:38:33 -0800. <9506211538.AA04467@snark.imsi.com> Date: Wed, 21 Jun 1995 10:51:33 PDT From: Steve Deering Message-Id: <95Jun21.105136pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I'd like to make a modest proposal. Lets change "host" in the specs to > "non-router". Its a neologism, but it makes what we mean totally > unambiguous. Then we have nodes that are routers and nodes that are > non-routers and thats that -- both could be thought of as "hosts" by > the confused. This is a purely cosmetic modification that wouldn't > require a new set of drafts. Yes, I know something like it has been > proposed several times, but it looks like this continues to be a problem. Well, the word "router" is also apparently a source of ambiguity ("Surely these rules for routers don't apply to my workstation product that just happens to have the ip_forward flag set!"). However, it seems to me that, if people are so convinced that they *know* what a host is and what a router is, even though they don't all agree, they can't artculate clearly their own definitions, and they are unable to read and understand the simple, crisp definitions given in the IPv6 spec, we might be better off completely expunging the words "host" and "router" from the IPv6 document set. We could use the terms node, forwarder, and non-forwarder instead, and leave "host" and "router" for sloppy, colloquial use by the "general public". Is that what everyone wants to do? Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 11:45:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01182; Wed, 21 Jun 95 11:45:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01176; Wed, 21 Jun 95 11:45:28 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16422; Wed, 21 Jun 1995 11:35:34 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id LAA00180; Wed, 21 Jun 1995 11:35:23 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA02587; Wed, 21 Jun 95 14:33:49 EDT Received: from karma.engeast by BayNetworks.com (4.1/SMI-4.1) id AA22649; Wed, 21 Jun 95 14:35:10 EDT Date: Wed, 21 Jun 95 14:35:10 EDT From: mdavis@BayNetworks.com (Mike Davis) Message-Id: <9506211835.AA22649@BayNetworks.com> Received: by karma.engeast (4.1/SMI-4.1) id AA06495; Wed, 21 Jun 95 14:34:58 EDT To: deering@parc.xerox.com Cc: perry@imsi.com, ipng@sunroof2.Eng.Sun.COM, deering@parc.xerox.com In-Reply-To: <95Jun21.105136pdt.75270@digit.parc.xerox.com> (message from Steve Deering on Wed, 21 Jun 1995 10:51:33 PDT) Subject: (IPng 247) Re: Re: Re: What is a Router? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >>>>> "Steve" == Steve Deering writes: Steve> We could use the terms node, forwarder, and Steve> non-forwarder instead, and leave "host" and "router" for Steve> sloppy, colloquial use by the "general public". Is that Steve> what everyone wants to do? 'Twould save the repetition of this particular discussion. Would we then have "all-forwarders multicast address", etc.? Steve> Steve --mad Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 12:17:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01227; Wed, 21 Jun 95 12:17:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01221; Wed, 21 Jun 95 12:17:32 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20378; Wed, 21 Jun 1995 12:07:43 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id MAA03816; Wed, 21 Jun 1995 12:07:40 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15153(6)>; Wed, 21 Jun 1995 12:07:17 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 21 Jun 1995 12:07:11 -0700 To: rja@cs.nrl.navy.mil Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 248) Re: Re: Re: Am I a router or host if... In-Reply-To: rja's message of Tue, 20 Jun 95 12:32:48 -0800. <9506201532.ZM598@bodhi.nrl.navy.mil> Date: Wed, 21 Jun 1995 12:07:05 PDT From: Steve Deering Message-Id: <95Jun21.120711pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Ran, This is a public reply to your private message... > % It is the responsibility of the final destination to defend itself from > % those attacks, e.g., by not reversing a source route in an unauthenticated > % packet. > > This is fine, but the specification(s) that discuss source routes > should explicitly note the potential security problem of accepting > unauthenticated source routes, ... I thought the security problems associated with source routing occured as a result of reversing a route when *replying* to a source routed packet, *not* as a result of simply accepting a source-routed packet. What are the special hazards of accepting a source-routed packet, if you do not use the reverse of the source route for a reply? (I suppose there are places where source routing can be used to get an otherwise undeliverable packet through a firewall, but surely that's just evidence of a leaky security perimeter and it should be the responsibility of the firewall(s) to plug that leak.) > Also, your clarification seems counter-intuitive (since at least Bob > Hinden and I reached the opposite conclusion :-), so it would be > useful to explain in the spec why hosts MUST forward source routed > packets that list that host as an intermediate hop. Well, I actually don't have that strong an opinion. I was not aware of a good reason why hosts should *not* forward source routed packets (given that receivers won't reverse unauthenticated routes for replies), and it seemed simpler and potentially useful to make all nodes forward source routed packets -- implementations that can be configured as either hosts or routers would not need to check the am-I-a-router-at-the-moment? flag as part of Routing header processing. Also, there are some potential uses of source routing where the second-to-last and final addresses in a source route might identify the same host. For example, you might reach a mobile host by sending a packet source-routed to a temporary address that it acquires in a foreign subnet, with the final destination being the host's "permanent" home address. In this case, the mobile host would have to be able to source route to itself. The easiest way to make everything just work is to say the Routing header processing rules apply to everyone: if you are not the final destination, bump the pointer and toss the packet back down to ip-output; no need for a bunch of tests, such as if (I-am-a-router-at-the-moment || next-addr is one of mine || ...) By the way, the rules for IPv4 (from RFC 1122) say that a host MAY forward packets source-routed to it. There is also a distinction made between forwarding back onto the arrival interface vs. forwarding to a different interface -- if the latter is supported, it must be governed by a configuration switch that defaults to OFF (i.e., don't forward). This equivocating and complicated set of rules reflects lack of consensus among the members of the Host Requirements working group (I know because I was one of those members). Some wanted to ban the use of source-route forwarding by hosts because of security problems, while some wanted to require source- route forwarding by hosts because of its potential to solve certain routing and network debugging problems; the compromise was to make it a MAY, which means you never know if it's going to work and you can't design new tools that depend on it working, nor can you ever be sure that whatever security problems that arise from allowing it have been eliminated. So, my own inclination for IPv6 is to make source-route forwarding by hosts either MUST or MUST NOT, not a fence-sitting MAY. If we make clear that hosts MUST NOT reverse unauthenticated source routes, can we make source route forwarding by hosts a MUST? Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 12:27:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01242; Wed, 21 Jun 95 12:27:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01236; Wed, 21 Jun 95 12:27:24 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21757; Wed, 21 Jun 1995 12:17:35 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id MAA05281; Wed, 21 Jun 1995 12:17:33 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14493(6)>; Wed, 21 Jun 1995 12:17:06 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 21 Jun 1995 12:16:57 -0700 To: mdavis@baynetworks.com (Mike Davis) Cc: ipng@sunroof2.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 249) Re: Re: Re: What is a Router? In-Reply-To: mdavis's message of Wed, 21 Jun 95 11:35:10 -0800. <9506211835.AA22649@BayNetworks.com> Date: Wed, 21 Jun 1995 12:16:53 PDT From: Steve Deering Message-Id: <95Jun21.121657pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Steve> We could use the terms node, forwarder, and > Steve> non-forwarder instead, and leave "host" and "router" for > Steve> sloppy, colloquial use by the "general public". Is that > Steve> what everyone wants to do? > > 'Twould save the repetition of this particular discussion. Would we > then have "all-forwarders multicast address", etc.? Yep. And we'd have Forwarder Solicitations and Forwarder Advertisements. That would indeed remove some ambiguity, I suspect. The down side is that people will criticise us of gratuitously inventing whole new terminology for IPv6, instead of using the familiar and "perfectly good" host and router terms from IPv4. On the other hand, we seem to have survived the introduction of "router" as a replacement for the original term "gateway", so we could probably survive this change as well. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 13:00:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01329; Wed, 21 Jun 95 13:00:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01323; Wed, 21 Jun 95 13:00:40 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25929; Wed, 21 Jun 1995 12:50:52 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id MAA09676; Wed, 21 Jun 1995 12:50:49 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07500; 21 Jun 95 14:59 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 250) I-D ACTION:draft-ietf-ipngwg-addr-arch-03.txt Date: Wed, 21 Jun 95 14:59:52 -0400 Message-Id: <9506211459.aa07500@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-03.txt Pages : 18 Date : 06/20/1995 This specification defines the addressing architecture of the IP Version 6 protocol. It includes a detailed description of the address formats for IPv6 [IPV6]. The editors would like to acknowledge the contributions of Paul Francis, Jim Bound, Brian Carpenter, Deborah Estrin, Peter Ford, Bob Gilligan, Christian Huitema, Tony Li, Greg Minshall, Erik Nordmark, Yakov Rekhtor, Bill Simpson, and Sue Thomson. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-addr-arch-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-03.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: <19950620160345.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950620160345.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 13:22:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01357; Wed, 21 Jun 95 13:22:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01348; Wed, 21 Jun 95 13:22:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28615; Wed, 21 Jun 1995 13:12:12 -0700 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id NAA11997; Wed, 21 Jun 1995 13:12:09 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA08589; Wed, 21 Jun 1995 13:01:04 -0700 Received: by xirtlu.zk3.dec.com; id AA24754; Wed, 21 Jun 1995 16:00:58 -0400 Message-Id: <9506212000.AA24754@xirtlu.zk3.dec.com> To: Steve Deering Cc: mdavis@baynetworks.com (Mike Davis), ipng@sunroof2.Eng.Sun.COM, bound@zk3.dec.com Subject: (IPng 251) Re: Re: Re: Re: What is a Router? In-Reply-To: Your message of "Wed, 21 Jun 95 12:16:53 PDT." <95Jun21.121657pdt.75270@digit.parc.xerox.com> Date: Wed, 21 Jun 95 16:00:52 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >> Steve> We could use the terms node, forwarder, and >> Steve> non-forwarder instead, and leave "host" and "router" for >> Steve> sloppy, colloquial use by the "general public". Is that >> Steve> what everyone wants to do? >> >> 'Twould save the repetition of this particular discussion. Would we >> then have "all-forwarders multicast address", etc.? >Yep. And we'd have Forwarder Solicitations and Forwarder Advertisements. >That would indeed remove some ambiguity, I suspect. > >The down side is that people will criticise us of gratuitously inventing >whole new terminology for IPv6, instead of using the familiar and "perfectly >good" host and router terms from IPv4. On the other hand, we seem to have >survived the introduction of "router" as a replacement for the original >term "gateway", so we could probably survive this change as well. I want to support what Steve stated and add that this discussion started from a valid question by Dan McDonald (and a good one which I had missed the jist of). Then we did a logic check that we could have a router implementation that handled a superset of tasks that are not required of a router (whatever). Then we drifted into a discussion that we already had and I tried to back out but the ball was going down the hill too fast. The present terminology for IPv6 has consensus. Lets keep it and get off this one. I apologize to the list if my questions or diatribe inadvertently caused this gigantic rathole (and we all have seen this big harry rat before and it is ugly). thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 14:34:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01458; Wed, 21 Jun 95 14:34:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01452; Wed, 21 Jun 95 14:34:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09559; Wed, 21 Jun 1995 14:24:23 -0700 Received: from zephyr.isi.edu by mercury.Sun.COM (Sun.COM) id OAA22660; Wed, 21 Jun 1995 14:24:21 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Wed, 21 Jun 1995 14:24:10 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199506212124.AA13425@zephyr.isi.edu> Subject: (IPng 252) Re: Re: What is a Router? To: deering@parc.xerox.com (Steve Deering) Date: Wed, 21 Jun 1995 14:24:10 -0700 (PDT) Cc: bmanning@ISI.EDU, sklower@cs.berkeley.edu, ipng@sunroof2.Eng.Sun.COM, deering@parc.xerox.com In-Reply-To: <95Jun21.080512pdt.75270@digit.parc.xerox.com> from "Steve Deering" at Jun 21, 95 08:04:58 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > > RFC 1009 and RFC 1716, along with their replacment, specify that > > a router (nee gateway) is a special purpose host. > > Of course they are only relevent to IPv4. If the IPv6 docs are > > changing this assumption, then the transition work has the potential > > to be "interesting". > > The IPv6 docs are not changing any such assumptions. They are simply trying > to use terminology more precisely. In the IPv4 specifications, the word > > IPv4 term IPv6 term > --------- --------- > forwarders routers routers > non-forwarders hosts hosts > U(forwarders, non-forwarders) hosts nodes > > where a "forwarder" is an IPv6 device that is configured to forward IPv6 > packets not explicitly addressed to itself. > > other misunderstandings or confusion. So we decided (at an IPng meeting > in Cambridge, MA) to stick with the node/router/hosts terms as defined in > the IPv6 spec. OK? > > Steve Ok... now the pointy query. Can an IPv6 device act as a forwarder and a non-forwarder AT THE SAME TIME? I would state that this is true and it seems that others are stating this is false. -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 14:46:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01476; Wed, 21 Jun 95 14:46:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01470; Wed, 21 Jun 95 14:46:29 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11506; Wed, 21 Jun 1995 14:36:41 -0700 Received: from zephyr.isi.edu by mercury.Sun.COM (Sun.COM) id OAA24360; Wed, 21 Jun 1995 14:36:40 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Wed, 21 Jun 1995 14:36:31 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199506212136.AA14146@zephyr.isi.edu> Subject: (IPng 253) Re: Re: What is a Router? To: perry@imsi.com Date: Wed, 21 Jun 1995 14:36:30 -0700 (PDT) Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506211538.AA04467@snark.imsi.com> from "Perry E. Metzger" at Jun 21, 95 11:38:33 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > > I'd like to make a modest proposal. Lets change "host" in the specs to > "non-router". Its a neologism, but it makes what we mean totally > unambiguous. Then we have nodes that are routers and nodes that are > non-routers and thats that -- both could be thought of as "hosts" by > the confused. This is a purely cosmetic modification that wouldn't > require a new set of drafts. Yes, I know something like it has been > proposed several times, but it looks like this continues to be a problem. > Sounds fine to me. See previous note. VonNeuman aside, I fully expect a node can be a operating as a router and a non-router at the same time. It is fully possible to have a node tranisting packets and acting as a packet source/sink. To insist that in IPv6, that this is not possible, is a recipe for disaster. -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 15:00:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01498; Wed, 21 Jun 95 15:00:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01492; Wed, 21 Jun 95 15:00:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13616; Wed, 21 Jun 1995 14:50:24 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id OAA26409; Wed, 21 Jun 1995 14:50:24 -0700 Received: from relay.imsi.com by wintermute.imsi.com id RAA21480; Wed, 21 Jun 1995 17:49:11 -0400 Received: from snark.imsi.com by relay.imsi.com id RAA15027; Wed, 21 Jun 1995 17:49:10 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA05341; Wed, 21 Jun 95 17:49:09 EDT Message-Id: <9506212149.AA05341@snark.imsi.com> To: bmanning@ISI.EDU (Bill Manning) Cc: deering@parc.xerox.com (Steve Deering), sklower@cs.berkeley.edu, ipng@sunroof2.Eng.Sun.COM Subject: (IPng 254) Re: Re: Re: What is a Router? In-Reply-To: Your message of "Wed, 21 Jun 1995 14:24:10 PDT." <199506212124.AA13425@zephyr.isi.edu> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 21 Jun 1995 17:49:09 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Bill Manning writes: > Ok... now the pointy query. Can an IPv6 device act as a forwarder and a > non-forwarder AT THE SAME TIME? No, because it cannot act to both drop packets not addressed to it on the floor and to forward them at the same time. It can act as a source/sink for packets and as a forwarder at the same time, but either it forwards packets not addressed to it or it does not forward packets not addressed to it -- it cannot both forward and not forward such packets at the same time. > I would state that this is true and it seems that others are stating > this is false. I think you are trying to note that a node can both be a source/sink and a forwarder (an ES and an IS, or whatever) at the same time. This is true. However, it can't both be a forwarder (which reacts, for instance, to all-forwarders (was all-routers) broadcasts) and a non-forwarder (which does not react to such broadcasts) simultaneously. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 15:01:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01510; Wed, 21 Jun 95 15:01:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01504; Wed, 21 Jun 95 15:00:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13726; Wed, 21 Jun 1995 14:51:08 -0700 Received: from nic.ott.hookup.net by mercury.Sun.COM (Sun.COM) id OAA26493; Wed, 21 Jun 1995 14:51:03 -0700 Received: from [165.154.16.159] (kgk.ott.hookup.net [165.154.16.159]) by nic.ott.hookup.net (8.6.12/1.108) with SMTP id RAA08340; Wed, 21 Jun 1995 17:50:57 -0400 Message-Id: <199506212150.RAA08340@nic.ott.hookup.net> X-Sender: kgk@nic.ott.hookup.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Jun 1995 17:50:39 -0500 To: ipng@sunroof.Eng.Sun.COM From: kgk@hookup.net (Keith G Knightson) Subject: (IPng 255) What is a router Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dear all, The problems appear to be being caused by confusing the three following aspects: a) the logical functions (of forwarding and non-forwarding) b) how many logical functions can be in a given physical box; c) what the label might be assigned to a given physical box. Only a) is of real importance. If people mis-label boxes that's their problem. Presumably the actions depend on the value of the address... If acting as as forwarder DO X If not acting as a forwarder (because the address is that of the box), DO Y If some people want to label a box with a forwarding function and a non-forwarding function as a "router" you can't stop them. Conversely, if some other people want to label a box with a forwarding function and a non-forwarding function as a "host" you can't stop them either. Cheers Keith ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 16:24:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01689; Wed, 21 Jun 95 16:24:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01683; Wed, 21 Jun 95 16:24:47 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25382; Wed, 21 Jun 1995 16:14:59 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id QAA08991; Wed, 21 Jun 1995 16:15:00 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id QAA19604; Wed, 21 Jun 1995 16:14:07 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Jun 1995 16:15:55 -0700 To: Steve Deering From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 256) Re: Re: Re: What is a Router? Cc: ipng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Steve, >happens to have the ip_forward flag set!"). However, it seems to me that, >if people are so convinced that they *know* what a host is and what a router >is, even though they don't all agree, they can't artculate clearly their >own definitions, and they are unable to read and understand the simple, >crisp definitions given in the IPv6 spec, we might be better off completely >expunging the words "host" and "router" from the IPv6 document set. We >could use the terms node, forwarder, and non-forwarder instead, and leave >"host" and "router" for sloppy, colloquial use by the "general public". >Is that what everyone wants to do? Not me! I would much prefer to keep the current terms of node, router, and host. I think we have solid definitions of what they mean in IPv6. Any new terms will have some other degree of ambiguity. All we will have accomplished by new terms to get some other set of people confused. I do not believe that the vendors will have any trouble building IPv6 products or that their customers will have any trouble buying them. It may be that based on the protocol definitions there may be no pure IPv6 "routers" or "hosts" built. Everything may be some degree of a hybrid. The router vendors will still call their products routers, the computer vendors will still call their products workstations, PC's, supercomputers, etc. We will still have "brouters", "rbridges", operating systems that provide host and router functionality, hubs that do routing, etc. The purpose of these terms to make the operation of the protocol clear. I think that as long as the terms do that well (which I think they do), then we should not change them. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 20:52:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02313; Wed, 21 Jun 95 20:52:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02307; Wed, 21 Jun 95 20:52:02 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22613; Wed, 21 Jun 1995 20:42:09 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id UAA03798; Wed, 21 Jun 1995 20:42:01 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03444; Thu, 22 Jun 1995 13:40:51 +1000 (from kre@munnari.OZ.AU) To: bmanning@ISI.EDU (Bill Manning) Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 257) Re: Re: Re: What is a Router? In-Reply-To: Your message of "Wed, 21 Jun 1995 14:24:10 MST." <199506212124.AA13425@zephyr.isi.edu> Date: Thu, 22 Jun 1995 13:40:40 +1000 Message-Id: <4733.803792440@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Wed, 21 Jun 1995 14:24:10 -0700 (PDT) From: bmanning@ISI.EDU (Bill Manning) Message-ID: <199506212124.AA13425@zephyr.isi.edu> Can an IPv6 device act as a forwarder and a non-forwarder AT THE SAME TIME? I would state that this is true and it seems that others are stating this is false. Perry already responded that its false, and by conventional reasoning, including that it seems you're using, he's right. Its simply definition - a node that forwards packets not addressed to itself is a router (or a forwarder if the name change happens). Note this says nothing at all about what the node does with packets that are addressed to it. There is no requirement that routers drop packets that are addressed to them, or anything silly like that - they do whatever is appropriate with those packets. If the packet is an ICMP echo, they respond. If its SNMP, and the authorisation is OK, they respond. If its SMTP they respond to the SYN, either with an ACK (and SYN) or with a RST (and perhaps ICMP port unreachable). Whatever the box does with packets addressed to itself, if it forwards packets that aren't addressed to it, it is by IPv6 definition, a router. Note there is one potentially wacko case in which you might be right that its possible to be both a router & a host (or a forwarder and a non-forwarder) at the same time - that's if the box has three (or more) interfaces, and packets that arrive on two of those interfaces are forwarded if not addressed to the box, and packets that arrive on the third aren't. That is, when viewed from 2 cables the node is a router, when viewed from the third it isn't. Technically, as the box is forwarding some packets not addressed to itself, it probably is simply a router by definition, whatever it does on other interfaces, but I'm going to have to look very closely at the specs to see if that requires it to do anything on its third interface that it really shouldn't be doing given that its not acting as a forwarder there (and no, at the minute I don't know of anything that actually acts like that). I doubt if I would be bothering to send this message, as personally I see no problem or ambiguity, or difficulty at all with these definitions - I'm not 100% sure I like the terms node router & host because of the emotional connotations that we all have with those names (this very discussion illustrates that), but nor do I have good replacements. Anything to replace them would really have to be an invented term to avoid similar connotations (even "forwarder" and "non forwarder" didn't seem to avoid the problems). However, I was a little shocked to see this ... Message-Id: Date: Wed, 21 Jun 1995 16:15:55 -0700 From: hinden@Ipsilon.COM (Bob Hinden) It may be that based on the protocol definitions there may be no pure IPv6 "routers" or "hosts" built. Everything may be some degree of a hybrid. from one of the leading IPv6 authors - that again is just falling back into the same IPv4 trap, and from that causing confusion. The attraction of the IPv6 definition is that *everything* will either be a pure IPv6 "router" or "host" (though it may switch roles from time to time - at any one instant it is one or the other). That is, either the node is forwarding packets not addressed to itself, or it is not (this is a very simple yes no question with no real degree of ambiguity at all). If it is then it is a 100% pure IPv6 router (and it doesn't matter a damn that no-one is actually sending it any packets to forward, or that it currently has lots of telnet/smtp/http/ftp sessions established to it). If it will not forward packets addressed to some other node, then it is a 100% pure host, regardless of how much routing code is in it, buried, and not used because the "ipv6_forwarding" variable has been set to 0. This again is why I'm not overly happy with the nomenclature. In all of our brains we have this implicit definition of the thing that I log in on run the C compiler, and then once its compiled, the web browser as being a "host". On the other hand the noisy big blue box in the corner with a couple of dozen ethernet plugs on the back, and no C compiler, not even a disc to put one on, is a "router". That simply is not the IPv6 definition, with just that information you cannot say either way whether either of those boxes is a router or a host, only knowing whether the "forwarding" function is enabled provides the information - the shape, apparance, and other capabilities, of the box are all irrelevant. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 21:06:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02335; Wed, 21 Jun 95 21:06:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02325; Wed, 21 Jun 95 21:06:06 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23254; Wed, 21 Jun 1995 20:56:16 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id UAA04719; Wed, 21 Jun 1995 20:56:15 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Thu, 22 Jun 1995 12:52:34 +0900 From: Masataka Ohta Message-Id: <199506220352.MAA09972@necom830.cc.titech.ac.jp> Subject: (IPng 258) Re: Re: Re: What is a Router? To: bmanning@ISI.EDU (Bill Manning) Date: Thu, 22 Jun 95 12:52:33 JST Cc: deering@parc.xerox.com, bmanning@ISI.EDU, sklower@cs.berkeley.edu, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <199506212124.AA13425@zephyr.isi.edu>; from "Bill Manning" at Jun 21, 95 2:24 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Ok... now the pointy query. Can an IPv6 device act as a forwarder and a > non-forwarder AT THE SAME TIME? Sure. A multi-interface node can behave as a router on some interfaces and as a host on other interfaces. Router/non-router property of neighbor discovery is of each interface, not each node. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 21:26:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02364; Wed, 21 Jun 95 21:26:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02358; Wed, 21 Jun 95 21:26:03 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23992; Wed, 21 Jun 1995 21:16:12 -0700 Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM) id VAA06076; Wed, 21 Jun 1995 21:16:14 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 21 Jun 1995 21:16:12 -0700 Posted-Date: Wed, 21 Jun 1995 21:14:11 -0700 (PDT) Message-Id: <199506220414.AA04297@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 21 Jun 1995 21:14:11 -0700 Subject: (IPng 259) Re: Re: Re: What is a Router? To: mohta@necom830.cc.titech.ac.jp (Masataka Ohta) Date: Wed, 21 Jun 1995 21:14:11 -0700 (PDT) Cc: bmanning@ISI.EDU, deering@parc.xerox.com, sklower@cs.berkeley.edu, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <199506220352.MAA09972@necom830.cc.titech.ac.jp> from "Masataka Ohta" at Jun 22, 95 12:52:33 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > > Ok... now the pointy query. Can an IPv6 device act as a forwarder and a > > non-forwarder AT THE SAME TIME? > > Sure. > > A multi-interface node can behave as a router on some interfaces and > as a host on other interfaces. > > Router/non-router property of neighbor discovery is of each interface, > not each node. > > Masataka Ohta > And when it is doing this function (perhaps the twisted model that kre posited a few moments ago), what is it? A router or a host or a ???? --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 21:37:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02390; Wed, 21 Jun 95 21:37:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02384; Wed, 21 Jun 95 21:37:20 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25336; Wed, 21 Jun 1995 21:27:30 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id VAA06707; Wed, 21 Jun 1995 21:27:32 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15316(5)>; Wed, 21 Jun 1995 21:27:14 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 21 Jun 1995 21:27:10 -0700 To: bmanning@isi.edu (Bill Manning) Cc: ipng@sunroof2.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 260) Re: Re: What is a Router? In-Reply-To: bmanning's message of Wed, 21 Jun 95 14:24:10 -0800. <199506212124.AA13425@zephyr.isi.edu> Date: Wed, 21 Jun 1995 21:27:07 PDT From: Steve Deering Message-Id: <95Jun21.212710pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Bill, > Ok... now the pointy query. Can an IPv6 device act as a forwarder and a > non-forwarder AT THE SAME TIME? No. The fact that you even ask such a question indicates that you still don't understand the definitions. Please read kre's reply carefully; it is correct. The fact that the answer to your question above is "no" does *not* imply that IPv6 is lacking a capability that IPv4 has, contrary to what you seem to think. I can't, for the life of me, figure out why we are failing so miserably to communicate. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 21:40:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02407; Wed, 21 Jun 95 21:40:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02401; Wed, 21 Jun 95 21:40:07 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25543; Wed, 21 Jun 1995 21:30:16 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id VAA06924; Wed, 21 Jun 1995 21:30:17 -0700 Received: from relay.imsi.com by wintermute.imsi.com id AAA22655; Thu, 22 Jun 1995 00:27:56 -0400 Received: from snark.imsi.com by relay.imsi.com id AAA20090; Thu, 22 Jun 1995 00:27:55 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA05699; Thu, 22 Jun 95 00:27:55 EDT Message-Id: <9506220427.AA05699@snark.imsi.com> To: Masataka Ohta Cc: bmanning@ISI.EDU (Bill Manning), deering@parc.xerox.com, sklower@cs.berkeley.edu, ipng@sunroof2.Eng.Sun.COM Subject: (IPng 261) Re: Re: Re: Re: What is a Router? In-Reply-To: Your message of "Thu, 22 Jun 1995 12:52:33 +0200." <199506220352.MAA09972@necom830.cc.titech.ac.jp> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 22 Jun 1995 00:27:54 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Masataka Ohta writes: > > Ok... now the pointy query. Can an IPv6 device act as a forwarder and a > > non-forwarder AT THE SAME TIME? > > Sure. > > A multi-interface node can behave as a router on some interfaces and > as a host on other interfaces. > > Router/non-router property of neighbor discovery is of each interface, > not each node. Ohta-san; You have pointed out the one oddball case -- that is, that a multi-interface node could forward packets arriving on some interfaces and not on others. However, I would say that the exception, although important, only serves to confuse, and should be ignored by the confused until the understand the real point, to whit: "router" means "box that forwards packets not addressed to it" and that "host" means "non-router". Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 21:42:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02427; Wed, 21 Jun 95 21:42:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02417; Wed, 21 Jun 95 21:42:06 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25660; Wed, 21 Jun 1995 21:32:17 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id VAA07036; Wed, 21 Jun 1995 21:32:16 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Thu, 22 Jun 1995 13:28:40 +0900 From: Masataka Ohta Message-Id: <199506220428.NAA10246@necom830.cc.titech.ac.jp> Subject: (IPng 262) Re: Re: Re: What is a Router? To: bmanning@ISI.EDU Date: Thu, 22 Jun 95 13:28:39 JST Cc: deering@parc.xerox.com, sklower@cs.berkeley.edu, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <199506220414.AA04297@zed.isi.edu>; from "bmanning@ISI.EDU" at Jun 21, 95 9:14 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > And when it is doing this function (perhaps the twisted model that kre > posited a few moments ago), what is it? A router or a host or a ???? As > > Router/non-router property of neighbor discovery is of each interface, > > not each node. it is an IPv6 entity (node, host or whatever) with router interfaces and host interfaces. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 21:50:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02442; Wed, 21 Jun 95 21:50:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02436; Wed, 21 Jun 95 21:50:07 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26335; Wed, 21 Jun 1995 21:40:17 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id VAA07508; Wed, 21 Jun 1995 21:39:53 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06211; Thu, 22 Jun 1995 14:38:37 +1000 (from kre@munnari.OZ.AU) To: Steve Deering Cc: bmanning@isi.edu (Bill Manning), ipng@sunroof2.Eng.Sun.COM Subject: (IPng 263) Re: Re: Re: What is a Router? In-Reply-To: Your message of "Wed, 21 Jun 1995 21:27:07 PDT." <95Jun21.212710pdt.75270@digit.parc.xerox.com> Date: Thu, 22 Jun 1995 14:38:24 +1000 Message-Id: <4757.803795904@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Wed, 21 Jun 1995 21:27:07 PDT From: Steve Deering Message-ID: <95Jun21.212710pdt.75270@digit.parc.xerox.com> I can't, for the life of me, figure out why we are failing so miserably to communicate. I sort of can. Its that a "router" is a box one buys from Cisco, Proteon, BayNetworks, ... On the other hand, a "host" is a box one buys from IBM, DEC, Sun, SGI, ... Those "definitions" are very deeply ingrained. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 21:54:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02462; Wed, 21 Jun 95 21:54:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02456; Wed, 21 Jun 95 21:53:58 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26545; Wed, 21 Jun 1995 21:44:09 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id VAA07744; Wed, 21 Jun 1995 21:44:07 -0700 Received: from relay.imsi.com by wintermute.imsi.com id AAA22684; Thu, 22 Jun 1995 00:44:04 -0400 Received: from snark.imsi.com by relay.imsi.com id AAA20251; Thu, 22 Jun 1995 00:44:03 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA05726; Thu, 22 Jun 95 00:44:02 EDT Message-Id: <9506220444.AA05726@snark.imsi.com> To: bmanning@ISI.EDU Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 264) Re: Re: Re: Re: What is a Router? In-Reply-To: Your message of "Wed, 21 Jun 1995 21:14:11 PDT." <199506220414.AA04297@zed.isi.edu> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 22 Jun 1995 00:44:02 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk bmanning@ISI.EDU writes: > > A multi-interface node can behave as a router on some interfaces and > > as a host on other interfaces. > > > > Router/non-router property of neighbor discovery is of each interface, > > not each node. > > And when it is doing this function (perhaps the twisted model that kre > posited a few moments ago), what is it? A router or a host or a ???? For purposes of neighbor discovery and other algorithms, it is a router on any network on which it forwards traffic, and a host on any other. I will point out that I know of no implementations of IPv4 that make this easy to set up without hand hacking the IP stack, and I don't expect to see many for IPv6. Its a big pain, and I don't think its going to be very important from a standards perspective. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 21:54:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02474; Wed, 21 Jun 95 21:54:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02468; Wed, 21 Jun 95 21:54:47 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26583; Wed, 21 Jun 1995 21:44:57 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id VAA07803; Wed, 21 Jun 1995 21:44:56 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Thu, 22 Jun 1995 13:41:24 +0900 From: Masataka Ohta Message-Id: <199506220441.NAA10364@necom830.cc.titech.ac.jp> Subject: (IPng 265) Re: Re: Re: Re: Re: What is a Router? To: perry@imsi.com Date: Thu, 22 Jun 95 13:41:22 JST Cc: bmanning@ISI.EDU, deering@parc.xerox.com, sklower@cs.berkeley.edu, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506220427.AA05699@snark.imsi.com>; from "Perry E. Metzger" at Jun 22, 95 12:27 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > A multi-interface node can behave as a router on some interfaces and > > as a host on other interfaces. > You have pointed out the one oddball case -- Yes. But multi-interface issue, in general, is the oddball. > However, I would say that the exception, although > important, only serves to confuse, and should be ignored by the > confused until the understand the real point, Unless multi-interface issues are solved in a way that all the multi-interface nodes are required to be routers on all interfaces, > to whit: "router" means > "box that forwards packets not addressed to it" and that "host" means > "non-router". "router" is a property of an interface, not a box. Moreover, unless multi-interface issues are solved in a way that all the multi-interface nodes are required to be routers, multi-interface nodes, seemingly, have to construct thier own routing table. That is, we need all-forwarder-multicast and all-routing-table-owner-multicast Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 21:58:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02490; Wed, 21 Jun 95 21:58:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02484; Wed, 21 Jun 95 21:57:57 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26826; Wed, 21 Jun 1995 21:48:07 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id VAA08096; Wed, 21 Jun 1995 21:48:07 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Thu, 22 Jun 1995 13:44:18 +0900 From: Masataka Ohta Message-Id: <199506220444.NAA10423@necom830.cc.titech.ac.jp> Subject: (IPng 266) Re: Re: Re: Re: What is a Router? To: kre@munnari.OZ.AU (Robert Elz) Date: Thu, 22 Jun 95 13:44:16 JST Cc: deering@parc.xerox.com, bmanning@isi.edu, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <4757.803795904@munnari.OZ.AU>; from "Robert Elz" at Jun 22, 95 2:38 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I can't, for the life of me, figure out why we are failing so miserably to > communicate. > > I sort of can. Its that a "router" is a box one buys from > Cisco, Proteon, BayNetworks, ... On the other hand, a "host" > is a box one buys from IBM, DEC, Sun, SGI, ... > > Those "definitions" are very deeply ingrained. Also, don't forget "/etc/hosts", "gethostnamebyaddr()" ... Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 21 22:13:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02537; Wed, 21 Jun 95 22:13:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02531; Wed, 21 Jun 95 22:13:10 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27417; Wed, 21 Jun 1995 22:03:20 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id WAA08964; Wed, 21 Jun 1995 22:03:22 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15383(6)>; Wed, 21 Jun 1995 22:03:08 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 21 Jun 1995 22:02:57 -0700 To: Robert Elz Cc: bmanning@isi.edu (Bill Manning), ipng@sunroof2.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 267) Re: Re: Re: What is a Router? In-Reply-To: kre's message of Wed, 21 Jun 95 21:38:24 -0800. <4757.803795904@munnari.OZ.AU> Date: Wed, 21 Jun 1995 22:02:43 PDT From: Steve Deering Message-Id: <95Jun21.220257pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I can't, for the life of me, figure out why we are failing so miserably > to communicate. > > I sort of can. Its that a "router" is a box one buys from > Cisco, Proteon, BayNetworks, ... On the other hand, a "host" > is a box one buys from IBM, DEC, Sun, SGI, ... > > Those "definitions" are very deeply ingrained. Yes, I understand that that is at the root of the problem, but I have explained over and over again that those are not relevent distinctions from the point of view of specifying IPv6 behavior, and that *in the context of the IPv6 specs* "host" and "router" are technical terms that have a precise and unambiguous definition. Why can't some folks (including Bob Hinden, as you've observed :-)) just read the definitions and apply them? Frustrated, Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 00:18:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02758; Thu, 22 Jun 95 00:18:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02752; Thu, 22 Jun 95 00:18:32 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09195; Thu, 22 Jun 1995 00:08:44 -0700 Received: from bridge2.NSD.3Com.COM by mercury.Sun.COM (Sun.COM) id AAA15687; Thu, 22 Jun 1995 00:08:39 -0700 Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA06980 (5.65c/IDA-1.4.4nsd for ); Thu, 22 Jun 1995 00:08:17 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA24557 (5.65c/IDA-1.4.4-910730); Thu, 22 Jun 1995 00:05:10 -0700 Message-Id: <199506220705.AA24557@remmel.NSD.3Com.COM> To: Steve Deering Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 268) Re: Re: Re: Re: What is a Router? In-Reply-To: Your message of "Wed, 21 Jun 1995 22:02:43 PDT." <95Jun21.220257pdt.75270@digit.parc.xerox.com> Date: Thu, 22 Jun 1995 00:05:10 -0700 From: Tracy Mallory Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk [If this helps, great. If it seems way off base, let me know (but not everyone all at once;-). If if simply feels like more clutter, my apologies.] It seems to me that the basic problem is that most of us (at some point or other) have felt compelled to attach the terms 'host' and 'router' to physical systems, as if by being able to label a box we can set expectations for its behavior. Steve, et al, are trying to point out that these terms are being defined only with respect to IPv6 protocol behavior, i.e. the content and sequence of IPv6 messages at 'host' or 'router' interfaces. And even here we must try not to associate interfaces with physical connectors, or MAC addresses, but with individual logical interfaces, so that box labeling becomes meaningless. The discussion has focussed on the forwarding aspects of behavior (router interfaces may receive/send packets with dest/source addresses not their own, while a host will only receive/send packets with its own dest/source address), but again there is a tendancy to look at the box and the number of interfaces it supports and their composite behavior, whereas the IPv6 protocol definition applies to the behavior at the individual interfaces. A box with a single 'router' interface is perfectly reasonable. But there are other equally important distinctions having to do with address discovery, etc., where the distinction between 'host' and 'router' behavior is explicit, and where the appearance of a single type of message explicitly identifies the kind of interface. A router (interface) that only happens to be consuming packets addresses to itself is still clearly a router when these other types of behavior are considered. So if the urge to use 'host' and 'router' labels is irresistable (especially in the face of creative network devices), then use your sharpest razor to carve out the specific logical interfaces at which the host-vs-router behavior is clearly identifiable. Regards, Tracy ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 02:37:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02863; Thu, 22 Jun 95 02:37:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02857; Thu, 22 Jun 95 02:36:57 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14286; Thu, 22 Jun 1995 02:27:09 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id CAA23325; Thu, 22 Jun 1995 02:27:07 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18131; Thu, 22 Jun 1995 19:26:42 +1000 (from kre@munnari.OZ.AU) To: Steve Deering Cc: bmanning@isi.edu (Bill Manning), ipng@sunroof2.Eng.Sun.COM Subject: (IPng 269) Re: Re: Re: What is a Router? In-Reply-To: Your message of "Wed, 21 Jun 1995 22:02:43 PDT." <95Jun21.220257pdt.75270@digit.parc.xerox.com> Date: Thu, 22 Jun 1995 19:18:08 +1000 Message-Id: <4843.803812688@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Wed, 21 Jun 1995 22:02:43 PDT From: Steve Deering Message-ID: <95Jun21.220257pdt.75270@digit.parc.xerox.com> I have explained over and over again that those are not relevent distinctions from the point of view of specifying IPv6 behavior, The problem may be that some of us, trained in either the law or mathematics, accept that Humpty Dumpty was right, while others simply can't see past Alice's feeble arguments. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 04:13:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02913; Thu, 22 Jun 95 04:13:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02907; Thu, 22 Jun 95 04:12:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16641; Thu, 22 Jun 1995 04:03:08 -0700 Received: from rodan.UU.NET by mercury.Sun.COM (Sun.COM) id EAA27509; Thu, 22 Jun 1995 04:03:08 -0700 Received: by rodan.UU.NET id QQyvfg20253; Thu, 22 Jun 1995 07:03:07 -0400 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 270) router or host - dessert wax or floor topping? RATHOLE!!! Date: Thu, 22 Jun 1995 07:03:07 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk if you have a box which is carefully engineered to be good at forwarding packets, it will often have client AND/OR server implementations of TELNET, FTP or TFTP, NTP, DNS, Kerberos, RADIUS, SNMP, and a host of routing protocols, all requiring it to behave exactly like a "host" for the purposes of running those protocols. the issue here, and the heart of this argument, methinks, is that the decision of whether to behave like a "host" or a "router" takes place on a packet-by-packet basis. some it routes, some it processes internally. How is this different from, say, a BSDI box with "IPV6_FORWARD" turned on, or even one with it turned off but a high-level process selectively forwarding packets between the two sides of a crypto-firewall??? NOTHING!!!!! with the possible exception of "first-order intent". I think people are reacting to some previous "bad experiences" caused by a BAD choice of the DEFAULT value of "IP_FORWARD" in various products and are trying to legislate morality here. One cannot simply dictate that "thems what routes can't do these other things", because it simply isn't workable. What we can do is RECOMMEND in the strongest possible terms that sofware specifically not intended to ALWAYS be a FULL-TIME router, or that could even accidently be installed in a non-router scenario, should ship with IPV6_FORWARD turned OFF. For me, A "litmus test" (not THE litmus test) of intent is determined by whether the software is bundled with hardware where the system is intended for full-time packet-forwarding service. If the software loads on different boxes and is regularly sold for non-router purposes, then it must ship with IP_FORWARDING disabled. THe user should have the freedom to turn it on, but it should ship with it disabled. So let's just make this recommendation, realize that we have wandered down a wonderful rathole, and get on with things more important. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 06:44:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03016; Thu, 22 Jun 95 06:44:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03010; Thu, 22 Jun 95 06:44:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24089; Thu, 22 Jun 1995 06:34:16 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id GAA08061; Thu, 22 Jun 1995 06:34:14 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Thu, 22 Jun 1995 22:30:36 +0900 From: Masataka Ohta Message-Id: <199506221330.WAA12583@necom830.cc.titech.ac.jp> Subject: (IPng 271) Re: router or host - dessert wax or floor topping? RATHOLE!!! To: mo@uunet.uu.net (Mike O'Dell) Date: Thu, 22 Jun 95 22:30:34 JST Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: ; from "Mike O'Dell" at Jun 22, 95 7:03 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > if you have a box which is carefully engineered to be good at > forwarding packets, it will often have client AND/OR server > implementations of TELNET, FTP or TFTP, NTP, DNS, Kerberos, > RADIUS, SNMP, and a host of routing protocols, all requiring > it to behave exactly like a "host" for the purposes of running > those protocols. "forwarding packets" at which layer? > How is this different from, say, a BSDI box with "IPV6_FORWARD" turned > on, or even one with it turned off but a high-level process > selectively forwarding packets between the two sides of a > crypto-firewall??? Packet forwarder at the higher level above the Internet or the transport layer is, for example, called an application relay and is not considered to be a router. Anyway, the application layer relays have nothing to do with neighbor discovery or some other link-, Internet-, or transport- layer protocols of IPv6. A Transport layer relay, which is a router recognizing transport layer flows with RSVP or ST2, might still be called a router. > I think people are reacting to some previous "bad experiences" caused > by a BAD choice of the DEFAULT value of "IP_FORWARD" in various > products and are trying to legislate morality here. I'm afraid that you are not thinking about the multi-interface issues. As I pointed out, that the BSD IPv4 default that multi-interface nodes have been behaving as a router, is the good choice. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 08:36:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03144; Thu, 22 Jun 95 08:36:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03138; Thu, 22 Jun 95 08:36:37 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03928; Thu, 22 Jun 1995 08:26:38 -0700 Received: from bodhi.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id IAA21324; Thu, 22 Jun 1995 08:26:34 -0700 From: Ran Atkinson Message-Id: <9506221125.ZM3595@bodhi.nrl.navy.mil> Date: Thu, 22 Jun 1995 11:25:19 -0400 In-Reply-To: smb@research.att.com "Re: (IPng 248) Re: Re: Re: Am I a router or host if..." (Jun 21, 16:24) References: <9506212127.aa11498@cs.nrl.navy.mil> Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: Steve Deering Subject: (IPng 272) Re: Source routing issues Cc: ipng@sunroof2.Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Steve, My main security concern is that we openly note in the SECURITY CONSIDERATIONS section of the relevant documents something along the lines of: "When cryptographic authentication is NOT actually in use for a particular session, then source routed packets are a potential security problem. [cite CERT Advisory CA-95:01 here]" I fully agree that when cryptographic authentication is IN USE, this security problem goes away. I'd prefer to have the specs say something like "The IP Authentication Header or IP Encapsulating Security Payload SHOULD be present in all source-routed packets." {Another alternative to this wording is provided below.} Steve Deering raised the good question of whether there are security issues with packets that are source routed when the recipient doesn't reverse the route and cryptographic security is not in use. I believe the answer is YES {details next}. In practice, many systems will continue to implement policies based on the claimed FROM Address in a packet, whether or not such a policy seems reasonable to the security community. An adversary can do a lot of damage with a one-way forged packet. One such attack is described in the January 95 CERT Advisory (CA-95:01). The same CERT Advisory (in its Section B) suggests that routers/firewalls be configured to filter out (i.e. drop) packets from outside a domain that claim to originate inside a domain [case 1 below]. To prevent [case 2 below], many sites have configured their routers/firewalls to drop _all_ source routed IPv4 packets. [Case 1] Consider that a forged packet actually from B claiming to be from A and destined to C (no src route header) can be caught and dropped by router packet filters unless B is legitimately on the route between A and C. [Case 2] However, a forged packet actually from B claiming to be from A and source-routed via B and destined to C can NOT be caught by those same packet filters in routers regardless of whether B is legitimately on the route from A to C. To catch these packets, one would need to have the router either filter out all source-routed packets claiming to originally originate from the inside or just filter out all source routed packets or use some technique to cryptographically authenticate all source routed packets before forwarding them. An IPv6 host that accepts a source-routed packet that lacks both the Authentication Header and the Encapsulating Security Payload is vulnerable to attacks similar to those in [CA-95:01] unless its routers/firewalls are configured as described for both [case 1] and [case2]. In general, I don't see how a host can determine how its routers/firewalls are configured. To me, this implies that the specs should have language discouraging acceptance of any source-routed packet that has neither valid ESP nor valid AH present. {e.g. "Hosts SHOULD NOT accept incoming source-routed packets that have neither a valid AH nor a valid ESP. Implementers are encouraged to provide implementation-specific methods for enabling/disabling acceptance of such non-authenticated source-routed packets." } Because on private networks some users might wish to disable all security for their own reasons, I believe the specs should not outright prohibit acceptance of source-routed packets that lack cryptographic authentication. I would like to see source routing become widely useful. I believe that many sites on the Internet will in practice drop source routed packets lacking cryptographic authentication (either at routers, firewalls, or end hosts) regardless of what the specs say. So I think that strongly encouraging ("SHOULD"/"SHOULD NOT") language is appropriate to foster widespread utility of source routing in the Internet. [ No security discussions below here :-] Purely from an aesthetic perspective, I think that if I'm a host and not a router (i.e. IP_FORWARD or its equivalent is set to 0), then I ought not forward any packets. I don't see why forwarding source-routed packets is so unlike forwarding other packets as to be a special case. So I'd prefer a "Hosts MUST NOT forward any packets." and "Routers MUST forward packets." This assumes the canonical IPv6 definitions of "Host" and "Router" where my router might be an OSF/1 workstation (or such like) that also is a file server and a general purpose computer at the same time. This is just my two cents. I'll go with whatever the consensus is, but I'd like the spec to be clarified in whatever direction the consensus dictates so that there is less ambiguity than exists now. Regards, Ran rja@cs.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 08:53:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03168; Thu, 22 Jun 95 08:53:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03160; Thu, 22 Jun 95 08:52:53 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05527; Thu, 22 Jun 1995 08:43:03 -0700 Received: from ns.newbridge.com by mercury.Sun.COM (Sun.COM) id IAA23431; Thu, 22 Jun 1995 08:43:03 -0700 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id LAA05257 for ; Thu, 22 Jun 1995 11:43:01 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma005250; Thu Jun 22 11:42:41 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id LAA15787 for ; Thu, 22 Jun 1995 11:42:41 -0400 Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA05593; Thu, 22 Jun 95 11:40:51 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA11839; Thu, 22 Jun 1995 11:41:55 +0500 Date: Thu, 22 Jun 1995 11:41:55 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9506221541.AA11839@lobster.Newbridge.COM> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 273) Re: Re: Source routing issues X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I would like to second the notion that source route forwarding is merely another case of packet forwarding. As such, using the IPng definitions, a router MUST forward packets currently addressed to itself with further source route, and a host MUST NOT forward such packets. The case where a source route ends with two addresses for the same host, as a mechanism to support mobility or something, is a different matter as the packet is not being forwarded. In generally, I would like to keep hosts out of the packet forwarding business unless there is a very good reason to do otherwise. Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 09:16:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03205; Thu, 22 Jun 95 09:16:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03199; Thu, 22 Jun 95 09:16:03 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08593; Thu, 22 Jun 1995 09:06:13 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id JAA26829; Thu, 22 Jun 1995 09:06:11 -0700 Received: from relay.imsi.com by wintermute.imsi.com id MAA24721; Thu, 22 Jun 1995 12:05:31 -0400 Received: from snark.imsi.com by relay.imsi.com id MAA28979; Thu, 22 Jun 1995 12:05:30 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA06471; Thu, 22 Jun 95 12:05:29 EDT Message-Id: <9506221605.AA06471@snark.imsi.com> To: jhalpern@Newbridge.COM (Joel Halpern) Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 274) Re: Re: Re: Source routing issues In-Reply-To: Your message of "Thu, 22 Jun 1995 11:41:55 +0500." <9506221541.AA11839@lobster.Newbridge.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 22 Jun 1995 12:05:29 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Joel Halpern writes: > In generally, I would like to keep hosts out of the packet forwarding > business unless there is a very good reason to do otherwise. Agreed. There is no normally legitimate reason to thread source routed packets through a host. .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 09:31:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03243; Thu, 22 Jun 95 09:31:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02013; Wed, 21 Jun 95 17:42:41 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05175; Wed, 21 Jun 1995 17:32:52 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id RAA18188; Wed, 21 Jun 1995 17:32:51 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10647; 21 Jun 95 17:15 EDT To: IETF-Announce:;@mercury Cc: ipng@sunroof.Eng.Sun.COM From: IESG Secretary Subject: (IPng 275) Last Call: Internet Protocol, Version 6 (IPv6) Specification to Proposed Standard Date: Wed, 21 Jun 95 17:15:40 -0400 Message-Id: <9506211715.aa10647@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The IESG has received a request from the IPNG Working Group to consider the following four Internet-Drafts for the status of Proposed Standard: 1. Internet Protocol, Version 6 (IPv6) Specification 2. IP Version 6 Addressing Architecture 3. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 4. DNS Extensions to Support IP Version 6 The IESG will also consider the publication of An Architecture for IPv6 Unicast Address Allocation as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by July 5, 1995. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 09:42:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03286; Thu, 22 Jun 95 09:42:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03280; Thu, 22 Jun 95 09:42:31 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12215; Thu, 22 Jun 1995 09:32:38 -0700 Received: from inet-gw-2.pa.dec.com by venus.Sun.COM (Sun.COM) id JAA08404; Thu, 22 Jun 1995 09:32:39 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA29615; Thu, 22 Jun 95 09:28:09 -0700 Received: by xirtlu.zk3.dec.com; id AA09184; Thu, 22 Jun 1995 12:28:08 -0400 Message-Id: <9506221628.AA09184@xirtlu.zk3.dec.com> To: deering@parc.xerox.com Cc: ipng@sunroof2.Eng.Sun.COM, bound@zk3.dec.com Subject: (IPng 276) Re: Re: Source routing issues In-Reply-To: Your message of "Thu, 22 Jun 95 11:25:19 EDT." <9506221125.ZM3595@bodhi.nrl.navy.mil> Date: Thu, 22 Jun 95 12:28:02 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Steve, Steve I would like to support Ran's message that we need to be careful that source routes in IPv6 do not open major security attacks to the Internet. I will use Ran's mail to second my support and add some more words. I have one issue at the end Ran may or may not agree with or others more knowledgable than I about security relative to source routes, and to the discussion of not requiring a checksum if authentication is in use. -------------------------------------- > My main security concern is that we openly note in the SECURITY >CONSIDERATIONS section of the relevant documents something along the >lines of: > "When cryptographic authentication is NOT actually in use for >a particular session, then source routed packets are a potential >security problem. [cite CERT Advisory CA-95:01 here]" If we are going to specify security as a MUST we MUST be consistent in all cases or else we are >I fully agree that when cryptographic authentication is IN USE, this >security problem goes away. I'd prefer to have the specs say >something like "The IP Authentication Header or IP Encapsulating >Security Payload SHOULD be present in all source-routed packets." >{Another alternative to this wording is provided below.} This wording seems correct to me. >[Case 2] However, a forged packet actually from B claiming to be from >A and source-routed via B and destined to C can NOT be caught by those >same packet filters in routers regardless of whether B is legitimately >on the route from A to C. To catch these packets, one would need to >have the router either filter out all source-routed packets claiming >to originally originate from the inside or just filter out all source >routed packets or use some technique to cryptographically authenticate >all source routed packets before forwarding them. I think Case 2 is very valid and in fact can cause a major security attack on networks that are not isolated from external networks. >An IPv6 host that accepts a source-routed packet that lacks both the >Authentication Header and the Encapsulating Security Payload is >vulnerable to attacks similar to those in [CA-95:01] unless its >routers/firewalls are configured as described for both [case 1] and >[case2]. I believe firewalls for hosts inside the private network state what they can do and have company security police that we trust as users. In places where such rigorous policy does not exist then the attack can happen and that we must consider. But we don't want to prevent or mandate that an entity cannot use a firewall to cover Case 1 and Case 2. Mostly because they will do it anyway and are working on these particular cases now in the market where firewalls are being used. > In general, I don't see how a host can determine how its >routers/firewalls are configured. To me, this implies that the specs >should have language discouraging acceptance of any source-routed >packet that has neither valid ESP nor valid AH present. {e.g. "Hosts >SHOULD NOT accept incoming source-routed packets that have neither a >valid AH nor a valid ESP. Implementers are encouraged to provide >implementation-specific methods for enabling/disabling acceptance of >such non-authenticated source-routed packets." } Because on private >networks some users might wish to disable all security for their own >reasons, I believe the specs should not outright prohibit acceptance >of source-routed packets that lack cryptographic authentication. I agree. >I would like to see source routing become widely useful. I believe >that many sites on the Internet will in practice drop source routed >packets lacking cryptographic authentication (either at routers, >firewalls, or end hosts) regardless of what the specs say. So >I think that strongly encouraging ("SHOULD"/"SHOULD NOT") language >is appropriate to foster widespread utility of source routing in >the Internet. I agree. I would like to reiterate that removal of the requirement of the checksum in cases where we know end-to-end that security is in tact should be possibly permitted. The problem is that we do not know today what the key management protocol or APIs will be to inform an implementation that the end-to-end case exists. I personally believe we won't have this all sorted out for some time and folks will build firewalls to filter IPv6 security attacks and other measures within the present firewall product lines in the market. I know lots of folks don't like this, but firewalls in the market are a booming business at present and the market won't wait too long for the IETF to figure out the key management issues, and firewall engineers are already thinking on solutions using IPv6 and related benefits. Or some vendor will do such a good job with a key management software strategy and license it at a reasonable cost that we will all buy into that strategy. But even in this case I perceive Gateway-to-Host authentication happening first except maybe in sites that are more open and less controlled such as a University site. But even the rapid emerging Internet home connections for the most part are connecting via a Server over a link. But in case we can gurantee that end-to-end can happen I think it prudent on our part to permit implementations to not implement a checksum caclulation when its not really required for tcp and udp. For ICMP I am very unclear how an implementation would even establish the mechanisms for authentication (as the packet only goes to the IPv6 layer) without a really clear and specified key management protocol, an API spec to set the required effect, and additional words in the existing ICMP spec for this case. So for ICMP I am not sure we can or should not perform the checksum. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 09:57:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03326; Thu, 22 Jun 95 09:57:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03320; Thu, 22 Jun 95 09:57:37 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14274; Thu, 22 Jun 1995 09:47:46 -0700 Received: from inet-gw-2.pa.dec.com by mercury.Sun.COM (Sun.COM) id JAA02943; Thu, 22 Jun 1995 09:47:31 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA01582; Thu, 22 Jun 95 09:41:12 -0700 Received: by xirtlu.zk3.dec.com; id AA09371; Thu, 22 Jun 1995 12:41:14 -0400 Message-Id: <9506221641.AA09371@xirtlu.zk3.dec.com> To: deering@parc.xerox.com Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 277) Re: Re: Re: Source routing issues In-Reply-To: Your message of "Thu, 22 Jun 95 11:41:55 +0500." <9506221541.AA11839@lobster.Newbridge.COM> Date: Thu, 22 Jun 95 12:41:08 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Steve, i am here working on my dhcpv6 spec and all day yesterday deeply read the varying updated ipv6 core specs (nd, addrconf, arch addr, base spec, icmp, ngtrans) and I really think we should just keep the terms we have per the reasons bob hinden gave. host and router are all over the specs. in my spec i don't want to call a dhcpv6 client a non-router i want to call it a host. plus we would all have major editing to do to make the change. and most of us barely get our stuff done on time now. plus again as bob pointed out if we make new terms folks can rathole again for those terms imho and we will just have more mail on the subject. we had this discussion at cambridge, san jose, and danvers lets go with the terminology in ipv6 base spec it seems very clear to me. we just need rules on forwarding and thats from the source route discussion anyway i think. we have so much work to do i think the chairs should make a non-democratic decision and be done with it. if someone feels they can't build a product becuase of anything in a spec then i am sure we will tell the chairs. as one who wants much freedom to build nodes that can perform lots of ipv6 functions i will pipe in for sure. i have no issue but do await the decision on forwarding and a response to joel halperns last mail and wg response. but that has nothing to do imho with our present terminology. [sorry for all lower case but can't take time to hit the cap key]. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 10:07:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03353; Thu, 22 Jun 95 10:07:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03347; Thu, 22 Jun 95 10:07:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15915; Thu, 22 Jun 1995 09:57:44 -0700 Received: from ns.newbridge.com by mercury.Sun.COM (Sun.COM) id JAA04552; Thu, 22 Jun 1995 09:57:44 -0700 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id MAA10113 for ; Thu, 22 Jun 1995 12:57:42 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma010107; Thu Jun 22 12:57:33 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id MAA17263 for ; Thu, 22 Jun 1995 12:57:32 -0400 Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA06139; Thu, 22 Jun 95 12:55:43 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA11868; Thu, 22 Jun 1995 12:56:46 +0500 Date: Thu, 22 Jun 1995 12:56:46 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9506221656.AA11868@lobster.Newbridge.COM> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 278) Neighbor Discovery X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I have been reading the latest neighbor discovery draft, and a feature that had been discussed earlier does not appear. This may be because the group decided not to deal with it, but I would like soem feedback. The issue is how multi-homed hosts may perform exit selection. The goal, in consonance with that stated for neighbor discovery, is that hosts not run/eavesdrop on routing protocols. The problem is that some remote destinations may be reachable only through some exits. To a lesser degree, there can be significant differences in reachability costs based on exit. The proposal that had been discussed was to allow multi-homed hosts to query for non-local destinations. And that routers could respond to such queries, with their metric information for reaching the destination. Neither this proposal (which was discussed quite a while back) nor any other solution that I can find appears in the current document. Is it the working groups intention to ignore this problem? Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 12:00:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03499; Thu, 22 Jun 95 12:00:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03493; Thu, 22 Jun 95 12:00:51 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05889; Thu, 22 Jun 1995 11:50:55 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id LAA01663; Thu, 22 Jun 1995 11:50:55 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id LAA26945; Thu, 22 Jun 1995 11:49:29 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Jun 1995 11:51:18 -0700 To: Robert Elz From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 279) Re: Re: Re: Re: What is a Router? Cc: ipng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Robert >However, I was a little shocked to see this ... Sorry to shock you. > Message-Id: > Date: Wed, 21 Jun 1995 16:15:55 -0700 > From: hinden@Ipsilon.COM (Bob Hinden) > > It may be that based on the protocol definitions there may > be no pure IPv6 "routers" or "hosts" built. Everything may > be some degree of a hybrid. I was trying to make the point (poorly?) that we will see implementations which can be configured to be a router or a host. They will include code for both. That is what I meant by a "hybrid". Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 13:24:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03649; Thu, 22 Jun 95 13:24:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03508; Thu, 22 Jun 95 12:18:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08344; Thu, 22 Jun 1995 12:08:40 -0700 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id MAA04294; Thu, 22 Jun 1995 12:08:36 -0700 Received: from localhost.itd.nrl.navy.mil by cs.nrl.navy.mil id aa13498; 22 Jun 95 20:04 GMT To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 280) Should we bound fragment sizes? Date: Thu, 22 Jun 1995 15:04:20 -0500 From: Craig Metz Message-Id: <9506222004.aa13498@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reading through the IPv6 base spec, I noticed that the fragmentation section does not address what sizes are allowed and/or appropriate for fragments. It seems reasonable to me to specify that all packets that have the "more" bit set in the fragmentation header should have their size equal to that of the current path MTU to the destination (give or take as necessary because we need to have the fragmented payload be a multiple of eight bytes). If we required something like this, an important side effect is that fragments with the "more" bit set that are smaller than the minimum MTU of 576 would be invalid. There are several well-known attacks on routers that do packet filtering that are based on sending fragments sufficiently small that the transport header is spread across two or more fragments. Strictly speaking, the problem here lies in the routers, because they are not supposed to be operating on end-to-end data such as the transport headers. However, given that packet filtering is not going away, it seems reasonable to me to make it more difficult to construct legitimate packets that meet the conditions needed for a transport header to span multiple fragments. It also seems reasonable to me to push vendors to use fragments that are as close to MTU as possible in order to improve performance. A suggestion as to how this condition might be added to the base spec is (replacing the last paragraph on page 16): The fragmentation algorithm is as follows: The payload (including any extension headers that need be processed only by the destination node(s)) is divided into fragments. Each, except possibly the last, is an integer multiple of 8 octets long and sized such that, with fragment header, any extension headers not considered transport, and an IPv6 header prepended, the total packet length is as large as possible while still being below the path MTU (this total packet length may not be smaller than 576 octets except for the last fragment). The M ("more") flag is set to 1 on all fragments of the same payload except the last. (...) So, my question: Does anyone think that bounding fragment sizes this way is necessarily a good or bad idea? -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 14:21:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03704; Thu, 22 Jun 95 14:21:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03698; Thu, 22 Jun 95 14:21:37 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26020; Thu, 22 Jun 1995 14:11:46 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id OAA20195; Thu, 22 Jun 1995 14:11:31 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA09939; Thu, 22 Jun 95 17:10:08 EDT Received: from andover.engeast by BayNetworks.com (4.1/SMI-4.1) id AA20552; Thu, 22 Jun 95 17:11:29 EDT Date: Thu, 22 Jun 95 17:11:28 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9506222111.AA20552@BayNetworks.com> To: cmetz@sundance.itd.nrl.navy.mil Subject: (IPng 281) Re: Should we bound fragment sizes? Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Craig, I second your request for bounding fragment sizes as you described. Also to add to your valid points, it allows to estimate the upper bound on resources that may be needed to to accomplish re-assembly. This will simplify some implementations. Dimitry ----- Begin Included Message ----- From major@marvin Thu Jun 22 16:44:06 1995 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 280) Should we bound fragment sizes? Date: Thu, 22 Jun 1995 15:04:20 -0500 From: Craig Metz Sender: owner-ipv6@marvin Content-Length: 2506 Reading through the IPv6 base spec, I noticed that the fragmentation section does not address what sizes are allowed and/or appropriate for fragments. It seems reasonable to me to specify that all packets that have the "more" bit set in the fragmentation header should have their size equal to that of the current path MTU to the destination (give or take as necessary because we need to have the fragmented payload be a multiple of eight bytes). If we required something like this, an important side effect is that fragments with the "more" bit set that are smaller than the minimum MTU of 576 would be invalid. There are several well-known attacks on routers that do packet filtering that are based on sending fragments sufficiently small that the transport header is spread across two or more fragments. Strictly speaking, the problem here lies in the routers, because they are not supposed to be operating on end-to-end data such as the transport headers. However, given that packet filtering is not going away, it seems reasonable to me to make it more difficult to construct legitimate packets that meet the conditions needed for a transport header to span multiple fragments. It also seems reasonable to me to push vendors to use fragments that are as close to MTU as possible in order to improve performance. A suggestion as to how this condition might be added to the base spec is (replacing the last paragraph on page 16): The fragmentation algorithm is as follows: The payload (including any extension headers that need be processed only by the destination node(s)) is divided into fragments. Each, except possibly the last, is an integer multiple of 8 octets long and sized such that, with fragment header, any extension headers not considered transport, and an IPv6 header prepended, the total packet length is as large as possible while still being below the path MTU (this total packet length may not be smaller than 576 octets except for the last fragment). The M ("more") flag is set to 1 on all fragments of the same payload except the last. (...) So, my question: Does anyone think that bounding fragment sizes this way is necessarily a good or bad idea? -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com ----- End Included Message ----- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 15:38:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03862; Thu, 22 Jun 95 15:38:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03856; Thu, 22 Jun 95 15:38:32 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06697; Thu, 22 Jun 1995 15:28:43 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id PAA00919; Thu, 22 Jun 1995 15:28:40 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA12561; Thu, 22 Jun 95 18:27:18 EDT Received: from andover.engeast by BayNetworks.com (4.1/SMI-4.1) id AA23384; Thu, 22 Jun 95 18:28:39 EDT Date: Thu, 22 Jun 95 18:28:39 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9506222228.AA23384@BayNetworks.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 282) fragmentation question Cc: dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk This may be a silly question but still.. Should it be required that all fragments of a fragmented packet carry identical extension headers, i.e. in each fragment the fragment header MUST be at the same offset from the beginning of packet. This is not clear from the spec. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 16:57:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03990; Thu, 22 Jun 95 16:57:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03984; Thu, 22 Jun 95 16:57:32 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17588; Thu, 22 Jun 1995 16:47:42 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id QAA10922; Thu, 22 Jun 1995 16:47:41 -0700 Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA22152; Fri, 23 Jun 1995 09:47:26 +1000 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA25523; Fri, 23 Jun 95 09:27:18 +1000 Received: by dcthq2.datacraft.com.au; Fri, 23 Jun 95 9:51:34 +1100 Date: Fri, 23 Jun 95 9:46:04 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: craig@aland.bbn.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 283) re: Re: ipv6 spec X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk craig, sorry if i confused with the table, I used the ISO/ ITU terminology just as an example. ie. M = Mandatory O = Optional C = Conditional eg. Cn = Conditional.. see note n this where conditions are applied to the parameter's use. eg. Parameter Support IP6 Addrs M NSAP Dest Opt C1 C1 if the NSAP gateway function is used. regards alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 17:12:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04010; Thu, 22 Jun 95 17:12:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04004; Thu, 22 Jun 95 17:12:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19328; Thu, 22 Jun 1995 17:02:22 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id RAA12083; Thu, 22 Jun 1995 17:02:14 -0700 Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA22902; Fri, 23 Jun 1995 10:02:08 +1000 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA25646; Fri, 23 Jun 95 09:41:24 +1000 Date: Fri, 23 Jun 95 09:41:24 +1000 Message-Id: <9506222341.AA25646@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au; Fri, 23 Jun 95 10:05:40 +1100 Resent-Date: Fri, 23 Jun 95 9:55:47 +1100 Resent-Message-Id: Resent-From: Alan.Lloyd@datacraft.com.au From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 284) re: Re: Re: What is a Router? X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Forwarded to: internet[ipng@sunroof.eng.sun.com] cc: Comments by: Alan Lloyd@Marketing@DCTHQ -------------------------- [Original Message] ------------------------- vadim.. briliant .. A IPV6NRHN. yes it is better than an OSI ES but by the time I have said IPV6NRHN I could have implemented an ES :-) what is wrong with: a host and router are just "abstracted" functions which relate to the nature of their role in a network. A host is an addressable termination point and a router routes addressed packets to those points. Two major points apply to these functions. 1. They can be combined within an implementation. 2. That routers for the purpose of **management** only will have some "host" associated function but should not be considered as hosts (ie. addressable network termination points). regards alan@oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 17:57:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04060; Thu, 22 Jun 95 17:57:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04054; Thu, 22 Jun 95 17:56:55 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24346; Thu, 22 Jun 1995 17:47:04 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id RAA16548; Thu, 22 Jun 1995 17:47:02 -0700 Received: from [204.160.241.224] ([204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id RAA04000; Thu, 22 Jun 1995 17:46:05 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Jun 1995 17:47:54 -0700 To: cmetz@sundance.itd.nrl.navy.mil From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 285) Re: Re: Should we bound fragment sizes? Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Craig, >It seems reasonable to me to specify that all packets that have the "more" bit >set in the fragmentation header should have their size equal to that of the >current path MTU to the destination (give or take as necessary because we need Maybe I am missing something, but if the source knew what the Path MTU was, then it could avoid fragmenting the packets in the first place. Does this only work if PMTU is known. The best way to improve performance is to not use fragmentation in the first place. Requiring the first fragment to be large enough to include the transport headers seems like a good idea (to avoid the firewall problem you describe) except that for packets with a combination of legal extension headers (i.e., security, routing header, etc.) it might be impossible to enforce. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 20:44:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04207; Thu, 22 Jun 95 20:44:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04201; Thu, 22 Jun 95 20:43:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04456; Thu, 22 Jun 1995 20:34:05 -0700 Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM) id UAA29867; Thu, 22 Jun 1995 20:34:06 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 20:34:03 -0700 Posted-Date: Thu, 22 Jun 1995 20:32:01 -0700 (PDT) Message-Id: <199506230332.AA04549@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Thu, 22 Jun 1995 20:32:01 -0700 Subject: (IPng 286) Re: Re: Re: Re: What is a Router? To: perry@imsi.com Date: Thu, 22 Jun 1995 20:32:01 -0700 (PDT) Cc: bmanning@ISI.EDU, deering@parc.xerox.com, sklower@cs.berkeley.edu, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506212149.AA05341@snark.imsi.com> from "Perry E. Metzger" at Jun 21, 95 05:49:09 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > > I think you are trying to note that a node can both be a source/sink > and a forwarder (an ES and an IS, or whatever) at the same time. This > is true. However, it can't both be a forwarder (which reacts, for > instance, to all-forwarders (was all-routers) broadcasts) and a > non-forwarder (which does not react to such broadcasts) > simultaneously. > > Perry > ------------------------------------------------------------------------------ Thank You. -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 20:44:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04219; Thu, 22 Jun 95 20:44:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04213; Thu, 22 Jun 95 20:44:41 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04501; Thu, 22 Jun 1995 20:34:49 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id UAA29920; Thu, 22 Jun 1995 20:34:50 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04357; Fri, 23 Jun 1995 13:34:05 +1000 (from kre@munnari.OZ.AU) To: hinden@Ipsilon.COM (Bob Hinden) Cc: cmetz@sundance.itd.nrl.navy.mil, ipng@sunroof.Eng.Sun.COM Subject: (IPng 287) Re: Re: Re: Should we bound fragment sizes? In-Reply-To: Your message of "Thu, 22 Jun 1995 17:47:54 MST." Date: Fri, 23 Jun 1995 13:33:55 +1000 Message-Id: <4885.803878435@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Thu, 22 Jun 1995 17:47:54 -0700 From: hinden@Ipsilon.COM (Bob Hinden) Message-ID: Maybe I am missing something, but if the source knew what the Path MTU was, then it could avoid fragmenting the packets in the first place. This works only for stream based protocols (packet boundaries convey no information) where the IPv6 headers (in total) are small enough to fit, along with some application data, in one packet. For datagram based protocols (eg: UDP) one datagram is a unit of transport, it can't necessarily simply be made arbitrarily smaller. The idea of "all headers in all packets" can't possibly apply, there's no guarantee that all the IPv6 extension headers will actually fit in one fragment. It might (and probably does) make sense to expect that all headers before the frag header be the same (assuming we want to require that all frags be routed along the same path, ie: contain the same routing header, etc?) PMTU discovery is mandatory anyway - without that there's no way to know how big to make the fragments (except if you wanted to limit yourself to frags no bigger than the guaranteed MTU, which you probably only would want if your local interface had an MTU only that big - ie: you're connected to Appletalk...) kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 20:52:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04234; Thu, 22 Jun 95 20:52:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04228; Thu, 22 Jun 95 20:52:30 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04810; Thu, 22 Jun 1995 20:42:38 -0700 Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM) id UAA00423; Thu, 22 Jun 1995 20:42:40 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 22 Jun 1995 20:42:39 -0700 Posted-Date: Thu, 22 Jun 1995 20:40:37 -0700 (PDT) Message-Id: <199506230340.AA04560@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Thu, 22 Jun 1995 20:40:38 -0700 Subject: (IPng 288) Re: Re: Re: Re: What is a Router? To: mohta@necom830.cc.titech.ac.jp (Masataka Ohta) Date: Thu, 22 Jun 1995 20:40:37 -0700 (PDT) Cc: bmanning@ISI.EDU, deering@parc.xerox.com, sklower@cs.berkeley.edu, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <199506220428.NAA10246@necom830.cc.titech.ac.jp> from "Masataka Ohta" at Jun 22, 95 01:28:39 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > > And when it is doing this function (perhaps the twisted model that kre > > posited a few moments ago), what is it? A router or a host or a ???? > > As > > > > Router/non-router property of neighbor discovery is of each interface, > > > not each node. > > it is an IPv6 entity (node, host or whatever) with router interfaces > and host interfaces. > So, the situation is that the -interfaces- carry the router/host attributes? This seems more and more odd. Just what construct computes the routing & forwarding tables... on a per interface basis? (It is my feeble understanding that current, common technologies have the system CPU compute a system wide routing/forwarding table for all the interfaces on a node) Sorry to be such a bother Steve. -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 22 23:02:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04369; Thu, 22 Jun 95 23:02:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04363; Thu, 22 Jun 95 23:02:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09620; Thu, 22 Jun 1995 22:52:39 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id WAA08605; Thu, 22 Jun 1995 22:52:38 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Fri, 23 Jun 1995 14:48:31 +0900 From: Masataka Ohta Message-Id: <199506230548.OAA16433@necom830.cc.titech.ac.jp> Subject: (IPng 289) Re: Re: Re: Re: Re: What is a Router? To: bmanning@ISI.EDU Date: Fri, 23 Jun 95 14:48:30 JST Cc: deering@parc.xerox.com, sklower@cs.berkeley.edu, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <199506230340.AA04560@zed.isi.edu>; from "bmanning@ISI.EDU" at Jun 22, 95 8:40 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > > > Router/non-router property of neighbor discovery is of each interface, > > > > not each node. > > > > it is an IPv6 entity (node, host or whatever) with router interfaces > > and host interfaces. > > > > So, the situation is that the -interfaces- carry the router/host attributes? > This seems more and more odd. Agreed. > Just what construct computes the routing & > forwarding tables... on a per interface basis? Theoretically, a CPU time-shared by interfaces can. > (It is my feeble understanding that current, common technologies have the > system CPU compute a system wide routing/forwarding table for all the > interfaces on a node) I think all the problem related to multi-interface node will go away if it MUST behave as a router, which is less than what BSD IPv4 is doing. Are there any reason not to do so? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 23 08:02:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04674; Fri, 23 Jun 95 08:02:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04668; Fri, 23 Jun 95 08:02:34 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00222; Fri, 23 Jun 1995 07:52:41 -0700 Received: from redrock.BSDI.COM by mercury.Sun.COM (Sun.COM) id HAA10937; Fri, 23 Jun 1995 07:52:38 -0700 Received: from redrock.BSDI.COM (karels@localhost.BSDI.COM [127.0.0.1]) by redrock.BSDI.COM (8.6.12/8.6.9) with ESMTP id JAA06700; Fri, 23 Jun 1995 09:52:16 -0500 Message-Id: <199506231452.JAA06700@redrock.BSDI.COM> To: Masataka Ohta Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 290) Re: Re: Re: Re: Re: Re: What is a Router? In-Reply-To: Your message of Fri, 23 Jun 1995 14:48:30 +0200. <199506230548.OAA16433@necom830.cc.titech.ac.jp> Date: Fri, 23 Jun 1995 09:52:12 -0500 From: Mike Karels Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I think all the problem related to multi-interface node will go away > if it MUST behave as a router, which is less than what BSD IPv4 is > doing. > Are there any reason not to do so? Yes. It is perfectly reasonable to use a multi-interface node to connect to otherwise disconnected networks (e.g. an internal corporate net and part of the Internet) but to prevent packet forwarding. Such a node must have sufficient routing knowledge to choose the exit interface correctly. That might require participation in routing protocols, but often it is easy to do with static configuration. Mike ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 23 09:23:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04730; Fri, 23 Jun 95 09:23:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04724; Fri, 23 Jun 95 09:23:17 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09408; Fri, 23 Jun 1995 09:13:24 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id JAA20736; Fri, 23 Jun 1995 09:13:21 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA00681; Fri, 23 Jun 95 12:11:54 EDT Received: from andover.engeast by BayNetworks.com (4.1/SMI-4.1) id AA14913; Fri, 23 Jun 95 12:13:03 EDT Date: Fri, 23 Jun 95 12:13:03 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9506231613.AA14913@BayNetworks.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 291) Re: Re: Re: Re: Should we bound fragment sizes? Cc: dhaskin@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > From: Robert Elz > > It might (and probably does) make sense to expect that all > headers before the frag header be the same (assuming we want to > require that all frags be routed along the same path, ie: > contain the same routing header, etc?) > Is it just a reasonable expectation which may not be true in some limited cases or a requirement (MUST) that mandate it to be true in ALL cases? E.g. IPv4 allows some options to be present in only the initial fragment (one which has pdu offset 0). Or if we want to require that only specific extention headers of (e.g. routing header) of the original datagram to be present in all its fragment, I'd like to see more specifics in the IPv6 spec. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 23 09:45:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04768; Fri, 23 Jun 95 09:45:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04680; Fri, 23 Jun 95 08:08:42 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00813; Fri, 23 Jun 1995 07:58:46 -0700 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id HAA11771; Fri, 23 Jun 1995 07:58:37 -0700 Received: from localhost.itd.nrl.navy.mil by cs.nrl.navy.mil id aa14816; 23 Jun 95 13:54 GMT To: Bob Hinden Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 292) Re: Re: Should we bound fragment sizes? In-Reply-To: Your message of "Thu, 22 Jun 1995 17:47:54 MST." Date: Fri, 23 Jun 1995 08:54:33 -0500 From: Craig Metz Message-Id: <9506231354.aa14816@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In message , Bob Hinden writes: >>It seems reasonable to me to specify that all packets that have the "more" bi >>set in the fragmentation header should have their size equal to that of the >>current path MTU to the destination (give or take as necessary because we nee >Maybe I am missing something, but if the source knew what the Path MTU was, >then it could avoid fragmenting the packets in the first place. Does this >only work if PMTU is known. The best way to improve performance is to not >use fragmentation in the first place. I fully agree. However, severall well known and well deployed protocols (NFS as an example) routinely fragment packets and do not use path MTU information themselves. By definition, when we are fragmenting at all, we are dealing with a protocol that is not (properly) adjusting its datagram size to fit within the path MTU. In that case, we might as well try to make the fragments take advantage of path MTU as best we can. >Requiring the first fragment to be large enough to include the transport >headers seems like a good idea (to avoid the firewall problem you describe) >except that for packets with a combination of legal extension headers >(i.e., security, routing header, etc.) it might be impossible to enforce. I believe the term that should be used here is end-to-end rather than transport. End-to-end headers, which include transport, ESP, and Destination Options in the second incarnation are all subject to fragmentation. I am not sure wether it is reasonable to try to require that all end-to-end headers appear in the first fragment, especially given that we have no real grasp of what could be included in the destination options bag(s). I do think, however, that fragments with the more bit set should/must be reasonably close in size to the path MTU (where I define reasonably as at most seven octets less than the path MTU, thus absorbing the case where our path MTU isn't a multiple of eight octets). This is a performance win because it will push implementors to fragment into fragments close to the path MTU to avoid extra header overhead. Otherwise, we may well see implementations that wastefully slice all fragments to fit into the minimum MTU of 576 octets rather than try to figure out what size they should be. This also should interact nicely with path MTU discovery and give the sender quick notification if the path MTU shrinks. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 23 09:46:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04780; Fri, 23 Jun 95 09:46:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04681; Fri, 23 Jun 95 08:08:43 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00818; Fri, 23 Jun 1995 07:58:50 -0700 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id HAA11790; Fri, 23 Jun 1995 07:58:48 -0700 Received: from localhost.itd.nrl.navy.mil by cs.nrl.navy.mil id aa14923; 23 Jun 95 14:05 GMT To: Robert Elz Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 293) Re: Re: Re: Should we bound fragment sizes? In-Reply-To: Your message of "Fri, 23 Jun 1995 13:33:55 +1000." <4885.803878435@munnari.OZ.AU> Date: Fri, 23 Jun 1995 09:05:25 -0500 From: Craig Metz Message-Id: <9506231405.aa14923@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In message <4885.803878435@munnari.OZ.AU>, Robert Elz writes: >PMTU discovery is mandatory anyway - without that there's no >way to know how big to make the fragments (except if you wanted >to limit yourself to frags no bigger than the guaranteed MTU, >which you probably only would want if your local interface had >an MTU only that big - ie: you're connected to Appletalk...) It is very feasable that an implementation would be made that always fragments into slices of minimum MTU or even lower sizes. For instance, I could have an IPv6 fragmentation engine that fragments all IPv6 datagrams into 56-byte slices (not completely unlikely as some half-baked IPv4 stacks might get just as half-baked a conversion to IPv6) regardless of path MTU. Even if the path MTU is minimum (576), that engine will generate about ten times the number of packets (assuming no optional headers) and will be completely within the spec to my reading. At the very least, fragments with the more bit set that are smaller than 576 bytes long should be completely verboten. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 23 19:57:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05531; Fri, 23 Jun 95 19:57:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05525; Fri, 23 Jun 95 19:57:15 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22551; Fri, 23 Jun 1995 19:47:21 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id TAA05877; Fri, 23 Jun 1995 19:47:20 -0700 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01358; Sat, 24 Jun 1995 12:46:42 +1000 (from kre) Date: Sat, 24 Jun 1995 12:46:42 +1000 From: Robert Elz Message-Id: <9506240246.1358@munnari.oz.au> To: cmetz@sundance.itd.nrl.navy.mil, hinden@ipsilon.com Subject: (IPng 294) Re: Re: Re: Should we bound fragment sizes? Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Fri, 23 Jun 1995 08:54:33 -0500 From: Craig Metz Message-Id: <9506231354.aa14816@cs.nrl.navy.mil> I do think, however, that fragments with the more bit set should/must be reasonably close in size to the path MTU I fully agree with the sentiment, however ... (where I define reasonably as at most seven octets less than the path MTU, thus absorbing the case where our path MTU isn't a multiple of eight octets) But I'm not sure I would go quite that far. It may be that an application finding a Path MTU of 1500 (a not uncommon event) may prefer 1024 data bytes (plus headers) - well under 1493 - because that fits more nicely with the intrinsic data size it is dealing with. I doubt there's any advantage to be gained in pushing the implementation to pad the fragment with 400 bytes of hop-by-hop (so they're in all fragments) no-op options, is there? (Or even end-to-end no-op options, if there are only 2 frags, and only the first needs padding). In any case, whatever is decided here can really be no more than a recommendation (that is, we could require such an implementation be labelled non-conformant, but it would still work just fine). A receiving IPv6 stack can't refuse to accept fragments smaller than it believes should have been sent, as it can't tell what the MTU is on the path from the sender to it - those fragments might fit the sender's best idea of what is possible. For IPv4 there was also the big argument about whether the better place to send the "left over" smaller fragment was first or last. My recollection is that that was basically left undecided, there is no one best answer for everyone. Your proposal would mandate that the small piece be last. I'm not sure I want that battle again right now (though I'm in the smallest last camp). I'd be happier with some warm and comfy words indicating that implementations should send as few fragments as practicable when fragments must be sent at all and leave it at that. That leaves it open for an implementation when sending a 2K packet over a PMTU of 1500 to send 1500 + 548, or 548 + 1500, or two of 1024, or various other combinations. I'm not sure I can think of any really compelling arguments for one over the other. Sending four fragments, each no bigger than 576 is clearly silly, and sub-optimal, but I'm not sure it can be legislated against rather than advised against. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jun 25 06:29:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05990; Sun, 25 Jun 95 06:29:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05984; Sun, 25 Jun 95 06:29:34 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07871; Sun, 25 Jun 1995 06:19:41 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id GAA15571; Sun, 25 Jun 1995 06:19:40 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Sun, 25 Jun 1995 22:16:31 +0900 From: Masataka Ohta Message-Id: <199506251316.WAA26399@necom830.cc.titech.ac.jp> Subject: (IPng 295) Re: Re: Re: Re: Re: Re: Re: What is a Router? To: karels@BSDI.COM (Mike Karels) Date: Sun, 25 Jun 95 22:16:29 JST Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: <199506231452.JAA06700@redrock.BSDI.COM>; from "Mike Karels" at Jun 23, 95 9:52 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > I think all the problem related to multi-interface node will go away > > if it MUST behave as a router, which is less than what BSD IPv4 is > > doing. > > > Are there any reason not to do so? > > Yes. It is perfectly reasonable to use a multi-interface node to connect > to otherwise disconnected networks (e.g. an internal corporate net and > part of the Internet) but to prevent packet forwarding. OK. > Such a node > must have sufficient routing knowledge to choose the exit interface > correctly. OK. > That might require participation in routing protocols, > but often it is easy to do with static configuration. Router/host distinction is useful for ND and RD. If you use static configuration, we don't have to distinguish routers and hosts. So, I think there sill is no reason for ND not to require a multi-interface node be a router. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jun 25 16:25:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06093; Sun, 25 Jun 95 16:25:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06087; Sun, 25 Jun 95 16:25:52 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19542; Sun, 25 Jun 1995 16:15:58 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id QAA08894; Sun, 25 Jun 1995 16:15:57 -0700 Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AB22518; Mon, 26 Jun 1995 09:15:47 +1000 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA03537; Mon, 26 Jun 95 08:54:37 +1000 Received: by dcthq2.datacraft.com.au; Mon, 26 Jun 95 9:19:42 +1100 Date: Mon, 26 Jun 95 9:01:30 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 296) ipv6 address transition and management X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I posted the list with a query last week re the transition of IP4-6. The transition works fine for tunnels where IP4 mapped addresses are used. In this case tunnels can have automatic address mapping. Where a host uses a pure IP6 address (that is not IP4 mapped) I believe that all the remote routers (that tunnel) this host uses will have to be manually configured. This strikes me as quite an operational problem in the transition stage for a network the size of the internet. Also it seems that Neighbour Discovery uses IP 6 multicast forms of addresses as no doubt other forms of "searching" and route management protocols. Therefore, is there a problem that once ANY IP6 or multicast discovery protocols that use unmapped addresses, invoke a remote tunnel that it will have to be manually configured. Naturally this will be on any path that A host's traffic will transit to any of ITS destinations. If this is not true, then blame the aussie sun. If it is, do we need something to assist in the configuration of tunnels. Maybe a hop by hop option that carrries tunnel parameters? And is it likely that hosts will require a range of IP6 addresses (ie IP4 mapped, IP6 and some multicast sets) thoughts please regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 26 01:41:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06471; Mon, 26 Jun 95 01:41:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06465; Mon, 26 Jun 95 01:41:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04599; Mon, 26 Jun 1995 01:31:16 -0700 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id BAA03796; Mon, 26 Jun 1995 01:31:14 -0700 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 297) Re: Re: Re: Re: Should we bound fragment sizes? To: cmetz@sundance.cs.nrl.navy.mil (Craig Metz) Date: Mon, 26 Jun 1995 09:20:16 +0100 (BST) Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9506231405.aa14923@cs.nrl.navy.mil> from "Craig Metz" at Jun 23, 95 09:05:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > It is very feasable that an implementation would be made that always > fragments into slices of minimum MTU or even lower sizes. For instance, I > could have an IPv6 fragmentation engine that fragments all IPv6 datagrams into > 56-byte slices (not completely unlikely as some half-baked IPv4 stacks might > get just as half-baked a conversion to IPv6) regardless of path MTU. Even if > the path MTU is minimum (576), that engine will generate about ten times > the number of packets (assuming no optional headers) and will be completely > within the spec to my reading. At the very least, fragments with the more > bit set that are smaller than 576 bytes long should be completely verboten. Iffy. Specify that only one fragment may be undersized. There are good reasons for sending fragments in reverse order (single pass checksum, fragment and send, getting to know the length of the final reassembled frame early). A specification shouldn't make that needlessly hard. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 26 05:11:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06517; Mon, 26 Jun 95 05:11:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06511; Mon, 26 Jun 95 05:10:52 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09680; Mon, 26 Jun 1995 05:00:58 -0700 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id FAA13184; Mon, 26 Jun 1995 05:00:57 -0700 Received: from localhost.itd.nrl.navy.mil by cs.nrl.navy.mil id aa18116; 26 Jun 95 12:57 GMT To: Robert Elz Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 298) Re: Re: Re: Re: Should we bound fragment sizes? In-Reply-To: Your message of "Sat, 24 Jun 1995 12:46:42 +1000." <9506240246.1358@munnari.oz.au> Date: Mon, 26 Jun 1995 07:57:23 -0500 From: Craig Metz Message-Id: <9506261257.aa18116@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In message <9506240246.1358@munnari.oz.au>, Robert Elz writes: >intrinsic data size it is dealing with. I doubt there's any advantage to >be gained in pushing the implementation to pad the fragment with 400 bytes >of hop-by-hop (so they're in all fragments) no-op options, is there? (Or >even end-to-end no-op options, if there are only 2 frags, and only the first >needs padding). Many intermediate network devices have performance characteristics per packet, not per unit size, and would work better if you were able to pack those bytes in and lessen the number of packets. >In any case, whatever is decided here can really be no more than a >recommendation (that is, we could require such an implementation be >labelled non-conformant, but it would still work just fine). A receiving >IPv6 stack can't refuse to accept fragments smaller than it believes >should have been sent, as it can't tell what the MTU is on the path from >the sender to it - those fragments might fit the sender's best idea >of what is possible. If we require some reasonably predictable behaviors, though, we could allow the receiver to sanity check incoming fragments. >For IPv4 there was also the big argument about whether the better place >to send the "left over" smaller fragment was first or last. My recollection >is that that was basically left undecided, there is no one best answer for >everyone. Your proposal would mandate that the small piece be last. >I'm not sure I want that battle again right now (though I'm in the smallest >last camp). I doubt seriously that re-opening an old debate would be of any use. >I'd be happier with some warm and comfy words indicating that implementations >should send as few fragments as practicable when fragments must be sent at >all and leave it at that. That leaves it open for an implementation when >sending a 2K packet over a PMTU of 1500 to send 1500 + 548, or 548 + 1500, >or two of 1024, or various other combinations. I'm not sure I can think of >any really compelling arguments for one over the other. Sending four >fragments, each no bigger than 576 is clearly silly, and sub-optimal, but >I'm not sure it can be legislated against rather than advised against. I think your "warm, comfy" wording is a reasonable way to approach the performance half of this problem. The question does remain, however, of wether we should bound non-odd fragments (i.e., ones that are not the first or last) in some way. It seems to me that two reasonable ways in which they could be bounded is to say that senders must not produce non-odd (this is a lousy term, I know) fragments that are smaller than 576 octets and to say that senders must prepend identical sets of headers before the fragmentation headers of all fragments. The latter is bad in the case where something like a routing header needs to while you're sending out the fragments. The former is getting a bit complex now that the first and last both must be excepted. So I think the best solution to this problem would be to insert words similar to your "warm, comfy" approach and leave the packet filtering concerns to the packet filtering people. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 26 06:01:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06542; Mon, 26 Jun 95 06:01:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06536; Mon, 26 Jun 95 06:01:24 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB11443; Mon, 26 Jun 1995 05:51:30 -0700 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id FAA16401; Mon, 26 Jun 1995 05:51:28 -0700 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 299) Re: Re: Re: Re: Re: Should we bound fragment sizes? To: cmetz@sundance.cs.nrl.navy.mil (Craig Metz) Date: Mon, 26 Jun 1995 13:40:35 +0100 (BST) Cc: kre@munnari.oz.au, ipng@sunroof.Eng.Sun.COM In-Reply-To: <9506261257.aa18116@cs.nrl.navy.mil> from "Craig Metz" at Jun 26, 95 07:57:23 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > So I think the best solution to this problem would be to insert > words similar to your "warm, comfy" approach and leave the packet filtering > concerns to the packet filtering people. How about "A host SHOULD use no more than the minimum number of fragments required to traverse the link without fragmentation when it fragments a frame for that link" That side steps the endian argument and gets the point over. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 26 06:19:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06554; Mon, 26 Jun 95 06:19:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06548; Mon, 26 Jun 95 06:18:52 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12411; Mon, 26 Jun 1995 06:08:57 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id GAA17670; Mon, 26 Jun 1995 06:08:56 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22963; Mon, 26 Jun 1995 23:08:24 +1000 (from kre@munnari.OZ.AU) To: iialan@iifeak.swan.ac.uk (Alan Cox) Cc: cmetz@sundance.itd.nrl.navy.mil (Craig Metz), ipng@sunroof.Eng.Sun.COM Subject: (IPng 300) Re: Re: Re: Re: Re: Should we bound fragment sizes? In-Reply-To: Your message of "Mon, 26 Jun 1995 13:40:35 +0100." Date: Mon, 26 Jun 1995 23:08:04 +1000 Message-Id: <5190.804172084@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Mon, 26 Jun 1995 13:40:35 +0100 (BST) From: iialan@iifeak.swan.ac.uk (Alan Cox) Message-ID: How about "A host SHOULD use no more than the minimum number of fragments required to traverse the link without fragmentation when it fragments a frame for that link" Well, kind of perhaps, but "without fragmentation" makes no sense, as "fragmentation without fragmentation" would just confuse the universe (though I think we know what you mean) but more because once the sender sends a packet in IPv6 there is no more fragmentation. Perhaps: "A node, when fragmenting a packet, should create no more fragments than required to avoid exceeding the discovered path MTU of the route to the destination". I'd also be quite willing to add ... "All fragments with the "MORE" bit set in the fragment header must be a multiple of 8 octets long, unless that would cause an additional fragment to be required". Having leading frags multiples of 8 makes reassembly much faster (on architectures where 8 is magic of course, and doesn't harm the others). It also doesn't alter the "small fragment first/last/anywhere" argument - just slightly alters the size of what is the small fragment if its not last (needs to be rounded up to next multiple of 8, and the final fragment made correspondingly smaller). However I doubt that we want to force an extra fragment if doing this multiple of 8 thing would mean an extra fragment is needed of just a few bytes, that could have been crammed into the earlier fragments. Or do we? kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 26 07:21:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06575; Mon, 26 Jun 95 07:21:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06569; Mon, 26 Jun 95 07:21:27 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15834; Mon, 26 Jun 1995 07:11:32 -0700 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id HAA22810; Mon, 26 Jun 1995 07:11:28 -0700 Received: from localhost.itd.nrl.navy.mil by cs.nrl.navy.mil id aa18691; 26 Jun 95 15:09 GMT To: Alan Cox Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 301) Re: Re: Re: Re: Re: Should we bound fragment sizes? In-Reply-To: Your message of "Mon, 26 Jun 1995 13:40:35 +0100." Date: Mon, 26 Jun 1995 10:09:51 -0500 From: Craig Metz Message-Id: <9506261509.aa18691@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In message , Alan Cox writes: >> So I think the best solution to this problem would be to insert >> words similar to your "warm, comfy" approach and leave the packet filtering >> concerns to the packet filtering people. > >How about "A host SHOULD use no more than the minimum number of fragments >required to traverse the link without fragmentation when it fragments a frame >for that link" > >That side steps the endian argument and gets the point over. This seems very reasonable. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 26 10:09:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06670; Mon, 26 Jun 95 10:09:49 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06664; Mon, 26 Jun 95 10:09:41 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id JAA27935; Mon, 26 Jun 1995 09:59:41 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id JAA26056; Mon, 26 Jun 1995 09:59:25 -0700 Date: Mon, 26 Jun 1995 09:59:25 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199506261659.JAA26056@bobo.Eng.Sun.COM> To: kre@munnari.OZ.AU, ipng@sunroof.Eng.Sun.COM Subject: (IPng 302) Re: Should we bound fragment sizes? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I'd also be quite willing to add ... > > "All fragments with the "MORE" bit set in the fragment header > must be a multiple of 8 octets long, unless that would cause > an additional fragment to be required". That is already the case. The fragment offset is specified in the unit of 8 bytes. Thus it it impossible for fragments with the M flag set to be anything but a multiple of 8 bytes. Erik --- From draft-ietf-ipngwg-ipv6-spec-01.txt -------- Fragment Offset 13-bit unsigned integer. The offset, in 8-octet units, of the following payload, relative to the start of the original, unfragmented payload. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 26 15:24:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07170; Mon, 26 Jun 95 15:24:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07164; Mon, 26 Jun 95 15:24:22 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21330; Mon, 26 Jun 1995 15:14:23 -0700 Received: from IETF.nri.reston.VA.US by venus.Sun.COM (Sun.COM) id PAA05745; Mon, 26 Jun 1995 15:14:22 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12157; 26 Jun 95 16:28 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@venus Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 303) I-D ACTION:draft-ietf-ipngwg-bsd-api-01.txt Date: Mon, 26 Jun 95 16:28:13 -0400 Message-Id: <9506261628.aa12157@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Program Interfaces for BSD Systems Author(s) : R. Gilligan, S. Thomson, J. Bound Filename : draft-ietf-ipngwg-bsd-api-01.txt Pages : 23 Date : 06/22/1995 In order to implement the version 6 Internet Protocol (IPv6) [1] in an operating system based on Berkeley Unix (4.x BSD), changes must be made to the application program interface (API). TCP/IP applications written for BSD-based operating systems have in the past enjoyed a high degree of portability because most of the systems derived from BSD provide the same API, known informally as "the socket interface". We would like the same portability with IPv6. This memo presents a set of extensions to the BSD socket API to support IPv6. The changes include a new data structure to carry IPv6 addresses, new name to address translation library functions, new address conversion functions, and some new setsockopt() options. The extensions are designed to provide access to IPv6 features, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-bsd-api-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-bsd-api-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950622150545.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-api-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950622150545.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 26 18:44:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07526; Mon, 26 Jun 95 18:44:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07520; Mon, 26 Jun 95 18:44:07 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15843; Mon, 26 Jun 1995 18:34:12 -0700 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id SAA22485; Mon, 26 Jun 1995 18:34:12 -0700 Received: from orna.mentat.com ([192.88.122.155]) by mentat.com (4.1/SMI-4.1) id AA27081; Mon, 26 Jun 95 18:32:46 PDT Received: by orna.mentat.com (5.0/SMI-SVR4) id AA13295; Mon, 26 Jun 1995 18:32:45 +0800 Date: Mon, 26 Jun 1995 18:32:45 +0800 From: mark@mentat.com (Marc Hasson) Message-Id: <9506270132.AA13295@orna.mentat.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 304) BSD API & routing header? X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In the BSD API draft I see fine mechanisms for sending/receiving source routes via an address list but I don't see how IPv6 protocol code would know to set the strict/loose bits in the Routing Header's bitmask for an outgoing datagram. Loose vs. strict source routing is something which is generally available to today's IPv4 applications. Is this something we forgot about? Perhaps we need the loose/strict bitmask passed on/from the sendto/recvfrom calls along with the addresses list? -- Marc -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 26 19:35:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07544; Mon, 26 Jun 95 19:35:09 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07538; Mon, 26 Jun 95 19:35:01 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id TAA29922; Mon, 26 Jun 1995 19:25:07 -0700 Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4) id AA12541; Mon, 26 Jun 1995 19:27:54 -0700 Date: Mon, 26 Jun 1995 19:27:54 -0700 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9506270227.AA12541@kandinsky.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng 305) re: BSD API & routing header? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > In the BSD API draft I see fine mechanisms for sending/receiving source > routes via an address list but I don't see how IPv6 protocol code would > know to set the strict/loose bits in the Routing Header's bitmask for > an outgoing datagram. Loose vs. strict source routing is something which > is generally available to today's IPv4 applications. > > Is this something we forgot about? Perhaps we need the loose/strict > bitmask passed on/from the sendto/recvfrom calls along with the > addresses list? Yes, that is indeed an oversight. (Actually, at the time we designed that part of the API, the loose/strict bitmask hadn't yet been invented.) Thanks for finding it! As to how to solve the problem, we certainly have lots of unused space in the address array passed with sendto() and receivfrom(). The sin6_port and sin6_flowinfo fields are unused in all but the first sockaddr_in6 structure in the array. Using these fields might be kind of ugly, though, since we would be overloading the fields. We also have 4 unused bits at the high-order end of the sin6_flowinfo field (its a 32-bit field, but the flowID and priority only use up 28 bits of it). We could steal one of these bits for loose/strict indication; e.g. high-order bit of sin6_flowinfo set to 1 indicates that the address is "strict". Any other ideas? Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 00:46:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07747; Tue, 27 Jun 95 00:46:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07741; Tue, 27 Jun 95 00:46:42 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01365; Tue, 27 Jun 1995 00:36:47 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id AAA16554; Tue, 27 Jun 1995 00:36:46 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11363; Tue, 27 Jun 1995 17:36:21 +1000 (from kre@munnari.OZ.AU) To: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 306) Re: Should we bound fragment sizes? In-Reply-To: Your message of "Mon, 26 Jun 1995 09:59:25 MST." <199506261659.JAA26056@bobo.Eng.Sun.COM> Date: Tue, 27 Jun 1995 17:35:57 +1000 Message-Id: <5323.804238557@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Mon, 26 Jun 1995 09:59:25 -0700 From: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Message-ID: <199506261659.JAA26056@bobo.Eng.Sun.COM> That is already the case. The fragment offset is specified in the unit of 8 bytes. Thus it it impossible for fragments with the M flag set to be anything but a multiple of 8 bytes. Ah, yes, of course - the next frag must start at a multiple of 8, so this one must end on one.... That does mean that the possibility of making a slightly longer frag (up to another 7 octets if that will fit) so as to avoid a possible very short one doesn't exist - but that's OK I think, and certainly not worth reworking the entire frag header stuff for, kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 08:32:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07834; Tue, 27 Jun 95 08:32:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07828; Tue, 27 Jun 95 08:32:18 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22932; Tue, 27 Jun 1995 08:22:19 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id IAA21994; Tue, 27 Jun 1995 08:22:08 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4390; Tue, 27 Jun 95 11:22:04 EDT Received: by RTP (XAGENTA 4.0) id 4696; Tue, 27 Jun 1995 11:21:59 -0400 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17153; Tue, 27 Jun 1995 11:21:51 -0400 Message-Id: <9506271521.AA17153@cichlid.raleigh.ibm.com> To: jhalpern@Newbridge.COM (Joel Halpern) Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 307) Re: Neighbor Discovery In-Reply-To: (Your message of Thu, 22 Jun 95 12:56:46 R.) <9506221656.AA11868@lobster.Newbridge.COM> Date: Tue, 27 Jun 95 11:21:50 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >I have been reading the latest neighbor discovery draft, and a feature that >had been discussed earlier does not appear. This may be because the group >decided not to deal with it, but I would like soem feedback. Multihomed hosts are a can of worms. We consciously made the decision to say as little as possible about them because we'd really not be saying enough and didn't want to say something in Neighbor Discovery that later conflicted with another document that covers multihoming issues in greater detail. >The issue is how multi-homed hosts may perform exit selection. Exit selection is also tied in with source address selection (which we don't address in Neighbor Discovery). Multihomed hosts should always send packets out on the interface that matches the source address of the outgoing packet. Otherwise, redirects don't work (the neighboring gateway won't know that the packet originated from a neighbor on the same network). >The goal, in consonance with that stated for neighbor discovery, is that >hosts not run/eavesdrop on routing protocols. >The problem is that some remote destinations may be reachable only >through some exits. To a lesser degree, there can be significant differences >in reachability costs based on exit. Another way to solve this problem is to turn the multihomed host into a router. >The proposal that had been discussed was to allow multi-homed hosts to >query for non-local destinations. And that routers could respond to >such queries, with their metric information for reaching the destination. >Is it the working groups intention to ignore this problem? How common is the above scenario in practice? My feeling is that the additional complexity in both hosts and routers needed to solve the above scenario using Neighbor Discovery is not worth the benefit to the small number of multihomed hosts. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 09:09:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07856; Tue, 27 Jun 95 09:09:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07850; Tue, 27 Jun 95 09:09:41 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27533; Tue, 27 Jun 1995 08:59:45 -0700 Received: from ns.newbridge.com by mercury.Sun.COM (Sun.COM) id IAA26641; Tue, 27 Jun 1995 08:59:42 -0700 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id LAA26886 for ; Tue, 27 Jun 1995 11:59:41 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma026884; Tue Jun 27 11:59:40 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id LAA11780 for ; Tue, 27 Jun 1995 11:59:39 -0400 Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA08756; Tue, 27 Jun 95 11:57:46 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA12702; Tue, 27 Jun 1995 11:58:53 +0500 Date: Tue, 27 Jun 1995 11:58:53 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9506271558.AA12702@lobster.Newbridge.COM> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 308) Neighbor Discovery and Multi-Homed hosts X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk As stated in the neighbor discovery draft, there is a general goal to get hosts out of the "router" business if they are not forwarding packets. However, for multi-homed hosts, the current neighbor discovery draft does not accomplish that. There was discussion, quite a long time ago, on this list, of an approach to resolve this. Two pieces of mechanism were suggested which, combined, seemed to address the problem sufficiently: 1) Allow a router to respond for a non-local destination when it seems a neighbor discovery query. This response would have to indicate that it was a routing response, so that it would not be confused with any notions of identity. 2) Allow a router to provide metric information in a response. Then, a multi-homed host looking to reach a remote destination could query out all its interfaces to see which ones had connectivity to the destination, and if so to select the best one. I had actually thought that the earlier discussion had agreed that this was a good thing. Discussion with the current authors has shown me that this is not necessarily a shered perspective. Therefore, I am raising this issue now for comment. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. PS The fact that this allows us to move away from Mask and Match behaviors is something I consider desirable. The fact that it does not require us to move away from such behavior allows the current model to continue also. PPS Requiring that all multi-homed hosts run/eavesdrop routing protocols is an extremely awkward requirement, and is becoming more difficult with protocols such as OSPF. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 09:16:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07868; Tue, 27 Jun 95 09:16:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07862; Tue, 27 Jun 95 09:15:55 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28302; Tue, 27 Jun 1995 09:05:55 -0700 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id JAA27314; Tue, 27 Jun 1995 09:05:53 -0700 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 309) Re: Neighbor Discovery To: narten@VNET.IBM.COM (Thomas Narten) Date: Tue, 27 Jun 1995 16:52:36 +0100 (BST) Cc: jhalpern@Newbridge.COM, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506271521.AA17153@cichlid.raleigh.ibm.com> from "Thomas Narten" at Jun 27, 95 11:21:50 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > >The proposal that had been discussed was to allow multi-homed hosts to > >query for non-local destinations. And that routers could respond to > >such queries, with their metric information for reaching the destination. > > >Is it the working groups intention to ignore this problem? > > How common is the above scenario in practice? My feeling is that the > additional complexity in both hosts and routers needed to solve the > above scenario using Neighbor Discovery is not worth the benefit to > the small number of multihomed hosts. Everyone with machines on a pair of networks one for secure and one for insecure data. Every host (not router!) running as a proxy gateway between a private network and the big bad internet proper. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 11:34:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07910; Tue, 27 Jun 95 11:34:56 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07904; Tue, 27 Jun 95 11:34:48 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id LAA21980; Tue, 27 Jun 1995 11:24:52 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id LAA07560; Tue, 27 Jun 1995 11:24:35 -0700 Date: Tue, 27 Jun 1995 11:24:35 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199506271824.LAA07560@bobo.Eng.Sun.COM> To: jhalpern@Newbridge.COM Subject: (IPng 310) Re: Neighbor Discovery and Multi-Homed hosts Cc: ipng@sunroof2.Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > There was discussion, quite a long time ago, on this list, of an approach > to resolve this. Two pieces of mechanism were suggested which, combined, > seemed to address the problem sufficiently: > 1) Allow a router to respond for a non-local destination when it seems a > neighbor discovery query. This response would have to indicate that > it was a routing response, so that it would not be confused with > any notions of identity. There must be something missing. How does a host determine that it should send a query for the destination? Hosts only send ND queries for neighbors. > 2) Allow a router to provide metric information in a response. > > Then, a multi-homed host looking to reach a remote destination could > query out all its interfaces to see which ones had connectivity to the > destination, and if so to select the best one. While I agree that it would be good if multihomed hosts could somehow determine the optimal outgoing interface, I think this is outside the scope of neighbor discovery. ND is concerned with neighbors (i.e. nodes attached to the same link) discovering eachother (as well as discovering certain link properties such as prefixes and mtu). What you want for multihomed hosts is a "route query" mechanism for hosts asking questions about off-link addresses. Wouldn't it be feasible to define a separate protocol to solve this problem? Such a protocol could then be separate from ND and hosts can optionally implement it. The protocol could consist e.g. of a "metric query" and a "metric response" message that multihomed hosts can multicast to the all-routers address on all interfaces. Such a protocol would also have to define the metric unit so that different routing protocols can attempt to provide consistent metrics. (Without some consistency among metrics the protocol would be fairly useless if a multihomed host has RIP routers on one interface and e.g. IGRP routers on another interface.) Note that the previous version of the ND document (as far as I can read and understand them) did not specify a mechanism for multihomed hosts to QUERY routers to determine the optimal outgoing interface. It did specify a mechanism for routers to ADVERTISE off-link prefixes with metrics. I recall the WG discussing this "minimal routing protocol" mechanism and there didn't seem to be much support for it. Also, an advertisement based protocol has the undesirable property that it would force a multihomed host to build a routing table just in case it later wants to optimally reach some off-link destination. A query based protocol allows a host to gather information about off-link destinations on demand. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 11:53:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07933; Tue, 27 Jun 95 11:53:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07927; Tue, 27 Jun 95 11:53:21 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21312; Tue, 27 Jun 1995 11:43:24 -0700 Received: from ns.newbridge.com by mercury.Sun.COM (Sun.COM) id LAA24669; Tue, 27 Jun 1995 11:43:20 -0700 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id OAA02863; Tue, 27 Jun 1995 14:43:13 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma002860; Tue Jun 27 14:43:11 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id OAA15613; Tue, 27 Jun 1995 14:43:10 -0400 Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA10017; Tue, 27 Jun 95 14:41:16 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA12770; Tue, 27 Jun 1995 14:42:24 +0500 Date: Tue, 27 Jun 1995 14:42:24 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9506271842.AA12770@lobster.Newbridge.COM> To: nordmark@jurassic-248.Eng.Sun.COM Subject: (IPng 311) Re: Neighbor Discovery and Multi-Homed hosts Cc: ipng@sunroof2.Eng.Sun.COM X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk With the enhancement I am suggesting, a host could send a query for anything. This would be relevant in two situations: 1) When anything could be a neighbor 2) When it needs information from the routers for things that are not directly neighbors. One can argue that this is not part of "neighbor discovery", but if we are going to keep hosts out of routing, that is where this function ends up. The first case could apply to a large bridged ethernet, or could be migration related to ATM/Frame Relay, and other large networks. If it were just for that, I would have dealt with it separately. But the multi-homed hosts need support. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 12:14:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07999; Tue, 27 Jun 95 12:14:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07993; Tue, 27 Jun 95 12:14:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24087; Tue, 27 Jun 1995 12:04:36 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id MAA26931; Tue, 27 Jun 1995 12:04:34 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA02916; Tue, 27 Jun 95 15:03:12 EDT Received: from andover.engeast by BayNetworks.com (4.1/SMI-4.1) id AA16524; Tue, 27 Jun 95 15:04:24 EDT Date: Tue, 27 Jun 95 15:04:24 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9506271904.AA16524@BayNetworks.com> To: jhalpern@Newbridge.COM Subject: (IPng 312) Re: Neighbor Discovery and Multi-Homed hosts Cc: ipng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Joel, I agree that defining ways for hosts to query for an optimum route is a very worthy and interesting project. However, I concure with the current authors of the Neighbor Discovery spec that solution(s) for this problem should be pursued outside of the ND scope (may be in the routing area of IETF). IMO, this is a complex problem in it's own rights which can not be quickly incorporated in the ND spec. E.g., you indicated that a host can selet a route based on metrics supplied by neighboring routers. But different hosts may have different criteria for route selection. How do you insure that metrics supplied to a particular host are relevant to the host's policy? Furethermore, how is it ensured that different routers supply comparable metrics? To reiterate, as long as the Neghbor Discovery does not preclude development of route resolution solutions I don't see any benefits in tying it to the ND work which specifies the address resolution mechanism. Regards, Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 12:21:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08012; Tue, 27 Jun 95 12:21:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08006; Tue, 27 Jun 95 12:21:14 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24982; Tue, 27 Jun 1995 12:11:19 -0700 Received: from ns.newbridge.com by venus.Sun.COM (Sun.COM) id MAA26635; Tue, 27 Jun 1995 12:11:16 -0700 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id PAA03778; Tue, 27 Jun 1995 15:09:59 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma003774; Tue Jun 27 15:09:56 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id PAA16192; Tue, 27 Jun 1995 15:09:55 -0400 Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA10139; Tue, 27 Jun 95 15:08:01 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA12821; Tue, 27 Jun 1995 15:09:08 +0500 Date: Tue, 27 Jun 1995 15:09:08 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9506271909.AA12821@lobster.Newbridge.COM> To: dhaskin@BayNetworks.com Subject: (IPng 313) Re: Neighbor Discovery and Multi-Homed hosts Cc: ipng@sunroof2.Eng.Sun.COM X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Given that any host decision will be "correct", it seems that the complexity of possible host resolutions of the answer does not affect the correctness of the mechanism. Further, it seems that the question being asked here is the same question being asked with neighbor discovery, namely "where is X". So why solve it in a different protocol. There is no "routing" work to do. In particular, I note that nd is supposed to be the successor to "Router Discovery", and this fits very nicely into that notion. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 12:25:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08024; Tue, 27 Jun 95 12:25:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08018; Tue, 27 Jun 95 12:25:02 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25518; Tue, 27 Jun 1995 12:15:07 -0700 Received: from itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id MAA28269; Tue, 27 Jun 1995 12:15:00 -0700 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA04866; Tue, 27 Jun 95 15:14:52 EDT Date: Tue, 27 Jun 95 15:14:52 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9506271914.AA04866@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 314) multi-homed hosts Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Folks, I don't agree that multi-homed hosts are uncommon. We have MANY of them in my neighborhood, including my own machine. None of the local multi-homed hosts are routers and none eavesdrop on any routing protocol (I'm locally famous for killing sendmail(8) and routed(8) as my first two actions on any newly arrived hosts :-). Most local dual-homed systems run (host-side) Router Discovery now and some few have manually configured default routers because their OS doesn't yet support Router Discovery. The number of multi-homed hosts is on the increase in my neck of the woods, often to increase network availability to command and control systems. Alan Cox's example is increasingly commonplace in the real world. Lots of DoD/Navy hosts are dual-homed onto administratively separate networks and yet are not routers. When I was working for a Fortune 500 firm in the late 80s, a fair number of systems were dual-homed to provide redundancy and improved availability (two networks had to fail before a node lost all connectivity, which is important to some customers such as those on Wall Street or parts of the military). My own experience with hosts eavesdropping on routing protocols (such as running "routed -q") is all strongly negative, so I'd prefer that we avoid mandating that approach or (possibly worse) mandating that all multi-homed nodes function as routers. If a dual-homed system knows the Routing Prefix associated with each interface, then it has a fighting chance of picking a plausible outgoing interface for a packet. If someone has a better approach to picking an outgoing interface, I'm all ears. I believe that most customers will not want to be _forced_ to turn their multi-homed hosts into routers and will not want to be _forced_ to eavesdrop on routing protocols (too much administrative pain involved with either of those options if you have many multihomed hosts). The approach for multi-homed discovery described in Simpson's drafts seemed very reasonable to me (and some others). Regardless of what one thinks about the rest of Bill's work, we ought to reconsider adapting the multi-homing approach outlined by Bill for the new ND. Thanks to Joel for reminding us about this issue. Ran & Dan rja@cs.nrl.navy.mil danmcd@cs.nrl.navy.mil ---------------------------------------------------------------------- AN EXAMPLE: "x" = host part of routing prefix; A, B, C, D, F are arbitary numbers. |================|----| PREFIX = B.D.x | | R1 | ========================================= |----| | | ------- | |------| | SRC | |-----| DEST | ------- | |------| | | ======================================== | PREFIX= A.C.x | | PREFIX = B.F.x | | ------ ------ | R2 | | R3 | ------ ------ | | | | TO THE INTERNET Different connection TO THE INTERNET ASSUMPTIONS: R1, R2, and R3 are routers. "SRC" is a multi-homed sending host. "DEST" is the node that "SRC" is sending to. R2 is higher preference in Router Discovery than R1. SRC wants to send packets to DEST. CASE 1: The default routing path would be to send via R2, The Internet, and R3 to DEST. This is not nearly optimal (and perhaps not "reasonable" :-). Is it possible for SRC to be told to send via R1, using the shorter path ?? If so, how ?? One way would be if SRC performs longest-prefix match for prefixes that have been advertised for directly attached interfaces. Wouldn't this be reasonable ?? Another way (IMHO, mostly evil :-) would be for SRC to eavesdrop on routing protocols. Also, if SRC became a router then it might know via routing protocols. CASE 2: Recall the Alan Cox scenario where network "B" is not attached to The Internet at any location. In this case R3 does not exist above. (This case is pretty common in military networks.) Now, when SRC sends to DEST via R2 the packets will never arrive at DEST even though a (different) path did exist between SRC and DEST. Again, eavesdropping on routing protocols should work, though the sideeffects of such eavesdropping are mostly evil. Longest prefix matching will also work nicely here without the problems of routing eavesdropping. Manual configuration would work, but is annoying to administer. Are there better alternatives ? GENERAL NOTE: In talking with Dan about this, Dan observed that routing prefixes have lifetimes and are stored in some logical table in the host [per our understanding of ADDRCONF & the new DISCOVERY]. One possible (BSDish) implementation of the longest prefix match approach goes like this: 1) lookup DEST in Routing Table (radix) code. 2) if DEFAULT-ROUTE returned && multi-homed, then compare DEST against the prefix list kept anyway for Discovery/AddrConf reasons. 3) pick the longest prefix-match interface if one exists, else send to default router (if more than one interface has non-zero and longest prefix match, just pick one, the rationale being that if there are multiple matches, they are inside a Routing Domain, and redirects will be issued eventually). 4) update NextHop Cache with new entry for DESt This would only need to be done for the 1st packet to DEST. ---------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 13:01:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08084; Tue, 27 Jun 95 13:01:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08078; Tue, 27 Jun 95 13:01:24 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29537; Tue, 27 Jun 1995 12:51:29 -0700 Received: from lobster.wellfleet.com by venus.Sun.COM (Sun.COM) id MAA00043; Tue, 27 Jun 1995 12:51:26 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04169; Tue, 27 Jun 95 15:48:32 EDT Received: from karma.engeast by BayNetworks.com (4.1/SMI-4.1) id AA18823; Tue, 27 Jun 95 15:49:51 EDT Date: Tue, 27 Jun 95 15:49:51 EDT Message-Id: <9506271949.AA18823@BayNetworks.com> Received: by karma.engeast (4.1/SMI-4.1) id AA27040; Tue, 27 Jun 95 15:49:45 EDT From: Mike Davis To: jhalpern@Newbridge.COM Cc: dhaskin@BayNetworks.com, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506271909.AA12821@lobster.Newbridge.COM> (jhalpern@Newbridge.COM) Subject: (IPng 315) Re: Neighbor Discovery and Multi-Homed hosts Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >>>>> "Joel" == Joel Halpern writes: Joel> Further, it seems that the question being asked here is the Joel> same question being asked with neighbor discovery, namely Joel> "where is X". So why solve it in a different protocol. Joel> There is no "routing" work to do. I thought the question being answered by ND was "who else lives on this wire, i.e., who are my neighbors. If I am sadly misinformed, please correct me. If I am serendipitously correct, please tell me why finding out "where is X," when X is not on a local were, is not "routing." (In the classical sense :^). It seems to me the question of correct interface for multi-homed hosts involves much more than in intended by Neighbor Discovery, and that, as Dimitry said, the only thing ND should do is not preclude a future mechanism for discovering the appropriate information. . . . Joel> Yours, Joel> Joel M. Halpern jhalpern@newbridge.com Joel> Newbridge Networks Inc. Thanks, --mad Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 13:09:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08104; Tue, 27 Jun 95 13:09:22 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08098; Tue, 27 Jun 95 13:09:14 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id MAA26609; Tue, 27 Jun 1995 12:59:18 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id MAA08247; Tue, 27 Jun 1995 12:59:01 -0700 Date: Tue, 27 Jun 1995 12:59:01 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199506271959.MAA08247@bobo.Eng.Sun.COM> To: jhalpern@Newbridge.COM Subject: (IPng 316) Re: Neighbor Discovery and Multi-Homed hosts Cc: ipng@sunroof2.Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Further, it seems that the question being asked here is the same question > being asked with neighbor discovery, namely "where is X". So why solve it > in a different protocol. There is no "routing" work to do. I my view of the world the question asked in ND is not as general as "where is X". This general question could have answers like "17 hops away" which clearly ND does not provide. ND does answer the questions "is X on-link?", "what is the link-layer address of X", "is there a router on this link?". > In particular, I note that nd is supposed to be the successor to > "Router Discovery", and this fits very nicely into that notion. The router discovery mechanism (in IPv4 or ND) does not pretend to provide the optimal first hop router - it merely provides a set of potential first home routers. In the case of a host attached to a single link ND provides the ability for routers to redirect a host to a more optimal first hop router. What you are arguing for is an additional mechanism for multihomed hosts to determine the optimal first hop router. I agree that such a mechanism would be very useful while arguing that it can and should be done separately from ND. Why do you feel that this mechanism should be integrated with ND and not be done as a separate protocol? Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 17:02:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08223; Tue, 27 Jun 95 17:02:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08217; Tue, 27 Jun 95 17:02:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04606; Tue, 27 Jun 1995 16:52:09 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id QAA00059; Tue, 27 Jun 1995 16:52:08 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Wed, 28 Jun 1995 08:48:59 +0859 From: Masataka Ohta Message-Id: <199506272349.IAA11040@necom830.cc.titech.ac.jp> Subject: (IPng 317) Re: Neighbor Discovery and Multi-Homed hosts To: jhalpern@Newbridge.COM (Joel Halpern) Date: Wed, 28 Jun 95 8:48:58 JST Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506271558.AA12702@lobster.Newbridge.COM>; from "Joel Halpern" at Jun 27, 95 11:58 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > PPS Requiring that all multi-homed hosts run/eavesdrop routing protocols > is an extremely awkward requirement, and is becoming more difficult > with protocols such as OSPF. An alternative requirement is to configure the host routing table statically, which, it seems to me, is good enough for most of the multi-interface cases. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 17:28:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08249; Tue, 27 Jun 95 17:28:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08243; Tue, 27 Jun 95 17:28:03 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07634; Tue, 27 Jun 1995 17:18:07 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id RAA02804; Tue, 27 Jun 1995 17:18:06 -0700 Received: from relay.imsi.com by wintermute.imsi.com id UAA19166; Tue, 27 Jun 1995 20:17:10 -0400 Received: from snark.imsi.com by relay.imsi.com id UAA18357; Tue, 27 Jun 1995 20:17:09 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA16707; Tue, 27 Jun 95 20:17:08 EDT Message-Id: <9506280017.AA16707@snark.imsi.com> To: jhalpern@Newbridge.COM (Joel Halpern), ipng@sunroof2.Eng.Sun.COM Cc: Masataka Ohta Subject: (IPng 318) Re: Neighbor Discovery and Multi-Homed hosts In-Reply-To: Your message of "Wed, 28 Jun 1995 08:48:58 +0200." <199506272349.IAA11040@necom830.cc.titech.ac.jp> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 27 Jun 1995 20:17:08 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Masataka Ohta writes: > > PPS Requiring that all multi-homed hosts run/eavesdrop routing protocols > > is an extremely awkward requirement, and is becoming more difficult > > with protocols such as OSPF. > > An alternative requirement is to configure the host routing > table statically, which, it seems to me, is good enough > for most of the multi-interface cases. Not in my world it isn't. If you are running with multiple redundant routers on every network to assure reliability and availability, the use of static routes is taboo because it eliminates the whole point of having redundant routers. I'd love it if someone had a solution that didn't require running an eavesdropper on the routing protocol, though. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 19:40:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08311; Tue, 27 Jun 95 19:40:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08305; Tue, 27 Jun 95 19:39:58 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17869; Tue, 27 Jun 1995 19:29:53 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id TAA13701; Tue, 27 Jun 1995 19:29:49 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Wed, 28 Jun 1995 11:26:35 +0900 From: Masataka Ohta Message-Id: <199506280226.LAA11970@necom830.cc.titech.ac.jp> Subject: (IPng 319) Re: Neighbor Discovery and Multi-Homed hosts To: jhalpern@Newbridge.COM (Joel Halpern) Date: Wed, 28 Jun 95 11:26:33 JST Cc: nordmark@jurassic-248.Eng.Sun.COM, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506271842.AA12770@lobster.Newbridge.COM>; from "Joel Halpern" at Jun 27, 95 2:42 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > With the enhancement I am suggesting, a host could send a query for > anything. This would be relevant in two situations: > 1) When anything could be a neighbor > 2) When it needs information from the routers for things that are not > directly neighbors. One can argue that this is not part of > "neighbor discovery", but if we are going to keep hosts out of routing, > that is where this function ends up. > > The first case could apply to a large bridged ethernet, or could be > migration related to ATM/Frame Relay, and other large networks. The word "neighbor" implies that there is all-*-multicast. So, don't expect multi-/broad-cast poor datalink can be related to the issue. I think, for the time being, it is enough to statically configure OR to construct a routing table. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 27 20:26:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08365; Tue, 27 Jun 95 20:26:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08359; Tue, 27 Jun 95 20:26:43 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20217; Tue, 27 Jun 1995 20:16:46 -0700 Received: from inet-gw-2.pa.dec.com by mercury.Sun.COM (Sun.COM) id UAA17056; Tue, 27 Jun 1995 20:16:47 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA09797; Tue, 27 Jun 95 20:14:38 -0700 Received: by xirtlu.zk3.dec.com; id AA22167; Tue, 27 Jun 1995 23:14:41 -0400 Message-Id: <9506280314.AA22167@xirtlu.zk3.dec.com> To: jhalpern@newbridge.com (Joel Halpern) Cc: nordmark@jurassic-248.Eng.Sun.COM, ipng@sunroof2.Eng.Sun.COM Subject: (IPng 320) Re: Neighbor Discovery and Multi-Homed hosts In-Reply-To: Your message of "Tue, 27 Jun 95 14:42:24 +0500." <9506271842.AA12770@lobster.Newbridge.COM> Date: Tue, 27 Jun 95 23:14:35 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Joel, I think we do need this to be done as a separate spec for three reasons. 1. This is not 'neighbor discovery' in the pure sense as was not addrconf. 2. I am not clear now how this can be done. There are several approaches and could even be done at the application layer. 3. We need ND to move to proposed standard status and this new effort will interfere IMHO with that progress. We have several precedents in the IPNGWG that support this: a) ADDRCONF - We are punting on the issue of the DNS being in synch or out of synch (when the advertisement changes prefix does not DNS have to be updated). We (the WG) decided we can move ADDRCONF forward now and fix this issue later. Or for sure I doubt ADDRCONF will get to proposed std after stockholm. b) NGTRANS - In the transition spec going forward at present we have not dealt with the ICMP unreachable message in all tunnel cases across an IPv6 then IPv4 and then IPv6 etc.. We will have to fix this at some point. c) Security is moving forward without a key management set of standards in place. I have to agree with Dimitry Haskin and Mike Davis that this needs to be done separate from ND. It could be that the work produces a need for a new ND message or field extension (as ADDRCONF did). Thats OK we can add that while in proposed standard status. I also agree that this can be statically configured for now as we begin to test IPv6 with the next version of ND. I agree that the present mechanisms used are not good to continue, mostly because of the administration work required. Thats my input, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 28 07:22:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08541; Wed, 28 Jun 95 07:22:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08535; Wed, 28 Jun 95 07:21:52 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14714; Wed, 28 Jun 1995 07:11:09 -0700 Received: from VNET.IBM.COM by venus.Sun.COM (Sun.COM) id HAA18244; Wed, 28 Jun 1995 07:11:06 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8345; Wed, 28 Jun 95 10:10:56 EDT Received: by RTP (XAGENTA 4.0) id 4951; Wed, 28 Jun 1995 10:10:50 -0400 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17555; Wed, 28 Jun 1995 10:10:34 -0400 Message-Id: <9506281410.AA17555@cichlid.raleigh.ibm.com> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 321) Re: multi-homed hosts In-Reply-To: (Your message of Tue, 27 Jun 95 15:14:52 EDT.) <9506271914.AA04866@itd.nrl.navy.mil> Date: Wed, 28 Jun 95 10:10:34 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I don't agree that multi-homed hosts are uncommon. That may be the case. However, ... >Most local >dual-homed systems run (host-side) Router Discovery now and some few >have manually configured default routers because their OS doesn't yet >support Router Discovery. The number of multi-homed hosts is on the >increase in my neck of the woods, often to increase network >availability to command and control systems. The current ND spec sticks with this model, so you haven't lost an ability you had before. I agree that there are still scenarios that neither v4 or the ND solve satisfactorily, namely, selecting which outgoing *interface* to use in forwarding a packet to an off-link destination. > Alan Cox's example is increasingly commonplace in the real world. >Lots of DoD/Navy hosts are dual-homed onto administratively separate >networks and yet are not routers. But in such situations aren't we also getting into policy routing types of issues/questions (e.g., when do we use the secure network, when not)? Is a simple "query for a metric" protocol going to solve this problem in the general case? Would we be better off focusing effort on solving the general case? > My own experience with hosts eavesdropping on routing protocols >(such as running "routed -q") is all strongly negative, Could you summarize those negatives? That is, are they flaws with implementations or fundamental to eavesdropping? Would the negatives go away if a new "barebones" routing protocol was developed that restricited itself to propagating routing information from routers to neighboring hosts? >If a dual-homed >system knows the Routing Prefix associated with each interface, then >it has a fighting chance of picking a plausible outgoing interface for >a packet. If someone has a better approach to picking an outgoing >interface, I'm all ears. Not sure I follow your point. Under ND, hosts do know the routing prefixes associated with each interface (for on-link neighbors). If you want hosts to also know prefixes for off-link destinations as well (so that they can choose the best outgoing interface), a routing protocol is needed. Call it what you want; it is in fact a routing protocol that hosts would need to listen in on. ND at present does not support this model. > I believe that most customers will not want to be _forced_ to turn >their multi-homed hosts into routers and will not want to be _forced_ >to eavesdrop on routing protocols (too much administrative pain >involved with either of those options if you have many multihomed >hosts). > The approach for multi-homed discovery described in Simpson's drafts >seemed very reasonable to me (and some others). I think that the "query router for a destination's metric" is deceptively simple, but I'm not convinced that it is the right model. For one thing, whenever a connection is opened to a new destination, there will be a delay (several seconds perhaps) while a host sends out queries, waits long enough to be sure its gotten all the responses, and then chooses the best one. Note that it would not be sufficient to act on the first response; one must wait long enough before acting to be sure no additional responses (with the best metric!) come along. (Note also that one shouldn't pick one interface and then change it when a better response comes along, since the source address of the outgoing packet must match that of the outgoing interface.) Moreover, you'd have to periodically issue new queries, to handle metrics/reachability changing (e.g., stale cache problem). As an alternate approach, it might be reasonable to define a new "routing protocol" whose sole purpose is to propgate routing information one way from routers to (multihomed) hosts. By making it a standard that all routers must implement, future changes to other routing protocols would not break the existing mechanism. The protocol could also be simple; the routers would do the main work of figuring metrics, hosts would just choose routers based on simple metric comparisons. >"x" = host part of routing prefix; A, B, C, D, F are arbitary numbers. > > |================|----| > PREFIX = B.D.x | | R1 | > ========================================= |----| > | | > ------- | |------| > | SRC | |-----| DEST | > ------- | |------| > | | > ======================================== | > PREFIX= A.C.x | | PREFIX = B.F.x > | | > ------ ------ > | R2 | | R3 | > ------ ------ > | | > | | > TO THE INTERNET Different connection > TO THE INTERNET >ASSUMPTIONS: > R1, R2, and R3 are routers. > "SRC" is a multi-homed sending host. > "DEST" is the node that "SRC" is sending to. > R2 is higher preference in Router Discovery than R1. >SRC wants to send packets to DEST. >CASE 1: > The default routing path would be to send via R2, The >Internet, and R3 to DEST. This is not nearly optimal (and perhaps not >"reasonable" :-). > Is it possible for SRC to be told to send via R1, > using the shorter path ?? If so, how ?? The above configuration is a bit curious. If we've got a zillion multihomed hosts connected to both net A.C and B.D, wouldn't there be at least one router between those networks? In that case, choosing the wrong default interface would result in a sub-optimal path (one extra LAN hop), but the overall picture would not be as bad as the picture suggests. >CASE 2: > Recall the Alan Cox scenario where network "B" is > not attached to The Internet at any location. This is the really bad case. >GENERAL NOTE: > In talking with Dan about this, Dan observed that routing prefixes > have lifetimes and are stored in some logical table in the host > [per our understanding of ADDRCONF & the new DISCOVERY]. One > possible (BSDish) implementation of the longest prefix match > approach goes like this: > 1) lookup DEST in Routing Table (radix) code. > 2) if DEFAULT-ROUTE returned && multi-homed, then > compare DEST against the prefix list kept > anyway for Discovery/AddrConf reasons. I don't understand this suggestion (are we confusing "prefixes" as defined to identify on-link destination vs. "prefixes" that identify both on- and off-link destinations)? Are you saying, "check the prefixes that we know about from Router Advertisements, even though the "on-link" bit is off, meaning that we are not supposed to interpret the destination as being on-link? This would seem a bad idea on principle. Moreover, I don't see how this relates to finding paths to off-link destinations. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 28 08:07:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08584; Wed, 28 Jun 95 08:07:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08578; Wed, 28 Jun 95 08:07:23 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18243; Wed, 28 Jun 1995 07:57:25 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA07077; Wed, 28 Jun 95 07:57:24 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24987; Thu, 29 Jun 1995 00:55:07 +1000 (from kre@munnari.OZ.AU) To: "Thomas Narten" Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 322) Re: multi-homed hosts In-Reply-To: Your message of "Wed, 28 Jun 1995 10:10:34 EST." <9506281410.AA17555@cichlid.raleigh.ibm.com> Date: Thu, 29 Jun 1995 00:54:54 +1000 Message-Id: <5480.804351294@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Wed, 28 Jun 95 10:10:34 -0500 From: "Thomas Narten" Message-ID: <9506281410.AA17555@cichlid.raleigh.ibm.com> If you want hosts to also know prefixes for off-link destinations as well (so that they can choose the best outgoing interface), a routing protocol is needed. Call it what you want; it is in fact a routing protocol that hosts would need to listen in on. It would need to be a routing protocol to the same extent that EGP is (was) a routing protocol (ie: just barely). The real problem that has to be solved is in being able to reach destinations than can be reached only out one interface, where sending out the wrong one isn't just sub-optimal, its completely ineffective. A simple announcement of reachable destinations is sufficient for this. It seems to me this is essential (to at least exist and be implemented in routers). Many sites won't need to enable it, but it needs to be there when required. If it then turns out that while building this protocol that its easy, and meaningful, to associate some kind of metric with the announcements, so that where destinations are reachable out more than one interface a multi-homed host can choose which interface is better to use, and perhaps which router through that interface is the best first hop gateway, then that's good, do that. I don't see this as a fundamental requirement however. (Note also that one shouldn't pick one interface and then change it when a better response comes along, since the source address of the outgoing packet must match that of the outgoing interface.) I have seen this stated a few times, and I believe its an impossible requirement. A nice thing to prefer, but not to require. Consider if the multi-homed host is A, with two interfaces X and Y (ie: X and Y are the interface addresses). Consider another host B opening a TCP connection to A, using address X. Assume that host B is only reachable out interface Y. Unless TCP has changed recently, the source address A sticks in its SYN-ACK (and then all later) packets is X - but the packet must go out through interface Y, or it won't get to B. That is, A is required to violate your "must" above. Why did B send to X instead of Y? Because the DNS (correctly) told it both addresses, and X was the one it picked. How did the packet get to A if there's no route to X visible on the side of A that B is located (because there's no path from A's X interface to B)? Because some administrator of B did a "route add X Y" command (or replace Y by a router address that has had a similar command performed) on appropriate hosts/routers to make the path exist. This kind of thing happens. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 28 08:29:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08599; Wed, 28 Jun 95 08:29:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08593; Wed, 28 Jun 95 08:29:08 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20432; Wed, 28 Jun 1995 08:19:09 -0700 Received: from bodhi.nrl.navy.mil by venus.Sun.COM (Sun.COM) id IAA28354; Wed, 28 Jun 1995 08:19:05 -0700 From: Ran Atkinson Message-Id: <9506281116.ZM12341@bodhi.nrl.navy.mil> Date: Wed, 28 Jun 1995 11:16:35 -0400 In-Reply-To: "Thomas Narten" "Re: (IPng 314) multi-homed hosts" (Jun 28, 10:10) References: <9506281410.AA17555@cichlid.raleigh.ibm.com> Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: Thomas Narten Subject: (IPng 323) Re: multi-homed hosts Cc: ipng@sunroof2.Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk On Jun 28, 10:10, Thomas Narten wrote: } Subject: Re: (IPng 314) multi-homed hosts % But in such situations aren't we also getting into policy routing % types of issues/questions (e.g., when do we use the secure network, % when not)? No, it is not a policy routing issue. This has NOTHING particular to "secure" networks at all. It is just a matter of trying to select a reasonable (NOT optimal) outbound interface for a multi-homed host. > My own experience with hosts eavesdropping on routing protocols >(such as running "routed -q") is all strongly negative, >If a dual-homed >system knows the Routing Prefix associated with each interface, then >it has a fighting chance of picking a plausible outgoing interface for >a packet. If someone has a better approach to picking an outgoing >interface, I'm all ears. % Not sure I follow your point. Under ND, hosts do know the routing % prefixes associated with each interface (for on-link neighbors). Yes, hosts do know the routing prefixes associated with each interface (on-link neighbors is irrelevant, the key is that the routing prefix is known for each of the host's interfaces) % If you want hosts to also know prefixes for off-link destinations as % well (so that they can choose the best outgoing interface), a routing % protocol is needed. I do NOT want any host to know any prefix other than those on that host's own interfaces. I DO want that multi-homed host to perform longest prefix match comparison between the outbound Destination Address and the Routing Prefixes associated with the host's own interfaces when that multi-homed host needs to select an outbound interface. If there is a partial match, pick the closest match as the outbound interface. (This description is abbreviated, see the original outline at the bottom of our original note for a more detailed outline). We don't need, IMHO, any kind of routing protocol here at all. We just need to have multi-homed hosts perform a straight-forward test as part of outbound interface selection. This does not provide optimal outbound interface selection. It does provide a sufficiently reasonable outbound interface selection and obviates the need to eavesdrop on routing protocols. % The above configuration is a bit curious. If we've got a zillion % multihomed hosts connected to both net A.C and B.D, wouldn't there be % at least one router between those networks? No. I know of lots of cases where such configurations exist today. % Are you saying, "check the prefixes that we know about from Router % Advertisements, even though the "on-link" bit is off, meaning that we % are not supposed to interpret the destination as being on-link? No. Just perform longest prefix match checking between the outbound Destination Address and all on-link prefixes for our own interfaces. Select the outbound interface based on which has the nearest prefix match (even though it might not be a perfect match). Once interface selection is done, then do the normal Discovery procedures. The proposed enhancement ONLY affects multi-homed hosts. It does not affect single-homed hosts and it does not affect routers. It only affects the outbound interface selection code on those multi-homed hosts. I'm afraid that I erred in mentioning Bill's spec at all. Several folks appear to be misinterpreting my note as a result. Please IGNORE Bill's spec completely for this particular discussion and just consider the outbound interface selection for multi-homed hosts that we have described. Ran rja@cs.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 28 08:31:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08609; Wed, 28 Jun 95 08:31:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08603; Wed, 28 Jun 95 08:30:47 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20573; Wed, 28 Jun 1995 08:20:41 -0700 Received: from sundance.itd.nrl.navy.mil by venus.Sun.COM (Sun.COM) id IAA28584; Wed, 28 Jun 1995 08:20:37 -0700 Subject: (IPng 324) Re: multi-homed hosts To: narten@vnet.ibm.com, IPng Mailing list Date: Wed, 28 Jun 1995 11:20:34 -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 Message-Id: <9506281620.aa29060@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Thomas, I'll address one point of your followup to Ran's and my note. > >GENERAL NOTE: > > 1) lookup DEST in Routing Table (radix) code. > > 2) if DEFAULT-ROUTE returned && multi-homed, then > > compare DEST against the prefix list kept > > anyway for Discovery/AddrConf reasons. > > 3) pick the longest prefix-match interface if one > > exists, else send to default router > > (if more than one interface has non-zero > > and longest prefix match, just pick one, the > > rationale being that if there are multiple matches, > > they are inside a Routing Domain, and redirects will > > be issued eventually). > > 4) update NextHop Cache with new entry for DEST > > > > This would only need to be done for the 1st packet to DEST. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The only additional complexity with this is a few more checks at the host and that only happening on the first packet to a destination (like a TCP SYN, for example). This way, no interfaces are changed in the middle of communication, etc. (Which is what I believe was one of KRE's points.) > I don't understand this suggestion (are we confusing "prefixes" as > defined to identify on-link destination vs. "prefixes" that identify > both on- and off-link destinations)? Are you saying, "check the > prefixes that we know about from Router Advertisements, even though > the "on-link" bit is off, meaning that we are not supposed to > interpret the destination as being on-link? I mean check the ON-LINK prefixes only. The rationale behind it being, it might not be optimal, but it will be closer than blindly picking the default router. It is also relatively straightforward to implement. With this simple addition, I think we can avoid having to bloat the relatively clean neighbor discovery, or create a new lightweight routing protocol. We don't have to change documents, add new complexity, etc. Dan McD. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 28 09:10:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08663; Wed, 28 Jun 95 09:10:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08654; Wed, 28 Jun 95 09:10:15 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24970; Wed, 28 Jun 1995 09:00:16 -0700 Received: from VNET.IBM.COM by venus.Sun.COM (Sun.COM) id JAA04880; Wed, 28 Jun 1995 09:00:15 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0580; Wed, 28 Jun 95 11:58:32 EDT Received: by RTP (XAGENTA 4.0) id 5009; Wed, 28 Jun 1995 11:58:25 -0400 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18863; Wed, 28 Jun 1995 11:58:07 -0400 Message-Id: <9506281558.AA18863@cichlid.raleigh.ibm.com> To: Robert Elz Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 325) Re: multi-homed hosts In-Reply-To: (Your message of Thu, 29 Jun 95 00:54:54 W.) <5480.804351294@munnari.OZ.AU> Date: Wed, 28 Jun 95 11:58:07 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > (Note also that one shouldn't pick one interface > and then change it when a better response comes along, since the > source address of the outgoing packet must match that of the outgoing > interface.) >I have seen this stated a few times, and I believe its an >impossible requirement. A nice thing to prefer, but not >to require. It's the "strong ES-IS model" described (but not required) in the Host Requirements RFC. If a host sends a packet out an interface with the "wrong" address (e.g., one from its other interfaces), the next-hop gateway has no easy way of knowing that the packet originated from a neighbor, and can't send it a redirect when appropriate. Thus, if we don't have this requirement (e.g., the "weak ES-IS model"), we can't guarantee optimal routing (unless our host becomes more router-like). >Consider if the multi-homed host is A, with two interfaces >X and Y (ie: X and Y are the interface addresses). Consider >another host B opening a TCP connection to A, using address X. >Assume that host B is only reachable out interface Y. Unless >TCP has changed recently, the source address A sticks in its >SYN-ACK (and then all later) packets is X - but the packet >must go out through interface Y, or it won't get to B. That >is, A is required to violate your "must" above. In v6, you can prefix the packet with a new header containing the correct address (yes, it does make the packet bigger). Steve Deering should comment more on this. I seem to recall him saying that this behavior is a requirement for making flows (or ??) work correctly. I don't recall the details now. I note that the Host Requirement RFC lists both the "strong ES-IS" and "weak ES-IS" model, but does not take a stand on which one is required. The former has significant implications for implementors. If there are technical reasons for requiring one or the other, that is an issue we should deal with ASAP. >This kind of thing happens. Agreed. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 28 10:01:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08772; Wed, 28 Jun 95 10:01:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08766; Wed, 28 Jun 95 10:01:41 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02082; Wed, 28 Jun 1995 09:51:43 -0700 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA21250; Wed, 28 Jun 95 09:51:43 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29501; Thu, 29 Jun 1995 02:50:15 +1000 (from kre@munnari.OZ.AU) To: "Thomas Narten" Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 326) Re: multi-homed hosts In-Reply-To: Your message of "Wed, 28 Jun 1995 11:58:07 EST." <9506281558.AA18863@cichlid.raleigh.ibm.com> Date: Thu, 29 Jun 1995 02:49:59 +1000 Message-Id: <5537.804358199@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Wed, 28 Jun 95 11:58:07 -0500 From: "Thomas Narten" Message-ID: <9506281558.AA18863@cichlid.raleigh.ibm.com> It's the "strong ES-IS model" described (but not required) in the Host Requirements RFC. If a host sends a packet out an interface with the "wrong" address (e.g., one from its other interfaces), the next-hop gateway has no easy way of knowing that the packet originated from a neighbor, and can't send it a redirect when appropriate. Thus, if we don't have this requirement (e.g., the "weak ES-IS model"), we can't guarantee optimal routing (unless our host becomes more router-like). We can't guarantee optimal routing anyway, worrying over much about this (comparatively rare) special case simply isn't worth the bother. Routing won't be optimal, but packets will get through. Hosts certainly should use the address associated with the outgoing interface whenever possible, but you can't legislate it. In v6, you can prefix the packet with a new header containing the correct address (yes, it does make the packet bigger). You can stick on a routing header to bamboozle the destination address, this can help with mobility (though EIDs are a much nicer solution to that problem, but never mind). I don't think there's any good way to fiddle the source address this way (which isn't a problem for mobility unless there's some firewall box in the way that won't allow an "inappropriate" source address in outgoing packets). I note that the Host Requirement RFC lists both the "strong ES-IS" and "weak ES-IS" model, but does not take a stand on which one is required. Probably because requiring either makes little sense. Strong ES-IS is preferable, not not requireable. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 28 10:08:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08787; Wed, 28 Jun 95 10:08:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08781; Wed, 28 Jun 95 10:08:23 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03081; Wed, 28 Jun 1995 09:58:25 -0700 Received: from munnari.oz.au by venus.Sun.COM (Sun.COM) id JAA16078; Wed, 28 Jun 1995 09:58:25 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29820; Thu, 29 Jun 1995 02:58:14 +1000 (from kre@munnari.OZ.AU) To: "Thomas Narten" Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 327) Re: multi-homed hosts In-Reply-To: Your message of "Wed, 28 Jun 1995 11:58:07 EST." <9506281558.AA18863@cichlid.raleigh.ibm.com> Date: Thu, 29 Jun 1995 02:57:58 +1000 Message-Id: <5542.804358678@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Wed, 28 Jun 95 11:58:07 -0500 From: "Thomas Narten" Message-ID: <9506281558.AA18863@cichlid.raleigh.ibm.com> If a host sends a packet out an interface with the "wrong" address (e.g., one from its other interfaces), the next-hop gateway has no easy way of knowing that the packet originated from a neighbor, and can't send it a redirect when appropriate. This is pretty gross - but for IPv6 we could actually fix that quite easily. We could define a hop-by-hop option "original hop count" that the sending host would set to the hop count in the packet when originally sent. Routers could check the current (incoming) hop count against that value, and know it makes sense to send a redirect any time those compare equal (the packet hasn't passed through an intermediate router). The host would only ever send the option when the router wouldn't be able to tell from the addresses, which will be rare in practice, and even then, only when starting a new conversation, or resuming after an idle period, and perhaps occasionally during long connections. That is, just often enough to elicit a redirect if one is required - and not on single packet "conversations" (DNS lookups, etc) as getting a redirect from one of those is basically a waste of time. Certainly ugly, but might be useful. Perhaps the first hop-by-hop option? kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 28 10:21:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08819; Wed, 28 Jun 95 10:21:53 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08813; Wed, 28 Jun 95 10:21:44 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id KAA29680; Wed, 28 Jun 1995 10:11:43 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id KAA09071; Wed, 28 Jun 1995 10:11:24 -0700 Date: Wed, 28 Jun 1995 10:11:24 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199506281711.KAA09071@bobo.Eng.Sun.COM> To: rja@cs.nrl.navy.mil Subject: (IPng 328) Re: multi-homed hosts Cc: ipng@sunroof2.Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I do NOT want any host to know any prefix other than those on that > host's own interfaces. I DO want that multi-homed host to perform > longest prefix match comparison between the outbound Destination > Address and the Routing Prefixes associated with the host's own > interfaces when that multi-homed host needs to select an outbound > interface. If there is a partial match, pick the closest match as the > outbound interface. (This description is abbreviated, see the > original outline at the bottom of our original note for a more > detailed outline). I think we are being confused by your use of the term "longest prefix match". Let me try to explain what I think you mean (using your example). If SRC has interfaces to the links with prefixes B.D.x and A.C.x and it wants to send to DEST that has address B.F.7 (which is on a link with prefix B.F.x - but the prefix doesn't matter since SRC doesn't know that prefix for this "remote" link). Your proposal (as I understand it) states that SRC should do a bit-by-bit comparison (ignoring the lengths of the prefixes) between the destination and the prefixes for its attached links. In the above example SRC would find that there are more leading bits in common between B.D.x and B.F.7 than between A.C.x and B.F.7. This would make SRC use the interface to B.D.x. (Note: I wouldn't use the "longest prefix match" term to describe this algorithm. As we've observed that causes lots of confusion.) Such a bit-by-bit comparison does solve your particular example. However, if you change the prefix B.D.x to C.H.x your proposed algorithm does not solve the problem of selecting the outgoing interface. > We don't need, IMHO, any kind of routing protocol here at all. We > just need to have multi-homed hosts perform a straight-forward test > as part of outbound interface selection. This does not provide > optimal outbound interface selection. It does provide a sufficiently > reasonable outbound interface selection and obviates the need to > eavesdrop on routing protocols. Your proposed creative use of the prefixes is not a general solution for multihoming. It has, IMHO, severe constraints on the address assignment in proximity of a multihomed host. You have to force the addresses reachable out different interfaces on the multihomed host to have different high-order prefixes but still a common high-order prefix for each interface. Some solutions (there could be more than these) that can be made to work without any constrains on the address assignment are: - advertise off-link prefixes to the multihomed hosts - a host to router query protocol for off-link destinations We can discuss the pros and cons of these (and other) alternatives once we have a "multihomed host" BOF or WG. (hint, hint) Now back to Neighbor Discovery. Erik -------------------- Ran's EXAMPLE: "x" = host part of routing prefix; A, B, C, D, F are arbitary numbers. |================|----| PREFIX = B.D.x | | R1 | ========================================= |----| | | ------- | |------| | SRC | |-----| DEST | ------- | |------| | | B.F.7 ======================================== | PREFIX= A.C.x | | PREFIX = B.F.x | | ------ ------ | R2 | | R3 | ------ ------ | | | | TO THE INTERNET Different connection TO THE INTERNET ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 28 13:30:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09224; Wed, 28 Jun 95 13:30:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09105; Wed, 28 Jun 95 12:56:19 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27452; Wed, 28 Jun 1995 12:46:20 -0700 Received: from ndtl.harvard.edu by venus.Sun.COM (Sun.COM) id MAA17401; Wed, 28 Jun 1995 12:46:14 -0700 Received: (from sob@localhost) by ndtl.harvard.edu (8.6.9/8.6.9-MT2.02) id PAA27529 for ipng@sunroof.Eng.Sun.COM; Wed, 28 Jun 1995 15:49:42 -0400 (EDT) Date: Wed, 28 Jun 1995 15:49:42 -0400 (EDT) From: Scott Bradner Message-Id: <199506281949.PAA27529@ndtl.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 329) IPv6 API prople should look at this ID Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk From ietf-announce-request@IETF.CNRI.Reston.VA.US Wed Jun 28 15:24:54 1995 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-sklower-ipv6-getconninfo-03.txt Date: Wed, 28 Jun 95 14:56:38 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Getconninfo(): An alternative to Gethostbyname() Author(s) : K. Sklower Filename : draft-sklower-ipv6-getconninfo-03.txt Pages : 6 Date : 06/27/1995 This document proposes a uniform programmatic interface to the Internet name resolution system, in which differences between IPv4, IPv6, IPX, and CLNP are irrelevant to the applications programmer. This work was originally motivated by the desire to minimize the impact on standard BSD utilities to support TUBA, but work equally well for IPv6. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sklower-ipv6-getconninfo-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-sklower-ipv6-getconninfo-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-sklower-ipv6-getconninfo-03.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: <19950627133505.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-sklower-ipv6-getconninfo-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-sklower-ipv6-getconninfo-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950627133505.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 28 22:10:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09911; Wed, 28 Jun 95 22:10:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09905; Wed, 28 Jun 95 22:10:36 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18235; Wed, 28 Jun 1995 22:00:37 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id WAA09234; Wed, 28 Jun 1995 22:00:40 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15181(4)>; Wed, 28 Jun 1995 22:00:33 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 28 Jun 1995 22:00:27 -0700 To: jhalpern@newbridge.com (Joel Halpern) Cc: ipng@sunroof2.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 330) Re: Neighbor Discovery and Multi-Homed hosts In-Reply-To: jhalpern's message of Mon, 26 Jun 95 23:58:53 -0800. <9506271558.AA12702@lobster.Newbridge.COM> Date: Wed, 28 Jun 1995 22:00:25 PDT From: Steve Deering Message-Id: <95Jun28.220027pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Joel, > I had actually thought that the earlier discussion had agreed that this > [a metric query function] was a good thing. I don't remember such as agreement. Can you give an approximate date of the discussion, so I can look it up in the archive? Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 29 06:50:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10121; Thu, 29 Jun 95 06:50:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10115; Thu, 29 Jun 95 06:50:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06227; Thu, 29 Jun 1995 06:40:36 -0700 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id GAA08545; Thu, 29 Jun 1995 06:40:32 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA16232; Thu, 29 Jun 1995 06:12:38 -0700 Received: by xirtlu.zk3.dec.com; id AA23181; Thu, 29 Jun 1995 09:12:32 -0400 Message-Id: <9506291312.AA23181@xirtlu.zk3.dec.com> To: rja@cs.nrl.navy.mil Cc: Thomas Narten , ipng@sunroof2.Eng.Sun.COM, bound@zk3.dec.com Subject: (IPng 331) Re: multi-homed hosts In-Reply-To: Your message of "Wed, 28 Jun 95 11:16:35 EDT." <9506281116.ZM12341@bodhi.nrl.navy.mil> Date: Thu, 29 Jun 95 09:12:27 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I am wondering now after I see Tom and Ran's last mail the following: #1 Can we solve this problem even though I "don't think" we have finished what hosts can do as far as forwarding packets. #2 If all we must do is forward the packet onto another interface (and thats allowed by a host in #1) then this is just a simple case of a prefix match as Ran suggested using whatever means an implementor determines to store and locate ND prefixes for interfaces in their kernel implementation (could be in user space but I don't think that will perform well). If all we want to do is #2 and #1 per the WG says thats OK, then its just a matter of using the present ND as it currently is specified. If someone wants something else. Take a stab at stating exactly what would change in ND and please be specific with wording. I think we are past the point of general discussion and need specifics. THen depending on if the ND authors feel its part of ND and will not hold up going to proposed standard they can comment. But I think we are drifting now. I am assuming now that no one wants to "find off-link" prefixes with ND? Joel Halpern do you agree with above statement I think Ran did but I am not sure you do?. This could be the main issue and if so lets get it clearly on the table. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 29 07:07:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10165; Thu, 29 Jun 95 07:07:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10159; Thu, 29 Jun 95 07:07:03 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07210; Thu, 29 Jun 1995 06:56:55 -0700 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id GAA10348; Thu, 29 Jun 1995 06:56:51 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA04583; Thu, 29 Jun 1995 06:20:46 -0700 Received: by xirtlu.zk3.dec.com; id AA23316; Thu, 29 Jun 1995 09:20:43 -0400 Message-Id: <9506291320.AA23316@xirtlu.zk3.dec.com> To: Dan McDonald Cc: narten@vnet.ibm.com, IPng Mailing list , Dan McDonald , Ran Atkinson , bound@zk3.dec.com Subject: (IPng 332) Re: multi-homed hosts In-Reply-To: Your message of "Wed, 28 Jun 95 11:20:34 CDT." <9506281620.aa29060@cs.nrl.navy.mil> Date: Thu, 29 Jun 95 09:20:37 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dan, >The only additional complexity with this is a few more checks at the host >and that only happening on the first packet to a destination (like a TCP >SYN, for example). This way, no interfaces are changed in the middle of >communication, etc. (Which is what I believe was one of KRE's points.) Per addrconf and the next version of DHCPv6 too existing, communications will not be broken ever if a deprecated lifetime is used. We can implement this pretty easy by adding a reference_counter in ifaddr structures to see the variant states an address can be in at the transport. This way we can elegantly migrate interfaces from an old address to a new one. >I mean check the ON-LINK prefixes only. The rationale behind it being, >it might not be optimal, but it will be closer than blindly picking the >default router. It is also relatively straightforward to implement. >With this simple addition, I think we can avoid having to bloat the >relatively clean neighbor discovery, or create a new lightweight routing >protocol. We don't have to change documents, add new complexity, etc. I agree but I don't think we need to put this in ND I think the issue is if a host is multihomed and forwards packets does that break our model of what a host is as specified in Internet Protocol version 6 spec? Personally I think an implementation should be able to forward packets in this manner, but I don't think we need ND to say anything we can implement what you outlined without any changes or words to ND. But not if I am a host as its defined right now. I still think Joel was asking another question? thanks /jim /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 29 07:19:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10185; Thu, 29 Jun 95 07:19:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10179; Thu, 29 Jun 95 07:19:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08118; Thu, 29 Jun 1995 07:09:09 -0700 Received: from ns.newbridge.com by mercury.Sun.COM (Sun.COM) id HAA11525; Thu, 29 Jun 1995 07:09:08 -0700 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id KAA05985; Thu, 29 Jun 1995 10:09:05 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma005983; Thu Jun 29 10:08:52 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id KAA00549; Thu, 29 Jun 1995 10:08:51 -0400 Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA08415; Thu, 29 Jun 95 10:06:55 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA13593; Thu, 29 Jun 1995 10:08:04 +0500 Date: Thu, 29 Jun 1995 10:08:04 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9506291408.AA13593@lobster.Newbridge.COM> To: rja@cs.nrl.navy.mil, bound@zk3.dec.com Subject: (IPng 333) Re: multi-homed hosts Cc: narten@VNET.IBM.COM, ipng@sunroof2.Eng.Sun.COM X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk No, what Ran asked for and what I asked for are two completely different things. Ran has proposed a host behavior for multi-homed hosts which works for certain very carefully assigned address topologies. It may well be very useful for those topologies, and can probably be done strickly by manual configuration in the multi-homed hosts. What I am asking for is a general mechanism based on a simple extension to Neighbor Discovery. This extension was discussed last September. The wording change would 1) Allow a host to send a neighbor discovery query out without any notion of whether the target is actually a neighbor. Since on-wire prefixes are not required, this is arguably at least sometimes currently legal. 2) Allow a router to respond with information about an off-wire destination. This response would have to include a bit indicating that it is a routed destination, so as not to confuse any notions of locality. I would be perfectly happy to accept this response either with a "prefix", or just for the requested host. Note1: There is no problem with the information from such a response becoming unusable. There is already a mechanism for discovering if a router goes down. If the router is still up, but no longer forwards the destination away from the wire, it will send either a re-direct or an unreachable as appropriate, causing the host to take the proper steps. Note2: For multi-homed hosts which send the query out each interface, and select an answer, the selection of one possible interface/next hop when several replies are received is not a routing problem. It is a host policy issue, since all such replies will result in loop free forwarding. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 29 07:52:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10222; Thu, 29 Jun 95 07:52:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10216; Thu, 29 Jun 95 07:52:17 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10688; Thu, 29 Jun 1995 07:42:14 -0700 Received: from inet-gw-1.pa.dec.com by mercury.Sun.COM (Sun.COM) id HAA15252; Thu, 29 Jun 1995 07:42:10 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA13796; Thu, 29 Jun 95 07:33:10 -0700 Received: by xirtlu.zk3.dec.com; id AA25649; Thu, 29 Jun 1995 10:33:05 -0400 Message-Id: <9506291433.AA25649@xirtlu.zk3.dec.com> To: jhalpern@newbridge.com (Joel Halpern) Cc: rja@cs.nrl.navy.mil, bound@zk3.dec.com, narten@VNET.IBM.COM, ipng@sunroof2.Eng.Sun.COM Subject: (IPng 334) Re: multi-homed hosts In-Reply-To: Your message of "Thu, 29 Jun 95 10:08:04 +0500." <9506291408.AA13593@lobster.Newbridge.COM> Date: Thu, 29 Jun 95 10:32:59 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Joel, >No, what Ran asked for and what I asked for are two completely different >things. Thanks I thought so. >Ran has proposed a host behavior for multi-homed hosts which works for >certain very carefully assigned address topologies. It may well be >very useful for those topologies, and can probably be done strickly by >manual configuration in the multi-homed hosts. I agree and I would ask ND authors to address that suggesting seperately and it has two questions as I proposed that need answers. We may not have to do anything in ND as I could implement Dan's idea without any changes to ND and I would not be against the spirit of IPv6 unless I should not forward packets as a multi-homed node. >What I am asking for is a general mechanism based on a simple extension >to Neighbor Discovery. This extension was discussed last September. >The wording change would >1) Allow a host to send a neighbor discovery query out without any notion > of whether the target is actually a neighbor. Since on-wire prefixes > are not required, this is arguably at least sometimes currently legal. Well I fought this battle about 6 months ago and was told it would be counter to RFC 1256 where much of the design philosophy came from for ND as far as what hosts can or cannot do. This would be a new solicitation type in ND. >2) Allow a router to respond with information about an off-wire destination. > This response would have to include a bit indicating that it is a routed > destination, so as not to confuse any notions of locality. I would be > perfectly happy to accept this response either with a "prefix", or just > for the requested host. OK can we get a real world example of how this would be used? But let me try one OK and if my example is wrong please correct me. I have an application that wants to get a message to a node that I know can send a message over an ATM link I want to use. But its not in my ND cache and I have not heard from it or even the prefix. I ask the link anyone know about this node. The router responds come to me I will get you to the mountain you wish to climb. The question I have is how does a host know its wants to get to this node? It must come from some kind of application right? Why would this ever be the case and for what business reason would this be valuable to any customer? It seems to me that this avoids the entire ND design philosophy of the default router and preferences. In fact counter to ND and a backdoor to ignore the ND inherent policy in the present spec? Is this really a good idea? >Note1: There is no problem with the information from such a response > becoming unusable. There is already a mechanism for discovering if > a router goes down. If the router is still up, but no longer forwards > the destination away from the wire, it will send either a re-direct or > an unreachable as appropriate, causing the host to take the proper steps. Yes this will work for a default router too for that link? >Note2: For multi-homed hosts which send the query out each interface, and > select an answer, the selection of one possible interface/next hop when > several replies are received is not a routing problem. It is a host > policy issue, since all such replies will result in loop free forwarding. I agree only when duplicate preference levels exist in the ND advertisement. This could be something we need to add to ND that the routers on the link MUST NOT have duplicate preference levels. But, are you also assuming that the multihome host is using two distinct links or on the same link. On the same link I don't think we should see the same preference level. You are asking for off-link prefix detection and more if the router can do it. thanks for the clarification, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 29 09:21:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10285; Thu, 29 Jun 95 09:21:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10279; Thu, 29 Jun 95 09:20:53 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20660; Thu, 29 Jun 1995 09:10:53 -0700 Received: from inet-gw-1.pa.dec.com by venus.Sun.COM (Sun.COM) id JAA06325; Thu, 29 Jun 1995 09:10:53 -0700 Received: from muggsy.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA28044; Thu, 29 Jun 95 09:03:43 -0700 Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA29586; Thu, 29 Jun 1995 12:03:41 -0400 Received: by netrix.lkg.dec.com; (5.65/1.1.8.2/28May95-0415PM) id AA09855; Thu, 29 Jun 1995 12:03:43 -0400 Date: Thu, 29 Jun 1995 12:03:43 -0400 From: Dan Harrington Message-Id: <9506291603.AA09855@netrix.lkg.dec.com> To: narten@VNET.IBM.COM Subject: (IPng 335) Re: multi-homed hosts Cc: dan@netrix.lkg.dec.com, ipng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi Thomas, In responding to Ran you stated: > I agree that there are still scenarios that neither v4 or the ND solve > satisfactorily, namely, selecting which outgoing *interface* to use in > forwarding a packet to an off-link destination. I'd just like to point out (as I did off-line at the interim meeting) that the problem isn't limited to off-link destinations...if a multihomed host has to transmit a packet to a Link-Local destination address, it still has no idea which source address/interface to use. In particular, the statement in Section 9 that packets should only be transmitted on links with routers (and hence learned prefixes) will cause connectivity problems for hosts using link-local addresses. For this particular case I'd suspect that doing Neighbor Solicitation on all interfaces would be appropriate, but this is yet another mechanism which falls outside the scope of Neighbor Discover per se. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 29 09:31:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10297; Thu, 29 Jun 95 09:31:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10291; Thu, 29 Jun 95 09:31:15 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22016; Thu, 29 Jun 1995 09:21:11 -0700 Received: from bodhi.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id JAA27172; Thu, 29 Jun 1995 09:21:09 -0700 From: Ran Atkinson Message-Id: <9506291219.ZM14230@bodhi.nrl.navy.mil> Date: Thu, 29 Jun 1995 12:19:37 -0400 In-Reply-To: bound@zk3.dec.com "Re: (IPng 323) Re: multi-homed hosts" (Jun 29, 9:12) References: <9506291312.AA23181@xirtlu.zk3.dec.com> Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: bound@zk3.dec.com, rja@cs.nrl.navy.mil Subject: (IPng 336) Re: multi-homed hosts Cc: Thomas Narten , ipng@sunroof2.Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Jim, I have never wanted to determine "off-link prefixes" using the bitwise comparisons. My only objective was to improve the probability of using an outbound interface that does have reachability to the destination, for the single case of multi-homed hosts. I don't think this means altering any ND packets whatsoever and believe this would be a change strictly within the multi-homed hosts itself (perhaps I'm confused about the scope of the proposed change, if so please correct). Ran rja@cs.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 29 09:39:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10314; Thu, 29 Jun 95 09:39:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10308; Thu, 29 Jun 95 09:39:40 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23148; Thu, 29 Jun 1995 09:29:41 -0700 Received: from bodhi.nrl.navy.mil by venus.Sun.COM (Sun.COM) id JAA07964; Thu, 29 Jun 1995 09:29:36 -0700 From: Ran Atkinson Message-Id: <9506291223.ZM14245@bodhi.nrl.navy.mil> Date: Thu, 29 Jun 1995 12:23:15 -0400 In-Reply-To: bound@zk3.dec.com "Re: (IPng 324) Re: multi-homed hosts" (Jun 29, 9:20) References: <9506291320.AA23316@xirtlu.zk3.dec.com> Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 337) Re: multi-homed hosts Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Jim, I wasn't (and I don't think Dan was) talking about having a multi-homed host _forward_ any packets. We like the current IPv6 definitions of node, host, and router. Our proposal is limited just to the initial selection of which outbound interface to use for a given first IP packet. We were not suggesting any forwarding at all and don't envision any changes to our BSD forwarding engine to add this outbound interface selection process. Maybe I am not following your comments ? Ran rja@cs.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 29 10:54:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10438; Thu, 29 Jun 95 10:54:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10432; Thu, 29 Jun 95 10:54:46 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04815; Thu, 29 Jun 1995 10:44:40 -0700 Received: from inet-gw-2.pa.dec.com by mercury.Sun.COM (Sun.COM) id KAA13093; Thu, 29 Jun 1995 10:44:40 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA18324; Thu, 29 Jun 95 10:36:30 -0700 Received: by xirtlu.zk3.dec.com; id AA00589; Thu, 29 Jun 1995 13:36:26 -0400 Message-Id: <9506291736.AA00589@xirtlu.zk3.dec.com> To: rja@cs.nrl.navy.mil Cc: bound@zk3.dec.com, Thomas Narten , ipng@sunroof2.Eng.Sun.COM Subject: (IPng 338) Re: multi-homed hosts In-Reply-To: Your message of "Thu, 29 Jun 95 12:19:37 EDT." <9506291219.ZM14230@bodhi.nrl.navy.mil> Date: Thu, 29 Jun 95 13:36:20 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Ran, > I have never wanted to determine "off-link prefixes" using the bitwise >comparisons. My only objective was to improve the probability of using >an outbound interface that does have reachability to the destination, >for the single case of multi-homed hosts. I don't think this means >altering any ND packets whatsoever and believe this would be a change >strictly within the multi-homed hosts itself (perhaps I'm confused >about the scope of the proposed change, if so please correct). I realize this and agree. My issue is that your msg was in response to Joels and Joel does want knowledge of off-link interfaces. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 29 10:58:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10456; Thu, 29 Jun 95 10:58:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10450; Thu, 29 Jun 95 10:58:20 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05465; Thu, 29 Jun 1995 10:48:20 -0700 Received: from inet-gw-2.pa.dec.com by mercury.Sun.COM (Sun.COM) id KAA13717; Thu, 29 Jun 1995 10:48:20 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA19223; Thu, 29 Jun 95 10:41:58 -0700 Received: by xirtlu.zk3.dec.com; id AA00756; Thu, 29 Jun 1995 13:42:01 -0400 Message-Id: <9506291742.AA00756@xirtlu.zk3.dec.com> To: rja@cs.nrl.navy.mil Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 339) Re: multi-homed hosts In-Reply-To: Your message of "Thu, 29 Jun 95 12:23:15 EDT." <9506291223.ZM14245@bodhi.nrl.navy.mil> Date: Thu, 29 Jun 95 13:41:55 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Ran, > I wasn't (and I don't think Dan was) talking about having a multi-homed >host _forward_ any packets. We like the current IPv6 definitions of node, >host, and router. Our proposal is limited just to the initial selection >of which outbound interface to use for a given first IP packet. We >were not suggesting any forwarding at all and don't envision any changes >to our BSD forwarding engine to add this outbound interface selection >process. > Maybe I am not following your comments ? To only select the packet for an interface IMHO requires no change to ND we have that now. Yes I was assuming (incorrectly) that you were proposing if a packet comes in one interface and the destination is on the other multihome interface (gateway box which hosts do often today) the packet will get forwarded. If we want to do that I can do that too with the present ND. Anyway we have two topics going on now. I agree with you that under the present spec I would not forward a packet in an implementation to another interface unless I was a "router". But Joels request is different. And I don't think we need any change to ND to do what Dan suggested? But another topic its an implementation issue I don't think a standards issue? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 29 16:24:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10753; Thu, 29 Jun 95 16:24:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10747; Thu, 29 Jun 95 16:24:37 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18926; Thu, 29 Jun 1995 16:14:30 -0700 Received: from wizard.gsfc.nasa.gov by mercury.Sun.COM (Sun.COM) id QAA19074; Thu, 29 Jun 1995 16:14:28 -0700 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA04960; Thu, 29 Jun 95 19:11:31 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9506292311.AA04960@wizard.gsfc.nasa.gov> Subject: (IPng 340) Re: multi-homed hosts To: bound@zk3.dec.com Date: Thu, 29 Jun 1995 19:11:30 -0400 (EDT) Cc: jhalpern@newbridge.com, rja@cs.nrl.navy.mil, narten@VNET.IBM.COM, ipng@sunroof2.Eng.Sun.COM In-Reply-To: <9506291433.AA25649@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jun 29, 95 10:32:59 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > >2) Allow a router to respond with information about an off-wire destination. > > This response would have to include a bit indicating that it is a routed > > destination, so as not to confuse any notions of locality. I would be > > perfectly happy to accept this response either with a "prefix", or just > > for the requested host. > > OK can we get a real world example of how this would be used? But let > me try one OK and if my example is wrong please correct me. > > I have an application that wants to get a message to a node that I know > can send a message over an ATM link I want to use. But its not in my ND > cache and I have not heard from it or even the prefix. I ask the link > anyone know about this node. The router responds come to me I will get > you to the mountain you wish to climb. > > The question I have is how does a host know its wants to get to this > node? It must come from some kind of application right? Why would this > ever be the case and for what business reason would this be valuable to > any customer? > > It seems to me that this avoids the entire ND design philosophy of the > default router and preferences. In fact counter to ND and a backdoor to > ignore the ND inherent policy in the present spec? Is this really a > good idea? The simple idea of a default route is no longer sufficient for picking routes to destinations for which the host does not have an explicit route. The real world case which is of major interest to me is a multi-homed host which has a connection to say an Ethernet (or FDDI or ...) which provides an indirect connection to the Internet and also a connection to an ATM network which provides direct ATM connectivity to a large number of different nets. I want to be able to direct any traffic to a destination that is directly reachable on the ATM network to use the ATM interface, while possibly setting the default route to the Ethernet connection so any other traffic uses the normal Internet path (and not require a huge routing table on the host). This could be done by querying the neighboring router on the Ethernet and a neighboring route server on the ATM net for the route to the destination IP address. Each router/route server would return the best match route/prefix for the destination and the host would select the "best" match from the responses. For example, if the host query was for a destination that was directly reachable via the ATM net, the neighboring ATM route server would return an explicit route for the destination while the neighboring Ethernet router might just return the default route, and the explicit route would be a better match than the default route, so the ATM path would be used over the Ethernet path. If the host request was for a non-ATM destination, the neighboring ATM route server might return a null response indicating it didn't have a route for the destination, while the neighboring Ethernet router would again return the default route. In this case, the default route would be used, and the Ethernet path to the Internet would be taken. In case of ties on prefix length, a routing metric could be used to determine the "best" route, e.g. if the neighboring ATM route server and the neighboring Ethernet router both simply returned the default route. One other oddity to this scheme is that the neighboring ATM route server might very well return routes with a metric of 0, to indicate to the host that the destination was directly reachable via the ATM net, i.e. it should be treated as an interface route on the ATM interface. The ATM route server might not actually forward any packets but only function to provide reachability information for those nets that were part of the ATM cloud. I don't like the idea of the router actually advertising external routes, since this might be very impractical when a very large number of nets were involved. I prefer it being done on-demand via a query/response mechanism. Having said all that, I don't know if such a function should be part of Neighbor Discovery. Perhaps there should be an adjunct document, say Route Discovery, that could specify a mechanism for this. For one thing, it might not be the immediately neighboring router that you would want to query, but perhaps an authoritative router/route server for the site. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 29 16:59:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10774; Thu, 29 Jun 95 16:59:30 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10768; Thu, 29 Jun 95 16:59:21 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id QAA16554; Thu, 29 Jun 1995 16:49:21 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id QAA01173; Thu, 29 Jun 1995 16:49:03 -0700 Date: Thu, 29 Jun 1995 16:49:03 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199506292349.QAA01173@bobo.Eng.Sun.COM> To: dan@lkg.dec.com, ipng@sunroof2.Eng.Sun.COM Subject: (IPng 341) Re: multi-homed hosts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Quoting Dan out of context: > For this particular case I'd suspect that doing Neighbor Solicitation > on all interfaces would be appropriate, but this is yet another > mechanism which falls outside the scope of Neighbor Discover per se. I'm glad that you think this falls out of scope. What I'd like to do in order to make progress on ND is the following: - ensure that the ND specification does not restrict implementors from experimenting with various solutions relating to multihomed hosts. We plan on adding some text to the next rev of the spec to clarify this. - encourage implementors and the WG to discuss multihoming problems and solutions much like this thread of email. In case it isn't obvious, I think it is premature to put any special support for multihomed hosts in ND. We do not yet have a specifcation for how multihomed IPv6 hosts work in general and before we have a shared agreement on that it is hard to agree on what, if anything, needs to be added to ND. Some of the multihoming issues on which we need to agree are the old ones discussed in the host requirements WG but left open to the implementor. However, this email thread and previous discussions has identified other issues like: - selecting the outgoing interface for off-link destionations. - selecting the outgoing interface when the host doesn't know if the destination is on or off-link (e.g. the host doesn't know the prefixes because there are no routers). - selecting, among multiple addresses assigned to an interface, the source address to use for a packet/connection. This issue applies to hosts that are logically multihomed by having multiple IP addresses without necesserily having multiple interfaces. I would welcome any effort to address these issues. I don't think we should hold up ND until we have decided how these (and potentially other) multihoming issues are resolved. Does anybody think that we need to do more to the ND specification than relax the language about multihoming to point out that hosts may experiment with algorithms for multihoming? Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 29 18:15:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10787; Thu, 29 Jun 95 18:15:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10781; Thu, 29 Jun 95 18:14:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29931; Thu, 29 Jun 1995 18:04:57 -0700 Received: from mailrelay.ipsilon.com by mercury.Sun.COM (Sun.COM) id SAA29273; Thu, 29 Jun 1995 18:04:58 -0700 Received: from [140.174.164.133] (annex-p133.meer.net [140.174.164.133]) by mailrelay.ipsilon.com (8.6.10/8.6.10) with SMTP id SAA18667; Thu, 29 Jun 1995 18:11:06 -0700 X-Sender: hinden@tester.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Jun 1995 18:06:03 -0700 To: ipng@sunroof2.Eng.Sun.COM From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 342) Re: multi-homed hosts Cc: hinden@ipsilon.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Folks, A few thoughts on multi-homed hosts in IPv6. 1) Doing a good job dealing with multi-homed hosts in IPv6 is a good idea. There are many multi-homed hosts now and I think we will see more in the future. 2) Currently the majority of hosts are not multi-homed and I do not think single-homed hosts should be required to support the mechanisms for being multi-homed. 3) Dealing with multi-homed hosts is hard. The problem has been around for a long time. It has a number of aspects (selection of best routes, source address selection, routerless operation, security, etc.). I suspect it will take a long time to develop a satisfactory overall solution for multi-homed support. 4) The problem looks to me like a routing problem. I do not think the solution should part of neighbor discovery. I am not certain, but I wonder if we develop a new mechanism to handle multi-homed hosts, we will end up developing a protocol which looks a lot like a routing protocol (i.e., has metrics, routes, masks, etc). I also wonder if some of the work on demand routing is relevant here. 5) I am also not convinced that the current IPv4 solution of listening to RIP updates is so bad. It does not work in all environments, but in a lot of environments it seems to work well. I don't think we should be so quick to discard it. These issues clearly need to be discussed in Stockholm. I don't think we should hold up the ND work to add multi-homed host support. I would prefer it being in a separate document. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 30 02:32:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11055; Fri, 30 Jun 95 02:32:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11049; Fri, 30 Jun 95 02:32:20 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21217; Fri, 30 Jun 1995 02:22:22 -0700 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id CAA01812; Fri, 30 Jun 1995 02:22:21 -0700 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 343) Re: multi-homed hosts To: hinden@Ipsilon.COM (Bob Hinden) Date: Fri, 30 Jun 1995 10:11:56 +0100 (BST) Cc: ipng@sunroof2.Eng.Sun.COM, hinden@ipsilon.com In-Reply-To: from "Bob Hinden" at Jun 29, 95 06:06:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > 5) I am also not convinced that the current IPv4 solution of listening to > RIP updates is so bad. It does not work in all environments, but in a lot > of environments it seems to work well. I don't think we should be so quick > to discard it. The problem is the work it requires, and the fact the hosts have to be in the router multicast groups. A router->host 'simple route update protocol' is probably more appropriate than having .5Mb of gated chewing at OSPF tables on every host. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 30 06:33:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11152; Fri, 30 Jun 95 06:33:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11146; Fri, 30 Jun 95 06:33:28 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28773; Fri, 30 Jun 1995 06:23:29 -0700 Received: from dg-rtp.dg.com by mercury.Sun.COM (Sun.COM) id GAA15235; Fri, 30 Jun 1995 06:23:28 -0700 Received: from commtg3-alt.rtp.dg.com by dg-rtp.dg.com (5.4R2.01/dg-rtp-v02) id AA23247; Fri, 30 Jun 1995 09:23:15 -0400 Received: by commtg3 (8.6.10/rtp-s04) id NAA21903; Fri, 30 Jun 1995 13:23:13 GMT Date: Fri, 30 Jun 1995 13:23:13 GMT From: smithk@dg-rtp.dg.com (Keith Smith) Message-Id: <199506301323.NAA21903@commtg3> To: ipng@sunroof2.Eng.Sun.COM Cc: sklower@CS.Berkeley.EDU Subject: (IPng 344) gethostbyname/getconninfo Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk With regard to draft-sklower-ipv6-getconninfo-03.txt, here's an RFE. It would be useful for an application to be able to specify the resolution mechanism(s) to attempt ... that is, to override /etc/svcorder. A case in point is a server application which parses hostnames from it's config file but can't generate network traffic because of a potential deadlock; using /etc/hosts w/o parsing it would be nice. The same is true of getservbyname and /etc/services. Another possibility (perhaps in addition to) would be an enhanced /etc/svcorder mechanism which allows users to specify the resolution order on a "per-application basis". The API would then need an application identification field/param to select the appropriate entry. -- Thanks, Keith ------------------------------------------------------------------------- Keith Smith Data General Corp - RTP, NC smithk@dg-rtp.dg.com (919) 248-6244 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 30 07:13:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11186; Fri, 30 Jun 95 07:13:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11180; Fri, 30 Jun 95 07:13:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01308; Fri, 30 Jun 1995 07:03:12 -0700 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id HAA18749; Fri, 30 Jun 1995 07:03:06 -0700 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 345) Re: gethostbyname/getconninfo To: smithk@dg-rtp.dg.com (Keith Smith) Date: Fri, 30 Jun 1995 14:51:55 +0100 (BST) Cc: ipng@sunroof2.Eng.Sun.COM, sklower@CS.Berkeley.EDU In-Reply-To: <199506301323.NAA21903@commtg3> from "Keith Smith" at Jun 30, 95 01:23:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > specify the resolution mechanism(s) to attempt ... that is, > to override /etc/svcorder. A case in point is a server > application which parses hostnames from it's config file > but can't generate network traffic because of a potential > deadlock; using /etc/hosts w/o parsing it would be nice. The > same is true of getservbyname and /etc/services. > > Another possibility (perhaps in addition to) would be an > enhanced /etc/svcorder mechanism which allows users to specify > the resolution order on a "per-application basis". The API > would then need an application identification field/param > to select the appropriate entry. > Minor side related issue to all of this. Can people please keep paths _out_ of discussions/documents. /etc/hosts is very unix-specific. IPv6 socket API's and their discussion don't belong that way. After all it might be [shudder 8)] SYS$SYSTEM:[IPV6.ETC]hosts;1 I would agree with the poster that the order (and choice) of resolutions has to configurable. Its easy to conceive of securitly levels for different resolution mechanisms based on their spoofabililty. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 30 17:00:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11330; Fri, 30 Jun 95 17:00:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11324; Fri, 30 Jun 95 17:00:18 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12333; Fri, 30 Jun 1995 16:50:18 -0700 Received: from CLYNN.BBN.COM by mercury.Sun.COM (Sun.COM) id QAA04949; Fri, 30 Jun 1995 16:50:18 -0700 Message-Id: <199506302350.QAA04949@mercury.Sun.COM> Date: Fri, 30 Jun 95 19:48:47 EDT From: Charles Lynn To: iesg@cnri.reston.va.us Cc: ipng@sunroof2.Eng.Sun.COM, CLynn@BBN.COM Subject: (IPng 346) Re: Last Call: Internet Protocol, Version 6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Folks, In response to the IESG Last Call on 1. Internet Protocol, Version 6 (IPv6) Specification 3. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Executive Summary ================= My primary concerns are with a lack of extensibility in the Routing Header, trying to keep hosts out of "routing", inability of the ICMPv6 message formats to communicate information necessary to satisfy the written requirements, and a few security issues. I think that these issues should be addressed before the documents are advanced to Proposed Standard. Discussion ========== draft-ietf-ipngwg-ipv6-spec-02.txt 1) The meaning of "excluded" in section 4.2, Options, should be made clearer. It might mean "set to zero", or it might mean "the bytes are removed and the message repacked". 2) It is also not clear whether "Data that can change en-route" means the whole Option Data field, or only those bytes that might change. If it means the latter, then each option defining document should explicitly specify which bytes MUST be zeroed. The choice could also depend on the Option Type. For reasons of extensibility, I would specify that the whole Option Data field should be zeroed, even though dosing so slightly reduces the portion of the packet that can be authenticated. Suggested text is to add a sentence after: Data that can change en-route must be excluded from the integrity assurance computation performed when the Authentication header is present. Add: By "excluded", we mean that all bytes of the Option Data field should be set to zero (0) when being processed by the authentication transform. 3) The Routing Header as defined does not go far enough to allow future versions to be incrementally deployed in the Internet. Having a version number field is not sufficient, since changes in the end-systems (hosts) as well as the intermediate-systems (routers) would be required before a new version could be used. In the past, a high priority has been placed on allowing upgrades to the routing infrastructure without simulatneously requiring changes to the hosts. I believe we should have the same goal for IPv6. I suggest the following changes to make incremental deployment of new Routing Header versions possible. There should be a length field so that a node that receives a packet containing a new version of the Routing Header can skip over it and continue processing the datagram. There should be a mechanism to indicate that the semantics of the Routing Header have been satisfied, so that a node processing the packet knows it may legitimately skip over the Routing Header. The node that completes the semantics of the Routing Header should use the mechanism to mark the Routing Header as completed for subsequent nodes. 4) A datagram originating host, not being a router, may not have sufficient information to construct a Routing Header, either for an existing version or a new version. Consequently, some other system, such as a (policy) router, may insert a Routing Header after the packet has left the source host. If the source provided an Authentication Header, the receiving system has no way to tell that the Routing Header should not be included when validating the end-to-end authentication. I suggest adding a flag that indicates that the Routing Header was added by an intermediate system and that the Routing Header should be ignored when authenticating the packet. An alternative mechanism, encapsulating the datagram in an identical IPv6 header (except for Payload Length) followed by the inserted Routing Header, seems particularly wasteful so I would not try to use it. A proposed solution to points 3 and 4: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len |A|C|RoutingType| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . type-specific data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Hdr Ext Len 8-bit unsigned integer. Length of the Routing Header in 8-octet units, not including the first 8 octets. A 1-bit flag. Initialized to zero (0). Set to one (1) when a system inserts the Routing Header into a packet that is already covered by an Authentication Header. A system omits the whole Routing Header from its authentication transform when the A bit is set to one (1). C 1-bit flag. Initialized to zero (0). Set to one (1) when a system has processed the last item in the Routing Header. A system that receives a Routing Header with the C bit set to one (1) may skip over the header if it does not understand the Routing Type, and continue normal processing of the packet, e.g., deliver it to an upper protocol layer. Routing Type 6-bit identifier of a particular Routing header variant. The A and C bits could be moved to a separate byte if 64 routing variants are thought to be inadequate for the projected lifespan of IPv6. draft-ietf-ipngwg-icmp-02.txt 5) Several ICMP messages MUST be "passed to the upper layer". There are two scenarios where this is not possible given the definition of the messages. The first is where the necessary demultiplexing information, upper layer protocol number and ports, is not present in the message because the offending packet was truncated to meet the 576 byte ICMPv6 packet length limit. The second case is when the information is opaque due to the presence of an ESP header. Note also that in the case of ESP, even if the complete packet in error will fit into the 576 byte limit, that the originating system may not be able in all cases, to decrypt the opaque data, e.g., when asymmetric keying is in use. The problem of demultiplexing all ICMPv6 messages needs to be solved. Given that IPv6 does not contain a well defined packet identifier, one suggestion to solve the problem is to add 128 bits to the ICMPv6 message headers as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused / Type specific data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aux Type | Protocol | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upper Layer 0-31 or SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upper Layer 32-63 or Opaque 0-31 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upper Layer 64-95 or Opaque 32-63 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As much of invoking packet | + as will fit without ICMPv6 packet + | exceeding 576 octets | + + | | where: Aux Type 8-bit unsigned integer. When 1, upper layer protocol information follows. When 2, ESP information follows. Protocol, Upper Layer 0-95 When Aux Type is 1, Protocol contains the upper layer protocol number from the datagram in error and Upper Layer 0-95 is the first 96 bits of the upper layer protocol header. SPI, Opaque 0-63 When Aux Type is 2, the SPI contains the SPI field from the ESP header and Opaque 0-63 contains the first 64 bits of the Opaque Transform Data. The encapsulating node SHOULD retain information about the upper layer protocol and ports of datagrams that it sends along with the resulting SPI and initial Opaque Transform Data so that subsequently received ICMPv6 messages can be matched to the SPI and Opaque 0-63 fields and thus recover the upper layer protocol layer information. A side effect of making the upper layer Protocol number and initial header data explicit is that the node that detects the error must be able to parse the packet to find the upper layer protocol header, which in turn implies that the node can tell the difference between IPv6 Extension Headers and upper layer protocols. Since both new extension headers and protocols will be added in the future, an extensible mechanism needs to be defined. Two possibilities are to use a configurable (a la DHCPv6) list of extension protocol numbers, or to assign all extension protocol numbers from a well known block, e.g., starting with 254 and working down, while upper layer protocols would continue to work up from 1. Given that extension header numbers have already been assigned that do not meet this criteria, the first mechanism seems like the best choice. 6) "Security considerations are not discussed in this memo." is not adequate. There should at least be some guidelines about when to include the Authentication Header in ICMPv6 messages. Having to have a preexisting explicit security association (SPI) for each end system in each router in order to authenticate an ICMP message does not scale. There needs to be some mechanism that does not require negotiation between the node originating the ICMPv6 datagram and the node that will receive it. One possibility would be to enter router nodes into the DNS and use DNS KEY record information to authenticate the messages. Maybe there should be some well defined SPI value(s) (less the keying material, which could come from the DNS KEY records) to specify standard transform(s) for use by nodes that generate ICMPv6 messages. The question of whether and when ICMPv6 messages should use ESP should be discussed. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com