From owner-ipng@sunroof.eng.sun.com Tue Apr 1 02:33:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA25682; Tue, 1 Apr 1997 02:25:22 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA25675; Tue, 1 Apr 1997 02:25:09 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA04047; Tue, 1 Apr 1997 02:25:52 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id CAA05675; Tue, 1 Apr 1997 02:30:46 -0800 From: Masataka Ohta Message-Id: <199704011023.TAA16149@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA16149; Tue, 1 Apr 1997 19:22:45 +0859 Subject: (IPng 3459) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt To: Erik.Nordmark@Eng (Erik Nordmark) Date: Tue, 1 Apr 97 19:22:43 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199704010002.QAA19375@bobo.eng.sun.com>; from "Erik Nordmark" at Mar 31, 97 4:02 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1682 > The document says: > 4) Make a clear distinction between the ``locator'' part of an > address and the ``identifier'' part of the address. The former > is used to route a packet to its end point, the latter is used > to identify an end point, independent of the path used to > deliver the packet. Although this is a potentially revolutionary > change to IPv6 addressing model, existing transport protocols > such as TCP and UDP will not take advantage of the split. Future > transport protocols (e.g., TCPng), however, may. > > I think that the benefit of globally unique ESDs will be very low unless > TCP and UDP can take advantage of the ESDs from the start. Agreed. This kind of decision will need yet another revision only to delay the final standardization of IPv6. > I was looking through the draft for a clear and concise line of argument > the back up the above recommendation but I didn't find much. There was no discussion on this point except that Mike's idea of hiding locator is no good. > What exactly are the concerns that lead to the above recommendation? The concern at the Interim meeting was that lack of TCP checksum protection may nor may not be harmful if source locator is rewritten at the site border router. There, absolutely, is no concern about rewriting the destination locator. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 04:45:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA25761; Tue, 1 Apr 1997 04:35:17 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA25754; Tue, 1 Apr 1997 04:34:57 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA11656; Tue, 1 Apr 1997 04:35:54 -0800 Received: from mimesweeper.integralis.co.uk (mimesweeper.integralis.co.uk [193.122.60.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id EAA29687 for ; Tue, 1 Apr 1997 04:40:51 -0800 Date: Tue, 1 Apr 1997 04:40:51 -0800 Received: from justin (unverified [193.128.143.160]) by mimesweeper.integralis.co.uk (Integralis SMTPRS 2.02) with ESMTP id ; Tue, 01 Apr 1997 12:38:40 +0000 Message-Id: <3341021D.2DFA@integralis.com> From: Justin Clark - Integralis UK Reply-To: ipng@integralis.com Organization: INTEGRALIS X-Mailer: Mozilla 4.0b2 (WinNT; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 3460) Re: IPng Interim Meeting Minutes X-Priority: 3 (Normal) References: <9703271929.AA20274@ludwigia.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2008 Thomas Narten wrote: > > > >I've been background to this mailing list and have come across two > > >terms, ESD and 8+8 that, I cannot find any reference to in the > > >IPng-related RFCs. > > > See: > > Title : GSE - An Alternate Addressing Architecture for IPv6 > > Author(s) : M. O'Dell Thanks again for the pointers. I'm assuming (please correct me if I've read it wrong!) that as GSE addressing would have a DNS RR in two sections - RG and AAA (ESD+STP) - and that the RG can be re-written on outgoing packets by a Site Border Router, then a Corporate with two of more ISP links could in effect have the best network path chosen *automatically* depending on current path loads (fast/slow/live/dead links). i.e egress packets onto the public topology have their packets registered (and automatically routed) via the most appropriate link at that time? Correct? I also have a question regarding the dynamic insertion of RG upon Site egress (..."means that a computer system might forge the ESD in a source address, it CANNOT forge the point of injection into the Public Topology."). Will it/Could it allow for a non-repudiation of data transmission via IPSECurity AUTH header? i.e the organisation connecting to the public network could legally be held responsible for all data communication? ...and finally for a word I haven't come across before: Goop /gu:n/ n. slang 1) a stupid or fatuous person 2) semi-fluid or sticky material. Routing Goop - Please explain why it could be vacantly silly, purposeless or even perhaps sticky? :) TIA ----------------------------------------------------------------------- Justin Clark Product Manager INTEGRALIS (UK) Email: justin.clark@integralis.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 05:17:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA25849; Tue, 1 Apr 1997 05:07:35 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA25842; Tue, 1 Apr 1997 05:07:25 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA13898; Tue, 1 Apr 1997 05:08:22 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA09724 for ; Tue, 1 Apr 1997 05:13:24 -0800 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA20538; Tue, 1 Apr 1997 08:08:20 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id IAA23468; Tue, 1 Apr 1997 08:08:19 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA17822; Tue, 1 Apr 1997 08:07:43 -0500 Message-Id: <9704011307.AA17822@ludwigia.raleigh.ibm.com> To: Erik.Nordmark@Eng (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3461) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Mon, 31 Mar 1997 16:02:19 PST." <199704010002.QAA19375@bobo.eng.sun.com> Date: Tue, 01 Apr 1997 08:07:43 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2678 > The document says: > 4) Make a clear distinction between the ``locator'' part of an > address and the ``identifier'' part of the address. The former > is used to route a packet to its end point, the latter is used > to identify an end point, independent of the path used to > deliver the packet. Although this is a potentially revolutionary > change to IPv6 addressing model, existing transport protocols > such as TCP and UDP will not take advantage of the split. Future > transport protocols (e.g., TCPng), however, may. > I think that the benefit of globally unique ESDs will be very low unless > TCP and UDP can take advantage of the ESDs from the start. Are we perhaps quibbling about what it means to "take advantage of ESDs"? > I was looking through the draft for a clear and concise line of argument > the back up the above recommendation but I didn't find much. > What exactly are the concerns that lead to the above recommendation? There are (obviously) some problems with the wording. Is the specific objection with "TCP and UDP will not take advantage of the split. ..."? Thinking about what's in the draft, we spend a lot of time explaining why using the ESD alone (without also taking into consideration the current RG) is dangerous. Consequently, our immediate conclusion is that TCP derives *no* benefit from splitting the address into Routing Stuff and an ESD, since any benefit comes with a high prices (e.g., connection hijacking). Although it wasn't our intention, I suspect that most readers would conclude then that our recommendation is to leave TCP alone and have it continue to operate as today, i.e., use full 16 byte addresses. I suppose that is not, strictly speaking, correct. We could (would) still have TCP demultiplex only on the ESD, exclude the Routing Stuff from the pseudo checksum, etc. We don't say that in the draft, though we probably should (since that is where we were heading at the interim meeting). I think we didn't spell this out in the draft because doing these things *today* has no benefit. So why bother? In theory, we could modify TCP down the road to change the Routing Stuff it uses, but I tend to view that as a "new transport protocol", which is perhaps too strong. As long as the ESD is unique enough at the time TCPng is developed, I think things would be OK. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 06:21:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA25975; Tue, 1 Apr 1997 06:12:50 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA25968; Tue, 1 Apr 1997 06:12:39 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA19245; Tue, 1 Apr 1997 06:13:36 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA26603 for ; Tue, 1 Apr 1997 06:18:38 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA21523; Wed, 2 Apr 1997 00:13:28 +1000 (from kre@munnari.OZ.AU) To: Erik.Nordmark@Eng (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3462) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Mon, 31 Mar 1997 16:02:19 PST." <199704010002.QAA19375@bobo.eng.sun.com> Date: Wed, 02 Apr 1997 00:13:28 +1000 Message-Id: <205.859904008@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1013 Date: Mon, 31 Mar 1997 16:02:19 -0800 From: Erik.Nordmark@Eng.Sun.COM (Erik Nordmark) Message-ID: <199704010002.QAA19375@bobo.eng.sun.com> I think that the benefit of globally unique ESDs will be very low unless TCP and UDP can take advantage of the ESDs from the start. Absolutely. Further, the very idea of a TCP or UDP that is in any way incompatible with the TCP shipped with IPv6 ever appearing (after IPv6 is shipped in volume) is so ludicrous as to make suggestions that such a thing may eventually appear absurd. If TCP is ever to make use of ESDs (and I believe it should) as distinct from locators (addresses if you like), now is the time to make it happen - the only chance. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 06:29:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA26000; Tue, 1 Apr 1997 06:19:40 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA25993; Tue, 1 Apr 1997 06:19:29 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA19920; Tue, 1 Apr 1997 06:20:25 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA28612 for ; Tue, 1 Apr 1997 06:25:27 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA27552; Wed, 2 Apr 1997 00:20:10 +1000 (from kre@munnari.OZ.AU) To: Thomas Narten Cc: Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 3463) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Tue, 01 Apr 1997 08:07:43 -0400." <9704011307.AA17822@ludwigia.raleigh.ibm.com> Date: Wed, 02 Apr 1997 00:20:10 +1000 Message-Id: <211.859904410@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1779 Date: Tue, 01 Apr 1997 08:07:43 -0400 From: Thomas Narten Message-ID: <9704011307.AA17822@ludwigia.raleigh.ibm.com> I think we didn't spell this out in the draft because doing these things *today* has no benefit. So why bother? Because if the mechanism isn't there today, there's no rational way to add it later and retain compatibility? In theory, we could modify TCP down the road to change the Routing Stuff it uses, but I tend to view that as a "new transport protocol", which is perhaps too strong. I doubt it, I think that is what it would (and needs) to be. As long as the ESD is unique enough at the time TCPng is developed, I think things would be OK. Yes. However unless that happens right now, TCPng is doomed. We can (just maybe) change IP, with the justification that otherwise we're out of capacity, and if we don't do something new, the vast majority of the world won't be able to connect to the internet, so they'll have to do something different, leaving us small minority who are connected with access to a trivially small portion of the world's networks. To avoid that it is worth upgrading. To allow some easier renumbering someplace, or perhaps easier mobile communicatins - upgrade all the systems I own - no way at all. Anything you can bundle with the IPv6 rollout will be adopted, anything simply planned to be added later (as a core protocol) will remain planned forever. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 06:55:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA26053; Tue, 1 Apr 1997 06:47:02 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA26046; Tue, 1 Apr 1997 06:46:53 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA25426; Tue, 1 Apr 1997 06:47:50 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA07294 for ; Tue, 1 Apr 1997 06:52:53 -0800 Received: from rtpdce01.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA30538; Tue, 1 Apr 1997 09:47:13 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id JAA38078; Tue, 1 Apr 1997 09:47:15 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA12068; Tue, 1 Apr 1997 09:46:35 -0500 Message-Id: <9704011446.AA12068@ludwigia.raleigh.ibm.com> To: Robert Elz Cc: Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 3464) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Wed, 02 Apr 1997 00:20:10 +1000." <211.859904410@munnari.OZ.AU> Date: Tue, 01 Apr 1997 09:46:34 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2810 Robert Elz writes: > I think we didn't spell this out in the draft because doing > these things *today* has no benefit. So why bother? > Because if the mechanism isn't there today, there's no rational > way to add it later and retain compatibility? Are you asking the question or asserting this is the case? If the latter, please give specifics. My impression is that there are no TCP changes needed today in order to do ESD-only later. The sender can safely checksum the entire 16 byte address. The requirement for omitting the Routing Stuff from that calculation comes from Border Routers rewriting the RG part of addresses. With that not happening, the sender can checksum the entire address. The issue of dumultiplexing based on ESD only is a receiver issue. It has value only if the receiver is prepared to handle packets coming from different Routing Stuff being delivered to the same endpoint. With routers no longer rewriting the RG, it is not clear to me that this is an issue. Especially if the receiver will continue sending return traffic to the "old" (i.e., assumed to be valid) RG. If there is some benefit of requiring demultiplexing take place now using only the ESD, I don't see it. > As long as the ESD is unique enough at > the time TCPng is developed, I think things would be OK. > Yes. However unless that happens right now, TCPng is doomed. Agreed. And that is the position our draft takes. Quoting from the draft: IPv6 provider-based addressing plan and had enough benefit to warrant making changes to some existing IPv6 documents. These changes include: 3) Designating the low-order 8 bytes of IPv6 addresses to be a globally unique End System Designator (ESD). This change has potential benefits to future transport protocols (e.g., TCPng). > Anything you can bundle with the IPv6 rollout will be adopted, > anything simply planned to be added later (as a core protocol) > will remain planned forever. I'm not sure how to interpret this comment. What are you suggesting that we do? You said before, TCPng is out. We all agree on that. Our conclusion is that ESD-only transport endpoints provide no benefit for today's TCP. Having TCP take advantage of ESD-only things turns it into TCPng, which we can't do. However, that doesn't mean we shouldn't make the ESD-only change viable for a *future* TCPng. Are you saying TCPng won't ever happen? That may be so, but we certainly don't want to preclude that possibility. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 07:31:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA26173; Tue, 1 Apr 1997 07:22:41 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA26166; Tue, 1 Apr 1997 07:22:32 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04883; Tue, 1 Apr 1997 07:23:30 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA19522 for ; Tue, 1 Apr 1997 07:28:30 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA23988; Wed, 2 Apr 1997 01:22:57 +1000 (from kre@munnari.OZ.AU) To: Thomas Narten Cc: Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 3465) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Tue, 01 Apr 1997 09:46:34 -0400." <9704011446.AA12068@ludwigia.raleigh.ibm.com> Date: Wed, 02 Apr 1997 01:22:57 +1000 Message-Id: <241.859908177@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4775 Date: Tue, 01 Apr 1997 09:46:34 -0400 From: Thomas Narten Message-ID: <9704011446.AA12068@ludwigia.raleigh.ibm.com> Are you asking the question or asserting this is the case? Asserting. The problem is that while if I want to talk to a mobile host (say one using a new protocol which allows the RG to be varied) I will upgrade my host, and I can upgrade the mobile host, with the protocols necessary to do it. But the mobile host will also want to talk to the rest of the world. If its 128 bit address is being changed out from under it (leaving just the ESD alone), then there is no way at all it can ever communicate with any host that has not been upgraded to deal with demux on only the ESD. That is, whether you believe the ESD demux is a local issue for hosts or not, I believe it isn't - it actually affects the way the protocols can develop in the future. Note that in the possible future, there may be no hijacking threat from any of this - once we get to the stage where the cpu cost of using encryption everywhere is so neglibible that no-one would even think of turning it off, established TCP connections will essentially be hijack proof. Now right now we probably don't want anyone to simply be able to stick any ESD in a packet, and their RG, and steal connections. One way to avoid that is for a switch in the TCP on hosts, which will cause them to return packets to only the RG/ESD pair seen in the SYN packet (or passed down from the app for active opens). It needs to be a switch so it can be turned off when appropriate. But keep the demux on ESD only - or if you insist, enable that to to altered via a switch too, to lower(minisculely) the possibility of inserting data into an existing stream, even without seeing the output - which exists already in IPv4 as we have it now, almost no-one checks source addresses to see they're valid, and when they're checked at all it is only at boundaries, and coarsely. Also, while I agree totally that RG rewriting by routers now has no use that we can find - I would not like to write it off as something that we're prepared to say now shall never be done (on penalty of checksum errors). Or more correctly, that to do it, the router needs to delve inside the packet, and "fix" the checksum in the transport protocol, condemning anyone who wants to have router RG rewriting (locally, or at any peer) to never being able to use the encryption header as that makes the checksum fix kind of difficult (they probably wouldn't be able to use the AH either, but I don't recall which bytes it includes). Thus, pseudo-header checksum only the ESD, and at least switchably, demux only on the ESD. Then whatever we decide to do to the RG later won't break what we are about to install now. Otherwise, it very well might. I'm not sure how to interpret this comment. What are you suggesting that we do? You said before, TCPng is out. No, I said we do it now, or never (of course, sometime in the future, someone might call something TCPng which is an upwardly compatible version - that doesn't count in the "never"). Our conclusion is that ESD-only transport endpoints provide no benefit for today's TCP. I would agree with that. Having TCP take advantage of ESD-only things turns it into TCPng, which we can't do. Yes - but making it possible for TCP now to interoperate correctly with TCPng later, makes it possible to do TCPng later without it being undeployable. So, while we can't take advantage of it now, we can plan for the future. However, that doesn't mean we shouldn't make the ESD-only change viable for a *future* TCPng. Absolutely - but the way things seem to be going now, there can never be such a thing. Are you saying TCPng won't ever happen? If it doesn't interoperate seamlessly with the TCP that is shipped with IPv6, then no, it will never happen. That would be a not so nice. So, we must plan IPv6's TCP (by which I mean the TCP that goes out the door with IPv6, and the way the two interact) in such a way that a TCPng can be introduced later in an upwardly compatible way. That may be so, but we certainly don't want to preclude that possibility. Good. So, use the ESD only for TCP (with just that switch to set a "safety" mode for now - to return packets only to where the first came from). That way we aren't building in hurdles that need to be jumped (or avoided) later. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 07:56:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA26230; Tue, 1 Apr 1997 07:47:36 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA26223; Tue, 1 Apr 1997 07:47:26 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA10944; Tue, 1 Apr 1997 07:48:24 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA28486 for ; Tue, 1 Apr 1997 07:53:25 -0800 Received: from rtpdce02.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA32256; Tue, 1 Apr 1997 10:46:01 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id KAA25194; Tue, 1 Apr 1997 10:46:03 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15204; Tue, 1 Apr 1997 10:45:22 -0500 Message-Id: <9704011545.AA15204@ludwigia.raleigh.ibm.com> To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3466) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Wed, 02 Apr 1997 01:22:57 +1000." <241.859908177@munnari.OZ.AU> Date: Tue, 01 Apr 1997 10:45:22 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3089 Robert Elz writes: > The problem is that while if I want to talk to a mobile host > (say one using a new protocol which allows the RG to be varied) > I will upgrade my host, and I can upgrade the mobile host, with > the protocols necessary to do it. So you agree that to make use of ESD-only advantages, *both* the sender and receiver must be upgraded? > But the mobile host will also want to talk to the rest of the world. Yes. And I suspect that it will have to use TCPold for this. > If its 128 bit address is being changed out from under it (leaving > just the ESD alone), then there is no way at all it can ever > communicate with any host that has not been upgraded to deal with > demux on only the ESD. I don't think I agree. If the mobile node's address changes --- and its "old" address stops working, then interoperability with non-upgraded hosts can't happen. They will continue to send return traffic to the "old" address (i.e., the "old" Routing Stuff) precisely because they won't change the Routing Stuff they send to once a connection has been started. Thus, even though the non-upgraded host accepts packets coming from the mobile node's "new" address, it won't send packets back to that address. Consequently, two things must happen: the mobile node needs to continue recognizing/processing packets sent to the "old" address, and packets sent to that address need to be delivered to the mobile node's current address (i.e., via something like mobile IP). None of these thing happen will happen today. That is, in order to continue talking to the non-upgraded hosts, the mobile node needs to be fully compatable with the old protocol. The issue of dumultiplexing on ESD and/or not checksumming the Routing Stuff part of an address simply doesn't come into play. The "other" host needs to be modified in order for the benefits of ESD-only operations to have benefit. Consequently, I don't see the need to have today's TCP/UDP do ESD-only things. Again, what is the benefit? > Also, while I agree totally that RG rewriting by routers now > has no use that we can find - I would not like to write it off > as something that we're prepared to say now shall never be done > (on penalty of checksum errors). I (personally) am willing to write it off. I see no sensible way of authenticating RG at the receiver without the sender knowing what its source RG is. Having routers rewrite addresses makes some problems much harder (authenticating received RG for starters). Endpoints must be able to authenticate RG if they are to dynamically use it. > Are you saying TCPng won't ever happen? > If it doesn't interoperate seamlessly with the TCP that is shipped > with IPv6, then no, it will never happen. We can certainly have dual TCPs, TCPold and TCPng. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 08:21:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA26333; Tue, 1 Apr 1997 08:12:43 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA26326; Tue, 1 Apr 1997 08:12:33 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA15539; Tue, 1 Apr 1997 08:13:31 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA07955 for ; Tue, 1 Apr 1997 08:18:29 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id QA30714; Wed, 2 Apr 1997 02:13:14 +1000 (from kre@munnari.OZ.AU) To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3467) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Tue, 01 Apr 1997 10:45:22 -0400." <9704011545.AA15204@ludwigia.raleigh.ibm.com> Date: Wed, 02 Apr 1997 02:13:14 +1000 Message-Id: <270.859911194@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4093 Date: Tue, 01 Apr 1997 10:45:22 -0400 From: Thomas Narten Message-ID: <9704011545.AA15204@ludwigia.raleigh.ibm.com> So you agree that to make use of ESD-only advantages, *both* the sender and receiver must be upgraded? Yes, that is the problem. We need to make it so that as most one of them does. Note that the problem doesn't only occur when you're actually achieving some benefit in communications by use of the ESD only thing, but whenever that applies to you. Eg: if you're a mobile host as I postulated - anyone you communicate with needs to be upgraded. That effectively means the world - and the only time that upgrade will happen is with the IPv6 rollout. ie: Upgrade now... > But the mobile host will also want to talk to the rest of the world. Yes. And I suspect that it will have to use TCPold for this. I think this means either one of two things. Either mobile hosts (and other things that might change in the future) will keep using their old mobileip protocol, hiding the address change - which will be necessary if all the millions of old host can't otherwise talk - and which would make inventing a better protocol a waste of time. Or we make sure now that they will be able to use IPv6 TCP for this by not imposing limitations. I don't think I agree. If the mobile node's address changes --- and its "old" address stops working, then interoperability with non-upgraded hosts can't happen. But it can, if we make the old host implementation flexible enough. That's what has to happen now, as later is too late. We don't have to enable it now - but we have to have the code out there so that it is possible. They will continue to send return traffic to the "old" address (i.e., the "old" Routing Stuff) precisely because they won't change the Routing Stuff they send to once a connection has been started. This is an assumption about the way the old hosts work. If we make that switch on sending packets back, and allow either the addr from the incoming SYN (or addr from active open), as one position on the switch, and the addr (RG) from the last received packet as the other position on the switch, then any host admin can simply throw the switch, based upon their assesment of the cost/benefits of so doing. Consequently, I don't see the need to have today's TCP/UDP do ESD-only things. Again, what is the benefit? As above. But I prefer to ask "What is the cost"? By insisting on adding the RG in where it isn't essential you are limiting future flexibility. For what? As I see it, the only rationale is to keep at least IPv4 level security for connections that have no security. All that means is that return packets go to the address they originally came from (no hijacking) - that's all we have in IPv4. Let's plan for maximum flexibility, and then determine exactly what limits we have to add to make sure we're not losing what we now have, rather than planning for minimum flexibility so everything will be as close to what we have now as we can possibly make it, so we can avoid having to think. We can certainly have dual TCPs, TCPold and TCPng. We can have 100% TCPold, and 0.00001% TCPng, sure. And which of those is your application going to use? As for RG rewriting - didn't someone (Brian perhaps) already point out that this is just NAT done better. NAT seems to (unfortunately) be alive and well right now. Yet sources seem not to know what their address really is. Somehow it works. While I don't think NAT is much of an excuse for anything at all (though others do) it is generally best not to be too sure that an application that's sane won't be found for almost anything that we allow to work. Don't build fences. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 09:18:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA26454; Tue, 1 Apr 1997 09:10:00 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA26447; Tue, 1 Apr 1997 09:09:52 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA26797; Tue, 1 Apr 1997 09:10:48 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA01997 for ; Tue, 1 Apr 1997 09:15:51 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA20490; Tue, 1 Apr 1997 09:06:56 -0800 Message-Id: <3.0.1.32.19970401090443.00700f7c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 01 Apr 1997 09:04:43 -0800 To: bound@zk3.dec.com From: Bob Hinden Subject: (IPng 3468) Re: Router renumbering Cc: Matt Crawford , ipng@sunroof.eng.sun.com In-Reply-To: <9703311416.AA23444@wasted.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1255 Jim, >How about an "INJECT" type where the prefix is injected by an upstream >provider to a Border Router, while we are doing this...or it could go to >an anycast router downstream in the site. Until we have all parts of renumbering done and working, I am a bit nervous about having an ISP change all of the prefixes in a site. I think it is safer policy to keep this control in the site. However, I think the current draft allows this to happen by giving the provider the MD5 key. I also think that in the case where the ISP is providing the router to the internet and all DNS, DHCP, etc. services for the site, the ISP could renumber (add a new prefix, deprecate the old one, later remove the old one) a site with a minimal impact. In this case the ISP would be able to make the changes to the DNS, DHCP, etc. services at the same time they made the prefix changes. >Good job.... Thanks. Matt should get most of the credit. He actually wrote the draft! Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 10:36:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA26607; Tue, 1 Apr 1997 10:27:16 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA26600; Tue, 1 Apr 1997 10:27:04 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA16031; Tue, 1 Apr 1997 10:27:59 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA05529 for ; Tue, 1 Apr 1997 10:32:58 -0800 Received: from rtpdce01.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA25194; Tue, 1 Apr 1997 13:27:14 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id NAA31684; Tue, 1 Apr 1997 13:27:17 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15532; Tue, 1 Apr 1997 13:26:40 -0500 Message-Id: <9704011826.AA15532@ludwigia.raleigh.ibm.com> To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3469) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Wed, 02 Apr 1997 02:13:14 +1000." <270.859911194@munnari.OZ.AU> Date: Tue, 01 Apr 1997 13:26:40 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3159 Robert Elz writes: > So you agree that to make use of ESD-only advantages, *both* the > sender and receiver must be upgraded? > Yes, that is the problem. Seems like we are having a violent agreement of sorts. :-) > Or we make sure now that they will be able to use IPv6 TCP for this > by not imposing limitations. Let me make myself clear. I've been coming from the perspective I had after the interim meeting. We considered changing TCP within the context of GSE, and concluded that there were compelling reasons not to make such a change. The assumption during these discussions was that GSE routers would rewrite RG. With the subsequent decision that routers should not rewrite addresses, the conclusions concerning TCP should be reevaluated. (One of the big stumbling blocks with the GSE scheme was how to authenticate a change in the RG, when the sender couldn't have an IPSec AH covering the RG since it didn't know what its RG was.) Without some modifications to TCP, I don't think there is a benefit to having it do ESD-only operations. I don't see any harm, but I also don't see any benefit. I also don't think we preclude doing ESD-only operations later in an interoperable way. The ESD-only vs. full-address demultiplexing is a receiver issue. It has no impact on the sender, i.e., the sender's behavior is the same whether the receiver demultiplexes on ESD or full address. Whether the sender checksums the full address or just the ESD has no impact, so long as the sender and receiver both know what has been chosen. The checksum was excluded in GSE because the sender didn't know its RG -- there is no way it could include it in the checksum. But that is not an issue now, so it makes sense for the sender to go ahead and do the checksum. IPSec is a little different. It can (and should) make use of the ESD-only. Since IPSec by definition implies shared keys, a lot of the hijacting/security concerns that are present with TCP vanish. The shared keys provide a much stronger assurance than simple address comparisons. Perhaps the right way to turn the discussion now is to consider whether we can make relatively small changes to TCP (and UDP) that would allow it to have equivalent robustness to the current TCP/UDP (i.e., it is not TCPng) and still be able to take advantage of ESD-only benefits. For example, something like the Binding Update (defined for mobile IPv6) (or one of the several variants that have been proposed in the last few years) could be used to direct a specific transport endpoint (e.g., a TCP connection) to change the Routing Stuff part to send outgoing traffic. We'd of course require that the update be processed only if the the sender can be properly authenticated (IPSec should work OK for this). This might give us enough of the benefits without having to go the full route of TCPng. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 11:16:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA26648; Tue, 1 Apr 1997 11:07:25 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA26641; Tue, 1 Apr 1997 11:07:15 -0800 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA02794; Tue, 1 Apr 1997 11:08:14 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA20721; Tue, 1 Apr 1997 11:08:13 -0800 Date: Tue, 1 Apr 1997 11:08:13 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199704011908.LAA20721@bobo.eng.sun.com> To: narten@raleigh.ibm.com Subject: (IPng 3470) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5622 > Are we perhaps quibbling about what it means to "take advantage of > ESDs"? No, it is a more fundamental question. Either ESDs are good (and I think they are) in which case we need to iron out all the issues so that TCP and UDP (especially in the context of surviving runumbering events and handling mobility) can use them. If there are hard unresolved issues with using ESDs for connection identification, security associations etc that we can't resolve I don't see much benefit in introducing ESDs so that some yet to be implemented and deployed new transport protocol can take advantage of the the ESDs. (How many new tranport protocols have been introduced and widely deployed in the Internet in the last 10 years? What evidence do we have that the next 10 years will be different?) So, in my opinion we need to figure out how TCP and UDP can use ESDs for connection identification without jepardizing robustness and introducing new kinds of security holes. Hoping that some new transport protocol will do this for us in the future seems foolish. > There are (obviously) some problems with the wording. Is the specific > objection with "TCP and UDP will not take advantage of the > split. ..."? Yes. If you had said "there are N issues in making TCP and UDP to take advantage of ESD" and listed the issues it would have been a lot better. > Thinking about what's in the draft, we spend a lot of time explaining > why using the ESD alone (without also taking into consideration the > current RG) is dangerous. Consequently, our immediate conclusion is > that TCP derives *no* benefit from splitting the address into Routing > Stuff and an ESD, since any benefit comes with a high prices (e.g., > connection hijacking). I can't quite parse the above. To paraphrase you claim that there are no benfits since the cost/benefit ratio is too high. But the fact that there is a cost/benefit ratio means that there must be some benefits, right? Seriously, as described in draft-thomas-ipv6-esd-00.txt it is not hard to come up with a scheme that makes TCP connections (and UDP?) survive renumbering events by using AH plus a different source RG as a trigger. But note this is quite different than the original GSE proposal since the full IPv6 addresses are part of the pseudo-hdr checksum and covered by AH. > Although it wasn't our intention, I suspect > that most readers would conclude then that our recommendation is to > leave TCP alone and have it continue to operate as today, i.e., use > full 16 byte addresses. Which, BTW is different then what I think the consensus was as the PAL1 meeting. So I think the authors of the draft have found some addition issues that need to be resolved - I just wish the draft would clearly and succinctly list those issues. > > I suppose that is not, strictly speaking, correct. We could (would) > still have TCP demultiplex only on the ESD, exclude the Routing Stuff > from the pseudo checksum, etc. What I read as being the consensus of PAL1 was that, assuming that we can come up with a plan for allocating globally unqueue ESDs, that we want to be able to use just the ESD for identification purposes. But in order to avoid all the problems with undetected bit corruption of the RG that the pseudo-hdr checksum as well as AH should cover the RGs. > We don't say that in the draft, though > we probably should (since that is where we were heading at the interim > meeting). I think we didn't spell this out in the draft because doing > these things *today* has no benefit. So why bother? What do you mean by "*today*". As far as I know nothing related to IPv6 has any benefit today since none of it hasn't been deployed in production environments. But IPv6 is expected to have large benefits in the future - I think the same is true for ESDs assuming we can work out any unresolved robustness issues. So I don't see how you can just disregard any future benefits of ESDs. > In theory, we could modify TCP down the road to change the Routing > Stuff it uses, but I tend to view that as a "new transport protocol", > which is perhaps too strong. As long as the ESD is unique enough at > the time TCPng is developed, I think things would be OK. Unfortunately I think we only have one chance at this. Either we specify the connection identification rules for TCP (and UDP) to use just the ESDs when running on IPv6 or we will never be able to count on this being there. Yes, if somebody does a good job at developping a TCPng it might be deployed. But it will never reach 100% penetration on the IPv6 nodes out there - maybe it won't even reach 10% penetration! Thus in your scenario nobody can rely on TCPng being out there which would make it inpossible to use TCPng's capability to survive connection renumbering just a neat feature but nothing that can be used to convince a large site that they can renumber there site with very little risk since there will be all those old TCP/IPv6 implementations out there. I agree with the motivation for GSE to make site renumbering easier and less risky. We can take a big step in this direction if we use globally unque ESDs to make TCP survive renumbering events. So please list the detailed issues that you guys discovered when writing the draft so that we can get to work and resolve those issues and move forward. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 11:26:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA26666; Tue, 1 Apr 1997 11:16:15 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA26659; Tue, 1 Apr 1997 11:16:02 -0800 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA04049; Tue, 1 Apr 1997 11:16:53 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA20728; Tue, 1 Apr 1997 11:16:52 -0800 Date: Tue, 1 Apr 1997 11:16:52 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199704011916.LAA20728@bobo.eng.sun.com> To: narten@raleigh.ibm.com Subject: (IPng 3471) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt Cc: ipng@sunroof.eng.sun.com, kre@munnari.OZ.AU MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 912 > Having TCP take advantage of ESD-only things turns it > into TCPng, which we can't do. I disagree. We can't require that IPv6 nodes need a new version of TCP. However, if we can develop some compatible mechanisms in TCP that will make it survide renumbering events we can very well put that on the standards track and also perhaps use it as an optimization in IPv6 mobility. I think draft-thomas-ipv6-esd-00.txt is a good start in this direction. Then the implementors building IPv6 might very well decide to bundle these TCP changes with their IPv6 implementation just like the might decide to bundle Dynamic DNS. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 11:45:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA26712; Tue, 1 Apr 1997 11:36:35 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA26705; Tue, 1 Apr 1997 11:36:25 -0800 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA07087; Tue, 1 Apr 1997 11:37:11 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA20741; Tue, 1 Apr 1997 11:37:10 -0800 Date: Tue, 1 Apr 1997 11:37:10 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199704011937.LAA20741@bobo.eng.sun.com> To: kre@munnari.OZ.AU Subject: (IPng 3472) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt Cc: ipng@sunroof.eng.sun.com, narten@raleigh.ibm.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1237 > Thus, pseudo-header checksum only the ESD, and at least > switchably, demux only on the ESD. Excluding the RG from the pseudo-header checksum makes TCP a lot less robust. This issue was brought up and discussed in the PAL1 meeting. The problem is that a single-bit error in the source RG on a SYN packet will cause TCP to send the SYN|ACK to a bogus RG. When the SYN is retransmitted the TCP can't trust the new source RG (since the first one could have been ok and the second SYN could have a bit error) so it will end up retransmitting the SYN|ACK until it times out. Similar issues can show up in statefull protocols built on top of UDP. Thus I think the best path forward is to pseudo-header checksum the whole addresses but only use the ESD for connection identification. This does make it harder to introduce RG rewriting in the future but I don't see how we can exclude the RG from the checksum without compromizing the robustness. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 13:20:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26908; Tue, 1 Apr 1997 13:10:05 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26901; Tue, 1 Apr 1997 13:09:55 -0800 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA24020; Tue, 1 Apr 1997 13:10:46 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA20943; Tue, 1 Apr 1997 13:10:44 -0800 Date: Tue, 1 Apr 1997 13:10:44 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199704012110.NAA20943@bobo.eng.sun.com> To: narten@raleigh.ibm.com Subject: (IPng 3473) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt Cc: ipng@sunroof.eng.sun.com, kre@munnari.OZ.AU MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2650 > Without some modifications to TCP, I don't think there is a benefit to > having it do ESD-only operations. I don't see any harm, but I also > don't see any benefit. I also don't think we preclude doing ESD-only > operations later in an interoperable way. The ESD-only vs. > full-address demultiplexing is a receiver issue. It has no impact on > the sender, i.e., the sender's behavior is the same whether the > receiver demultiplexes on ESD or full address. Whether the sender > checksums the full address or just the ESD has no impact, so long as > the sender and receiver both know what has been chosen. The checksum > was excluded in GSE because the sender didn't know its RG -- there is > no way it could include it in the checksum. But that is not an issue > now, so it makes sense for the sender to go ahead and do the checksum. I disagree that the demux is only a receiver issue. Suppose the sender knows that its source address is changing (i.e. the source prefix it was using is no longer preferred). Then the sender might want to start sending packets with the new source RG and include an AH so that the receiver can authenticate the response. In your model this can't be done since the sender doesn't know if the receiver will use the full source address (including RG) or just the ESD to demux. If it does the former the packets will the new source RG will either be dropped on the floor or cause a TCP reset. Thus by allowing the receiver to demux on the whole address you are preventing (or at least making it a lot harder) to employ schemes like the above example. If you require that the receiver only use the ESDs to demux the above scheme is much more attractable - if the receiver doesn't support the authenticate switch of the peer RG it will just continue to send using the original peer RG and the connection will live until the peer RG becomes invalid. > Perhaps the right way to turn the discussion now is to consider > whether we can make relatively small changes to TCP (and UDP) that > would allow it to have equivalent robustness to the current TCP/UDP > (i.e., it is not TCPng) and still be able to take advantage of > ESD-only benefits. Yes! First we need to indentify to potential sources of reduces robustness to which the draft is elluding so that we can make sure that we are not making things less robust. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 1 19:59:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA27417; Tue, 1 Apr 1997 19:50:42 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA27410; Tue, 1 Apr 1997 19:50:33 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA20229; Tue, 1 Apr 1997 19:51:31 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA05578 for ; Tue, 1 Apr 1997 19:56:41 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id DA16251; Wed, 2 Apr 1997 13:51:20 +1000 (from kre@munnari.OZ.AU) To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3474) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Tue, 01 Apr 1997 13:26:40 -0400." <9704011826.AA15532@ludwigia.raleigh.ibm.com> Date: Wed, 02 Apr 1997 13:51:19 +1000 Message-Id: <343.859953079@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5780 Date: Tue, 01 Apr 1997 13:26:40 -0400 From: Thomas Narten Message-ID: <9704011826.AA15532@ludwigia.raleigh.ibm.com> Seems like we are having a violent agreement of sorts. :-) Almost, but not quite. Without some modifications to TCP, I don't think there is a benefit to having it do ESD-only operations. I don't see any harm, but I also don't see any benefit. I think this is the fundamental difference between us. I see a harm - but that's not the real difference. It is that where there's no particular reason to pick A over B, you (and certainly others) seem to conclude "don't change" (from what we have now). I conclude "simplify". That is, don't do anything that even smells like it could be a limitation later. [See footnote]. Now if we were talking about a widely deployed product, I'd totally agree with you, and if change isn't essential, don't do it. But we're not - yet. Now we can make this change and make it easily. I also don't think we preclude doing ESD-only operations later in an interoperable way. I do. The ESD-only vs. full-address demultiplexing is a receiver issue. It has no impact on the sender, No - it does - if a receiver is demuxing on the full address, then the sender cannot alter the address it sends from. That is an impact on the sender as far as I'm concerned. Further, without some other fancy new negotiation, or something, the sender can't know whether the receiver is demuxing on just ESD or the full address, and so because some receivers may demux upon the full address, it needs to assume that all receivers do. That's the safe and conservative way. Thus no sender can ever change the RG it is using during any connection safely. Whether the sender checksums the full address or just the ESD has no impact, so long as the sender and receiver both know what has been chosen. This is certainly true - but again provided that none of the data is variable. This you assume that RG modification is never to be permitted, ever, anywhere, anytime. I prefer to avoid making that kind of prediction of the future if there isn't a good reason for it. Perhaps the right way to turn the discussion now is to consider whether we can make relatively small changes to TCP (and UDP) that would allow it to have equivalent robustness to the current TCP/UDP (i.e., it is not TCPng) and still be able to take advantage of ESD-only benefits. The "it is not TCPng" confuses me, as I have no idea what that is not to be. No-one seems to agree what TCPng might be - some use it simply as the label for "The TCP used with IPng" which I think is the right definition (the clearest, simplest, and best). Others seem to imagine TCPng as being a radical change to TCP to achieve some unstated purpose (which probably varies from person to person). The "not TCPng" seems to be assuming that TCPng is the latter. Certainly I'm not interested in gutting TCP and starting again - for that we'd need some really compelling reason. Apart from that, I agree - what we should look for is the right way to impose as few unnecessary restrictions upon TCP as we can, while not making its security (and really, it is only security - or the pretence of it - that we're talking about here, none of the changes suggested affect anything else) any weaker than IPv4's for the cases where no other security is being added. Note that my aim here is to be able to take a computer (laptop for example), establish a login session (telnet) to someplace, then suspend the laptop, and disconnect the cables. Now if I reconnect, and resume operations, the telnet session will still be there alive. That's fine. However, if instead of reconnecting I get on a plane, and fly to the other side of the world, and then reconnect, I want the telnet session to also still be alive. Note that in this case the laptop *will* acquire a new address, it loses the old one and acquires the new one with no overlap in address uses at all (as far as it is concerned one microsecond it has one address, and the next time it notices it has a different one). That is, it cannot send packets from its old address to notify the peer of the change, and as it had no idea there was even going to be a new address before it happened, it couldn't have sent a message indicating that a new address is about to be used before the change. Note: I'm willing for other conditions to be imposed to make this work - if it is necessary to use AH on the connection, I'll be using it (from the start - that is, every telnet from the laptop will use AH). Same with encryption. Of course, I'll almost certainly be using those anyway (for reasons obvious to most and unrelated to mobility). If necessary the laptop can have extra new code running in it - but the peers cannot, as I have no idea in advance with whom the telnet session will be established when the changes occur. kre Footnote: I think the same about the link local address definition. I see no compelling reason to require that all the bits in the middle (between prefix and token) be filled with zeroes, so I would prefer not to require that. Others saw it as a change from what existed already (ie: from what had been defined a year before) without compelling reason (which I admit) and so should not be done. I still believe that to have been a mistake, but never mind. Its the same philosophy anyway. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Apr 2 06:13:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA27906; Wed, 2 Apr 1997 06:03:47 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA27899; Wed, 2 Apr 1997 06:03:38 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA24230; Wed, 2 Apr 1997 06:04:36 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA07421 for ; Wed, 2 Apr 1997 06:09:53 -0800 Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA24608; Wed, 2 Apr 1997 09:04:25 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id JAA35098; Wed, 2 Apr 1997 09:04:22 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15252; Wed, 2 Apr 1997 09:03:43 -0500 Message-Id: <9704021403.AA15252@ludwigia.raleigh.ibm.com> To: Robert Elz , nordmark@Eng (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3475) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Wed, 02 Apr 1997 13:51:19 +1000." <343.859953079@munnari.OZ.AU> Date: Wed, 02 Apr 1997 09:03:43 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3428 Erik, kre: I think I see where our disagreement (confusion) lies. I agree that the *sender* needs to know what the receiver will do, in order for the sender to invoke some feature that requires its peer respond in some defined manner. I have been assuming that if the receiver implemented something like a "change this source Routing Stuff to something else" message, TCP could be modified at *that* time to do the right thing with such a message. Having a receiving TCP demultiplex on ESDs, but not do anything when packets are received with a different Routing Stuff, appears (to me) to have no benefit. (Actually, it would have some benefit, but not much, I suspect. Packets would be accepted from a different Routing Stuff, but return traffic would continue to be delivered via the older Routing Stuff. It is questionable whether there is much benefit if the older Routing Stuff continues to be used -- it would certainly not allow communication to continue if the old Routing Stuff becomes invalid, e.g., due to mobility or a renumbering.) I also suspect that from a sender's perspective, there is little practical difference between a receiver demuxing on an ESD but then doing nothing with the change in Routing Stuff vs. a receiver demuxing on the entire 16-byte address and consequently not delivering the packet at all. I agree that the sender does need to be able to determine whether the receiver acted on the message, but I suspect (perhaps incorrectly) there are ways of doing that that can be defined later. I.e., the receiver would return a port unreachable (or TCP RST) which the sender could then interpret in an appropriate manner. Or the reciever would simply ignore the message. Rather than continue down this rathole, however, let's put our effort elsewhere. I think we all agree 100% that we should try and get all TCPs to do the right thing *today*, rather than sometime in the (nebulous) future. Re: TCPng. I should start by saying that I was not a participant in the early IPng/TCPng discussions, so I would gladly defer to others here. The impression I have is that deployment of IPng is not allowed to also require a deployment of TCPng at the same time. That would presumably kill all IPv6 deployment. The question then becomes "what can we change in TCP without changing it into TCPng"? My impression is that we can make no change to TCP that changes its robustness compared with IPv4 or in anyway adds significant complexity that might cause TCP's robustness in practice to become suspect. Obviously, there is a bit of interpretation here as to what crosses the line. This constraint led to a number of the conclusions w.r.t. TCP in the GSE analysis document (i.e., don't change RG on existing TCP connections). Thus, any change in the way TCP behaves needs to be scrutinized carefully. It is my hope that we could define something like a "Binding Update" that we require all TCPs and UDPs to process today. I am optimistic that this can be done. I'd suggest forming a "design team" consisting of a small number of eager people willing to flesh out some details and put forth a straw man. Volunteers? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Apr 2 06:19:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA27916; Wed, 2 Apr 1997 06:10:02 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA27909; Wed, 2 Apr 1997 06:09:51 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA25181; Wed, 2 Apr 1997 06:10:49 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA09289 for ; Wed, 2 Apr 1997 06:16:04 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA18424; Wed, 2 Apr 1997 09:10:44 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id JAA40384; Wed, 2 Apr 1997 09:10:43 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16952; Wed, 2 Apr 1997 09:10:08 -0500 Message-Id: <9704021410.AA16952@ludwigia.raleigh.ibm.com> To: Erik.Nordmark@Eng (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com, kre@munnari.OZ.AU Subject: (IPng 3476) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Tue, 01 Apr 1997 13:10:44 PST." <199704012110.NAA20943@bobo.eng.sun.com> Date: Wed, 02 Apr 1997 09:10:08 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1234 > First we need to indentify to potential sources of reduces robustness > to which the draft is elluding so that we can make sure that > we are not making things less robust. The main issue we kept bumping up against was preventing connection hijacking (either at connection initiation or in the middle of communication). That means that a transport should *never* change the Routing Stuff it is using without authenticating (to its satisfaction) that switching to new Routing Stuff is safe. Just what is being authenticated is an interesting and subtle point, that I don't think I can do justice to right now (I'm not sure I fully understand the issue myself -- I'll try to get it into our revised analysis draft). In short, if you are currently speaking with a pear using Routing Stuff X, you want to authenticate with *that* peer that the change is OK prior to making the switch. In practice, I think using IPSec's AH would do the trick. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Apr 2 07:01:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA27986; Wed, 2 Apr 1997 06:51:54 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA27979; Wed, 2 Apr 1997 06:51:43 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA04288; Wed, 2 Apr 1997 06:52:41 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA24244 for ; Wed, 2 Apr 1997 06:57:58 -0800 Received: from gungnir.fnal.gov ("port 33509"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IH82WKHHZG0006NN@FNAL.FNAL.GOV>; Wed, 02 Apr 1997 08:52:33 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA18742; Wed, 02 Apr 1997 08:51:08 -0600 Date: Wed, 02 Apr 1997 08:51:08 -0600 From: Matt Crawford Subject: (IPng 3477) Re: Router renumbering In-reply-to: "31 Mar 1997 09:16:20 EST." <"9703311416.AA23444"@wasted.zk3.dec.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Message-id: <199704021451.IAA18742@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Go with HMAC-MD5...Key-MD5 is deprecated I think in the community. Actually, Jim, I cribbed the authentication stuff from a RIPv2 MD5 authentication draft by Atkinson & Baker (although later versions are by Baker alone). I'll have a look at your HMAC/MD5 reference. Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Apr 2 07:07:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA28003; Wed, 2 Apr 1997 06:57:48 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA27996; Wed, 2 Apr 1997 06:57:34 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA06160; Wed, 2 Apr 1997 06:58:31 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA26488 for ; Wed, 2 Apr 1997 07:03:49 -0800 Received: from gungnir.fnal.gov ("port 33511"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IH833VZQDM0006NN@FNAL.FNAL.GOV>; Wed, 02 Apr 1997 08:58:27 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA18766; Wed, 02 Apr 1997 08:58:10 -0600 Date: Wed, 02 Apr 1997 08:58:09 -0600 From: Matt Crawford Subject: (IPng 3478) Re: IPv6 "Who-Are-You?" In-reply-to: "31 Mar 1997 09:22:25 EST." <"9703311422.AA26619"@wasted.zk3.dec.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Message-id: <199704021458.IAA18766@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Do we want a time field as just another level of replay protection? I should think the querier can use some or all of the 64-bit cookie in that fashion if desired. > Also I think we need to nail down how these are stored. Stored? You mean, where they might fit into an RR tree in a DNS server which sends queries and caches answers? Yes, that's wide-open. We can leave the tree looking exactly like the existing ip6.int tree, or change it completely. Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Apr 2 11:33:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA28513; Wed, 2 Apr 1997 11:24:37 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA28506; Wed, 2 Apr 1997 11:24:24 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA18525; Wed, 2 Apr 1997 11:25:22 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA10280 for ; Wed, 2 Apr 1997 11:30:40 -0800 Received: by mail.noris.net id <35175-29395>; Wed, 2 Apr 1997 21:25:19 +0200 Path: noris.net!not-for-mail From: smurf@work.smurf.noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3479) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt Date: 2 Apr 1997 21:25:04 +0200 Organization: noris network GmbH, Nuernberg, FRG Lines: 35 Message-ID: <5hubqg$1e6$1@work.smurf.noris.de> References: <199704012110.NAA20943@bobo.eng.sun.com> <9704021410.AA16952@ludwigia.raleigh.ibm.com> <859992758.24653@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1723 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1906 Thomas Narten writes: > > analysis draft). In short, if you are currently speaking with a pear > using Routing Stuff X, you want to authenticate with *that* peer that > the change is OK prior to making the switch. > The "prior" part doesn't work. If I, as kre pointed out, turn off my laptop, plug it in somewhere else, and continue typing at my no-longer- suspended xterm, I want the connection to survive. Unfortunately, there's no advance notice... > In practice, I think using IPSec's AH would do the trick. That'd mean that TCP and whoever else is demuxing incoming packets basically ignores the incoming RG. Actually, there are four possibilities. If a connection is authenticated, the packet should always be processed and the RG updated. If not, we can either update anyway(1), ignore the RG change(2), throw away the packet(3), or send an RST back(4). The choice between 1/2/3/4 should probably be settable per-socket, and there should be a systemwide default which preferably shouldn't be 4 (current IPv6 implementations do that, though). This seems like a workable solution. Re checksumming. It seems that the above is orthogonal to the demuxing problem. I've still got mixed feeling about RG rewrites. Actually, we have NAT (which won't go away with IPv6, much as we all would like it to), which is worse because it'll certainly touch the EID part too. Therefore, excluding just the RG from the checksum is a partial solution at best. -- He who has had, has been, but he who hasn't been, has been had. -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Apr 2 11:51:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA28534; Wed, 2 Apr 1997 11:43:14 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA28527; Wed, 2 Apr 1997 11:43:04 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA22833; Wed, 2 Apr 1997 11:44:01 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA18117 for ; Wed, 2 Apr 1997 11:49:21 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id LAA15341; Wed, 2 Apr 1997 11:44:01 -0800 Message-Id: <3.0.1.32.19970402114222.00b73720@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 02 Apr 1997 11:42:22 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3480) Draft IPng Agenda for Memphis IETF Cc: hinden@Ipsilon.COM, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2653 Folks, Attached is the draft agenda for the IPng working group sessions at next weeks IETF. Please let us know if we left anything out, need more or less time, etc. Apologies in advance if you asked for a slot and it was not included or your name was misspelled. Bob Hinden / Steve Deering p.s. Other IPng working groups meetings at Memphis include: NGTRANS w.g. Monday 7:30-10:00pm 6Bone BOF Wednesday 2:15-3:15pm and the following working groups are discussing IPv6 related items: OSPF Wednesday 1:00-3:15pm Inter-Domain Routing Monday 3:30-5:30pm DNS Wednesday 2:15-3:15pm DHCP Wednesday 3:45-6:00pm DHCP Wednesday 8:00-10:00pm Mobile IP Monday 9:30-11:30am Mobile IP Tuesday 1:00-3:00pm ---------------------------------------------------------------------- ---------------------------------------------------------------------- IPng Working Group Draft Agenda for Memphis IETF Meeting --------------------------------------- Thursday 1:00-3:00pm -------------------- Introduction and Bash Agenda / Steve Deering (5 min) Document Status / Bob Hinden (5 min) Review of Action Items for Previous Meetings / Bob Hinden (5 min) Priority Field / Steve Deering (15 min) IPv6 Tunneling Spec and GRE / Steve Deering (15 min) Conclusions/Results from Interim Meeting / (60 min) Meeting Summary / Bob Hinden (5 min) Analysis of GSE Proposal / Matt Crawford and others (25 min) IPv6 over Ethernet & FDDI / Matt Crawford (5 min) IPv6 over PPP / Dimitry Haskin (5 min) Ipv6 over ARCNET and Appletalk / Bob Hinden (5 min) The Use of End System Designators in IPv6 / Matt Thomas (5 min) Routing Goop and AAAA Records in DNS / Jim Bound (5 min) Numbering point-to-point and boundary links / John Stewart (5 min) Friday 9:00-11:30am ------------------- Conclusions/Results from Interim Meeting Continued / 60min Solicited Node Definition / Steve Deering (15 min) Router Renumbering for IPv6 / Matt Crawford & Bob Hinden (15 min) Advertising site prefixes in RAs / Erik Nordmark (10 min) Inter-Domain Routing Status / Bob Hinden (5 min) Moving Base IPv6 Specs to Draft Standard / Steve Deering (30 min) Wrap Up and Action Items / Bob Hinden (15 min) ------------------------------------------------------------------------ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Apr 2 12:50:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA28602; Wed, 2 Apr 1997 12:38:03 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA28595; Wed, 2 Apr 1997 12:37:52 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA05551; Wed, 2 Apr 1997 12:38:47 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA09890 for ; Wed, 2 Apr 1997 12:44:03 -0800 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA51168; Wed, 2 Apr 1997 15:38:24 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id PAA19546; Wed, 2 Apr 1997 15:38:24 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15520; Wed, 2 Apr 1997 15:37:48 -0500 Message-Id: <9704022037.AA15520@ludwigia.raleigh.ibm.com> To: smurf@work.smurf.noris.de (Matthias Urlichs) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3481) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "02 Apr 1997 21:25:04 +0200." <5hubqg$1e6$1@work.smurf.noris.de> Date: Wed, 02 Apr 1997 15:37:48 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2741 smurf@work.smurf.noris.de (Matthias Urlichs) writes: > Thomas Narten writes: > > > > analysis draft). In short, if you are currently speaking with a pear > > using Routing Stuff X, you want to authenticate with *that* peer that > > the change is OK prior to making the switch. > > > The "prior" part doesn't work. If I, as kre pointed out, turn off my > laptop, plug it in somewhere else, and continue typing at my no-longer- > suspended xterm, I want the connection to survive. Unfortunately, there's > no advance notice... I believe I (very carefully!) stated the issue the way I intended. I didn't say there had to be advance notice in the sense of "I'm about to move". That is, the notice can come after the switch has taken place, so long as the receiving TCP refuses to send return TCP traffic (from the existing connection) via the new Routing Stuff until it has properly authenticated the proposed new Routing Stuff with the same peer it was speaking to prior to the switch. If one is using IPSec's AH, the request to change the Routing Stuff could be authenticated via an security association that had been set up prior to the move. That would provide the assurance that the *same* peer one had been talking to before is who one is talking to now. The fundamental difficulty one has with a message coming out of the blue saying "I am now here" is that it could be from a bad guy trying to hijack the connection. Consequently, one wants assurance *before* changing the Routing Stuff _from the peer one was speaking with before_. > > In practice, I think using IPSec's AH would do the trick. > That'd mean that TCP and whoever else is demuxing incoming packets > basically ignores the incoming RG. Yes. That would be the case. > Actually, there are four possibilities. If a connection is > authenticated, the packet should always be processed and the RG > updated. If not, we can either update anyway(1), ignore the RG > change(2), throw away the packet(3), or send an RST back(4). The > choice between 1/2/3/4 should probably be settable per-socket, and > there should = be a systemwide default which preferably shouldn't be > 4 (current IPv6 implementations do that, though). Why would the choice need to be per-socket? I think our goal is to have one way that it be done everywhere, and everyone agree that it is safe to do so. [note: I'm assuming that RG is *not* being rewritten, per the PAL1 meeting.] Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Apr 2 14:02:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA28846; Wed, 2 Apr 1997 13:52:24 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA28839; Wed, 2 Apr 1997 13:52:11 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA22364; Wed, 2 Apr 1997 13:53:10 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA10173 for ; Wed, 2 Apr 1997 13:58:28 -0800 Received: from gungnir.fnal.gov ("port 33700"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IH8HKX2B40000729@FNAL.FNAL.GOV>; Wed, 02 Apr 1997 15:53:03 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id PAA19965; Wed, 02 Apr 1997 15:52:44 -0600 Date: Wed, 02 Apr 1997 15:52:44 -0600 From: Matt Crawford Subject: (IPng 3482) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-reply-to: "02 Apr 1997 15:37:48 -0400." <"9704022037.AA15520"@ludwigia.raleigh.ibm.com> To: Thomas Narten Cc: smurf@work.smurf.noris.de (Matthias Urlichs), ipng@sunroof.eng.sun.com Message-id: <199704022152.PAA19965@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ If one is using IPSec's AH, the request to change the Routing Stuff > could be authenticated via an security association that had been set > up prior to the move. Danger: SA's are (now) indexed by SPI + Dest Addr, so if you want to send to a new DA, you have to hack a bit on your SA table. ESDs to the rescue? Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Apr 2 23:30:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA29376; Wed, 2 Apr 1997 23:17:00 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA29369; Wed, 2 Apr 1997 23:16:49 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA22460; Wed, 2 Apr 1997 23:17:43 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id XAA12297; Wed, 2 Apr 1997 23:23:05 -0800 From: Masataka Ohta Message-Id: <199704030714.QAA25368@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA25368; Thu, 3 Apr 1997 16:14:35 +0900 Subject: (IPng 3483) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt To: Erik.Nordmark@Eng (Erik Nordmark) Date: Thu, 3 Apr 97 16:14:35 JST Cc: kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com, narten@raleigh.ibm.com In-Reply-To: <199704011937.LAA20741@bobo.eng.sun.com>; from "Erik Nordmark" at Apr 1, 97 11:37 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1585 > > Thus, pseudo-header checksum only the ESD, and at least > > switchably, demux only on the ESD. > > Excluding the RG from the pseudo-header checksum makes TCP a lot > less robust. This issue was brought up and discussed in the PAL1 > meeting. The problem is that a single-bit error in the source RG > on a SYN packet will cause TCP to send the SYN|ACK to a bogus RG. > When the SYN is retransmitted the TCP can't trust the new source RG > (since the first one could have been ok and the second SYN could have > a bit error) so it will end up retransmitting the SYN|ACK until > it times out. It's a possible problem only when source identify and source locator is not checked through DNS. Moreover, there is no reason not to rewrite destination locator, which is the only locator worth to be modified. > Thus I think the best path forward is to pseudo-header checksum > the whole addresses but only use the ESD for connection identification. > > This does make it harder to introduce RG rewriting in the future No. It is a lot worse than that. The psuedo header checksum is there to confirm that some router is not buggy to rewrite something. Allowing recomputation of the psuedo header checksum by intermediate routers, there is no reason to have psuedo header checksum. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Apr 2 23:34:06 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA29385; Wed, 2 Apr 1997 23:21:40 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA29378; Wed, 2 Apr 1997 23:21:25 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA22888; Wed, 2 Apr 1997 23:22:21 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id XAA13180; Wed, 2 Apr 1997 23:27:45 -0800 From: Masataka Ohta Message-Id: <199704030719.QAA25386@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA25386; Thu, 3 Apr 1997 16:19:05 +0900 Subject: (IPng 3484) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt To: kre@munnari.OZ.AU (Robert Elz) Date: Thu, 3 Apr 97 16:19:05 JST Cc: narten@raleigh.ibm.com, Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com In-Reply-To: <211.859904410@munnari.OZ.AU>; from "Robert Elz" at Apr 2, 97 12:20 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 819 kre; > I think we didn't spell this out in the draft because doing > these things *today* has no benefit. So why bother? > > Because if the mechanism isn't there today, there's no rational > way to add it later and retain compatibility? As is presented in San Jose meeting, rewriting of destination locator simplifies mobility and multicast. The rewriting does not introduce a new security problem save minor ones (solved by stateful autoconfuguration) already introduced by stateless autoconfiguration. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 3 02:32:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA29485; Thu, 3 Apr 1997 02:20:03 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA29478; Thu, 3 Apr 1997 02:19:51 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA12435; Thu, 3 Apr 1997 02:20:49 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id CAA21116 for ; Thu, 3 Apr 1997 02:26:17 -0800 From: Masataka Ohta Message-Id: <199704031018.TAA26246@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA26246; Thu, 3 Apr 1997 19:17:47 +0859 Subject: (IPng 3485) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt To: narten@raleigh.ibm.com (Thomas Narten) Date: Thu, 3 Apr 97 19:17:46 JST Cc: smurf@work.smurf.noris.de, ipng@sunroof.eng.sun.com In-Reply-To: <9704022037.AA15520@ludwigia.raleigh.ibm.com>; from "Thomas Narten" at Apr 2, 97 3:37 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 547 As I checked the BSD kernel, it seems to me that the proper place to throw away old invalid incoming RG for the SAME rubustness as IPv4 is: in_losing() Then, invalid source RG is just as harmful as invaid default router or things like that. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 3 05:38:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA29590; Thu, 3 Apr 1997 05:27:58 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA29583; Thu, 3 Apr 1997 05:27:49 -0800 From: bound@ZK3.DEC.COM Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA27872; Thu, 3 Apr 1997 05:28:48 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA26077 for ; Thu, 3 Apr 1997 05:34:19 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA14832; Thu, 3 Apr 1997 08:23:51 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA21910; Thu, 3 Apr 1997 08:23:45 -0500 Message-Id: <9704031323.AA21910@wasted.zk3.dec.com> To: brian@hursley.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3486) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Tue, 01 Apr 97 02:16:57 +0100." <9704010116.AA22454@hursley.ibm.com> Date: Thu, 03 Apr 97 08:23:45 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1091 Brian, I may be responding to you and Eric without reading all my mail and I apologize for that (but the IDs coming out leave me no choice). I did not question the draft on use of global ESDs as yet because I felt we still need to have that discussion. But I want to agree with you and Eric. For me I don't need TCPng to use them "immediately" to enhance TCP and UPD code path for renumbering and "other" benefits (e.g. rehoming, cluster aliases). So I think I agree with you and Eric. I also DO NOT BELIEVE that chg'ng to use of ESD only for the virtual transport layer in implementations affects in anyway the TCP or UDP RFC set. So its not an issue there IMHO either. Is it a TCP/UDP implementation issue that "may" affect performance, yes, is this an IETF issue, IMHO NO NO NO NO NO NO.... /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 3 06:03:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA29630; Thu, 3 Apr 1997 05:50:35 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA29623; Thu, 3 Apr 1997 05:50:26 -0800 From: bound@zk3.dec.com Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA00164; Thu, 3 Apr 1997 05:51:24 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA23429; Thu, 3 Apr 1997 05:51:20 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA09982; Thu, 3 Apr 1997 08:42:43 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23312; Thu, 3 Apr 1997 08:42:41 -0500 Message-Id: <9704031342.AA23312@wasted.zk3.dec.com> To: Robert Elz Cc: Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 3487) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Wed, 02 Apr 97 00:13:28 +1000." <205.859904008@munnari.OZ.AU> Date: Thu, 03 Apr 97 08:42:40 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 885 >If TCP is ever to make use of ESDs (and I believe it should) >as distinct from locators (addresses if you like), now is the >time to make it happen - the only chance. Exactly. Its not a big deal folks and now is the time to do it. I perceive an implementation would still carry at 16byte PCB entry so the virtual routing and internet layer on hosts would be completely un-affected other than maybe to optimize search path for routing applications and IP utilities to support viewing route tables. As I stated at the Interim meeting if we can do this global ESD thing its a big win for IPv6. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 3 06:29:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA29664; Thu, 3 Apr 1997 06:17:39 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA29657; Thu, 3 Apr 1997 06:17:30 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA03377; Thu, 3 Apr 1997 06:18:28 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA10016; Thu, 3 Apr 1997 06:23:58 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA19751; Thu, 3 Apr 1997 09:05:19 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA25462; Thu, 3 Apr 1997 09:05:16 -0500 Message-Id: <9704031405.AA25462@wasted.zk3.dec.com> To: Erik.Nordmark@Eng (Erik Nordmark) Cc: narten@raleigh.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 3488) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Tue, 01 Apr 97 11:08:13 PST." <199704011908.LAA20721@bobo.eng.sun.com> Date: Thu, 03 Apr 97 09:05:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1739 Erik is correct on the consensus issue and his request. Look this is a no-brainer once we iron out all the issues (e.g. checksums, AH header, checking RG). HEre is why: TCP and UDP (and please do not NOT DISCUSS UDP) modules (e.g. tcp_input.c, tcp_wrap.c) do not need to know routing information today and surely don't for IPv6. The parsing of connections (given we address the issues noted) is not a big change today to the IPv6 code base implemented. It also will remain compatible with the existing IPv6/IPv4 hybrid stack implementations, except now we will need to ascertain v4/v6 prior to pcb or tcppcb lookups (this is minimal). TCPng (which is bogus if it does not inlude UDP )---> and a BIG PROBLEM with the "simulations" of RED if your following that thread) is not needed to make this change to IPv6. The benefits today are for Mobile, Cluster Aliases, Rehoming of Transactions, and a much faster search on 64bit machines for the ESD for transport connection lookups. We still will need the variant binding updates to renumber but they will be much easier to specify and implement if we adopt this change. p.s. I have not re-issued our binding update draft in support of Host anycast until we sort this discussion out and check out the McCann-HRA work as both will make the binding update I have proposed a no-brainer So I will have that for us at Munich. But this is immediately usable for IPv6 mobility and another benefit. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 3 06:40:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA29677; Thu, 3 Apr 1997 06:26:39 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA29670; Thu, 3 Apr 1997 06:26:25 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA04652; Thu, 3 Apr 1997 06:27:23 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA12980 for ; Thu, 3 Apr 1997 06:32:54 -0800 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA36020; Thu, 3 Apr 1997 09:26:46 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id JAA33782; Thu, 3 Apr 1997 09:26:53 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15776; Thu, 3 Apr 1997 09:26:16 -0500 Message-Id: <9704031426.AA15776@ludwigia.raleigh.ibm.com> To: Masataka Ohta Cc: smurf@work.smurf.noris.de, ipng@sunroof.eng.sun.com Subject: (IPng 3489) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Thu, 03 Apr 1997 19:17:46 +0200." <199704031018.TAA26246@necom830.hpcl.titech.ac.jp> Date: Thu, 03 Apr 1997 09:26:16 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 946 Masataka Ohta writes: > As I checked the BSD kernel, it seems to me that the proper > place to throw away old invalid incoming RG for the SAME > rubustness as IPv4 is: > in_losing() > Then, invalid source RG is just as harmful as invaid default > router or things like that. And most people would argue that IPv4 got it wrong here. in_losing() is invoked only by higher layers that have figured out that something seems wrong with the "connection" (i.e., the TCP connection is about to timeout). Applications sitting on top of UDP don't ever invoke in_losing(). Thus, it is not robust and we can't rely on it here. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 3 06:51:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA29701; Thu, 3 Apr 1997 06:36:49 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA29694; Thu, 3 Apr 1997 06:36:31 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA06719; Thu, 3 Apr 1997 06:37:29 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA16275; Thu, 3 Apr 1997 06:43:00 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA28991; Thu, 3 Apr 1997 09:24:37 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28248; Thu, 3 Apr 1997 09:24:33 -0500 Message-Id: <9704031424.AA28248@wasted.zk3.dec.com> To: Thomas Narten Cc: Robert Elz , nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 3490) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Wed, 02 Apr 97 09:03:43 -0400." <9704021403.AA15252@ludwigia.raleigh.ibm.com> Date: Thu, 03 Apr 97 09:24:33 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 882 >It is my hope that we could define something like a "Binding Update" >that we require all TCPs and UDPs to process today. I am optimistic >that this can be done. I'd suggest forming a "design team" consisting >of a small number of eager people willing to flesh out some details >and put forth a straw man. Volunteers? This is already in process but I am willing to work on it. But first I still believe we can demux on ESD and that discussion needs to complete first as it affects what you propose. Also this work is already in process and not sure we all agree yet what its "goals" are. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 3 09:41:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29965; Thu, 3 Apr 1997 09:28:54 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29958; Thu, 3 Apr 1997 09:28:44 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA23977; Thu, 3 Apr 1997 09:29:43 -0800 Received: from metro.isi.edu (metro.isi.edu [38.245.76.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA01510 for ; Thu, 3 Apr 1997 09:35:15 -0800 Received: from metro.isi.edu by metro.isi.edu (5.65c/5.61+local-24) id ; Thu, 3 Apr 1997 12:28:32 -0500 Message-Id: <199704031728.AA05597@metro.isi.edu> To: Masataka Ohta Cc: kre@munnari.OZ.AU (Robert Elz), narten@raleigh.ibm.com, Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com Subject: (IPng 3491) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Thu, 03 Apr 1997 16:19:05 +0200." <199704030719.QAA25386@necom830.hpcl.titech.ac.jp> X-Phone: +1 703 812 3704 From: "John W. Stewart III" Date: Thu, 03 Apr 1997 12:28:32 EST Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1315 > As is presented in San Jose meeting, rewriting of destination > locator simplifies mobility and multicast. > > The rewriting does not introduce a new security problem save > minor ones (solved by stateful autoconfuguration) already > introduced by stateless autoconfiguration. imo, the major benefit of rewriting was to obviate renumbering to ensure continued aggressive aggregation. however, the cost of hiding a node's full address from it was considered too great, so address rewriting no longer made sense i haven't yet heard the proposal of doing *just* destination address rewriting, but my initial reaction is that i don't like it. first off, it seems inconsistant to only rewrite in one direction of a flow. second, it re-raises the everything- that-terminates-a-site-to-site-tunnel-must-do-rewriting issue (and possibly the routing header issue, too?). it's also a performance hit; this didn't get much attention at PAL1 or in the document since we didn't go too far down the road of address rewriting /jws ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 3 11:29:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00269; Thu, 3 Apr 1997 11:16:17 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00262; Thu, 3 Apr 1997 11:16:04 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA21455; Thu, 3 Apr 1997 11:17:02 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA24636 for ; Thu, 3 Apr 1997 11:22:35 -0800 Received: from gungnir.fnal.gov ("port 33738"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IH9QFRJ22O000801@FNAL.FNAL.GOV>; Thu, 03 Apr 1997 13:16:59 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id NAA22069; Thu, 03 Apr 1997 13:16:39 -0600 Date: Thu, 03 Apr 1997 13:16:38 -0600 From: Matt Crawford Subject: (IPng 3492) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-reply-to: "03 Apr 1997 12:28:32 EST." <"199704031728.AA05597"@metro.isi.edu> To: "John W. Stewart III" Cc: Masataka Ohta , kre@munnari.OZ.AU (Robert Elz), narten@raleigh.ibm.com, Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com Message-id: <199704031916.NAA22069@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ imo, the major benefit of rewriting was to obviate renumbering > to ensure continued aggressive aggregation. however, the cost > of hiding a node's full address from it was considered too > great, so address rewriting no longer made sense ... To unwind the stack back to main(), the point of hiding a node's full address was to ensure that renumbering would have *no* impact on intra-site communication. Zero-impact may be achievable in other ways, either with a robust 2-faced DNS scheme, or strict address selection rules in the end nodes. These should be explored. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 3 16:29:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA00894; Thu, 3 Apr 1997 16:20:42 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA00887; Thu, 3 Apr 1997 16:20:28 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA01495; Thu, 3 Apr 1997 16:21:24 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA26219 for ; Thu, 3 Apr 1997 16:27:00 -0800 From: Masataka Ohta Message-Id: <199704040018.JAA28803@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA28803; Fri, 4 Apr 1997 09:18:04 +0900 Subject: (IPng 3493) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt To: narten@raleigh.ibm.com (Thomas Narten) Date: Fri, 4 Apr 97 9:18:02 JST Cc: mohta@necom830.hpcl.titech.ac.jp, smurf@work.smurf.noris.de, ipng@sunroof.eng.sun.com In-Reply-To: <9704031426.AA15776@ludwigia.raleigh.ibm.com>; from "Thomas Narten" at Apr 3, 97 9:26 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 817 > > As I checked the BSD kernel, it seems to me that the proper > > place to throw away old invalid incoming RG for the SAME > > rubustness as IPv4 is: > > > in_losing() > > > Then, invalid source RG is just as harmful as invaid default > > router or things like that. > > And most people would argue that IPv4 got it wrong here. That's fine. > Applications sitting on top of UDP don't ever invoke > in_losing(). Do they have some mechanism to flush invalid default router? If not, they are not so rubust. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Apr 4 11:47:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01880; Fri, 4 Apr 1997 11:36:42 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01873; Fri, 4 Apr 1997 11:36:33 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA13968; Fri, 4 Apr 1997 11:37:30 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA25935 for ; Fri, 4 Apr 1997 11:43:16 -0800 Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA44712; Fri, 4 Apr 1997 14:36:53 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id OAA37816; Fri, 4 Apr 1997 14:36:50 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16280; Fri, 4 Apr 1997 14:36:19 -0500 Message-Id: <9704041936.AA16280@ludwigia.raleigh.ibm.com> To: Masataka Ohta Cc: smurf@work.smurf.noris.de, ipng@sunroof.eng.sun.com Subject: (IPng 3494) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt In-Reply-To: Your message of "Fri, 04 Apr 1997 09:18:02 +0200." <199704040018.JAA28803@necom830.hpcl.titech.ac.jp> Date: Fri, 04 Apr 1997 14:36:19 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1025 Masataka Ohta writes: > > Applications sitting on top of UDP don't ever invoke > > in_losing(). > Do they have some mechanism to flush invalid default router? The problem isn't whether or not applications have a mechanism to flush invalid default routers. It is that the _application_ would be required to invoke it, since only the application can know if the packets it is sending aren't reaching the destination. The reality is that applications cannot be counted on to invoke such a mechanism (if it exists). > If not, they are not so rubust. You mean the applications aren't robust? I don't think we can reasonably expect applications to notify IP when IP's routing tables aren't right. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Apr 4 15:40:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA02114; Fri, 4 Apr 1997 15:31:09 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA02107; Fri, 4 Apr 1997 15:30:56 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA27660; Fri, 4 Apr 1997 15:31:55 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA18345 for ; Fri, 4 Apr 1997 15:37:45 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA04925; Fri, 4 Apr 1997 15:31:25 -0800 Message-Id: <3.0.1.32.19970404152939.00c4bbc8@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 04 Apr 1997 15:29:39 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3495) Updated IPng Agenda for Memphis IETF Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2814 Folks, Attached is the updated agenda for the IPng working group sessions at next weeks IETF. Please let us know if we left anything out, need more or less time, etc. Apologies in advance if you asked for a slot and it was not included or your name was misspelled. Bob Hinden / Steve Deering p.s. Other IPng working groups meetings at Memphis include: NGTRANS w.g. Monday 7:30-10:00pm 6Bone BOF Wednesday 2:15-3:15pm and the following working groups are discussing IPv6 related items: OSPF Wednesday 1:00-3:15pm Inter-Domain Routing Monday 3:30-5:30pm DNS Wednesday 2:15-3:15pm DHCP Wednesday 3:45-6:00pm DHCP Wednesday 8:00-10:00pm Mobile IP Monday 9:30-11:30am Mobile IP Tuesday 1:00-3:00pm ---------------------------------------------------------------------- ---------------------------------------------------------------------- IPng Working Group Draft Agenda for Memphis IETF Meeting --------------------------------------- Thursday 1:00-3:00pm -------------------- Introduction and Bash Agenda / Steve Deering (5 min) Document Status / Bob Hinden (5 min) Review of Action Items for Previous Meetings / Bob Hinden (5 min) Priority Field / Steve Deering (15 min) IPv6 Tunneling Spec and GRE / Steve Deering (15 min) Conclusions/Results from Interim Meeting / (60 min) Meeting Summary / Bob Hinden (5 min) Analysis of GSE Proposal / Matt Crawford and others (25 min) IPv6 over Ethernet & FDDI / Matt Crawford (5 min) IPv6 over PPP / Dimitry Haskin (5 min) Ipv6 over ARCNET and Appletalk / Bob Hinden (5 min) The Use of End System Designators in IPv6 / Matt Thomas (5 min) Routing Goop and AAAA Records in DNS / Jim Bound (5 min) Numbering point-to-point and boundary links / John Stewart (5 min) Friday 9:00-11:30am ------------------- Conclusions/Results from Interim Meeting Continued / 60min Solicited Node Definition / Steve Deering (15 min) Router Renumbering for IPv6 / Matt Crawford & Bob Hinden (15 min) Advertising site prefixes in RAs / Erik Nordmark (10 min) Who Are You / Matt Crawford (5 min) Inter-Domain Routing Status / Bob Hinden (5 min) ND Zero Lifetime advertisement issue / Thomas Narten (5 min) Advanced API Spec / Matt Thomas (5 min) Moving Base IPv6 Specs to Draft Standard / Steve Deering (20 min) Wrap Up and Action Items / Bob Hinden (10 min) ------------------------------------------------------------------------ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Sat Apr 5 09:26:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02637; Sat, 5 Apr 1997 09:18:11 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02630; Sat, 5 Apr 1997 09:18:02 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA18462; Sat, 5 Apr 1997 09:19:02 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA12982 for ; Sat, 5 Apr 1997 09:25:03 -0800 Received: from spruce.ipsilon.com ([205.226.20.239]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA01747; Sat, 5 Apr 1997 09:19:02 -0800 Message-Id: <3.0.1.32.19970405091540.006d62e0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 05 Apr 1997 09:15:40 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3496) Update to IPng Web Pages Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 529 I completed updating the IPng web pages which can be found at: http://playground.sun.com/ipng Changes include pointers to current specifications/drafts, new implementations, meeting notes, and a reorganization of the implementation page. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Sat Apr 5 17:00:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA02817; Sat, 5 Apr 1997 16:52:33 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA02810; Sat, 5 Apr 1997 16:52:20 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA11038; Sat, 5 Apr 1997 16:53:18 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA28816 for ; Sat, 5 Apr 1997 16:59:20 -0800 From: Masataka Ohta Message-Id: <199704060050.JAA04597@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA04597; Sun, 6 Apr 1997 09:49:56 +0859 Subject: (IPng 3497) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt To: narten@raleigh.ibm.com (Thomas Narten) Date: Sun, 6 Apr 97 9:49:54 JST Cc: mohta@necom830.hpcl.titech.ac.jp, smurf@work.smurf.noris.de, ipng@sunroof.eng.sun.com In-Reply-To: <9704041936.AA16280@ludwigia.raleigh.ibm.com>; from "Thomas Narten" at Apr 4, 97 2:36 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1249 > > > Applications sitting on top of UDP don't ever invoke > > > in_losing(). > > > Do they have some mechanism to flush invalid default router? > > The problem isn't whether or not applications have a mechanism to > flush invalid default routers. The problem is to keep TCP/UDP as robust as the current ones. So, as the UDP applications is not invoking such mechanism, there is no need to worry about very strong protection on other cases. > The reality is > that applications cannot be counted on to invoke such a mechanism (if > it exists). The reality is that, UDP applications rely on simple time-outs. > > If not, they are not so rubust. > > You mean the applications aren't robust? No. I mean they are not so robust. > I don't think we can > reasonably expect applications to notify IP when IP's routing tables > aren't right. That is, we don't have to worry about wrong routting tables, wrong default routers nor wrong RGs. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Sat Apr 5 21:26:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA03066; Sat, 5 Apr 1997 21:18:47 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA03059; Sat, 5 Apr 1997 21:18:35 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA22088; Sat, 5 Apr 1997 21:19:31 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA25387 for ; Sat, 5 Apr 1997 21:25:39 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id AAA17584; Sun, 6 Apr 1997 00:14:56 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18958; Sun, 6 Apr 1997 00:14:51 -0500 Message-Id: <9704060514.AA18958@wasted.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3498) Re: Update to IPng Web Pages In-Reply-To: Your message of "Sat, 05 Apr 97 09:15:40 PST." <3.0.1.32.19970405091540.006d62e0@mailhost.ipsilon.com> Date: Sun, 06 Apr 97 00:14:50 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 393 Looks good Bob and very impressive with the new players and new free stuff too. Good job sir.... thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Apr 7 20:01:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA04720; Mon, 7 Apr 1997 19:51:18 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA04713; Mon, 7 Apr 1997 19:51:09 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA26254; Mon, 7 Apr 1997 19:52:09 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA11048 for ; Mon, 7 Apr 1997 19:58:44 -0700 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA26180; Mon, 7 Apr 1997 22:45:52 -0400 (EDT) Received: by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24203; Mon, 7 Apr 1997 22:45:51 -0400 Date: Mon, 7 Apr 1997 22:45:51 -0400 From: Jack McCann Message-Id: <9704080245.AA24203@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3499) Re: Host Reachability Advertisement for IPv6 Cc: mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3369 Picking up the thread on draft-mccann-ipv6-hra-00.txt... I see I left an important piece out of the draft, I did not state some of the underlying assumptions. This will be rectified in the next version of the draft. Ray Hunter wrote: > Can't you always just create an internal virtual/loopback interface > and advertise that out of both interfaces via a proper routing protocol? and Mike Shand wrote: > This triggers the thought... Why aren't you using RIP for all this stuff? For the multihomed host case, my basic assumption is that the host does not participate in the routing protocols (i.e. it is not running RIP, OSPF, etc.). The ipngwg did a nice job of removing this need for singly homed hosts with the integral router discovery piece of ND, one goal is to extend this to multihomed hosts. Matthias Urlichs wrote: >My assumption is that the router knows which addresses are permissible >anycast addresses. Therefore it can send a ND Solicitation message for it >when a packet arrives. But how did the router learn of these anycast addresses? Granted this could be accomplished with some sort of manual configuration on the router, but plug-and-play would be nice. I was originally thinking only of the multihomed host case, but the following paragraph from rfc1884 lead me to think that the same mechanism might also be used for the anycast case: For any assigned anycast address, there is a longest address prefix P that identifies the topological region in which all interfaces belonging to that anycast address reside. Within the region identified by P, each member of the anycast set must be advertised as a separate entry in the routing system (commonly referred to as a "host route"); outside the region identified by P, the anycast address may be aggregated into the routing advertisement for prefix P. The HRA provides a means to inject that "host route" into the routing system. Now if the working group decides that the answer for the multihomed host is to participate in the routing protocols, and that the answer for the anycast case is something else TBD, this spec is not needed. Matthias Urlichs also wrote: > This may be a stupid question, but why do we need an additional couple of > ICMP messages when there's already the mandatory ND stuff (RFC1970)? To which Erik Nordmark responded: > ND doesn't contain a mechanism for a host to tell a router which > addresses it wants to receive. > : > Thus using current ND mechanisms a host can not tell a router > that it wants to received packets addressed to an address outside > the subnet prefixes. It may be possible to use the ND mechanisms, perhaps with some modifications. I'm not stuck on using these new ICMP messages, I have considered the possibility of extending the existing ND mechanisms. For purposes of initial discussion though, it felt cleaner to spec this in terms of separate ICMP messages so as not to get caught up in the details of tweaking the already heavily loaded set of ND messages. But we can certainly explore that avenue. - Jack ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Apr 7 20:05:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA04729; Mon, 7 Apr 1997 19:55:18 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA04722; Mon, 7 Apr 1997 19:55:06 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA26740; Mon, 7 Apr 1997 19:56:08 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA12083 for ; Mon, 7 Apr 1997 20:02:42 -0700 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA28978; Mon, 7 Apr 1997 22:54:46 -0400 (EDT) Received: by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24632; Mon, 7 Apr 1997 22:54:46 -0400 Date: Mon, 7 Apr 1997 22:54:46 -0400 From: Jack McCann Message-Id: <9704080254.AA24632@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3500) Re: Updated IPv6 Addressing Architecture draft Cc: mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1158 draft-ietf-ipngwg-ipv6-arch-00.txt, section 2.3 "Text Representation of Address Prefixes, states: An IPv6 address prefix is represented by the notation: ipv6-address/prefix-length where ipv6-address is an IPv6 address in any of the notations listed in section 2.2, with the extra rule that, if the written address ends in "::", the trailing "::" may be omitted. I'd like to suggest that this "extra rule" be added to the list of valid address forms in section 2.2, eliminating the special case parsing for addresses used in prefix notations. From an implementation standpoint, this will simplify code that has to parse these prefixes, I can just do inet_pton() on the ipv6-address portion of the prefix without having to worry about the special case. - Jack ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 10 18:04:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA07948; Thu, 10 Apr 1997 17:52:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA07941; Thu, 10 Apr 1997 17:51:54 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA25193; Thu, 10 Apr 1997 17:52:56 -0700 Received: from spitz.cisco.com (spitz.cisco.com [171.69.1.212]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA02277 for ; Thu, 10 Apr 1997 17:59:31 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by spitz.cisco.com (8.6.12/8.6.5) with ESMTP id RAA19442 for ; Thu, 10 Apr 1997 17:52:57 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id RAA27661; Thu, 10 Apr 1997 17:49:58 -0700 (PDT) Date: Thu, 10 Apr 1997 17:49:58 -0700 (PDT) Message-Id: <199704110049.RAA27661@pedrom-ultra.cisco.com> From: Pedro Marques To: ipng@sunroof.eng.sun.com Subject: (IPng 3502) ESDs Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2012 Having watched Thomas Narten's presentation from the mbone i'd like to make some comments as it seams that a WG decision on the subject will be made tomorrow (and unfortunatly not mboned). On Thomas slides the "Main Benefit" section has a bullet that reads: - Facilitates retroactive fixup of Routing Stuff: - mobile node says "I just moved, here is my new address" - during renumbering: "here is my new prefered addresss" As far as i understand it we are taling about explicit messages from the host which is renumbering to change the Routing Prefix stored in PCBs at the other end. This being the case, i don't see why ESDs facilitate things or provide any benefit at all. We are talking about a message saying: I'm X (64 bit ESD), moving to prefix P2 (64 routing prefix) compared to I'm Y (128 bit IPv6 address), moving to address Z (128 bit IPv6 address) I see absolutly no difference, besides one message being 128 bit smaller. What we go back over and over again when discussing EIDs is that they have not been found till now to solve any problem. They just add a new level of indirection to it, along with a full bunch of headaches. Being forced to assign globally unique EIDs being one of them. As a closing argument, a non hierarchical EID is useless for comunication purposes. To comunicate you need a "locator", somewhere to send packets to, and having a flat EID doesn't help in anyway since you cannot do lookups and resolve the locator part. I really liked to watch Thomas's presentation... it means there is still hope of some healthful conservatism on not jumping into a radical change from IPv4 which we don't really know what is going to buy us, if anything ;-) regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 10 20:45:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA08126; Thu, 10 Apr 1997 20:34:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA08119; Thu, 10 Apr 1997 20:34:37 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA24392; Thu, 10 Apr 1997 20:35:39 -0700 Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA10425 for ; Thu, 10 Apr 1997 20:42:16 -0700 Received: (roque@localhost) by trix.cisco.com (8.6.12/8.6.5) id UAA06557; Thu, 10 Apr 1997 20:35:37 -0700 Date: Thu, 10 Apr 1997 20:35:37 -0700 Message-Id: <199704110335.UAA06557@trix.cisco.com> From: Pedro Marques To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3503) Re: ESDs In-Reply-To: <199704110313.MAA25423@necom830.hpcl.titech.ac.jp> References: <199704110049.RAA27661@pedrom-ultra.cisco.com> <199704110313.MAA25423@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2944 >>>>> "Masataka" == Masataka Ohta writes: Ohta-san, >> >> >> Having watched Thomas Narten's presentation from the mbone i'd >> like to make some comments as it seams that a WG decision on >> the subject will be made tomorrow (and unfortunatly not >> mboned). >> >> On Thomas slides the "Main Benefit" section has a bullet that >> reads: >> >> - Facilitates retroactive fixup of Routing Stuff: - >> mobile node says "I just moved, here is my new address" - >> during renumbering: "here is my new prefered addresss" >> >> As far as i understand it we are taling about explicit messages >> from the host which is renumbering to change the Routing Prefix >> stored in PCBs at the other end. This being the case, i don't >> see why ESDs facilitate things or provide any benefit at all. Masataka> There is some, as long as the PCB lookup does not need Masataka> destination/source locator and destination locator is Masataka> not checksum protected. Can you please be more specific in terms of what are the benifits you find ?... >> As a closing argument, a non hierarchical EID is useless for >> comunication purposes. To comunicate you need a "locator", >> somewhere to send packets to, and having a flat EID doesn't >> help in anyway since you cannot do lookups and resolve the >> locator part. Masataka> As long as we don't need scalable security (which we do Masataka> need), we don't need hierarchical ID. Shall i read that statement as "non-hierarchical IDs are useless" ? Masataka> But, some just don't want to admit that stateless Masataka> autoconfiguration is not secure in a scalable manner. I think that everybody admits that addrconf startup is not secure in a scalable manner... It is just that the threat is confined to the local wire and most people think they can live with local threats as long as they can isolate remote ones. >> I really liked to watch Thomas's presentation... it means there >> is still hope of some healthful conservatism on not jumping >> into a radical change from IPv4 which we don't really know what >> is going to buy us, if anything ;-) Masataka> The problem is that some believe that ID/Locator Masataka> separation is a radical change, while the removal of Masataka> hierarchy from ID is not. I don't think i follow that. "removing hierarchy from ID" is precisly what the ESD proposal does... It removes the routing porting from the address to make it a less transient identificator. regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 10 20:54:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA08139; Thu, 10 Apr 1997 20:42:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA08128; Thu, 10 Apr 1997 20:42:35 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA25119; Thu, 10 Apr 1997 20:43:37 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA11934 for ; Thu, 10 Apr 1997 20:50:14 -0700 Received: from spruce.fedex.net (maxdialin6.Ipsilon.COM [205.226.20.236]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id UAA29861; Thu, 10 Apr 1997 20:43:06 -0700 Message-Id: <3.0.1.32.19970410204111.006cfb64@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 10 Apr 1997 20:41:11 -0700 To: Pedro Marques From: Bob Hinden Subject: (IPng 3504) Friday IPng Session at IETF will be on the MBONE Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199704110049.RAA27661@pedrom-ultra.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 569 Pedro, >Having watched Thomas Narten's presentation from the mbone i'd like to >make some comments as it seams that a WG decision on the subject will >be made tomorrow (and unfortunatly not mboned). Arrangements have been made for the Friday IPng session (9am CST) to be mboned. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 10 21:07:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA08149; Thu, 10 Apr 1997 20:54:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA08142; Thu, 10 Apr 1997 20:53:42 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA25988; Thu, 10 Apr 1997 20:54:45 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id VAA14356 for ; Thu, 10 Apr 1997 21:01:18 -0700 From: Masataka Ohta Message-Id: <199704110351.MAA25685@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA25685; Fri, 11 Apr 1997 12:51:37 +0900 Subject: (IPng 3505) Re: ESDs To: roque@cisco.com (Pedro Marques) Date: Fri, 11 Apr 97 12:51:36 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <199704110335.UAA06557@trix.cisco.com>; from "Pedro Marques" at Apr 10, 97 8:35 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2276 Pedro; > Masataka> There is some, as long as the PCB lookup does not need > Masataka> destination/source locator and destination locator is > Masataka> not checksum protected. > > Can you please be more specific in terms of what are the benifits you > find ?... Simplified mobility and multicast with no tunneling, which is what I presented in San Jose. I made almost the same presentation in Danvers 2 (sorry, I said 1 today) years ago with 6+2+8 addressing architecture. > Masataka> As long as we don't need scalable security (which we do > Masataka> need), we don't need hierarchical ID. > > Shall i read that statement as "non-hierarchical IDs are useless" ? It is as useful as IPv4 address with HOSTS.TXT. > Masataka> But, some just don't want to admit that stateless > Masataka> autoconfiguration is not secure in a scalable manner. > > I think that everybody admits that addrconf startup is not secure in > a scalable manner... Really? > It is just that the threat is confined to the > local wire and most people think they can live with local threats > as long as they can isolate remote ones. It's surprising that they believe the Internet has the global scale. But, what's wrong to offer them and I a flat 63bit ID space to be useful with local HOSTS.TXT, then? They don't mind scalablity and I sometimes don't, either. > Masataka> The problem is that some believe that ID/Locator > Masataka> separation is a radical change, while the removal of > Masataka> hierarchy from ID is not. > > I don't think i follow that. "removing hierarchy from ID" is precisly what > the ESD proposal does... ID of IPv4 (that is, IPv4 address) does have hierarchy value of which is well understood by most of DNS people. > It removes the routing porting from the address > to make it a less transient identificator. It's a completely conservative change of ID/Locator half-separation only to need a little longer address. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 10 21:18:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA08197; Thu, 10 Apr 1997 21:05:25 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA08190; Thu, 10 Apr 1997 21:05:07 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA27156; Thu, 10 Apr 1997 21:06:10 -0700 Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA17148 for ; Thu, 10 Apr 1997 21:12:47 -0700 Received: (roque@localhost) by trix.cisco.com (8.6.12/8.6.5) id VAA07078; Thu, 10 Apr 1997 21:06:08 -0700 Date: Thu, 10 Apr 1997 21:06:08 -0700 Message-Id: <199704110406.VAA07078@trix.cisco.com> From: Pedro Marques To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3506) Re: ESDs In-Reply-To: <199704110351.MAA25685@necom830.hpcl.titech.ac.jp> References: <199704110335.UAA06557@trix.cisco.com> <199704110351.MAA25685@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1932 >>>>> "Masataka" == Masataka Ohta writes: Ohta-san, Masataka> As long as we don't need scalable security (which we do Masataka> need), we don't need hierarchical ID. >> Shall i read that statement as "non-hierarchical IDs are >> useless" ? Masataka> It is as useful as IPv4 address with HOSTS.TXT. Masataka> But, some just don't want to admit that stateless Masataka> autoconfiguration is not secure in a scalable manner. >> I think that everybody admits that addrconf startup is not >> secure in a scalable manner... Masataka> Really? Never saw a statement in contrary. >> It is just that the threat is confined to the local wire and >> most people think they can live with local threats as long as >> they can isolate remote ones. Masataka> It's surprising that they believe the Internet has the Masataka> global scale. Masataka> But, what's wrong to offer them and I a flat 63bit ID Masataka> space to be useful with local HOSTS.TXT, then? There is a fundamental difference: people want non-local end to end communication. They can live with local thrust mecanisms as long as it still enables them to communicate with the global network. Your 63bit hosts.txt doesn't buy them anything because it can only provide for local security which they don't value much anyway having no advantage in the global scenario. Masataka> ID of IPv4 (that is, IPv4 address) does have hierarchy Masataka> value of which is well understood by most of DNS people. And it even works :-) and scales better than flat ID spaces. regards, ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 10 21:33:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA08239; Thu, 10 Apr 1997 21:19:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA08232; Thu, 10 Apr 1997 21:19:09 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA28238; Thu, 10 Apr 1997 21:20:12 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id VAA19960 for ; Thu, 10 Apr 1997 21:26:46 -0700 From: Masataka Ohta Message-Id: <199704110417.NAA25898@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA25898; Fri, 11 Apr 1997 13:17:01 +0900 Subject: (IPng 3507) Re: ESDs To: roque@cisco.com (Pedro Marques) Date: Fri, 11 Apr 97 13:17:00 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <199704110406.VAA07078@trix.cisco.com>; from "Pedro Marques" at Apr 10, 97 9:06 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1323 Pedro; > Masataka> But, some just don't want to admit that stateless > Masataka> autoconfiguration is not secure in a scalable manner. > >> I think that everybody admits that addrconf startup is not > >> secure in a scalable manner... > > Masataka> Really? > Never saw a statement in contrary. But when a poor engineer can't accept nor counter-argue against something, he tries to ignore it to repeat a defeated opinion. > Masataka> But, what's wrong to offer them and I a flat 63bit ID > Masataka> space to be useful with local HOSTS.TXT, then? > > There is a fundamental difference: people want non-local end to end > communication. They can live with local thrust mecanisms as long as > it still enables them to communicate with the global network. > Your 63bit hosts.txt doesn't buy them anything because it can only > provide for local security which they don't value much anyway > having no advantage in the global scenario. No. My /etc/hosts these days is only 10 lines long. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 10 21:52:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA08315; Thu, 10 Apr 1997 21:40:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA08306; Thu, 10 Apr 1997 21:40:27 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA29829; Thu, 10 Apr 1997 21:41:30 -0700 Received: from gecko.nas.nasa.gov (gecko.nas.nasa.gov [129.99.34.45]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA24448 for ; Thu, 10 Apr 1997 21:48:08 -0700 Received: from gecko.nas.nasa.gov (kml@localhost) by gecko.nas.nasa.gov (8.8.3/NAS.6.1) with ESMTP id VAA16642; Thu, 10 Apr 1997 21:41:31 -0700 (PDT) Message-Id: <199704110441.VAA16642@gecko.nas.nasa.gov> To: Pedro Marques cc: ipng@sunroof.eng.sun.com Subject: (IPng 3508) Re: ESDs In-reply-to: Your message of "Thu, 10 Apr 1997 17:49:58 PDT." <199704110049.RAA27661@pedrom-ultra.cisco.com> Date: Thu, 10 Apr 1997 21:41:30 -0700 From: "Kevin M. Lahey" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1986 In message <199704110049.RAA27661@pedrom-ultra.cisco.com>Pedro Marques writes >On Thomas slides the "Main Benefit" section has a bullet that reads: > > > - Facilitates retroactive fixup of Routing Stuff: > - mobile node says "I just moved, here is my new address" > - during renumbering: "here is my new prefered addresss" > > >As far as i understand it we are taling about explicit messages from >the host which is renumbering to change the Routing Prefix stored >in PCBs at the other end. This being the case, i don't see why ESDs >facilitate things or provide any benefit at all. > >We are talking about a message saying: > I'm X (64 bit ESD), moving to prefix P2 (64 routing prefix) >compared to > I'm Y (128 bit IPv6 address), moving to address Z (128 bit IPv6 >address) Actually, I think that all of this was supposed to happen without an explicit message. Host A at address A0 would start using the new address A1; as part of an ongoing TCP session with host B it would start sending messages with the source A1 instead of A0. Host B would see the new address, but associate it with the old TCP session because both addresses (A0 and A1) share an ESD. Host B might accept the new messages from A1, but would continue to reply to A0 until host A had sent at least an AH in one of the messages, to prevent trivial hijacking. Of course, this still requires host A to realize a change has happened and provide some sort of AH to host B. If host A has to do anything at all, why not provide an explicit message with a new 128 bit address, as you suggest above, and be done with it? ESDs don't seem to provide a big win here. But I guess we are in violent agreement. Kevin ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 10 22:04:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA08380; Thu, 10 Apr 1997 21:52:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA08372; Thu, 10 Apr 1997 21:52:01 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA00846; Thu, 10 Apr 1997 21:53:04 -0700 Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA26739 for ; Thu, 10 Apr 1997 21:59:41 -0700 Received: (roque@localhost) by trix.cisco.com (8.6.12/8.6.5) id VAA07928; Thu, 10 Apr 1997 21:53:03 -0700 Date: Thu, 10 Apr 1997 21:53:03 -0700 Message-Id: <199704110453.VAA07928@trix.cisco.com> From: Pedro Marques To: "Kevin M. Lahey" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3509) Re: ESDs In-Reply-To: <199704110441.VAA16642@gecko.nas.nasa.gov> References: <199704110049.RAA27661@pedrom-ultra.cisco.com> <199704110441.VAA16642@gecko.nas.nasa.gov> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2070 >>>>> "Kevin" == Kevin M Lahey writes: Kevin> In message Kevin> <199704110049.RAA27661@pedrom-ultra.cisco.com>Pedro Marques Kevin> writes >> On Thomas slides the "Main Benefit" section has a bullet that >> reads: >> >> - Facilitates retroactive fixup of Routing Stuff: - >> mobile node says "I just moved, here is my new address" - >> during renumbering: "here is my new prefered addresss" >> >> As far as i understand it we are taling about explicit messages >> from the host which is renumbering to change the Routing Prefix >> stored in PCBs at the other end. This being the case, i don't >> see why ESDs facilitate things or provide any benefit at all. >> >> We are talking about a message saying: I'm X (64 bit ESD), >> moving to prefix P2 (64 routing prefix) compared to I'm Y (128 >> bit IPv6 address), moving to address Z (128 bit IPv6 address) Kevin> Actually, I think that all of this was supposed to happen Kevin> without an explicit message. The explicit message we are talking about could be as simple as a destination option in a packet. Also, i don't think you want to change the locator part without an explicit message as the upper layer checksum in the ESD proposal doesn't include the locator part. Kevin> Of course, this still requires host A to realize a change Kevin> has happened and provide some sort of AH to host B. If Kevin> host A has to do anything at all, why not provide an Kevin> explicit message with a new 128 bit address, as you suggest Kevin> above, and be done with it? ESDs don't seem to provide a Kevin> big win here. Kevin> But I guess we are in violent agreement. Nice :-) regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Apr 11 04:59:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA08856; Fri, 11 Apr 1997 04:50:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA08849; Fri, 11 Apr 1997 04:50:24 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA00647; Fri, 11 Apr 1997 04:51:27 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id UAA06054 for ; Thu, 10 Apr 1997 20:22:51 -0700 From: Masataka Ohta Message-Id: <199704110313.MAA25423@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA25423; Fri, 11 Apr 1997 12:13:12 +0900 Subject: (IPng 3510) Re: ESDs To: roque@cisco.com (Pedro Marques) Date: Fri, 11 Apr 97 12:13:11 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199704110049.RAA27661@pedrom-ultra.cisco.com>; from "Pedro Marques" at Apr 10, 97 5:49 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1996 > > > Having watched Thomas Narten's presentation from the mbone i'd like to > make some comments as it seams that a WG decision on the subject will > be made tomorrow (and unfortunatly not mboned). > > On Thomas slides the "Main Benefit" section has a bullet that reads: > > > - Facilitates retroactive fixup of Routing Stuff: > - mobile node says "I just moved, here is my new address" > - during renumbering: "here is my new prefered addresss" > > > As far as i understand it we are taling about explicit messages from > the host which is renumbering to change the Routing Prefix stored > in PCBs at the other end. This being the case, i don't see why ESDs > facilitate things or provide any benefit at all. There is some, as long as the PCB lookup does not need destination/source locator and destination locator is not checksum protected. > As a closing argument, a non hierarchical EID is useless for comunication > purposes. To comunicate you need a "locator", somewhere to send packets to, > and having a flat EID doesn't help in anyway since you cannot do lookups > and resolve the locator part. As long as we don't need scalable security (which we do need), we don't need hierarchical ID. But, some just don't want to admit that stateless autoconfiguration is not secure in a scalable manner. > I really liked to watch Thomas's presentation... it means there is still > hope of some healthful conservatism on not jumping into a radical change > from IPv4 which we don't really know what is going to buy us, if anything ;-) The problem is that some believe that ID/Locator separation is a radical change, while the removal of hierarchy from ID is not. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Apr 11 11:35:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA09340; Fri, 11 Apr 1997 11:26:18 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA09333; Fri, 11 Apr 1997 11:25:44 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA20125; Fri, 11 Apr 1997 11:26:46 -0700 Received: from jennie.bellcore.com (jennie.bellcore.com [192.4.15.79]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA10386 for ; Fri, 11 Apr 1997 11:33:31 -0700 Received: from bellcore.com (localhost [127.0.0.1]) by jennie.bellcore.com (8.6.9/8.6.10) with ESMTP id OAA15908; Fri, 11 Apr 1997 14:26:43 -0400 Message-Id: <199704111826.OAA15908@jennie.bellcore.com> To: ipng@sunroof.eng.sun.com Cc: gja@bellcore.com Subject: (IPng 3511) IPv6 for ATM Date: Fri, 11 Apr 1997 14:26:41 -0400 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 609 I suspect this wasn't announced to the IPng list, but the latest IPv6/ATM I-D (under the ION WG) is now named: draft-ietf-ion-tn-00.txt (The 'tn' stands for Transient Neighbors, a reference to the use of ND to establish transient shortcuts to 'neighbors' on other IPv6 Links but on the same link-level cloud.) cheers, gja ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Sun Apr 13 09:36:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA11480; Sun, 13 Apr 1997 09:25:39 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA11473; Sun, 13 Apr 1997 09:25:27 -0700 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA26236; Sun, 13 Apr 1997 09:26:31 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA14333 for ; Sun, 13 Apr 1997 09:33:43 -0700 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA16068; Sun, 13 Apr 1997 12:21:16 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA32762; Sun, 13 Apr 1997 12:21:12 -0400 Message-Id: <9704131621.AA32762@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3512) aAA and RG records... Date: Sun, 13 Apr 97 12:21:11 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 891 Per our decision on Friday at Memphis. I assume there is no point in pursuing the DNS aAA and RG record differentiation. The reason is that for any reverse lookups asking DNS to parse token + RG is to much to ask on the search if the records are split. Also I see no gain without globally unique ESDs for now. For name look ups why add the extra work to our box now and why add the performance hit and complications to DNS per my slides at the meeting. Do we all agree. If not even so this work is low priority as opposed to other work as far as I am concerned???????????????? Comments... thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Sun Apr 13 11:56:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA11533; Sun, 13 Apr 1997 11:45:45 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA11526; Sun, 13 Apr 1997 11:45:33 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA02781; Sun, 13 Apr 1997 11:46:35 -0700 Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA02912 for ; Sun, 13 Apr 1997 11:53:50 -0700 Received: from Cust25.Max3.Boston.MA.MS.UU.NET by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA14650; Sun, 13 Apr 1997 11:40:23 -0700 Message-Id: <3.0.1.32.19970413143926.0091ece8@alphy.lkg.dec.com> X-Sender: altamatt@alphy.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 13 Apr 1997 14:39:26 -0400 To: bound@zk3.dec.com From: Matt Thomas Subject: (IPng 3513) Re: aAA and RG records... Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9704131621.AA32762@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2252 At 12:21 PM 4/13/97 -0400, bound@zk3.dec.com wrote: >Per our decision on Friday at Memphis. I assume there is no point in >pursuing the DNS aAA and RG record differentiation. I'm not sure I agree. I still think the idea of avoiding every host having to make DNS updating on renumbering is very appealing. $origin wireless.memphis.fedex.net. . IN AAxx 5f00:3400:1122:3344 IN AAxx ... ietfwl57 IN AAxxPTR wireless.memphis.fedex.net. IN xxAA 0800:0EFF:FE12:3456 >The reason is that for any reverse lookups asking DNS to parse token + >RG is to much to ask on the search if the records are split. Also I see >no gain without globally unique ESDs for now. Why do they need to? If Matt C.'s WHO-ARE-YOU are done, the host will answer based on the who-are-you request. If that's not done, you should do: $origin ptr.wireless.fedex.net. 6.5.4.3.2.1.e.f.f.f.e.0.0.0.8.0 IN PTR ietfwl57.wireless.fedex.net. 4.4.3.3.2.2.1.1.0.0.4.3.0.0.f.5.ip6.int. IN CNAME ptr.wireless.fedex.net. 4.4.3.3.0.0.0.0.0.0.0.0.0.c.e.f.ip6.int. IN CNAME ptr.wireless.fedex.net. This would allow one needing one PTR record per interface. >For name look ups why add the extra work to our box now and why add the >performance hit and complications to DNS per my slides at the meeting. If the change can be limited to the DNS servers then it's easy to defer this for now. If this is done on the client, it better be spec'ed ASAP so they implementation will be widespread. >Do we all agree. If not even so this work is low priority as opposed to >other work as far as I am concerned???????????????? It's definitely not high priority. But it's needed if are to get automatic router renumbering. -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Paranoid WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Apr 14 08:38:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA12405; Mon, 14 Apr 1997 08:28:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA12398; Mon, 14 Apr 1997 08:27:52 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA02416; Mon, 14 Apr 1997 08:28:54 -0700 Received: from mailhost2.BayNetworks.COM (ext-ns1.baynetworks.com [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA19044 for ; Mon, 14 Apr 1997 08:35:56 -0700 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/03/26-E) with ESMTP id IAA06214 Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17]) by ns1.BayNetworks.COM (8.8.5/BNET-97/03/12-I) with SMTP id IAA28644 Posted-Date: Mon, 14 Apr 1997 08:27:14 -0700 (PDT) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0) by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1) id AA23984; Mon, 14 Apr 97 11:27:09 EDT Received: from greenfield.engeast.baynetworks.com (greenfield.corpeast.baynetworks.com [192.32.170.19]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA25907; Mon, 14 Apr 1997 11:27:03 -0400 Message-Id: <3.0.32.19970414112620.006c3cb8@pobox.engeast.baynetworks.com> X-Sender: dhaskin@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 14 Apr 1997 11:26:22 -0400 To: tmatsuda@nttssl.nslab.ntt.co.jp (Matsuda), ion@nexen.com, ipng@sunroof.eng.sun.com From: Dimitry Haskin Subject: (IPng 3515) Re: Encapsulation (IPv6 traffic over Frame Relay)? Cc: tmatsuda@nttssl.nslab.ntt.co.jp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1078 Matsuda, I believe the assumption is that the SNAP and NULL encapsulations will be used for IPv6. Dimitry At 09:22 PM 4/14/97 +0900, Matsuda wrote: >Dear, > >Which NLPID value will be used for IPv6 encapsulation >over Frame Relay? >(1) IP(v4) NLPID(0xCC)? >(2) IPv6 NLPID(unassigned by ISO)? >(3) SNAP NLPID(with IPv6 Ethertype, 0x86-DD)? > >I think that (2) is best choice! >In case of the (1), IP version must be identified by IP version field. >In case of the (3), identifer filelds' structure for IPv6 is different >from one for IPv4. > >$B!v!v!v(BNTT Network Service Systems Laboratories$B!v!v!v(B >Broadband Network Systems Laboratory > Takao Matsuda Tel:+81 422 59 4050 >(E-mail:tmatsuda@nttssl.nslab.ntt.co.jp)Fax:+81 422 59 4549 > > > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Apr 14 12:10:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA12753; Mon, 14 Apr 1997 12:02:16 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA12746; Mon, 14 Apr 1997 12:01:36 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA27018; Mon, 14 Apr 1997 12:02:37 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA02889 for ; Mon, 14 Apr 1997 12:02:31 -0700 Received: from gungnir.fnal.gov ("port 34280"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IHP57YQAQY000I57@FNAL.FNAL.GOV> for ipng@sunroof.eng.sun.com; Mon, 14 Apr 1997 14:02:28 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA06896; Mon, 14 Apr 1997 14:01:48 -0500 Date: Mon, 14 Apr 1997 14:01:47 -0500 From: Matt Crawford Subject: (IPng 3517) While we have ND open To: ipng@sunroof.eng.sun.com Message-id: <199704141901.OAA06896@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA12921; Mon, 14 Apr 1997 13:36:45 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA12914; Mon, 14 Apr 1997 13:36:14 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA29519; Mon, 14 Apr 1997 13:37:16 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA01601; Mon, 14 Apr 1997 13:37:14 -0700 Date: Mon, 14 Apr 1997 13:37:14 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199704142037.NAA01601@bobo.eng.sun.com> To: crawdad@FNAL.GOV Subject: (IPng 3518) Re: While we have ND open Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1423 > While we have ND on the operating table, I'd like to see two more > bits of "Router Configuration Variables" (currently section 6.2.1) > added per advertised prefix on each interface. These bits would be > flags specifying that the router is decrementing AdvValidLifetime and > AdvPreferredLifetime. These flags need not appear in the > advertisements. I agree that this makes sense, but somebody needs to make sure that adding this functionality doesn't force us to go back to through the PS process. Who can do this? The only (other) changes I know of for ND is to - Change the solicited node multicast address description to be a reference to the definition in the addr-arch document. - Remove the text about setting the priority to 15 in transmitted packets. - Adding whatever we come up with for the "2 hour limit". I was going to do the site-prefixes as a separate draft with the hope of merging into ND as ND moves forward. (Assuming the idea pans out - there are some issues of how it might effectely introduce weaknesses in the DNS security since it is changing what gets returned to an application.) Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Apr 14 14:09:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA12971; Mon, 14 Apr 1997 14:01:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA12964; Mon, 14 Apr 1997 14:01:17 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA27741; Mon, 14 Apr 1997 14:02:19 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA05788 for ; Mon, 14 Apr 1997 14:09:40 -0700 Received: from gungnir.fnal.gov ("port 34298"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IHP9E31DT6000I57@FNAL.FNAL.GOV>; Mon, 14 Apr 1997 16:01:56 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA07284; Mon, 14 Apr 1997 16:01:14 -0500 Date: Mon, 14 Apr 1997 16:01:13 -0500 From: Matt Crawford Subject: (IPng 3519) Re: aAA and RG records... In-reply-to: "13 Apr 1997 12:21:11 EDT." <"9704131621.AA32762"@wasted.zk3.dec.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Message-id: <199704142101.QAA07284@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Per our decision on Friday at Memphis. I assume there is no point in > pursuing the DNS aAA and RG record differentiation. My opinion: While we may or may not decide to go ahead with rg+aaa as the records in the DNS, that decision is independent of whether the ESD (and I think we may still call it that) is globally unique. The rg+aaa scheme would be of more value in a world of GSE-style address rewriting at the borders. Without that, the tradeoff seems to be between a more complicated DNS scheme and having to do a large global replace on your DNS files when you change a prefix. And if that's the tradeoff, I think your conclusion is correct, that rg+aaa goes nowhere. Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Apr 14 20:06:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA13538; Mon, 14 Apr 1997 19:57:30 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA13531; Mon, 14 Apr 1997 19:56:51 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA08712; Mon, 14 Apr 1997 19:57:53 -0700 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA07851 for ; Mon, 14 Apr 1997 20:05:21 -0700 From: Margaret Forsythe To: ipng@sunroof.eng.sun.com Subject: (IPng 3521) multihomed host between sites Date: Mon, 14 Apr 97 22:57:46 -0400 Message-ID: <9704142257.aa13751@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1546 A question has arisen while implementing IPv6 for a multihomed host: Is it possible for a multihomed host (whether or not it is a router) to have interfaces in multiple sites (i.e. a two interface host where each interface is in a different site)? I believe this might be the case for a router between a site and an ISP, for example. Could there be non-router hosts which also exist in multiple sites? If so, in the world of non-globally unique ESDs, how would a host determine whether a particular site-local packet should be passed-up locally? Obviously, matching on all site-local addresses would have the potential for an incorrect match if the host has interfaces in different sites. Would packets be matched only against the site local address for the interface on which they were received? If so, could using site local addresses cause problems with the redundancy that multihomed hosts are designed to offer? Or could the host somehow determine which set of its interfaces were in the same site and match against the site local addresses for those interfaces? If so, how would the host determine this information? Would the answers be different for a router than for a non-router? Thanx, mrf ------- End of forwarded message ------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Apr 14 21:40:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA13684; Mon, 14 Apr 1997 21:30:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA13677; Mon, 14 Apr 1997 21:29:23 -0700 From: bound@zk3.dec.com Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA17320; Mon, 14 Apr 1997 21:30:23 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA01813; Mon, 14 Apr 1997 21:30:18 -0700 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id AAA13450; Tue, 15 Apr 1997 00:21:54 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA11081; Tue, 15 Apr 1997 00:21:52 -0400 Message-Id: <9704150421.AA11081@wasted.zk3.dec.com> To: Erik.Nordmark@Eng (Erik Nordmark) Cc: crawdad@fnal.gov, ipng@sunroof.eng.sun.com Subject: (IPng 3522) Re: While we have ND open In-Reply-To: Your message of "Mon, 14 Apr 97 13:37:14 PDT." <199704142037.NAA01601@bobo.eng.sun.com> Date: Tue, 15 Apr 97 00:21:52 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 573 Erik, Any chance of doing the draft of the changes with "diffmk" so we can just read the hash marks? Just asking I know sometimes it works for me and sometimes it don't depending on if I reformat the spec... I also think Matt C's rtr config variables make sense too as input. thx /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Apr 14 21:40:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA13695; Mon, 14 Apr 1997 21:31:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA13686; Mon, 14 Apr 1997 21:30:34 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA17388; Mon, 14 Apr 1997 21:31:35 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA02111 for ; Mon, 14 Apr 1997 21:31:30 -0700 Received: from [171.69.116.90] ([171.69.116.90]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id VAA15863; Mon, 14 Apr 1997 21:31:27 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <9704142257.aa13751@khitomer.epilogue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Apr 1997 21:32:04 -0700 To: Margaret Forsythe From: Steve Deering Subject: (IPng 3523) Re: multihomed host between sites Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1882 At 7:57 PM -0700 4/14/97, Margaret Forsythe wrote: > Is it possible for a multihomed host (whether or not it is a router) to > have interfaces in multiple sites (i.e. a two interface host where each > interface is in a different site)? I believe this might be the case for > a router between a site and an ISP, for example. Could there be non-router > hosts which also exist in multiple sites? Yes. A simple example might be a host attached to an Ethernet at one site, with a dialed-up modem connection to distant site. > If so, in the world of non-globally unique ESDs, how would a host determine > whether a particular site-local packet should be passed-up locally? The packet should be accepted for local delivery if the destination address matches any of the site-local addresses belonging to any of the interfaces attached to the same site as the arrival interface. (This is the "weak AS model" applied to site-local addresses, as I advocated in my handwaving presenation in San Jose.) It is what you suggested as your third possible answer: > Or could the host somehow determine which set of its interfaces were in the > same site and match against the site local addresses for those interfaces? > If so, how would the host determine this information? There will need to be a way to configure a node to identify sets of interfaces that attach to the same site. The default assumtion should be that all interfaces attach to the same site, so that configuration will not be needed in the common case. > Would the answers be different for a router than for a non-router? No. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Apr 14 22:26:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA13747; Mon, 14 Apr 1997 22:18:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA13740; Mon, 14 Apr 1997 22:17:33 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA21431; Mon, 14 Apr 1997 22:18:32 -0700 Received: from wizard.gsfc.nasa.gov (wizard.gsfc.nasa.gov [128.183.115.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA25566 for ; Mon, 14 Apr 1997 22:26:05 -0700 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA27226; Tue, 15 Apr 97 01:15:42 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9704150515.AA27226@wizard.gsfc.nasa.gov> Subject: (IPng 3524) Re: aAA and RG records... To: crawdad@FNAL.GOV (Matt Crawford) Date: Tue, 15 Apr 1997 01:15:41 -0400 (EDT) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: <199704142101.QAA07284@gungnir.fnal.gov> from "Matt Crawford" at Apr 14, 97 04:01:13 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 content-length: 1482 > > Per our decision on Friday at Memphis. I assume there is no point in > > pursuing the DNS aAA and RG record differentiation. > > My opinion: > While we may or may not decide to go ahead with rg+aaa as the records > in the DNS, that decision is independent of whether the ESD (and I > think we may still call it that) is globally unique. > > The rg+aaa scheme would be of more value in a world of GSE-style > address rewriting at the borders. Without that, the tradeoff seems > to be between a more complicated DNS scheme and having to do a large > global replace on your DNS files when you change a prefix. > > And if that's the tradeoff, I think your conclusion is correct, that > rg+aaa goes nowhere. > Matt I think the RG+aAA is still a big win with helping to renumber a site, especially when that change is as a result of a provider change rather than a site decision. I would hope that the way this would be handled would be addition of the new RG, both old and new RG coexisting for some transition period with the new RG being preferred, and finally the removal of the old RG. I believe this whole process would be much simpler with separate RG and aAA records. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 15 02:13:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA13927; Tue, 15 Apr 1997 02:04:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA13919; Tue, 15 Apr 1997 02:03:41 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA10984; Tue, 15 Apr 1997 02:04:42 -0700 Received: from relay2.mail.uk.psi.net (sys1.london.uk.psi.net [154.32.108.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA22242 for ; Tue, 15 Apr 1997 02:12:16 -0700 Received: from sys4.cambridge.uk.psi.net (sys4.cambridge.uk.psi.net [154.32.106.14]) by relay2.mail.uk.psi.net (8.8.4/) with ESMTP id KAA28430 for ; Tue, 15 Apr 1997 10:04:40 +0100 (BST) Received: from rrl.UUCP by sys4.cambridge.uk.psi.net (8.7.5/SMI-5.5-UKPSINet) id JAA28531; Tue, 15 Apr 1997 09:37:24 +0100 (BST) Date: Tue, 15 Apr 1997 09:22:51 +0100 From: asgari@rrl.co.uk ( Hamid Asgari ) Reply-To: asgari@rrl.co.uk Message-Id: <199704150822.JAA03583@rrl> To: ipng@sunroof.eng.sun.com Subject: (IPng 3525) Flow Label Cc: Asgari@rrl.co.uk X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2178 Hello everybody, Some questions have arisen while reading IPv6. They are related to the flow lable in the IPv6 header. A flow is a sequence of packets sent from a particular source to a particular (unicast or multicast) destination for which the source desires special handling by the intervening routers. A flow lable is assigned to a flow by the flow's source node. New flow lables must be chosen randomly and uniformly from the range of 1 to FFFFFF hex. All packets belonging to the same flow must be sent with the same source address, same destination address, and same non-zero flow label [1]. Here is the related questions: a) Is it arbitrary for the source to choose a random folw lable for a flow? If this is the case why flow lable includes 24 bits, that is, a sourcce can handle about 16 million flows simulatneously! This also causes table look-up problem that each router has to maitain a large table related to each active source. b) Does the source choose the flow lable based on some criteria which is common for all sources and dictated by a specific protocol? If this the case it creates some confusion. I mean a source's flow characteristic may differ from another source which may be forced to choose the same flow lable. I know the source and destination of these two flows are different. How does the router act? Look forward to hearing from you. Best reagrds, |***********************************************************| | Hamid Asgari | | Racal Reseach Limited | | Worton Drive, Tel (work): 01189-238378 | | Worton Grange Industrial Estate Fax (work): 01189-238399 | | Reading, Berkshire RG2 0SB, UK Email: Asgari@rrl.co.uk | ************************************************************* [1] Robert M. Hinden, "IP Next Generation Overview". ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 15 07:07:09 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA14146; Tue, 15 Apr 1997 06:58:28 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA14139; Tue, 15 Apr 1997 06:57:48 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA13246; Tue, 15 Apr 1997 06:58:47 -0700 Received: from cnrmail.lbl.gov (buster.lbl.gov [131.243.65.29]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA10537 for ; Tue, 15 Apr 1997 07:06:27 -0700 Received: from [128.3.9.22] by cnrmail.lbl.gov with ESMTP (Apple Internet Mail Server 1.1.1); Tue, 15 Apr 1997 06:58:50 -0700 X-Sender: rlfink@cnrmail.lbl.gov Message-Id: In-Reply-To: <9704150515.AA27226@wizard.gsfc.nasa.gov> References: <199704142101.QAA07284@gungnir.fnal.gov> from "Matt Crawford" at Apr 14, 97 04:01:13 pm Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Tue, 15 Apr 1997 06:58:46 -0700 To: bill@wizard.gsfc.nasa.gov (Bill Fink) From: Bob Fink Subject: (IPng 3528) Re: aAA and RG records... Cc: crawdad@FNAL.GOV (Matt Crawford), bound@zk3.dec.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 957 Bill, At 10:15 PM -0700 4/14/97, Bill Fink wrote: ... >I think the RG+aAA is still a big win with helping to renumber a site, >especially when that change is as a result of a provider change rather >than a site decision. I would hope that the way this would be handled >would be addition of the new RG, both old and new RG coexisting for >some transition period with the new RG being preferred, and finally >the removal of the old RG. I believe this whole process would be much >simpler with separate RG and aAA records. I also believe that RG+aAA is a real win for renumbering...I hope it doesn't die. Bob (yeah, those Finks again...but no relation to speak of :-) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 15 10:50:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA14340; Tue, 15 Apr 1997 10:41:49 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA14333; Tue, 15 Apr 1997 10:41:11 -0700 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA04044; Tue, 15 Apr 1997 10:42:10 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA19104 for ; Tue, 15 Apr 1997 10:49:43 -0700 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA27152; Tue, 15 Apr 1997 13:30:34 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA04023; Tue, 15 Apr 1997 13:30:31 -0400 Message-Id: <9704151730.AA04023@wasted.zk3.dec.com> To: asgari@rrl.co.uk Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3529) Re: Flow Label In-Reply-To: Your message of "Tue, 15 Apr 97 09:22:51 BST." <199704150822.JAA03583@rrl> Date: Tue, 15 Apr 97 13:30:31 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2655 >Here is the related questions: >a) Is it arbitrary for the source to choose a random folw lable for a flow? >If this is the case why flow lable includes 24 bits, that is, a sourcce can >handle about 16 million flows simulatneously! This also causes table look-up >problem that each router has to maitain a large table related to each active >source. I think the first part of your question is yes and no. The source can clearly request a flow from a seed or random number generator. Or we may develop a means to get the flow from a router or IP/Switch. This is all TBD. Also an issue for RSVP implementation to study in IPv6 too. I believe this is work in progress. I believe multiple options should be supported, but it is a MUST that the source (e.g. a host) be able to define the flow label for an application that is supported btw to end-nodes on a network or virtual network. As far as route table size this is work in progress and could be optimized by such work arounds like tag/label switching, or work on QOS in the routing area. >b) Does the source choose the flow lable based on some criteria which is >common for all sources and dictated by a specific protocol? If this the >case it creates some confusion. I mean a source's flow characteristic may >differ from another source which may be forced to choose the same flow >lable. I know the source and destination of these two flows are different. >How does the router act? I think what protocol uses the flow is up to that protocol and if it can be used. As far as source flow differentiation I think that is a policy issue and not sure we can define one policy to work in all cases. I believe if a source generates a duplicate flow thats an error and ill-behaved implementation and I believe should be caught by the first hop router. Or the router or IP/Switch that sourced the flow-label to an end node or other router. This is really undefined and work in progress how to use the flows as it stated in RFC 1883. We need to work on this for sure. But on an "Intranet" I predict if this is 3 year IETF discussion the vendors will collaborate to define flows for private nets to use IPv6 flows in their backbones with IPv6. I know I am looking at how this can be done at present (e.g. Internet Telephony, Auido/Video, IP/Switching, and Packet Prioritization on an Intranet). /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 15 10:57:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA14359; Tue, 15 Apr 1997 10:48:40 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA14352; Tue, 15 Apr 1997 10:47:57 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA05123; Tue, 15 Apr 1997 10:46:33 -0700 Received: from tuan.cse.rmit.EDU.AU (tuan.cse.rmit.EDU.AU [131.170.118.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA21422; Tue, 15 Apr 1997 10:54:12 -0700 Received: from huntsman.cse.rmit.edu.au (huntsman.cse.rmit.EDU.AU [131.170.118.241]) by tuan.cse.rmit.EDU.AU (8.8.5/8.8.5) with ESMTP id DAA04689; Wed, 16 Apr 1997 03:46:15 +1000 (EST) Received: from HUNTSMAN/SpoolDir by huntsman.cse.rmit.edu.au (Mercury 1.31); 16 Apr 97 03:46:33 +1000 Received: from SpoolDir by HUNTSMAN (Mercury 1.31); 16 Apr 97 03:46:05 +1000 From: "Ahmod Bakr El-Sayed: -SC" Organization: Computer Systems Engineering, RMIT To: Erik.Nordmark@Eng (Erik Nordmark), bound@zk3.dec.com Date: Wed, 16 Apr 1997 03:46:00 +1000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: (IPng 3530) Re: While we have ND open CC: crawdad@fnal.gov, ipng@sunroof.eng.sun.com In-reply-to: <9704150421.AA11081@wasted.zk3.dec.com> References: Your message of "Mon, 14 Apr 97 13:37:14 PDT." <199704142037.NAA01601@bobo.eng.sun.com> X-mailer: Pegasus Mail for Windows (v2.53/R1) Message-ID: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1132 hi this is burt from Australia I am doing a thesis in implementation of IPSEC in IP6 and it's effect on the firewall. I have already configured IP6 in my system five: SUN OS 5.5 Solaris 2.5 Box I have also configured SKIP and TIS Firewall Toolkit i need to develop some source code to let the firewall toolkit support the ip6 environment Unfortunatly there is no IP6 API library to make this development the only thing i found was the IP6 API library for Linux at http://www.terra.net/ipv6/linux-ipv6.faq-6.html#ss6.2 which is frustrating! Why we do not have any support from Sun for research development . Could any one tell me where would i find ?? 1- IP6 Source Code For SOLARIS . 2- Solaris 2.5 IP6 API library . This is very Urgent and I would appreciate any help thanks Burt I would be grateful if any one ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Apr 15 15:13:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14686; Tue, 15 Apr 1997 15:05:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14676; Tue, 15 Apr 1997 15:04:30 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA05716; Tue, 15 Apr 1997 15:05:31 -0700 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA16353 for ; Tue, 15 Apr 1997 15:13:14 -0700 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/03/26-E) with ESMTP id PAA21930 Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17]) by ns1.BayNetworks.COM (8.8.5/BNET-97/03/12-I) with SMTP id PAA09788 Posted-Date: Tue, 15 Apr 1997 15:04:53 -0700 (PDT) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0) by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1) id AA04295; Tue, 15 Apr 97 18:04:49 EDT Received: from greenfield.engeast.baynetworks.com (greenfield.corpeast.baynetworks.com [192.32.170.19]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA15365; Tue, 15 Apr 1997 18:04:42 -0400 Message-Id: <3.0.32.19970415180404.00694068@pobox.engeast.baynetworks.com> X-Sender: dhaskin@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 15 Apr 1997 18:04:05 -0400 To: tmatsuda@nttssl.nslab.ntt.co.jp (Matsuda), Dimitry Haskin From: Dimitry Haskin Subject: (IPng 3531) Re: Encapsulation (IPv6 traffic over Frame Relay)? Cc: ion@nexen.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 758 At 06:36 PM 4/15/97 +0900, Matsuda wrote: >Dear, > >Why the SNAP and NULL encapsulations will be used for IPv6? >In RFC1490, NLPID encapsulation is used for IPv4. > >Takao > Takao, There is no NLPID is allocated for v6 and getting it assigned is not easy. It does not seem worth the trouble for six bytes saving. So far no one has made a compelling case for the NLPID encapsulation for v6. On a side note, imo, the fewer encapsulation options are there, the better. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Apr 16 21:10:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA16246; Wed, 16 Apr 1997 21:02:38 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA16239; Wed, 16 Apr 1997 21:02:27 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA12193; Wed, 16 Apr 1997 21:03:36 -0700 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA04487 for ; Wed, 16 Apr 1997 21:11:02 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id XAA09538; Wed, 16 Apr 1997 23:51:06 -0400 Received: from wildbird.watson.ibm.com (wildbird.watson.ibm.com [9.2.23.71]) by mailhub1.watson.ibm.com (8.8.2/01-15-97) with SMTP id AAA20370; Thu, 17 Apr 1997 00:00:51 -0400 Received: from lig32-225-4-152.us.lig-dial.ibm.com by wildbird.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA17324; Thu, 17 Apr 1997 00:00:49 -0400 Message-Id: <9704170400.AA17324@wildbird.watson.ibm.com> From: "Ping Pan" To: , Cc: Subject: (IPng 3532) Re: Flow Label Date: Thu, 17 Apr 1997 00:00:36 -0400 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1304 Hello, Jim: > The source can > clearly request a flow from a seed or random number generator. Or we > may develop a means to get the flow from a router or IP/Switch. This is > all TBD. Also an issue for RSVP implementation to study in IPv6 too. I > believe this is work in progress. > > I believe multiple options should be supported, but it is a MUST that > the source (e.g. a host) be able to define the flow label for an > application that is supported btw to end-nodes on a network or virtual > network. > The flow label for an application is generated by a source, but I think it could be changed by the routers along the way. Right? Or is it a requirement in IPng that flow-label must be the same end-to-end? In case of IP-switching, flow label could essentially be a label (or tag) defined by MPLS. As a result, a flow label could be changed at every hop between a source and a destination. Does it make sense at all? :-) Regards, -- Ping Pan IBM Research Center, pan@watson.ibm.com, (914)-784-6579 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 17 07:18:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA16571; Thu, 17 Apr 1997 07:10:32 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA16564; Thu, 17 Apr 1997 07:10:19 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA18127; Thu, 17 Apr 1997 07:11:25 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA29190; Thu, 17 Apr 1997 07:18:43 -0700 Received: from gungnir.fnal.gov ("port 34522"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IHT1X5LMR4000F3K@FNAL.FNAL.GOV>; Thu, 17 Apr 1997 09:11:25 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA12108; Thu, 17 Apr 1997 09:10:38 -0500 Date: Thu, 17 Apr 1997 09:10:37 -0500 From: Matt Crawford Subject: (IPng 3533) problem with IPv6 group membership messages [was: (ngtrans) Revised draft v6-over-v4] In-reply-to: "14 Apr 1997 17:58:24 PDT." <"199704150058.RAA01983"@bobo.eng.sun.com> To: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Reply-to: ipng@sunroof.eng.sun.com Message-id: <199704171410.JAA12108@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ ... Nodes are not required to send membership reports > for the all-nodes address (at least not if the yet-to-be written > IPv6 spec follows the IGMPv2 spec). ... RFC1885, section 4.3, defines three group membership messages: Type 130 - Group Membership Query 131 - Group Membership Report 132 - Group Membership Reduction and says The ICMPv6 Group Membership messages are used to convey information about multicast group membership from nodes to their neighboring routers. The details of their usage is given in [RFC-1112]. Well, 1112 describes IGMPv1 and has nothing like a "Group Membership Reduction." Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 17 07:28:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA16582; Thu, 17 Apr 1997 07:18:22 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA16575; Thu, 17 Apr 1997 07:18:06 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA20206; Thu, 17 Apr 1997 07:19:12 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA01995 for ; Thu, 17 Apr 1997 07:26:31 -0700 Received: from gungnir.fnal.gov ("port 34524"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IHT27REKVM000F3K@FNAL.FNAL.GOV>; Thu, 17 Apr 1997 09:19:11 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA12129; Thu, 17 Apr 1997 09:18:11 -0500 Date: Thu, 17 Apr 1997 09:18:11 -0500 From: Matt Crawford Subject: (IPng 3534) Re: multihomed host between sites In-reply-to: "14 Apr 1997 22:57:46 EDT." <"9704142257.aa13751"@khitomer.epilogue.com> To: Margaret Forsythe Cc: ipng@sunroof.eng.sun.com Message-id: <199704171418.JAA12129@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Would packets be matched only against the site local address for the > interface on which they were received? ... I'm not sure we ever settled this question for any type of address! Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 17 08:18:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16685; Thu, 17 Apr 1997 08:10:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16662; Thu, 17 Apr 1997 08:08:46 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA01936; Thu, 17 Apr 1997 08:09:54 -0700 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA19051; Thu, 17 Apr 1997 08:17:11 -0700 Received: from rtpdce01.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA25732; Thu, 17 Apr 1997 11:09:49 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id LAA16390; Thu, 17 Apr 1997 11:09:51 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16220; Thu, 17 Apr 1997 11:09:23 -0400 Message-Id: <9704171509.AA16220@cichlid.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Cc: ngtrans@sunroof.eng.sun.com Subject: (IPng 3535) Re: problem with IPv6 group membership messages [was: (ngtrans) Revised draft v6-over-v4] In-Reply-To: Your message of "Thu, 17 Apr 1997 09:10:37 CDT." <199704171410.JAA12108@gungnir.fnal.gov> Date: Thu, 17 Apr 1997 11:09:23 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1141 Well, if we're gonna operate on ICMPv6 (out-patient surgery only I hope!), I noticed sometime back that there is no ICMP "attempt to forward packet beyond scope" message. Such an ICMP message could be issued when a router attempts to forward a packet that would take the source (or destination) address beyond an appropriate scope. For example, if a router was asked to forward to another link a packet with a link-local source or destination address. Or if a packet sent to/from a site-local address was about to leave the site-local boundary. The second case might arise if a packet is routed via a default route (e.g., a site isn't using site-local addresses, but a sender for some reason does). Such messages may also prove useful in deciding when it is appropriate to use site-local vs. global scope addresses. Would such a message be useful? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 17 08:31:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16709; Thu, 17 Apr 1997 08:23:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16702; Thu, 17 Apr 1997 08:23:10 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA04532; Thu, 17 Apr 1997 08:24:17 -0700 Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA25607 for ; Thu, 17 Apr 1997 08:31:36 -0700 Received: by INET-04-IMC with Internet Mail Service (5.0.1458.14) id ; Thu, 17 Apr 1997 08:23:44 -0700 Message-ID: From: Richard Draves To: "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 3536) RE: problem with IPv6 group membership messages Date: Thu, 17 Apr 1997 08:23:48 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.14) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1535 Sounds like a good idea to me. It could be a flavor of the destination-unreachable. > -----Original Message----- > From: Thomas Narten [SMTP:] > Sent: Thursday, April 17, 1997 7:09 AM > To: ipng@sunroof.Eng.Sun.COM > Cc: ngtrans@sunroof.Eng.Sun.COM > Subject: Re: problem with IPv6 group membership messages [was: > (ngtrans) Revised draft v6-over-v4] > > Well, if we're gonna operate on ICMPv6 (out-patient surgery only I > hope!), I noticed sometime back that there is no ICMP "attempt to > forward packet beyond scope" message. Such an ICMP message could be > issued when a router attempts to forward a packet that would take the > source (or destination) address beyond an appropriate scope. For > example, if a router was asked to forward to another link a packet > with a link-local source or destination address. Or if a packet sent > to/from a site-local address was about to leave the site-local > boundary. The second case might arise if a packet is routed via a > default route (e.g., a site isn't using site-local addresses, but a > sender for some reason does). > > Such messages may also prove useful in deciding when it is appropriate > to use site-local vs. global scope addresses. > > Would such a message be useful? > > Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 17 10:08:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16868; Thu, 17 Apr 1997 09:58:39 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16861; Thu, 17 Apr 1997 09:58:29 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA25757; Thu, 17 Apr 1997 09:59:34 -0700 Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA23172 for ; Thu, 17 Apr 1997 10:06:35 -0700 Received: (roque@localhost) by trix.cisco.com (8.6.12/8.6.5) id JAA13881; Thu, 17 Apr 1997 09:59:06 -0700 Date: Thu, 17 Apr 1997 09:59:06 -0700 Message-Id: <199704171659.JAA13881@trix.cisco.com> From: Pedro Marques To: ipng@sunroof.eng.sun.com Subject: (IPng 3537) Re: problem with IPv6 group membership messages [was: (ngtrans) Revised draft v6-over-v4] In-Reply-To: <9704171509.AA16220@cichlid.raleigh.ibm.com> References: <199704171410.JAA12108@gungnir.fnal.gov> <9704171509.AA16220@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2525 >>>>> "Thomas" == Thomas Narten writes: Thomas> I noticed sometime back that there Thomas> is no ICMP "attempt to forward packet beyond scope" Thomas> message. Such an ICMP message could be issued when a Thomas> router attempts to forward a packet that would take the Thomas> source (or destination) address beyond an appropriate Thomas> scope. For example, if a router was asked to forward to Thomas> another link a packet with a link-local source or Thomas> destination address. Thomas> Or if a packet sent to/from a Thomas> site-local address was about to leave the site-local Thomas> boundary. If a packet contains site local source and destination addresses it isn't subject to "leave the site-local boundary" unless routers mess up. So i think the two issues shouldn't be mixed. The proper reply for a router that doesn't know how to forward a packet due to lack of routing information is still "destination unreachable - code 0 (no route)". Thomas> The second case might arise if a packet is Thomas> routed via a default route (e.g., a site isn't using Thomas> site-local addresses, but a sender for some reason does). I think that fits well in the "no route to destination" message. If the reason for the failure to deliver is lack of a matching entry in the forwarding node's routing table, the Code field is set to 0 Thomas> Such messages may also prove useful in deciding when it is Thomas> appropriate to use site-local vs. global scope addresses. I don't think so... they should be used by hosts only in detecting missconfiguration. I think that the address selection (I suppose Steve Deering is still writing the doc) can be made conservative enough that you always have your packets forwarded without having to switch source addresses based on this kind of messages (and go messing up with your upper layer protocols). Thomas> Would such a message be useful? Yes, definitively. If you go back to the previous thread on this topic in the ipngwg mailing list you'll see that several implementations where using different behaviours when they get packets with an invalid address scope. regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 17 11:15:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA16962; Thu, 17 Apr 1997 11:07:16 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA16955; Thu, 17 Apr 1997 11:06:34 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA12995; Thu, 17 Apr 1997 11:07:40 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA25163 for ; Thu, 17 Apr 1997 11:14:59 -0700 Received: from gungnir.fnal.gov ("port 34639"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IHTA6U60JU000F3K@FNAL.FNAL.GOV> for ipng@sunroof.Eng.Sun.COM; Thu, 17 Apr 1997 13:07:31 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id NAA12991; Thu, 17 Apr 1997 13:06:41 -0500 Date: Thu, 17 Apr 1997 13:06:41 -0500 From: Matt Crawford Subject: (IPng 3538) Re: problem with IPv6 group membership messages [was: (ngtrans) Revised draft v6-over-v4] In-reply-to: "17 Apr 1997 11:09:23 -0300." <"9704171509.AA16220"@cichlid.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Message-id: <199704171806.NAA12991@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Such an ICMP message could be > issued when a router attempts to forward a packet that would take the > source (or destination) address beyond an appropriate scope. This can't happen with destination addresses, can it? Either the restricted-scope destination is reachable or it's unreachable for the normal "no route" reason or because it didn't answer ND. > Would such a message be useful? With the addition of an "insufficient source scope" message, there would be an easy test for a target being within a scope or not. Just send a packet to the target's global address using a restricted-scope source address. (But that's not quite so simple a test that we should build it into the resolver library!) Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 17 12:01:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17033; Thu, 17 Apr 1997 11:51:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17022; Thu, 17 Apr 1997 11:50:51 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA23827; Thu, 17 Apr 1997 11:51:52 -0700 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA17475 for ; Thu, 17 Apr 1997 11:59:09 -0700 Received: by mail.noris.net id <34906-8927>; Thu, 17 Apr 1997 20:51:38 +0200 Path: noris.net!not-for-mail From: smurf@work.smurf.noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3539) Re: Host Reachability Advertisement for IPv6 Date: 17 Apr 1997 20:51:16 +0200 Organization: noris network GmbH, Nuernberg, FRG Lines: 63 Message-ID: <5j5rf4$kn4$1@work.smurf.noris.de> References: <9704080245.AA24203@wasted.zk3.dec.com> <860470523.26383@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1778 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3489 Jack McCann writes: > > Matthias Urlichs wrote: > > >My assumption is that the router knows which addresses are permissible > >anycast addresses. Therefore it can send a ND Solicitation message for it > >when a packet arrives. > > But how did the router learn of these anycast addresses? Granted this > could be accomplished with some sort of manual configuration on the > router, but plug-and-play would be nice. I was originally thinking The problem is that an anycast address is something that's not necessarily confined to the local subnetwork. For instance, I might want to make our mail.noris.net an anycast address, with the different mail hosts (which all understand the same set of addresses, of course) living on different subnetworks. On further thought, this is what routing protocols are all about, so it might make more sense to have the hosts which offer anycast addresses multicast these addresses in periodical RIPv6 announcements. They wouldn't have to actually listen to RIPv6 (or any other routing protocol for that matter), so that the host would still be a host, and not a router. > Now if the working group decides that the answer for the multihomed > host is to participate in the routing protocols, and that the answer > for the anycast case is something else TBD, this spec is not needed. > See above... > mechanisms. For purposes of initial discussion though, it felt > cleaner to spec this in terms of separate ICMP messages so as > not to get caught up in the details of tweaking the already > heavily loaded set of ND messages. But we can certainly explore > that avenue. On the other hand, reinventing the wheel and having two slightly- inconsistent versions of essentially the same thing also is something to avoid. I'd rather try to put new ideas into the existing framework first, and do something new only when the 'old' stuff won't fit my needs, than to do something new and then, upon finding out that it's the same thing painted blue, try to mix the yellow and blue paint after the yellow stuff has started drying -- you won't get a nice green that way. ;-) This somewhat reminds me (the analogy is far from perfect (fortunately)) of the N slightly-incompatible versions of the X.25 link layer protocol that exist out there. Let's see, there's X.25, X.75, V.120, I.whatever, and at least one or two others I've forgotten about. All really the same, but slightly incompatible and (of course) documented with no reference towards each other whatsoever, so that the poor implementor has to walk through the documents with a fine-toothed comb to actually find out what are the real differences and what's a compatible improvement. :-( -- Freedom is the right to be wrong, not the right to do wrong. -- John Diefenbaker -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 17 13:01:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA17170; Thu, 17 Apr 1997 12:52:56 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA17163; Thu, 17 Apr 1997 12:52:47 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA08236; Thu, 17 Apr 1997 12:53:53 -0700 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA14738 for ; Thu, 17 Apr 1997 13:01:15 -0700 Received: from rtpdce03.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA36846; Thu, 17 Apr 1997 15:53:37 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id PAA73388; Thu, 17 Apr 1997 15:53:40 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA14928; Thu, 17 Apr 1997 15:53:12 -0400 Message-Id: <9704171953.AA14928@cichlid.raleigh.ibm.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3540) Re: problem with IPv6 group membership messages [was: (ngtrans) Revised draft v6-over-v4] In-Reply-To: Your message of "Thu, 17 Apr 1997 13:06:41 CDT." <199704171806.NAA12991@gungnir.fnal.gov> Date: Thu, 17 Apr 1997 15:53:12 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2297 > > Such an ICMP message could be > > issued when a router attempts to forward a packet that would take the > > source (or destination) address beyond an appropriate scope. > This can't happen with destination addresses, can it? Well, what does a router do today when it is asked to forward a packet to a link-local address? RFC 1884 simply says: Routers MUST not forward any packets with link-local source addresses. I seem to recall that a subsequent discussion concluded it had been a mistake not to say similar things about forwarding packets addressed to a link-local destination across a link other than the one on which the packet was originally received. In such cases, it might be nice to have an ICMP error returned rather than just having the router silently discard the packet. In practice, it used to be the case (and may still be??) that "homeless" packets would get sucked up by a default route. I could easily imagine a site using a site local prefix in which packets addressed to a site-local destination that didn't correspond to an actual site-local prefix that was in use would get sucked up by a default route. Such packets could easily escape the site boundary (though one could argue that in such cases the router won't bother returning ICMP error messages). So maybe such a message isn't really useful. I think I agree with Pedro that the existing "no route" message covers the case here. > With the addition of an "insufficient source scope" message, there > would be an easy test for a target being within a scope or not. Just > send a packet to the target's global address using a > restricted-scope source address. (But that's not quite so simple a > test that we should build it into the resolver library!) An ICMP message would probably be more useful for source addresses, though I'm not sure I like your suggested use. :-) I don't think we want applications doing this. We'll never get them all to do the right thing, so relying on it as a mechanism seems bad. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 17 14:24:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA17312; Thu, 17 Apr 1997 14:14:22 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA17305; Thu, 17 Apr 1997 14:13:43 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA26166; Thu, 17 Apr 1997 14:14:46 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA18156 for ; Thu, 17 Apr 1997 14:22:05 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id OAA13802; Thu, 17 Apr 1997 14:13:19 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <9704171953.AA14928@cichlid.raleigh.ibm.com> References: Your message of "Thu, 17 Apr 1997 13:06:41 CDT." <199704171806.NAA12991@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Apr 1997 14:13:44 -0700 To: Thomas Narten From: Steve Deering Subject: (IPng 3541) Re: problem with IPv6 group membership messages [was: (ngtrans) Revised draft v6-over-v4] Cc: Matt Crawford , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1082 At 11:53 AM -0700 4/17/97, Thomas Narten wrote: > Well, what does a router do today when it is asked to forward a packet > to a link-local address? There's no way to "ask" a router to forward a link-local-destined packet outside of the set of nodes attached to that link -- there is no way to for a link-local destination address to "refer to" or "imply the use of" an interface to a different link -- *except* by using a Routing header to request delivery to a larger-scope intermediate address before reaching an (intermediate or final) link-local destination address. And I seem to recall that we outlawed such use of Routing headers. The ICMP "scope limited" message sounds reasonable to me, for the case of either an insufficiently-scoped source address or an illegal Routing header. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 17 14:29:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA17324; Thu, 17 Apr 1997 14:18:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA17317; Thu, 17 Apr 1997 14:18:02 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA27177; Thu, 17 Apr 1997 14:19:05 -0700 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA20240 for ; Thu, 17 Apr 1997 14:26:09 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id RAA27716; Thu, 17 Apr 1997 17:18:32 -0400 Date: Thu, 17 Apr 1997 17:18:32 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9704171718.ZM27714@seawind.bellcore.com> In-Reply-To: Thomas Narten "(IPng 3540) Re: problem with IPv6 group membership messages [was: (ngtrans) Revised draft v6-over-v4]" (Apr 17, 3:53pm) References: <9704171953.AA14928@cichlid.raleigh.ibm.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: Thomas Narten , Matt Crawford Subject: (IPng 3542) Re: problem with IPv6 group membership messages [was: (ngtrans) Revised draft v6-over-v4] Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 798 > I seem to recall that a subsequent discussion concluded it had been a > mistake not to say similar things about forwarding packets addressed > to a link-local destination across a link other than the one on which > the packet was originally received. In such cases, it might be nice to > have an ICMP error returned rather than just having the router > silently discard the packet. How do we recognize that the packet was meant for another link ? There is no way to tell from the address. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 17 19:08:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA17884; Thu, 17 Apr 1997 18:59:59 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA17877; Thu, 17 Apr 1997 18:59:51 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA01965; Thu, 17 Apr 1997 19:00:56 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA14052 for ; Thu, 17 Apr 1997 19:08:22 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA04831; Thu, 17 Apr 97 18:59:53 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id TAA24023; Thu, 17 Apr 1997 19:01:20 -0700 Date: Thu, 17 Apr 1997 19:01:20 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199704180201.TAA24023@feller.mentat.com> To: deering@cisco.com Subject: (IPng 3543) Re: problem with IPv6 group membership messages [was: (ngtrans) Revised draft v6-over-v4] Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1597 Steve, > > There's no way to "ask" a router to forward a link-local-destined packet > outside of the set of nodes attached to that link -- there is no way to > for a link-local destination address to "refer to" or "imply the use of" > an interface to a different link -- *except* by using a Routing header to > request delivery to a larger-scope intermediate address before reaching > an (intermediate or final) link-local destination address. And I seem > to recall that we outlawed such use of Routing headers. I hope we finally have outlawed this however I don't remember at which meeting this occurred. > > The ICMP "scope limited" message sounds reasonable to me, for the case of > either an insufficiently-scoped source address or an illegal Routing header. > Steve > The new "scope limited" error message may well be worth defining, however, it may be adequate to simply add another code value to the destination un- reachable message. Currently I am using a destination unreachable error message with an administratively prohibited code value to handle these type of illegal address scoping errors. Adding a "illegal next hop scope" code value for the destination unreachable error message might have the small- est foot print on the document. Either way the change is modest. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 17 20:57:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA17984; Thu, 17 Apr 1997 20:48:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA17970; Thu, 17 Apr 1997 20:46:08 -0700 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA13734; Thu, 17 Apr 1997 20:47:15 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA11305; Thu, 17 Apr 1997 20:54:41 -0700 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA23581; Thu, 17 Apr 1997 23:40:30 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31738; Thu, 17 Apr 1997 23:40:29 -0400 Message-Id: <9704180340.AA31738@wasted.zk3.dec.com> To: ngtrans@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3544) Re: problem with IPv6 group membership messages [was: (ngtrans) Revised draft v6-over-v4] In-Reply-To: Your message of "Thu, 17 Apr 97 11:09:23 -0300." <9704171509.AA16220@cichlid.raleigh.ibm.com> Date: Thu, 17 Apr 97 23:40:29 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 374 thomas, i think it would be useful... matt, also IGMP is heading for version 3.... /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Apr 17 23:02:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA18082; Thu, 17 Apr 1997 22:54:05 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA18075; Thu, 17 Apr 1997 22:53:55 -0700 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA25836; Thu, 17 Apr 1997 22:55:01 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id XAA11183 for ; Thu, 17 Apr 1997 23:02:29 -0700 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id BAA31772; Fri, 18 Apr 1997 01:46:10 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA02636; Fri, 18 Apr 1997 01:46:08 -0400 Message-Id: <9704180546.AA02636@wasted.zk3.dec.com> To: "Ping Pan" Cc: , , Subject: (IPng 3545) Re: Flow Label In-Reply-To: Your message of "Thu, 17 Apr 97 00:00:36 EDT." <9704170400.AA17324@wildbird.watson.ibm.com> Date: Fri, 18 Apr 97 01:46:08 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3230 Ping Pan, >The flow label for an application is generated by a source, but I think it >could be changed by the routers along the way. Right? Or is it a >requirement in IPng that flow-label must be the same end-to-end? >From the beginning we have had the belief that flows should be able to support end-to-end connections. I don't think this should ever change. But with the advent of IP/Switching the routing area would like a means to do a very fast lookup to know if the IP layer can be avoided and the packet can be switched expediently at Layer 2. I do think this is a good idea IMO (in my opinion). Lots of IP/Switch wars going on in the routing area and as a host kind of guy I await their wisdom (IBM is proposing Aris). But what ever they decide when it comes back to our game in IPng if the eggs are broken and we don't have end-to-end flows the battle will rage and long discussions. But now that we are not assuming priority bits and there may be away for the source to note that this flow can be altered by the router. Fred Baker has a proposal to note a flow for TAGs but I don't know if it has consensus. I think its cool but do want hosts to participate TAGs as I believe the integration of hosts with tag switching is a win for the future. >In case of IP-switching, flow label could essentially be a label (or tag) >defined by MPLS. As a result, a flow label could be changed at every hop >between a source and a destination. Does it make sense at all? :-) Not to me. If the host puts bits in the flow label (that do not state that this flow is for a TAG) they should be honored if "possible" all the way to the destination address. But I don't know what MPLS means as an acroynm so your maybe be ahead of me? What is it? I believe flows should be defined for multiple reasons and honored: 1. end-to-end 2. TAG or ??? for IP/Switching 3. RSVP We have here a serious engineering trade off to make here. IP/Switching I believe is the future. That needs flows. But also I can see many reasons for applications to want to define flows. But if the first switch in a network lets say sources the flow to the host thru some form of negotiation at layer 2. Will that flow work downstream with the next switch in the network. Maybe the TAG switching wars are solving this problem. But what I don't want to see is them to come over to IPng and eat our lunch so the applications don't have an end-to-end flow because they need to steal the flow label from IPng WG 1883. There is a culture and business issue here that rages on a continum which is router view vs host view of the world. As you pointed out in your first mail the flow field is quite large and maybe it can be parsed up to appease both views of the world. I don't have time to do this but I would think we could apply a shift operation on the flow for each type of mechanism needed and then the flow could be used for all scenarios. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Apr 18 03:27:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA18177; Fri, 18 Apr 1997 03:18:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA18170; Fri, 18 Apr 1997 03:18:10 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA16187; Fri, 18 Apr 1997 03:19:17 -0700 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA11971 for ; Fri, 18 Apr 1997 03:26:43 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 18 Apr 1997 11:17:48 +0100 X-Mailer: exmh version 1.6.6 3/24/96 To: bound@zk3.dec.com cc: ipng Subject: (IPng 3546) Re: Flow Label In-reply-to: Your message of "Fri, 18 Apr 1997 01:46:08 EDT." <9704180546.AA02636@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Apr 1997 11:17:46 +0100 Message-ID: <6050.861358666@cs.ucl.ac.uk> From: Zheng Wang Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1227 > >The flow label for an application is generated by a source, but I think it > >could be changed by the routers along the way. Right? Or is it a > >requirement in IPng that flow-label must be the same end-to-end? This has been discussed many times before. Hop-by-hop flow-label is difficult to do over LAN. Steve Deering will no doubt ask his question again:-) > We have here a serious engineering trade off to make here. IP/Switching > I believe is the future. That needs flows. But also I can see many > reasons for applications to want to define flows. It is important to note that the current MPLS proposals (tag/aris) have separate mechanisms for destination-based best effort routes and QoS explicit routes. The ones that most people are talking about are those for destination-based routes for current best efforts traffic. If applications set up flows, they can also be mapped to Level 2 as an explicit route. Cheers Zheng ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Apr 18 07:02:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA18353; Fri, 18 Apr 1997 06:52:53 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA18346; Fri, 18 Apr 1997 06:52:41 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA08359; Fri, 18 Apr 1997 06:53:49 -0700 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA12445 for ; Fri, 18 Apr 1997 07:01:21 -0700 Received: from rtpmail03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA31966; Fri, 18 Apr 1997 09:50:51 -0400 Received: from vision.raleigh.ibm.com (vision.raleigh.ibm.com [9.37.177.224]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA21472; Fri, 18 Apr 1997 09:50:51 -0400 Received: by vision.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23984; Fri, 18 Apr 1997 09:50:51 -0400 Message-Id: <9704181350.AA23984@vision.raleigh.ibm.com> X-Mailer: exmh version 1.6.9 8/22/96 To: bound@zk3.dec.com Cc: "Ping Pan" , asgari@rrl.co.uk, ipng@sunroof.eng.sun.com Reply-To: slblake@vnet.ibm.com Subject: (IPng 3547) Re: Flow Label In-Reply-To: Your message of "Fri, 18 Apr 1997 01:46:08 EDT." <9704180546.AA02636@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Apr 1997 09:50:49 EDT From: Steven L Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1924 Jim Bound wrote: > Ping Pan wrote: > >In case of IP-switching, flow label could essentially be a label (or tag) > >defined by MPLS. As a result, a flow label could be changed at every hop > >between a source and a destination. Does it make sense at all? :-) > > Not to me. If the host puts bits in the flow label (that do not state > that this flow is for a TAG) they should be honored if "possible" all > the way to the destination address. Right on! > But I don't know what MPLS means as an acroynm so your maybe be ahead of > me? What is it? Multi-Protocol Label Switching > I believe flows should be defined for multiple reasons and honored: > > 1. end-to-end > 2. TAG or ??? for IP/Switching > 3. RSVP RSVP is just another application of end-to-end flows. Also, because RSVP set-up is a two-pass operation, I think it would be very difficult to signal the flow-label in the RSVP filterspec while allowing it to be swapped hop-by-hop unless swapping and RSVP was a mandatory operation end-to-end (and was coordinated with the RSVP signaling). As an observation, with global ESDs, a flow can be uniquely identified as the combination of the flow-label + the source ESD. This is essentially an 11-byte label (rather than 19) which globally unique. /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Steven L. Blake slblake@vnet.ibm.com | | Internetworking Technology (919)254-2030 (work) | | IBM Networking Hardware Division (919)254-5483 (fax) | | "You like the 'Net? You ain't seen nothin' yet!" | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Apr 18 08:41:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA18452; Fri, 18 Apr 1997 08:32:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA18445; Fri, 18 Apr 1997 08:31:55 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA03166; Fri, 18 Apr 1997 08:33:04 -0700 Received: from sun10.vsz.bme.hu (sun10.vsz.bme.hu [152.66.77.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA27771 for ; Fri, 18 Apr 1997 08:40:32 -0700 Received: from cp2907.dial.bme.hu (line45.dial.bme.hu [152.66.142.45]) by sun10.vsz.bme.hu (8.8.4/8.7.3) with ESMTP id RAA20552 for ; Fri, 18 Apr 1997 17:32:30 +0200 (MET DST) Message-Id: <199704181532.RAA20552@sun10.vsz.bme.hu> From: "Panos Peristeropoulos" To: Subject: (IPng 3548) IPng Simulator Date: Thu, 17 Apr 1997 15:28:23 +0200 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 492 To whoever can help, I am looking for a simulator in C of IPv6 packet structure and how addressing works. If someone has any idea where to find one please mail me at : s6739pan@sun10.vsz.bme.hu Thanks, Panos ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Apr 18 08:50:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA18461; Fri, 18 Apr 1997 08:39:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA18454; Fri, 18 Apr 1997 08:38:49 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA04402; Fri, 18 Apr 1997 08:39:58 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA01017 for ; Fri, 18 Apr 1997 08:47:24 -0700 Received: from gungnir.fnal.gov ("port 34814"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IHUJB0H6SE000MU7@FNAL.FNAL.GOV>; Fri, 18 Apr 1997 10:39:45 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA15508; Fri, 18 Apr 1997 10:37:36 -0500 Date: Fri, 18 Apr 1997 10:37:36 -0500 From: Matt Crawford Subject: (IPng 3549) Re: problem with IPv6 group membership messages [was: (ngtrans) Revised draft v6-over-v4] In-reply-to: "17 Apr 1997 19:01:20 PDT." <"199704180201.TAA24023"@feller.mentat.com> To: thartric@mentat.com (Tim Hartrick) Cc: deering@cisco.com, ipng@sunroof.eng.sun.com Message-id: <199704181537.KAA15508@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ > The ICMP "scope limited" message sounds reasonable to me, for the case > > of either an insufficiently-scoped source address or an illegal > > Routing header. > > ... Currently I am using a destination unreachable error > message with an administratively prohibited code value to handle these type > of illegal address scoping errors. That doesn't seem like a right use for this code, since it's architecturally prohibited, not administratively. (That is, it's not a local choice.) > Adding a "illegal next hop scope" code > value for the destination unreachable error message might have the small- > est foot print on the document. Or use "parameter problem" for an illegal source route, using either code=0 or a new code, and use "destination unreachable" with a new code for the case of a source address of insufficient scope. (But I would say that sending packets between addresses of different scope is legal when the two endpoints are within the "smaller" scope.) Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Apr 18 11:24:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA18830; Fri, 18 Apr 1997 11:13:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA18823; Fri, 18 Apr 1997 11:13:45 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA11573; Fri, 18 Apr 1997 11:14:53 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA15007 for ; Fri, 18 Apr 1997 11:22:26 -0700 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA20849; Fri, 18 Apr 1997 13:38:38 -0400 (EDT) Received: by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA20775; Fri, 18 Apr 1997 13:34:54 -0400 Date: Fri, 18 Apr 1997 13:34:54 -0400 From: Jack McCann Message-Id: <9704181734.AA20775@wasted.zk3.dec.com> To: smurf@work.smurf.noris.de Subject: (IPng 3550) Re: Host Reachability Advertisement for IPv6 Cc: ipng@sunroof.eng.sun.com, mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2026 Matthias Urlichs wrote: >The problem is that an anycast address is something that's not necessarily >confined to the local subnetwork. For instance, I might want to make our >mail.noris.net an anycast address, with the different mail hosts (which all >understand the same set of addresses, of course) living on different >subnetworks. > >On further thought, this is what routing protocols are all about, so it >might make more sense to have the hosts which offer anycast addresses >multicast these addresses in periodical RIPv6 announcements. They wouldn't >have to actually listen to RIPv6 (or any other routing protocol for that >matter), so that the host would still be a host, and not a router. Ah, you strike to the heart of the matter. Yes, the host could send routing protocol messages, in which case we don't need HRA. The feedback I got in several conversations at Memphis IETF as well as in some offline email was that people preferred the HRA (or something like it, i.e. a generic mechanism) over the routing protocols (e.g. RIPng) for this purpose. >> mechanisms. For purposes of initial discussion though, it felt=20 >> cleaner to spec this in terms of separate ICMP messages so as=20 >> not to get caught up in the details of tweaking the already >> heavily loaded set of ND messages. But we can certainly explore >> that avenue. > >On the other hand, reinventing the wheel and having two slightly- >inconsistent versions of essentially the same thing also is something to >avoid. I'd rather try to put new ideas into the existing framework first, >and do something new only when the 'old' stuff won't fit my needs, than t= Yes, I'll explore this avenue in the next draft, then we can debate the bits some more. - Jack ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Apr 18 11:53:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA18945; Fri, 18 Apr 1997 11:44:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA18938; Fri, 18 Apr 1997 11:44:12 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA18684; Fri, 18 Apr 1997 11:45:20 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA28766 for ; Fri, 18 Apr 1997 11:52:55 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA08904; Fri, 18 Apr 97 11:43:49 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id LAA24961; Fri, 18 Apr 1997 11:45:19 -0700 Date: Fri, 18 Apr 1997 11:45:19 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199704181845.LAA24961@feller.mentat.com> To: crawdad@FNAL.GOV Subject: (IPng 3551) Re: problem with IPv6 group membership messages [was: (ngtrans) Revised draft v6-over-v4] Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1457 Matt, > > > > ... Currently I am using a destination unreachable error > > message with an administratively prohibited code value to handle these type > > of illegal address scoping errors. > > That doesn't seem like a right use for this code, since it's > architecturally prohibited, not administratively. (That is, it's > not a local choice.) > Carpenters use the tools they have. If there was a better choice I would use it. Hopefully we can create a richer set of tools. > > Adding a "illegal next hop scope" code > > value for the destination unreachable error message might have the small- > > est foot print on the document. > > Or use "parameter problem" for an illegal source route, using either > code=0 or a new code, and use "destination unreachable" with a new > code for the case of a source address of insufficient scope. (But I > would say that sending packets between addresses of different scope > is legal when the two endpoints are within the "smaller" scope.) > If we need to distinguish between illegally scoped sources and illegally scoped destinations I would suggest a new destination unreachable codes for each case. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Apr 18 19:01:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA20053; Fri, 18 Apr 1997 18:52:54 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA20046; Fri, 18 Apr 1997 18:52:46 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA08621; Fri, 18 Apr 1997 18:53:53 -0700 Received: from INET-03-IMC.microsoft.com (mail3.microsoft.com [131.107.3.23]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id TAA25456 for ; Fri, 18 Apr 1997 19:01:33 -0700 Received: by INET-03-IMC with Internet Mail Service (5.0.1458.14) id ; Fri, 18 Apr 1997 18:54:34 -0700 Message-ID: From: Richard Draves To: "'IPng List'" Subject: (IPng 3552) ND questions Date: Fri, 18 Apr 1997 18:53:51 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.14) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2053 Reading RFC 1970... 1) Section 4.4, describing NA's, says that the target link-layer address option MUST be present. However section 7.1.2, describing NA validation, does not require the target link-layer address option. And section 7.2.4 says that the option SHOULD NOT be included in some situations. 2) Section 7.2.5's description of the Solicited flag is a little confusing... it says "If the target's neighbor cache entry is in any state other than INCOMPLETE when the advertisement is received, the advertisement's Solicited flag setting determines what the entry's new state should be." But then the described behavior for the Solicited flag is exactly the same as the description two paragraphs earlier of its effect on an INCOMPLETE entry. 3) Section 7.2.5 says that when an unsolicited NA is received, the neighbor cache entry MUST be set to the STALE state. This seems wrong to me. Suppose there is a host A that periodically multicasts unsolicited NA's to everybody on the link. Suppose there is another host B on the link that hears A's multicasts but B does not have reachability to A. Now the NUD protocol on host B will not work correctly - the neighbor cache entry for A will keep having its state set back to STALE, it will never progress all the way through the DELAY and PROBE states to discover the unreachability. Perhaps it should be, that an unsolicited NA that updates the cached link-layer address (ie the state was INCOMPLETE or the Override flag was set and the new address is actually different) changes the state to STALE, but otherwise it doesn't change the state. The description of the STALE state in section 7.3.2 hints at this. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 21 12:46:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA01386; Mon, 21 Apr 1997 12:38:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA01379; Mon, 21 Apr 1997 12:37:51 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA24421; Mon, 21 Apr 1997 12:39:01 -0700 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA06115 for ; Mon, 21 Apr 1997 12:47:15 -0700 Received: from mailhub2.watson.ibm.com (mailhub2.watson.ibm.com [9.2.250.15]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id PAA10640; Mon, 21 Apr 1997 15:26:29 -0400 Received: from wildbird.watson.ibm.com (wildbird.watson.ibm.com [9.2.23.71]) by mailhub2.watson.ibm.com (8.8.2/01-15-97) with SMTP id PAA21222; Mon, 21 Apr 1997 15:36:12 -0400 Received: from chowchow.watson.ibm.com by wildbird.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA18512; Mon, 21 Apr 1997 15:34:56 -0400 Message-Id: <9704211934.AA18512@wildbird.watson.ibm.com> From: "Ping Pan" To: Cc: , , Subject: (IPng 3553) Re: Flow Label Date: Mon, 21 Apr 1997 15:34:48 -0400 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2910 Jim: Thanks for the feedback. What I had in mind is the following scenario: +----+ label-1 label-1/label-2 +----+ | S1 |--->----+ +--->--------| R1 | +----+ | | +----+ | | | label-1 | +------+ -----> +------+ | RT-A |-------------| RT-B | +------+ -----> +------+ | label-2 | | | | | +----+ | | +----+ | S2 |--->----+ +---->-------| R2 | +----+ label-2 label-1/label-2 +----+ S1 and S2 send data to a multicast group with receivers R1 and R2. They have flow labels, label-1 and label-2 respectively. Routers RT-A and RT-B store both labels in their forwarding tables. Now, in case of shared reservation, would it be nice to have a single flow-label between RT-A and RT-B, as shown below? +----+ label-1 label-5 +----+ | S1 |--->----+ +--->--------| R1 | +----+ | | +----+ | | | label-3 | +------+ -----> +------+ | RT-A |-------------| RT-B | +------+ +------+ | | | | | | +----+ | | +----+ | S2 |--->----+ +---->-------| R2 | +----+ label-2 label-4 +----+ After flow merging, RT-A can just assign a new flow-label, label-3, for both streams from S1 and S2. In RT-B, instead of managing both label entries in the classifier, and mapping a single shared reservation state to two filter entries, RT-B can just use the label-3 and for data forwarding. I also think that the processing overhead in R1 and R2 can be simplified as a result. How is flow-label related to MPLS? Well, in case of ATM and Frame Relay, the flow label between RT-A and RT-B can a VCI, or a DLCI, or a tunneling ID, etc. Let's leave detailed MPLS/IPng interface issues in the future, please. :-) I am not proposing a rewrite of the existing spec. Rather, I just wish the specification can be flexible enough for design and development in the future. Thanks! Ping -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 21 13:03:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA01423; Mon, 21 Apr 1997 12:53:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA01416; Mon, 21 Apr 1997 12:53:44 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA29083; Mon, 21 Apr 1997 12:54:47 -0700 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA12344 for ; Mon, 21 Apr 1997 13:02:42 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id PAA13598; Mon, 21 Apr 1997 15:42:02 -0400 Received: from wildbird.watson.ibm.com (wildbird.watson.ibm.com [9.2.23.71]) by mailhub1.watson.ibm.com (8.8.2/01-15-97) with SMTP id PAA23983; Mon, 21 Apr 1997 15:51:46 -0400 Received: from chowchow.watson.ibm.com by wildbird.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA30098; Mon, 21 Apr 1997 15:51:41 -0400 Message-Id: <9704211951.AA30098@wildbird.watson.ibm.com> From: "Ping Pan" To: , Cc: , Subject: (IPng 3554) Re: Flow Label Date: Mon, 21 Apr 1997 15:51:33 -0400 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1287 Steve: > > >In case of IP-switching, flow label could essentially be a label (or tag) > > >defined by MPLS. As a result, a flow label could be changed at every hop > > >between a source and a destination. Does it make sense at all? :-) > > > > Not to me. If the host puts bits in the flow label (that do not state > > that this flow is for a TAG) they should be honored if "possible" all > > the way to the destination address. > > Right on! I think too much talk of IP-switching in this mailing-list may give people heart attacks! :-) Anyway, I just want to remind you that MPLS is meant for enhancing IP forwarding functionality in ROUTERS. As being illustrated by Ipsilon, it improves throughput in ATM switches. But I don't believe labeling should be worried by end stations for the time being. Let's wait until MPLS spec is finalized before relating IPng with it. What do you think? Later! Ping -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 21 15:04:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA01719; Mon, 21 Apr 1997 14:56:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA01712; Mon, 21 Apr 1997 14:56:20 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA01675; Mon, 21 Apr 1997 14:57:32 -0700 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA04865 for ; Mon, 21 Apr 1997 15:05:49 -0700 Received: from rtpmail02.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA49074; Mon, 21 Apr 1997 17:57:27 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA18968; Mon, 21 Apr 1997 17:57:30 -0400 Received: from lig32-224-57-11.us.lig-dial.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15034; Mon, 21 Apr 1997 17:56:58 -0400 Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id RAA01892; Mon, 21 Apr 1997 17:57:01 -0400 Message-Id: <199704212157.RAA01892@hygro.raleigh.ibm.com> To: Richard Draves Cc: "'IPng List'" Subject: (IPng 3555) Re: ND questions In-Reply-To: Your message of "Fri, 18 Apr 1997 18:53:51 PDT." Date: Mon, 21 Apr 1997 17:57:01 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2882 Richard, Thanks for the comments. We'll add them to the queue for the updated draft. > 1) Section 4.4, describing NA's, says that the target link-layer address > option MUST be present. Seems some wordsmithing is needed. Saying that the link-layer address MUST always be included is too strong. > However section 7.1.2, describing NA validation, does not require > the target link-layer address option. And section 7.2.4 says that > the option SHOULD NOT be included in some situations. I think that we added this relatively late in the development of the spec as a micro-optimization. We apparently missed adjusting the text in 4.4 > 2) Section 7.2.5's description of the Solicited flag is a little > confusing... I must confess you aren't the first to say this... :-( > it says "If the target's neighbor cache entry is in any > state other than INCOMPLETE when the advertisement is received, the > advertisement's Solicited flag setting determines what the entry's new > state should be." But then the described behavior for the Solicited flag > is exactly the same as the description two paragraphs earlier of its > effect on an INCOMPLETE entry. There does appear to be a bit of redundancy here. > 3) Section 7.2.5 says that when an unsolicited NA is received, the > neighbor cache entry MUST be set to the STALE state. This seems wrong to > me. > Suppose there is a host A that periodically multicasts unsolicited NA's > to everybody on the link. Suppose there is another host B on the link > that hears A's multicasts but B does not have reachability to A. Now the > NUD protocol on host B will not work correctly - the neighbor cache > entry for A will keep having its state set back to STALE, it will never > progress all the way through the DELAY and PROBE states to discover the > unreachability. > Perhaps it should be, that an unsolicited NA that updates the cached > link-layer address (ie the state was INCOMPLETE or the Override flag was > set and the new address is actually different) changes the state to > STALE, but otherwise it doesn't change the state. The description of the > STALE state in section 7.3.2 hints at this. Something like this would seem necessary to cover this case. Erik: did we consider something like this? I know we discussed having some cases that involved comparing the received address to the cached address, but were a bit concerned about getting down to this level of detail. I don't recall now whether this was one of them or not. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 22 07:24:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA02661; Tue, 22 Apr 1997 07:16:45 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA02654; Tue, 22 Apr 1997 07:16:33 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA25323; Tue, 22 Apr 1997 07:17:45 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA29845 for ; Tue, 22 Apr 1997 07:26:12 -0700 Received: from ietf.ietf.org by ietf.org id aa26736; 22 Apr 97 9:40 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3556) I-D ACTION:draft-ietf-ipngwg-ipv6router-alert-01.txt Date: Tue, 22 Apr 1997 09:40:10 -0400 Message-ID: <9704220940.aa26736@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3787 --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 Router Alert Option Author(s) : D. Katz, R. Atkinson Filename : draft-ietf-ipngwg-ipv6router-alert-01.txt Pages : 4 Date : 04/21/1997 This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for protocols addressed to a destination but also require special processing in routers along the path. 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-ipv6router-alert-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6router-alert-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu 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-ipv6router-alert-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. 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: <19970421173511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6router-alert-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6router-alert-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970421173511.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 23 18:06:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04218; Wed, 23 Apr 1997 17:58:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04211; Wed, 23 Apr 1997 17:58:40 -0700 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA24719; Wed, 23 Apr 1997 17:59:51 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA28213 for ; Wed, 23 Apr 1997 18:08:40 -0700 Received: from spruce.fedex.net (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA21049; Wed, 23 Apr 1997 17:59:51 -0700 Message-Id: <3.0.1.32.19970423180050.00717194@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 23 Apr 1997 18:00:50 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3558) IPng Working Group Minutes from Memphis IETF Cc: minutes@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 49126 Attached are the minutes from the IPng sessions at the Memphis IETF. Please send me corrections. Bob ______cut_here________________________________________________________ IPng Meeting Memphis IETF April 10 & 11, 1997 Bob Hinden, Ipsilon Networks / co-chair Steve Deering, Cisco Systems / co-chair Minutes taken and edited by Bob Hinden ------------------------------------------------------------------------ Agenda ------- Thursday 1-3pm Introduction and Bash Agenda / Steve Deering (5 min) Document Status / Bob Hinden (5 min) Review of Action Items for Previous Meetings / Bob Hinden (5 min) Priority Field / Steve Deering (15 min) Conclusions/Results from Interim Meeting / (80 min) Meeting Summary / Bob Hinden (5 min) Revision to Provider Based Addressing / Bob Hinden (10 min) Analysis of GSE Proposal / Matt Crawford and others (25 min) IPv6 over Ethernet & FDDI / Matt Crawford (5 min) IPv6 over PPP / Dimitry Haskin (5 min) IPv6 over ARCNET and LocalTalk / Bob Hinden (5 min) The Use of End System Designators in IPv6 / Matt Thomas (5 min) Routing Goop and AAAA Records in DNS / Jim Bound (5 min) Numbering point-to-point and boundary links / John Stewart (5 min) ESD Pro and Con's / Thomas Narten (10 min) Friday 9-11:30am Conclusions/Results from Interim Meeting Continued / 60min Solicited Node Definition / Steve Deering (15 min) IPv6 Tunneling Spec and GRE / Steve Deering (15 min) Router Renumbering for IPv6 / Matt Crawford & Bob Hinden (15 min) Advertising site prefixes in RAs / Erik Nordmark (10 min) Prefix Notation / Bob Hinden (5 min) Who Are You / Matt Crawford (5 min) Inter-Domain Routing Status / Bob Hinden (5 min) ND Zero Lifetime advertisement issue / Thomas Narten (5 min) Advanced API Spec / Matt Thomas (5 min) Moving Base IPv6 Specs to Draft Standard / Steve Deering (5 min) Wrap Up and Action Items / Bob Hinden (5 min) Thursday 1-3pm -------------- Introduction and Bash Agenda / Steve Deering -------------------------------------------- Steve Deering introduced meeting. Asked for agenda changes. Request to add slot for Mobile IP and an SNMP issue Document Status / Bob Hinden ---------------------------- The following RFC's were published as Proposed Standard: - An IPv6 Provider-Based Unicast Address Format , RFC 2073 - RIPng for IPv6 , RFC 2080 The IESG Approved for Informational RFC: - Basic Socket Interface Extensions for IPv6 IETF Last Calls were completed for: - Generic Packet Tunneling in IPv6 Specification The IPng document editor submitted to IESG for IETF Last Call: - TCP and UDP over IPv6 Jumbograms Working Group Last Call were completed for: - Header Compression for IPv6 - IPv6 Router Alert Option These will be advance as soon as updated Internet Drafts are published based on the comments received during the last calls. Review of Action Items for Previous Meetings / Bob Hinden --------------------------------------------------------- Action Items from San Jose IETF ------------------------------- Steve Deering will write up description of proposed changes to Priority Field and send to IPng list. - OBE based on discussion on IPng list. Need to get closure at Memphis meeting. On Agenda for Memphis. Document editor will send email to IANA to add default hop limit of 64 parameter to IANA registry for IPv6 defaults. - Sent on 12/12/96. Can't find it on IANA web site. - Resent on 3/12/97. Thomas Narten owns getting "IPv6 over Token Ring" issues resolved. - Working group last call will be done when new Internet Draft is out. Document editor will do a working group last call on BSD API. Goal is to publish an informational RFC. - Sent on 12/10/96. Working group last call ended 12/24/96. A number of comments were received. Will advance to IESG once a new internet draft is available based on comments. - Done. Submitted to IESG, IESG approved as Informational RFC. Document editor will submit Tunneling Spec to IESG for proposed standard. - Sent request to IESG on 12/10/96. IESG last call sent on 12/30/96 which ended on 1/17/97. Many comments received. IESG restarted last call for this document and two GRE documents on IPv4 tunneling. - Steve Deering currently reviewing GRE documents and will respond to IESG last call. On Agenda for Memphis. Document editor will do a working group last call on Header Compression specification. - Sent on 12/10/96. Working group last call ended 12/24/96. Comments received from Thomas Narten. Once comments resolved (and new draft published) document editor will send to IESG. Hinden and Deering will propose to the mailing list that the ND solicited node address be changed to fit into a longer prefix - On Agenda for Memphis. Steve Deering expected to have a draft on "Multihoming / Source Address Selection" in early 1997. - Open. Document to do a working group last call on IPv6 Router Alert Option. - Last call sent on 12/17/96. Working group last call ended on 12/31/96. One minor comment received. Document editor will send to IESG once new ID is published. Chairs to generate a list of changes which are being considered for the base specifications. - Needs to be done. Hold an interim meeting to discuss the 8+8 proposal. - Done. Held on Feb 27, 28, 1997. Bob Hinden write internet draft on his Router and Networking Renumbering proposal. - Matt Crawford volunteered to write draft. - Done. Draft written and on Memphis agenda. Dimitry Haskin and Dave Katz to write a draft proposing adding an option to BGP4 to carry IPv6 interdomain routes. - Drafts written for BGP+ and BGP5. IDR discussed. Compromise discussions underway. Bob Hinden to add to the addressing architecture document prefix notation. - Work underway. Expect to have new draft by ID deadline. - Done. Draft published. Thomas Narten to include in next update of neighbor discovery a rule to silently drop non-DAD packets which use the unspecified address as the source of the packet. - Open Action Items from Interim Meeting --------------------------------- Minutes for Interim meeting, and meeting report / Bob Hinden - Done. Sent to IPng list and installed on IPng web site. "WhoAreYou" ICMP Message / Matt Crawford - Draft missed ID deadline. Sent to IPng list and on Memphis agenda. Modify Link Name Draft / Dan Harrington - Update underway. Synthesized AAAA Replies / Jim Bound , Mike O'Dell - Done. Jim Bound write draft. Revise Provider Based Addressing Architecture / Mike O'Dell and Bob Hinden - Work started. Proposal on Memphis agenda. Unique ID's (ESD's) Assignment / Mike O'Dell, Allison Mankin, Matt Thomas - Done. Matt Thomas submitted draft. On agenda. Experimental Addresses Rewrite: Bob Hinden - Waiting for Provider Unicast Formats to settle a bit more. IPoverEthernet/FDDI / Matt Crawford - Done. Internet Draft published. IPoverPPP / Dimitry Haskin - Done. Internet Draft published. Lessons from meeting / Matt Crawford, Allison Mankin, Thomas Narten, John Stewart, Lixia Zhang - Done. Internet Draft published. Discussion on agenda. Priority Field / Steve Deering ------------------------------ Discussion on mailing list, but did not reach consensus. Current proposal is: - Declare that 4 bits of Priority are rewritable by routers/ISPs for private purposes (and exclude from authentication header). - Priority bits have no significance to receivers - Convention: Sender sets low order bit to mean interactive traffic. o Delay more important than throughput o Suggests that routers/ISPs use other bits before touching the "interactive bit". o Affects queuing only, not routing (since re-writable). After email discussion Deering still thinks that proposal is correct. Charlie Perkins: If left undefined and people do use them, it might be hard to define them later. Nordmark: Could anyone modify in transit? Yes. Narten: How many bits do router vendors want? Also, thinks it is important to not have interactive bit rewritten to preserve function. John Stewart: Thinks one bit is enough for interactive traffic, but more bits will be needed for additional services. Thinks making bits an integer field instead of individual bits would be better. IPSEC had proposed not including the whole first four bytes of the IPv6 header from authentication. This is in the latest AH draft. Would give us more flexibility. John Stewart: If we define now, would preclude different usage in future. Nordmark: Should define what host does to these bits when sending, and how it should handle these bits when receiving. Need to do this first. Mike O'Dell, likes the proposal. Thinks it is best he had heard in discussion. Changing version field will break header compression. Matt C. Good to define default action for hosts now, routers could use them differently later. Need this to define application behavior. Deering took poll. More were in favor. Group will go forward with this proposal in next version of base IPng specification. Important to make sure AH is consistent. First 32 bits of header should not be included in authentication computation. Conclusions/Results from Interim Meeting ---------------------------------------- Meeting Summary / Bob Hinden ---------------------------- Deering talked. Showed table of results from interim meeting. Summarized into the following table: Legend: X = do not adopt Y = adopt * = needs more study X Rewriting by routers X Name for Sites & Mapping to/from RG * ESD's Y RG structure * PCB Lookup rules X Pseudo checksum rules Y 8byte node ID Y Two faced DNS for site local Y Resolve DNS via ICMP "Who Are You" Y DNS response synthesis * Auto-Injection of prefixes into sites Y Inter-provider partition healing protocol(s) * Use only site-local prefixes for intra-site communication * How much of address is AH * Flow identification change * SA Ident change Shows which items were agreed to do, not to do, and which need more study. Revision to Provider Based Addressing / Bob Hinden -------------------------------------------------- New draft will be called "Aggregation-Based Unicast Address Formats". This was an output of the Interim meeting. This will replace RFC-2073 "An IPv6 Provider Based Unicast Address Format" Goal is to provide additional flexibility based on O'Dell GSE Draft. Changes include: - Remove Registry field - Base Design around Large Structures Structures _______________ _______________ / \+--------------+/ \ ( P1 ) +----+ ( P3 ) +\_______________/ | |----+\_______________/ | +--| X | | _______________ / | |-+ _______________ +/ \+ +-+--+ \ / \ ( P2 ) / \ +( P4 ) \_______________/ / \ \_______________/ | / \ | | | / | | | | / | | | _|_ _/_ _|_ _|_ _|_ / \ / \ / \ / \ / \ ( S.A ) ( S.B ) ( P5 ) ( S.D ) ( P6 ) \___/ \___/ \___/ \___/ \___/ | / \ _|_ _/_ \ ___ / \ / \ +-/ \ ( S.E ) ( S.F ) ( S.G ) \___/ \___/ \___/ The aggregation based address format is designed to support both long haul providers (shown as P1, P2, P3, and P4), interchanges (shown as X ), multiple levels of subscribers (shown as S.x) and providers (shown at P5 and P6). Interchanges (unlike current NAP, FIX, etc. connection points) will allocate IPv6 addresses. Providers who connect to these interchanges will also subscribe for long haul service from one or more long haul providers and achieve a certain degree of addressing independence from long haul transit providers. Format | 3 | 13 | 32 bits | 16 bits | 64 bits | +---+-------+---------------+-----------+-----------------------+ |010| TLA | NLA* | Subnet | Interface ID | +---+-------+---------------+-----------+-----------------------+ <-----Public Topology-------> Site <-----------> Topology <--Interface Identifier-> Fields - FP Format Prefix (010) - TLA Top Level Aggregator - NLA* Next Level Aggregator(s) - SUBNET Site Specific Topology - INTERFACE ID Interface Identifier Top Level Aggregator - Top Level in Addressing Hierarchy - Assigned to Organizations providing Public Transit Topology o Not to Private Transit Topology - Supports 2^^13 TLA's (8K) o Additional available by using another FP - IANA Assigns Blocks to Registries o Registries assign to TLA's o Registries get more from IANA Next Level Aggregator - Used by TLA's to o Create TLA Hierarchy o Identify Sites - TLA's may support NLA's in their own Site ID space - NLA's may support NLA's in their... - Works exactly like CIDR delegation - TLA's assume registry duties for NLA's NLA* +-----+------------------+--------+-----------------+ |NLA1 | Site | Subnet | Interface ID | +-----+------------------+--------+-----------------+ +-----+------------+--------+-----------------+ |NLA2 | Site | Subnet | Interface ID | +-----+------------+--------+-----------------+ +-----+------+--------+-----------------+ |NLA3 | Site | Subnet | Interface ID | +-----+------+--------+-----------------+ Proposal was generally well accepted. Some discussion about fixed boundaries in these addresses, particularly about the TLA boundary. This was clarified that it was only there for address allocation and was not visible by the routing system. Bob Hinden will write a internet draft for "Aggregation-Based Unicast Address Formats". Analysis of GSE Proposal / Matt Crawford and others ---------------------------------------------------- Most topics will be outcome of PAL1, some were the result of additional analysis. Motivation for GSE - Renumbering must happen to achieve and maintain the necessary aggregation to keep routing computation feasible. o Make intra-site communication impervious to global renumbering o Make renumbering easier to do - Put the routing cost of multi-homing onto the parties involved. GSE Mechanisms - Conceal global-scope prefixes from the sites' interiors. o Insert source prefix at exit/remove destination prefix at entrance - Fixed boundaries in addresses - Modifications to checksum, PCB/SA lookup rules - Globally unique identifiers for nodes o DNS magic - Two-faced DNS - AAAA synthesis from parts - AAAA synthesis from parts - RG upward indirection - Multiple providers set up fallback tunnels to create the illusion that failed links are up o Hole-punching" is confined to consenting parties. Major Difficulties - Due to host ignorance of prefixes o New failure modes due to RG not covered by checksum o Can't construct source routes (in general). o Hosts can't influence traffic handling by source address selection. - Interior routing fluctuations cause source address to thrash o Any node that is a tunnel endpoint must act as a border router. - Due to DNS modifications o Delegation problem: the one who holds your glue is not the one who changes your prefix. - No visible solutions o Two-faces DNS is required - Might be solvable - Due to source address rewriting o Multicast packets duplicated at multiple site exits. Recommendations - Do not hide the global prefixes from the interior nodes. - There has to be an overlap period (on the order of days to weeks) during prefix reassignments. - Define boundaries in addresses o Between global and site topology o Between routing and node designator - Address architecture must be improved for better aggregation. - Using site-local addresses can help quite a lot o Work on two faced DNS (the alternative is address selection rules for hosts) - Globally unique end-system designators have potential uses o But aren't a panacea. - The next address architecture document should accommodate an 8 byte unique ESD. o Candidate: IEEE EUI-64. Question: what does "accommodate" mean? Does it mean require requiring globally unique now. Answer: Yes. Implications - Need to work on Two-faced DNS - Need to study coordination between renumbering and updating DNS delegations - Root DNS servers at fixed addresses, globally host-routed? - Hosts will do source address selection, even if only by default. - Boundaries in global addresses facilitate the use of site-local addresses. Questions: Should we also work on source selection algorithms? Yes, we should be comparing the two approaches. O'Dell raised difficulty with scaling when hosts have many addresses. Doesn't think this will scale. Do the recommendations mean that I can't use prefix ::1? Yes, that would not be allowed. - Starting off a connection with site-local addresses may become inconvenient if one end later goes mobile off-site o Could some hosts simply not have site-local addresses? - Globally unique ESD's preclude routing prefixes of 64 < length < 128 o Or do they? If you have an aligned blocks of ESD's - What's the ESD of an anycast address? Comment that Anycast do not need globally unique, but need ESD which do not conflict with any real ESD. Question and discussion about stability of dialin assigned addresses. Lixa Z: Question about what it means to require global unique ESD's. Comment about getting more feedback from DNS "experts". Agreement we need more overlook. Need more coordination. M. Ohta: Asked why did we look at only rewriting destination locator (based on his proposal of about six months ago). Wants to be able to rewrite destination RG. Could preserve original address in source route header. IPv6 over Ethernet & FDDI / Matt Crawford ----------------------------------------- Changes to accommodate ESD's - Prefix for stateless auto-config must be /64 - Auto-config address token is EUI64 - Link-local address token is EUI64 - EUI-64 is derived from MAC address o 00--8-55-12-34-56 -> 0008:55FF:FE12:3456 o http://standards.ieee.org/db/oui/tutorials/EUI64.html IPv6 over PPP / Dimitry Haskin ------------------------------ Change to make PPP support 64bit interface ID. Now reserves this size token. No changes to date to accommodate global token. Pending outcome of global ESD issue. IPv6 over ARCNET and Localtalk / Bob Hinden ------------------------------------------- Hinden mentioned both ARCNET and local talk do not have IEEE addresses in hardware and would need some mechanism to get global identifiers. The Use of End System Designators in IPv6 ----------------------------------------- IEEE/ANSI EUI Formats - EUI-64 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | | | | | | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---- company_id -------><-------------vendor supplied id ------> - IEEE 802 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | | | | F | F | F | E | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <------- OUI ---------> <--- vendor id --------> - FiberChannel +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | | | | ? | | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---- company_id -------> <-------vendor supplied id --------> Hard problem is what if you do not have an IEEE address in system. IANA EUI Formats - IPv4 Address +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 5 | E | 1 | 0 | C | 7 | 5 | 1 | D | C | 9 | D | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---- company_id -------> <-IPv4 Addr (199.81.220.157) ---> - ASN +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 5 | E | 2 | 0 | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---- company_id -------> <--- ASN -------><--- Assigned -> o PPP servers could use IANA OUI and IPV4 address. - Can not use private use IPv4 addresses o Use company ID and Autonomous System number (ASN) Comment companies do not normally get ASN numbers. Only assigned to organizations who are multihomed. Random ESD Format +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | 2 | | | | | | | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---> <-------------------------------------------------------> 60 Random bits <---> Fixed 4 bits (locally administrated address space which is not used by IEEE IPv4 addresses in IPv6 - IPv4 Compatible +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---- company_id -------> <------ IPv4 Address -----------> - IPv4 Mapped +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | F | F | F | F | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <---- company_id -------> <------ IPv4 Address -----------> o IPv4 compatible are OK o IPv4 mapped have a problem because conflicts with other assignments. ESD Pro and Con's / Thomas Narten --------------------------------- Main Benefit - Automatic/transparent deliver of packet to transport endpoint, even if source or destination "Routing Stuff" changes (see below) - Transport endpoints ar TCP, UDP, IPSEC, etc. - Facilitates retroactive fix up of Routing Stuff o Mobile nodes says "I just moved" here is my new address" o During renumbering: "here is my new preferred address" o Required authentication prior to changing "routing stuff" Cons - Automatic delivery defined above simplifies implementation, but does NOT provide new functionality: o Functionality required: IPv6 destination option that says "use this address when demultiplexing instead of address in IPv6 header" o IPSEC AH provides assurance that option is not a hijack attempt o Basic idea has been proposed before - Context identifier parameter" in Huitema's "Multihomed TCP" draft. - "Source identifier Option" in Bound/Roque "IPv6 Anycasting Service" draft. - ESD uniqueness requirement adds complexity o Intruders guarantee that ESD can not be assumed unique, even if we design them to be o New denial-of-service attacks possible: - Intruder host "borrows" ESD of dilbert.foo.com, opens TCP connection to www.bar.com - Real dilbert.foo.com opens TCP connection to www.bar.com (using same port number) - Packets from both connections delivered to same TCP endpoint on web server - Second connection (real Dilbert) "loses" - Can't defend against without requiring authentication. o Need way dealing with devices that have no IEEE MAC address. Solution possible, but may require some manual configuration. o Accidential misdelivery of packet to wrong machine that is using same ESD may trigger dangerous error responses. o Disallows small subnets o Anycast address need ESD that doesn't conflict with existing ESD (solutions possible, misconfiguration possible) My opinion - Key issues: compare benefits against cost - There are real costs, some which are not fully understood - Supposed benefits oversold - Considered big picture, benefits not worth the cost. ---------------------------------------------------- Friday 9-11:30am ---------------------------------------------------- Mobile IP / Dave Johnson ------------------------ Mobile IPv6 - Allows transparent roaming of IPv6 mobile nodes o Routing to mobile node regardless of its current point of attachment to the Internet o Mobile node is always addressable by its "home agent" - High-level overview of operation o Care-of addresses from IPv6 address auto-configuration o Mobile node sends its own Binding Updates o Used for correspondent nodes and home registration o Nodes cache binding in a Binding Cache o Correspondents route own packets directly to mobile node - Current draft is Dynamic Home Agent Address Discovery - Mobile node may not always know its home agent address o While mobile node is away from home o Home network may need to be reconfigured o Different machine may take over as home agent - In Mobile IPv4 o Mobile node can send to "directed broadcast" address o All home agents in home network receive request o All reject, giving their own unicast addresses o Mobile node tries again with one of these addresses - Can't do this in Mobile IPv6 since no broadcast in IPv6 Home Agent Discovery Proposal #1 - To register when don't know own home agent address o Mobile node sends "home agent discovery" packet to home network router "anycast" address o Probably an ICMP message o By IPv6, received by one border router on home network o Router receiving packet multicasts "home agent discovery" into home network to "all home agents group" o Home agent returns reply with its IP address to mobile node o Mobile node registers to that IP address - Implementation would be required in ALL IPv6 routers Proposal #2 - Define "home agent anycast" address o Prefix defines which subnet o Bottom part could be all-ones (instead of all-zeros) - For home agent discovery o Mobile node sends request to home agent anycast address for home network o Request answered home agent, giving unicast address o Mobile node registers to that IP address - Implementation of this would be required in ALL IPv6 routers Comments, Please - Need feedback from IPng working group - Send to mobile-ip@smallworks.com (mobile ip mailing list) Topologically Correct Addressing - Packets sent to a mobile node: o Source address = correspondent node address o Destination address = mobile node care-of address o Routing header = mobile node home address o (Problem: size of Routing header in every packet) - Packets sent from a mobile node o Source address = mobile node home address o Destination address = correspondent node address o Problem: ingress filtering drops all of these packets! Proposed Solution: Source Address Remapping - Mobile node uses care-of-address as source address.. But only while packet on its way tot he destination node - At the sender: o Sender builds packet using home address o Then substitute care-of address as source o Makes packet source address topologically correct - At the receiver (only the end destination node) o Receiver substitutes correct source address (home address) back into packet in place of care-of address. - Implementation of this would be required in ALL IPv6 routers Source Addressing Remapping Method #1 - Two source addresses in "every" packet o Carry real source address in a destination option o If present, receiver substitutes into IP header before passing it to the transport layer o Used for receipt of this packet only o Option creates no state in the receiver o Option does not affect any routing from receiver o Option is authenticated if packet itself is authenticated o Otherwise, no extra authentication needed. SAR, Method #2 - One one source address (the care-of address) in packet o Also a bit in every packet: "source is a care-of-address" o Bit probably encoded by presence/absence of a destination option o Could also be bit in header or bit in source address o Receiver caches mappings o If bit set in received packet and no cache entry: - Receiver request mapping form care-of address - Reply MUST be authenticated - Receiver saves original packet and processes after reply - Request/reply is probably ICMP Some discussion. Will be discussed on mailing list. Synthesis of DNS aAA and RG Resource Records / Jim Bound -------------------------------------------------------- Motivation - IPng w..g PAL1 interim meeting on alternative addressing architecture - Add connotation of location and identifier to DNS Resource Record "syntax" for future use. - Avoid alteration to DNS protocol and APIs for IPv6 - Adjunct to other Interim meeting action items - Determine initial affect to applications and DNS syntax and processing. Processing Model - No change to the DNS protocol - Client resolve still requests AAAA records in query (e.g., gethostbyname2() ), using ESD address - DNS server synthesizes from ESD address an AAAA record for each RG record associated with an aAA ESD - DNS returns in query response one AAAA record for each RG + aAA pair synthesized at the DNS server. - Transparent to client applications during the query operations. New aAA and RG Types foo.bar.com IN aAA aa:bb:cc:dd:ee:ff:01 /* ESD */ IN RG 5f09::/?? IN RG 5f08::/?? To be Determined - RG and ESD length, semantics, and uniqueness. - Processing cached AAAA records for resolvers - Affects RFC 1886 and DHCPv6 extensions - Dynamic updates to DNS must deal with granularity of aAA and RG records - Reverse DNS processing is TBD. Numbering point-to-point and boundary links / John Stewart ---------------------------------------------------------- If global ESD's, mask lengths will be either up to 64 or 128. Nothing in between. Notion that like in IPv4, with current form of interconnects, some global RG would have to be assigned to interconnects (e.g., NAP, etc.). Solicited Node Definition / Steve Deering ----------------------------------------- Issue was wanting to avoid a many to one mapping to Ethernet multicast addresses. Don't want to have collisions. L2 filtering, etc. Proposal was to allocate IPv6 multicast addresses to not have multicast group > 32bits. ND solicited addresses conflict with this approach. Currently: FF02::1:xxxx:xxxx Proposes: FF02::1:FFxx:xxxx Working group agreed adopt change. Will go into Addressing Arch and ND drafts. New addressing architecture w/ new solicited node definition soon because ND and IPoverFoo need to copy definitions. IPv6 Tunneling Spec and GRE / Steve Deering ------------------------------------------- IPv6 tunneling spec has gone through IPng last call and IETF last call twice. IESG want to form a working group to resolve the number of differently tunneling specs. GRE IPv4 specs submission has caused IESG to take a deeper look. One of the original IPng working group requirements was to define IPv6 tunneling. We only want one tunneling specification for IPv6. Alex Conta: GRE specification is not ready for an IPv4 specification because it is not complete. It does not cover IPv6 tunneling as currently written. Specs are not compete. Jeff Burgen / AD: IESG has decided to look at tunneling overall. Will be resolved to quickly. The new group be in the internet area. The AD's will scope work. Doesn't want to drag on a long time. Deering suggested that IPv6 need not be in that charter of this group. IPv6 already has one specification. IPng Chairs will write strong note to IESG requesting IPv6 not be included in this new working group and concern about the delay to existing IPv6 work. Router Renumbering for IPv6 / Matt Crawford ------------------------------------------- Internet draft written by Matt Crawford based on presentation at previous IETF by Bob Hinden Router Renumbering (RR) Packet contains - Anti-replay fields - Zero or more Prefix Control Operations (PCOs), each of which has: [missing remainder of slide] RR Message Processing - Check for valid sequence number o Optionally check for valid replay - Verify authentication - For each PCO o For each interface - For each address and/or Prefix on that interface o Compatible to MatchPrefix, if it matches, - Preform operation - Do not create duplicate prefixes Why not use SNMP - Multicast - Renumbering will be "more fundamental" than other management functions - Security Why not use IPSEC for Authentication - SA is looked up by SPI + destination address, but destination addresses are changing during RR. - No dynamic key negotiation protocol for multicast destination (correct me if I am wrong) Based on discussion will change draft to HMAC SHA1 Jim Bound mentioned that new docs need to require method for key selection. Open Issues - More than 1 match on a single interface o repeat operation on each match - Require duplicate suppression, or advise against construction of non-idempotent combinations? - All-routers multicast address is currently only defined at node- and link-local scope. Site- or org-scope would also be useful. - Asymmetric authentication scheme might be more appealing - No attempt to distribute information for RA fields other than Prefix information (e.g., hop limit.) Nordmark: Thinks this is a good idea. We should be careful to not include things which could break things. Would be better to make it harder to keep things from breaking. Might require more elaborate mechanisms and/or procedures. Need to be careful to make it harder. Next steps to update draft to use HMAC and finish missing sections. Think about Nordmark suggestions. Advertising site prefixes in RAs / Erik Nordmark ------------------------------------------------ Announcing Site Prefixes in Router Advertisements - Goals: o Limit effect of renumbering by ensuring that traffic local to the site use site-local addresses o Do this without requiring a two-faced DNS (i.e., no site local in the DNS) - Proposal o Advise the global prefixes (w/ lifetimes) for the site in ND messages o The host use this info to maintain a list of the current site prefixes o The host resolver (gethostbyname function) checks against list of prefixes after resolving the name. o When one of the addresses retrieves from the DNS matches one of the site prefixes (i.e., the first N bits match) then add the corresponding site-local address to the front.... [slides showing how to encode in prefix advertisements] [missing remainder] Prefix Notation / Bob Hinden ---------------------------- Prefix notations was added to current draft of addressing architecture document. General form proposed is: ipv6-address / prefix-length Examples: 12AB:0000:0000:CD30:0000:0000:0000:0000/60 12AB::CD30:0:0:0:0/60 12AB:0:0:CD30::/60 12AB:0:0:CD30/60 It included a notation (shown in last example) to not require "::" at the end of the prefix. Implied left justifying prefix and zero fill remainder. General consensus of group was that his added complexity and to not support this (e.g., require "::"). Who Are You / Matt Crawford (5 min) ---------------------------------------------------- Motivation - GSE would have made it difficult to have reverse lookup domains. - IN=ADDR.ARPA poorly maintained, will IP6.INT be better. - Maintenance of delegations will be more difficult in the expected frequent-renumbering environment of "THE FUTURE". - For access control, or even logging, IP6.INT provides nothing but a hint anyway History - Experimental RFC by W. Simpson, "ICMP Domain Name Messages", RFC 1788. Format of Packet - ICMP Message 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time-To-Live | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NameLen | FQDN ... | +-+-+-+-+-+-+-+-+ + / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA1 - FQDN Query (more pronouncably known as Who-Are- You or WRU). TBA2 - FQDN Reply (possibly to be known as Sam-I-Am). Code For FQDN Query, always zero. For FQDN Reply: 0 Indicates that the Time-To-Live field is meaningful 1 Indicates that the responding node cannot provide a meaningful TTL for its Address-to-FQDN association. Checksum The ICMPv6 checksum. ID A 16-bit field to aid in matching replies and requests. Its value is chosen by the querier and copied from a Request to a Reply by the responder. Cookie An opaque 64-bit field to aid in avoiding spoofing. Its value is chosen by the querier and copied from a Request to a Reply by the responder. Time-To-Live The number of seconds that the name may be cached. For compatibility with DNS [1035], this is a 32-bit signed, 2's-complement number, which must not be negative. NameLen The length in octets of the FQDN, as an 8-bit unsigned integer. FQDN The fully-qualified domain name of the responder, as a sequence of NameLen US-ASCII octets, with periods between the components. The last three fields (Time-To-Live, NameLen and FQDN) are not present in the FQDN Query. Steve Deering: Wondered about supporting multiple names in packet? Alex Conta: How different form DNS? Simpler fewer options/etc. Intended only for reverse lookups. Usage and Issues - The internet could easily get clogged with these messages. Therefore, this could be a back-end to DNS servers, which would catch the answers. o What's a good TTL when the responder can't provide one? o What about a timeout for negative caching? Question about viability of current reverse lookup database. Questioner thought premise was untrue. Thought was was getting better. Response was that with renumbering this would get even harder to maintain. This mechanism does not require manual configuration of a database. Important to keep this simple. Features - PLUS: Routing system takes the place of IP6.INT delegation o Always current - PLUS" A Meaningful TTL is usually available from Autoconf. or DHCP. - MINUS: Target must be up and reachable to do a lookup o But is it meaningful to say a certain FQDN is associate with an address when it isn't. Comment. Dialin users do not know their name. DHCP could tell host their domain name when they get the address. Could also return with a empty name length. What about negative caching? Inter-Domain Routing Status / Bob Hinden ---------------------------------------- Covered in document status. ND Zero Lifetime advertisement issue / Thomas Narten ---------------------------------------------------- Denial-of-Service vulnerability in Stateless Addrconf Attack: - Intruder connects to local link (remote access not sufficient) - Listen for RAs, determine what prefixes are in active use - Send out a single RA, advertise in-use prefix(es) with lifetime of zero Consequence: - Receiving host immediately invalidates address(es) formed via stateless autoconf for the specified prefix(es). - Host immediately terminates all transport layer connections (addresses) in use no longer exists). - Every host acts on received RA, entire network effectively brought down. - Subsequent RA containing correct (no-zero) Lifetime does not undo damage. One Possible Solution: - When a prefix lifetime reaches zero, host enters DELAY state, doesn't actually invalidate for two additional hours. - Receipt of subsequent lifetime value > zero cancels DELAY state - While in DELAY state, silently ignore additional Lifetime values of zero (for receiving prefixes) - Result: Intruder's zero Lifetime advertisement effectively ignored; subsequent RAs from real router cancel intruders RA before DELAY state expires. Question for WG? - Is this significant threat? - Is the cost of fixing vulnerability small enough to justify. - Should we fix problem? There are plenty of denial-of-service vulnerabilities already: Why fix this one given the others? - Other attacks must target individual hosts, one at a time. - Other attacks disrupt first-hop path, not the hosts themselves. o When intruder leaves, path is restored; host may be able to continue. o TCP connections break on a timeout, which takes several minutes o Doing long-term damage require long-term presence of intruder (increasing likelihood they will be discovered). o Vulnerabilities in IPv6 are analogous to those in IPv4 (i.e., IPv6 doesn't make problem worse than what we have today). - In contract to IPv4, IPv6 zero lifetime attack: o Single packet is processed by all hosts in the same way. o Host actively terminates all existing transport connections immediately, no recovery possible. o IPv4 has nothing like this; IPv6 has introduced a vulnerability not present in IPv4. Suggestion that before invalidating prefix, send a RS and see if RA is consistent with message which invalidated prefix. Discussion and additional suggestions. General consensus to fix vulnerability but there are issues with proposed mechanism. Author will propose to mailing list. Advanced API Spec / Matt Thomas ------------------------------- Any last comments, authors would like to issue working group last call. Document editor will do a working last call for Informational RFC. SNMP Issues / Margaret Forythe ------------------------------ Couple of issue with current MIB drafts and discuss solutions. IPv6 MIB Issues - Separate TCP/UDP tables for IPv4 and IPv6 - No way to represent an IP address in a MIB that can be ether IPv4 or IPv6. - Various Nit's o IP Routing table updates o IPv6IfIndex as index in TCP/UDP Tables Possible Solution(s) - Unified IP Address format - Single UDP &TCP Tables for IPv6 & IPv4 "connections" - Minor MIB cleanup Unified IP Address - Type/version in IP address type? - Octet string or OID? - SMI Change or Textual conv. o SMI change (new App. type) allows type discrimination in SNMP packet. o SMI change does not permit backwards compat. to current managers/agents. o SMI change may be politically difficult o Display hints in textual convention do not give info to mgr. unfamiliar w/ particular MIB. SMI App types do. UnifiedIPAddress::= textual convention DISPLAY HINT "X" (?) STATUS current DESCRIPTION "IP Address type for both IPv4 or IPv6 addresses. Particular type can be determined from length. Length of 4 = IPv4; 16 = IPv6. Addresses are stored in network byte order. IPv4 addresses should be displayed as with display hint "1d.:; IPv6 addresses as with "2x:"." SYNTAX OCTET STRING (SIZE (4 | 16)) SMI Applications Type - UnifiedIPAdress ::= [APPLICATION 7] IMPLICIT OCTET STRING (SIZE (4|16)) Will work with MIB author to resolve issues. When new drafts are out, IPng Document Editor will issue w.g. last call to move the to Experimental status. Destination Locator Rewrititing / Masataka Ohta ------------------------------------------------ Motivation Protocol Modifications - Don't checksum-protect destination locator - Modify routing header (w/ authentication) to Preserve the Original Locators - PCB lookup with Source and Destination ESDs (both Checksummed). Modifications to Routing Header - Add address[0] to contain the first destination address o Extra 16 byte in header - Copy, don't swap o Faster operation expected o Same level of security [slide showing change to pkt format] Comment: This looks like what Dave Johnson is proposing for mobile IP. Might be able to combine? Global ESD Proposal / Bob Hinden -------------------------------- Presented a proposal which would keep open the option for future transport protocols to use global ESD. Proposal was as follows: - Require all Interface ID be constructed using EUI-64 framework. Easy for both for devices which have hardware 48bit MAC's and with the use of the IANA or vendor specific prefix, easy for serial lines, tunnel interfaces, localtalk, etc. Only cost is use of 64bit ID's. - Part of EUI64 is a bit which says if the address has global scope (uniqueness). We require that bit be set correctly. EUI-64 which are built from hardware MAC will be global. Serial lines, tunnel end points, localtalk, etc. will not. - We do not make any change to current TCP/UDP connection identification, pseudo checksum, etc. Current transport protocols will treat all addresses as opaque 128bit quantities. - New transport protocols and/or research projects can tell if the destination with which they are about to communicate has an address with a global identifier when they get the results of a DNS lookup. If so, then can do what ever ESD magic they want. In practice many (most?) interface ID's will be global. This proposal would "keep the door open" for global ESDs but limit the impact now. The only cost now is requiring 64 bit interface ID and setting the global scope bit correctly. Considerable discussion resulted. Chairs polled the working group: 0 voted for global ESDs in IPv6 7 voted for no global ESD in IPv6 (e.g., keeping current interface ID behavior) 33 voted for proposal to use EUI-64 global/local bit to identify if interface ID is global. This was a rough consensus to adopt this approach. Will be added to addressing architecture document. --------------------------------------------------------------------------- --------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 23 21:02:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA04337; Wed, 23 Apr 1997 20:54:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA04330; Wed, 23 Apr 1997 20:54:34 -0700 From: bound@ZK3.DEC.COM Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA14688; Wed, 23 Apr 1997 20:55:46 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA28924 for ; Wed, 23 Apr 1997 21:04:34 -0700 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA31123; Wed, 23 Apr 1997 23:47:49 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA20382; Wed, 23 Apr 1997 23:47:44 -0400 Message-Id: <9704240347.AA20382@wasted.zk3.dec.com> To: "Ping Pan" Cc: , , Subject: (IPng 3559) Re: Flow Label In-Reply-To: Your message of "Mon, 21 Apr 97 15:34:48 EDT." <9704211934.AA18512@wildbird.watson.ibm.com> Date: Wed, 23 Apr 97 23:47:43 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3751 Ping Pan, >Thanks for the feedback. What I had in mind is the following scenario: +----+ label-1 label-1/label-2 +----+ | S1 |--->----+ +--->--------| R1 | +----+ | | +----+ | | | label-1 | +------+ -----> +------+ | RT-A |-------------| RT-B | +------+ -----> +------+ | label-2 | | | | | +----+ | | +----+ | S2 |--->----+ +---->-------| R2 | +----+ label-2 label-1/label-2 +----+ >S1 and S2 send data to a multicast group with receivers R1 and R2. They >have flow labels, label-1 and label-2 respectively. Routers RT-A and RT-B >store both labels in their forwarding tables. Yes. >Now, in case of shared reservation, would it be nice to have a single >flow-label between RT-A and RT-B, as shown below? +----+ label-1 label-5 +----+ | S1 |--->----+ +--->--------| R1 | +----+ | | +----+ | | | label-3 | +------+ -----> +------+ | RT-A |-------------| RT-B | +------+ +------+ | | | | | | +----+ | | +----+ | S2 |--->----+ +---->-------| R2 | +----+ label-2 label-4 +----+ >After flow merging, RT-A can just assign a new flow-label, label-3, >for both streams from S1 and S2. In RT-B, instead of managing both >label entries in the classifier, and mapping a single shared reservation >state to two filter entries, RT-B can just use the label-3 and for data >forwarding. I also think that the processing overhead in R1 and R2 can >be simplified as a result. I believe RSVP has a model to address this type of set up? But we should check that? RSVP doing it is OK and does not break the RFC 1883 architecture. >How is flow-label related to MPLS? Well, in case of ATM and Frame Relay, >the flow label between RT-A and RT-B can a VCI, or a DLCI, or a >tunneling ID, etc. Let's leave detailed MPLS/IPng interface issues in >the future, please. :-) I agree. But that can be done so I think it hard to complete this discussion until then. >I am not proposing a rewrite of the existing spec. Rather, I just >wish the specification can be flexible enough for design and development >in the future. I can't argue that the theory of what you propose is not a good idea. But I think in practice will it work: - What flow will S1 or S2 see in an ICMP error msg? - WHat if I want to traceroute in the future a flow? I think your thoughts and diagram has to be input to RFC 1883. It is pretty good. But we don't want to permit routers or switches to be able to do this in a loosely coupled manner with the hosts. But in a tightly coupled manner. At the end of the day the end-to-end flow in IPv6 is a win for the future too. excellent response ...thanks for sharing, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 24 08:18:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04681; Thu, 24 Apr 1997 08:11:06 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04674; Thu, 24 Apr 1997 08:10:57 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA03339; Thu, 24 Apr 1997 08:12:11 -0700 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA18579 for ; Thu, 24 Apr 1997 08:12:18 -0700 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id IAA01768; Thu, 24 Apr 1997 08:12:04 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id IAA18012; Thu, 24 Apr 1997 08:12:02 -0700 (MST) Message-Id: <199704241512.IAA18012@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 24 Apr 1997 08:12:01 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 3560) Re: IPng Working Group Minutes from Memphis IETF Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 898 Having "watched" both IPng WG meetings on the mbone (many thanks again to everyone who helped multicast Friday's session) and going through the minutes, I believe the "Aggregation-Based Unicast Address Format" proposal will proceed, along with the ESD proposal as described at the end of the minutes. Correct? What I cannot determine, however, is if any consensus was reached on the DNS changes (aAA and RG records) along with the ICMP "who are you" message. What is planned for these two proposals? Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 25 16:28:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA06235; Fri, 25 Apr 1997 16:20:22 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA06228; Fri, 25 Apr 1997 16:20:09 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA01999; Fri, 25 Apr 1997 16:21:19 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA01992 for ; Fri, 25 Apr 1997 16:21:32 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id QAA18066; Fri, 25 Apr 1997 16:20:04 -0700 Message-Id: <3.0.1.32.19970425162102.00bfad64@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 25 Apr 1997 16:21:02 -0700 To: jburgan@BayNetworks.com From: Bob Hinden Subject: (IPng 3561) Request to Advance "IPv6 Router Alert Option" Cc: narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1016 Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a RFC with Proposed Standard status: Title : IPv6 Router Alert Option Author(s) : D. Katz, R. Atkinson Filename : draft-ietf-ipngwg-ipv6router-alert-01.txt Pages : 4 Date : 04/21/1997 A working group last call for this document was completed on 12/31/96. This version of the internet draft reflects comments received during the working group last call. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 25 16:45:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA06254; Fri, 25 Apr 1997 16:37:15 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA06247; Fri, 25 Apr 1997 16:37:06 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA04967; Fri, 25 Apr 1997 16:38:20 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA05544 for ; Fri, 25 Apr 1997 16:38:34 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id QAA18716; Fri, 25 Apr 1997 16:38:20 -0700 Message-Id: <3.0.1.32.19970425163917.00bfe8c8@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 25 Apr 1997 16:39:17 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3562) W.G. Last Call on "Advanced Sockets API for IPv6" Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 911 This is an ipng working group last call for comments on advancing the following document to Informational: Title : Advanced Sockets API for IPv6 Author(s) : W. Richard Stevens, Matt Thomas Filename : draft-stevens-advanced-api-02.txt Pages : 67 Date : March 26, 1997 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today, on May 9, 1997. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 25 18:22:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA06431; Fri, 25 Apr 1997 18:14:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA06424; Fri, 25 Apr 1997 18:14:36 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA18198; Fri, 25 Apr 1997 18:15:50 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA23523 for ; Fri, 25 Apr 1997 18:16:05 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id SAA21924; Fri, 25 Apr 1997 18:15:44 -0700 Message-Id: <3.0.1.32.19970425181642.006d5738@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 25 Apr 1997 18:16:42 -0700 To: "W. Richard Stevens" From: Bob Hinden Subject: (IPng 3563) Re: IPng Working Group Minutes from Memphis IETF Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: <199704241512.IAA18012@kohala.kohala.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1043 Rich, >Having "watched" both IPng WG meetings on the mbone (many thanks again >to everyone who helped multicast Friday's session) and going through >the minutes, I believe the "Aggregation-Based Unicast Address Format" >proposal will proceed, along with the ESD proposal as described at the >end of the minutes. Correct? Yes. I am working on new addressing drafts. >What I cannot determine, however, is if any consensus was reached on >the DNS changes (aAA and RG records) along with the ICMP "who are you" >message. What is planned for these two proposals? The DNS changes and ICMP "who are you" have considerable merit and should proceed as well. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Apr 26 08:34:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06707; Sat, 26 Apr 1997 08:26:35 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06700; Sat, 26 Apr 1997 08:26:27 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA08137; Sat, 26 Apr 1997 08:27:41 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA25021 for ; Sat, 26 Apr 1997 08:27:55 -0700 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA32414; Sat, 26 Apr 1997 11:15:50 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA17628; Sat, 26 Apr 1997 11:15:49 -0400 Message-Id: <9704261515.AA17628@wasted.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com, minutes@ietf.org Subject: (IPng 3564) Re: IPng Working Group Minutes from Memphis IETF In-Reply-To: Your message of "Wed, 23 Apr 97 18:00:50 PDT." <3.0.1.32.19970423180050.00717194@mailhost.ipsilon.com> Date: Sat, 26 Apr 97 11:15:49 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 457 Excellent job Bob. I wish all IETF WGs had such useful minutes. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 08:59:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA08082; Mon, 28 Apr 1997 08:51:14 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA08075; Mon, 28 Apr 1997 08:51:10 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA01250; Mon, 28 Apr 1997 08:52:29 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06568; Mon, 28 Apr 1997 08:51:28 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07372; Sun, 27 Apr 1997 13:33:15 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA02707; Sun, 27 Apr 1997 13:34:31 -0700 Received: from mail.cis.ohio-state.edu (mail.cis.ohio-state.edu [164.107.8.55]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA19236 for ; Sun, 27 Apr 1997 13:34:45 -0700 Received: from hoover (hoover.cis.ohio-state.edu [164.107.79.3]) by mail.cis.ohio-state.edu (8.6.7/8.6.4) with SMTP id QAA07282 for ; Sun, 27 Apr 1997 16:34:29 -0400 Message-ID: <3363B855.59E2B600@osu.edu> Date: Sun, 27 Apr 1997 16:34:30 -0400 From: Xinri Cong Organization: CIS X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3 sun4c) MIME-Version: 1.0 To: ipng Subject: (IPng 3567) IPng Routing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 544 Currently I am interested in IPng routing. Would anyone kindly tell me where I can find some papers/information about this issue besides those RFC? Thanks Xinri -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 10:54:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA08382; Mon, 28 Apr 1997 10:46:30 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA08375; Mon, 28 Apr 1997 10:46:26 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA19426; Mon, 28 Apr 1997 10:47:45 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA06736; Mon, 28 Apr 1997 10:46:45 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA08334; Mon, 28 Apr 1997 10:28:23 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA09346; Mon, 28 Apr 1997 10:29:23 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA04285 for ; Mon, 28 Apr 1997 10:29:33 -0700 Received: from ietf.ietf.org by ietf.org id aa25733; 28 Apr 97 10:08 EDT To: IETF-Announce:;@ietf.org@jurassic@jurassic cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 3569) Last Call: IPv6 Router Alert Option to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 28 Apr 1997 10:08:01 -0400 Message-ID: <9704281008.aa25733@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 840 The IESG has received a request from the IPNG Working Group to consider "IPv6 Router Alert Option" for the status of Proposed Standard. 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@ietf.org or ietf@ietf.org mailing lists by May 12, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 11:44:09 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08517; Mon, 28 Apr 1997 11:35:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08510; Mon, 28 Apr 1997 11:35:21 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA26583; Mon, 28 Apr 1997 11:36:36 -0700 Received: from endo.BBN.COM (ENDO.BBN.COM [128.89.10.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA25660 for ; Mon, 28 Apr 1997 11:36:53 -0700 Received: from endo.bbn.com (LOCALHOST.BBN.COM [127.0.0.1]) by endo.BBN.COM (8.6.10/8.6.5) with ESMTP id OAA10428; Mon, 28 Apr 1997 14:35:07 -0400 Message-Id: <199704281835.OAA10428@endo.BBN.COM> To: jburgan@baynetworks.com, dkatz@jnx.com, rja@inet.org, craig@aland.bbn.com cc: Bob Hinden , narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Subject: (IPng 3570) Router Alert Option Date: Mon, 28 Apr 1997 14:35:06 -0400 From: "Alden W. Jackson" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1531 Jeff, Dave and Ran: We're writing to see if it is too late to make a small change to the Router Alert specification. What we need is a version of Router Alert in which the semantics of the option are to intercept the datagram -- i.e. to receive it and *not* send on a copy. We need this for use for a technology called Smart Packets, in which the datagram contains some code that is evaluated at the router and determines if the datagram gets forwarded on. (Thus the need to terminate the datagram at the router, because if it is forwarded, it may get forwarded more than once). As an initial proposal, we'd suggest that if the high-bit of the 16-bit type field is set, the datagram is intercepted, rather than copied and forwarded. We're happy to hear of a better suggestion. We'd prefer to use Router Alert than to have to define our own (substantially overlapping) option. We also apologize for the late arrival of this suggestion -- we only realized the need for this kind of option late last week. Thanks! Alden Jackson Craig Partridge alden w jackson awjacks@bbn.com BBN Systems and Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 13:32:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA08874; Mon, 28 Apr 1997 13:22:44 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA08867; Mon, 28 Apr 1997 13:22:40 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA25201; Mon, 28 Apr 1997 13:23:59 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07175; Mon, 28 Apr 1997 13:22:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA08589; Mon, 28 Apr 1997 12:26:04 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA09524; Mon, 28 Apr 1997 12:27:18 -0700 Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA11136 for ; Mon, 28 Apr 1997 12:27:34 -0700 Received: from cirrus.jnx.com (cirrus.jnx.com [208.197.169.237]) by red.jnx.com (8.8.5/8.8.5) with ESMTP id MAA21850; Mon, 28 Apr 1997 12:24:28 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.jnx.com (8.8.5/8.7.3) id MAA18565; Mon, 28 Apr 1997 12:24:27 -0700 (PDT) Date: Mon, 28 Apr 1997 12:24:27 -0700 (PDT) Message-Id: <199704281924.MAA18565@cirrus.jnx.com> From: Dave Katz To: awjacks@bbn.com CC: jburgan@baynetworks.com, rja@inet.org, craig@aland.bbn.com, hinden@ipsilon.com, narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com In-reply-to: <199704281835.OAA10428@endo.BBN.COM> (awjacks@bbn.com) Subject: (IPng 3572) Re: Router Alert Option Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3498 This sounds reasonable on the surface, though I think it may be mostly (or perhaps completely) unnecessary. First, is it the intention that a packet received with an unrecognized code (with the high order bit set) should be dropped by the router? If so, then you've already lost, since this behavior will not be exhibited by any router that exists today. If not, then you may simply want to define a single type code for your application and leave it at that. A router that understands this type code will Do the Right Thing with the packet (intercept it and eat it) and a router that doesn't understand the type code will helplessly pass it on as it does today. If your application is identifiable through other fields in the packet (such as a protocol ID or an option type or whatever) then a new router alert type isn't necessary at all--the router alert option is enough to get the router's attention, and parsing of other fields will have the desired effect. The presence of a type code in the option was sort of thrown in as an insurance policy (in response to a comment received at the time it was initially published), though it wasn't clear to me how it would be used--in any case that I could think of, the information held there would be redundant. I suppose it would be possible to make a case for using the type field as sort of a shorthand for stuff in the other fields so that nonparticipants needn't go through the trouble of looking further in the packet, but I'm not sure that I find this argument (with myself) terribly compelling. A bit more background as to how your application works would be helpful. --Dave cc: Bob Hinden , narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Date: Mon, 28 Apr 1997 14:35:06 -0400 From: "Alden W. Jackson" Jeff, Dave and Ran: We're writing to see if it is too late to make a small change to the Router Alert specification. What we need is a version of Router Alert in which the semantics of the option are to intercept the datagram -- i.e. to receive it and *not* send on a copy. We need this for use for a technology called Smart Packets, in which the datagram contains some code that is evaluated at the router and determines if the datagram gets forwarded on. (Thus the need to terminate the datagram at the router, because if it is forwarded, it may get forwarded more than once). As an initial proposal, we'd suggest that if the high-bit of the 16-bit type field is set, the datagram is intercepted, rather than copied and forwarded. We're happy to hear of a better suggestion. We'd prefer to use Router Alert than to have to define our own (substantially overlapping) option. We also apologize for the late arrival of this suggestion -- we only realized the need for this kind of option late last week. Thanks! Alden Jackson Craig Partridge alden w jackson awjacks@bbn.com BBN Systems and Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 14:07:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA08953; Mon, 28 Apr 1997 13:59:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA08946; Mon, 28 Apr 1997 13:58:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA01453; Mon, 28 Apr 1997 14:00:09 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA06455 for ; Mon, 28 Apr 1997 14:00:23 -0700 Received: from gungnir.fnal.gov ("port 36191"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01II8TEHH85K000X7O@FNAL.FNAL.GOV>; Mon, 28 Apr 1997 15:59:59 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id PAA02742; Mon, 28 Apr 1997 15:58:47 -0500 Date: Mon, 28 Apr 1997 15:58:47 -0500 From: Matt Crawford Subject: (IPng 3573) Re: Router Alert Option In-reply-to: "28 Apr 1997 14:35:06 EDT." <"199704281835.OAA10428"@endo.BBN.COM> To: "Alden W. Jackson" Cc: dkatz@jnx.com, rja@inet.org, craig@aland.bbn.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Message-id: <199704282058.PAA02742@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09003; Mon, 28 Apr 1997 14:08:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA08996; Mon, 28 Apr 1997 14:07:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA03513; Mon, 28 Apr 1997 14:09:09 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA08188 for ; Mon, 28 Apr 1997 14:09:24 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id OAA23136; Mon, 28 Apr 1997 14:09:03 -0700 Message-Id: <3.0.1.32.19970428141006.00be387c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 28 Apr 1997 14:10:06 -0700 To: "Alden W. Jackson" From: Bob Hinden Subject: (IPng 3574) Re: Router Alert Option Cc: hinden@Ipsilon.COM, ipng@sunroof.eng.sun.com In-Reply-To: <199704281835.OAA10428@endo.BBN.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1052 Alden, > We're writing to see if it is too late to make a small change to > the Router Alert specification. I think it is too late. If you were saying the router alert was broken in some way it would reasonable to hold it up, but otherwise I think it is too late to add new functionality. I am also not sure why what you request is needed. I don't think (seriously) that a router need permission to not forward (e.g., drop) a packet. It already happens for a lot of reasons like not having a route to the destination. I think you are just adding a new reason. Bob p.s. I removed the long cc: line. I think everyone else will get the reply on the IPng list. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 14:43:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09061; Mon, 28 Apr 1997 14:35:35 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09054; Mon, 28 Apr 1997 14:35:25 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA09967; Mon, 28 Apr 1997 14:36:40 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA15992 for ; Mon, 28 Apr 1997 14:36:56 -0700 Received: from fra-e.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24) id ; Mon, 28 Apr 1997 14:32:57 -0700 Message-Id: <199704282132.AA06839@zephyr.isi.edu> X-Mailer: exmh version 1.6.7 5/3/96 To: "Alden W. Jackson" Cc: jburgan@baynetworks.com, dkatz@jnx.com, rja@inet.org, craig@aland.bbn.com, Bob Hinden , narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Subject: (IPng 3575) Re: Router Alert Option In-Reply-To: Your message of "Mon, 28 Apr 1997 14:35:06 -0400." <199704281835.OAA10428@endo.BBN.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Apr 97 14:34:12 PST From: Daniel Zappala Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1076 > > Jeff, Dave and Ran: > > We're writing to see if it is too late to make a small change to > the Router Alert specification. > > What we need is a version of Router Alert in which the semantics > of the option are to intercept the datagram -- i.e. to receive it > and *not* send on a copy. [snip] >From my understanding, the Router Alert option is simply to let a router move a packet into the slow forwarding path for further examination and to possibly intercept it. It does not mandate that the packet is always copied and forwarded. In other words, doesn't the Router Alert option do exactly what you want it to do? Did I miss something? Daniel Zappala daniel@isi.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 16:30:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA09509; Mon, 28 Apr 1997 16:20:31 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA09502; Mon, 28 Apr 1997 16:20:27 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA21318; Mon, 28 Apr 1997 16:21:47 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA07666; Mon, 28 Apr 1997 16:20:45 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09123; Mon, 28 Apr 1997 14:53:43 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA14227; Mon, 28 Apr 1997 14:54:57 -0700 Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA20419 for ; Mon, 28 Apr 1997 14:55:11 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id OAA08675; Mon, 28 Apr 1997 14:54:15 -0700 (PDT) Message-Id: <199704282154.OAA08675@aland.bbn.com> To: Dave Katz cc: awjacks@bbn.com, jburgan@baynetworks.com, rja@inet.org, craig@aland.bbn.com, hinden@ipsilon.com, narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Subject: (IPng 3578) Re: Router Alert Option In-reply-to: Your message of Mon, 28 Apr 97 12:24:27 -0700. <199704281924.MAA18565@cirrus.jnx.com> Date: Mon, 28 Apr 97 14:54:14 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2521 First, is it the intention that a packet received with an unrecognized code (with the high order bit set) should be dropped by the router? No. If not, then you may simply want to define a single type code for your application and leave it at that. A router that understands this type code will Do the Right Thing with the packet (intercept it and eat it) and a router that doesn't understand the type code will helplessly pass it on as it does today. I re-read the Router Alert Option RFC and I can see why you say that, but I think that's the wrong way to think about the problem (it specifies a particular architecture for IPv6 routers which isn't a good thing). Basically the question is what does the IPv6 layer do when it gets this option. As I read the document now it says "throw the datagram into a slow path." Now the problem is that "slow path" isn't well defined. Upleveling a moment, the goal is to have the contents of the datagram processed locally, and pass the datagram on. In a BSD router, an obvious way to do that is to copy the datagram to a raw socket (or application socket) and also forward the datagram. "Slow path" has no meaning here (unless one means to say RSVP has to be in the kernel processing path). In the multigigabit router I'm building, we have a fast path, mid-path, slow path and very slow path. It turns out that the option, as currently spec'd could cause the datagram to be copied onto both fast and very slow path simultaneously. Anyway, my point is the IPv6 semantics aren't perfectly clear in the draft and that I'd originally read them as saying "forward this datagram on, AND process it locally" which where I come from, means make a copy and pass on the original, since that's the natural way in BSD and my router to handle a desire to process data that passed by. Our goal is to have the option cause the datagram to terminate (be delivered to a client process/bit of software/whatever) at the node, rather than be processed and passed on. If unrecognized, the datagram just keeps going until it hits some node that knows how to process it. Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 16:32:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA09518; Mon, 28 Apr 1997 16:21:34 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA09511; Mon, 28 Apr 1997 16:21:28 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA21435; Mon, 28 Apr 1997 16:22:47 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA07693; Mon, 28 Apr 1997 16:21:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09140; Mon, 28 Apr 1997 14:55:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA14861; Mon, 28 Apr 1997 14:57:07 -0700 Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA21015 for ; Mon, 28 Apr 1997 14:57:22 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id OAA08685; Mon, 28 Apr 1997 14:56:54 -0700 (PDT) Message-Id: <199704282156.OAA08685@aland.bbn.com> To: Matt Crawford cc: "Alden W. Jackson" , dkatz@jnx.com, rja@inet.org, craig@aland.bbn.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Subject: (IPng 3579) Re: Router Alert Option In-reply-to: Your message of Mon, 28 Apr 97 15:58:47 -0500. <199704282058.PAA02742@gungnir.fnal.gov> Date: Mon, 28 Apr 97 14:56:54 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1172 Presumably, Smart Packets* will use yet-to-be-defined hop-by-hop or other extension headers, which the router is instructed to examine in full by the presence of the Router Alert option. Actually the datagram contents is a program to be run (in a very constrained language). In our context, the option says, "stop this datagram and process it here." An analogy is suppose we put an SNMP query into the datagram -- and this option. It would cause the SNMP query to get run on every router you went past. In our case, the semantics of the query are such that it can replicate itself. So the safest way to design the protocol was to say "OK, assume it replicates itself" -- in which case the correct thing for IPv6 to do is *not* to independently forward the datagram. Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 17:36:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA09702; Mon, 28 Apr 1997 17:29:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA09695; Mon, 28 Apr 1997 17:28:59 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA18967; Mon, 28 Apr 1997 17:30:14 -0700 Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA02317 for ; Mon, 28 Apr 1997 17:30:31 -0700 Received: from rodan.UU.NET by relay6.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQcnhi20879; Mon, 28 Apr 1997 20:30:16 -0400 (EDT) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcnhh11693; Mon, 28 Apr 1997 20:29:56 -0400 (EDT) Message-Id: To: Craig Partridge cc: Matt Crawford , "Alden W. Jackson" , dkatz@jnx.com, rja@inet.org, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Subject: (IPng 3580) Re: Router Alert Option In-reply-to: Your message of "Mon, 28 Apr 1997 14:56:54 PDT." <199704282156.OAA08685@aland.bbn.com> Date: Mon, 28 Apr 1997 20:29:56 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 637 and how, pray tell, do you authenticate who is allowed to use this marvelous new feature which would seem to be able to use rather more processor cycles than it would otherwise??? seems like a marvelous denial of service threat here in the making.... -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 18:02:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA09741; Mon, 28 Apr 1997 17:53:25 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA09734; Mon, 28 Apr 1997 17:53:14 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA22525; Mon, 28 Apr 1997 17:54:29 -0700 Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA07302 for ; Mon, 28 Apr 1997 17:54:46 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id RAA09026; Mon, 28 Apr 1997 17:54:26 -0700 (PDT) Message-Id: <199704290054.RAA09026@aland.bbn.com> To: "Mike O'Dell" cc: Craig Partridge , Matt Crawford , "Alden W. Jackson" , dkatz@jnx.com, rja@inet.org, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Subject: (IPng 3581) Re: Router Alert Option In-reply-to: Your message of Mon, 28 Apr 97 20:29:56 -0400. Date: Mon, 28 Apr 97 17:54:26 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 738 and how, pray tell, do you authenticate who is allowed to use this marvelous new feature which would seem to be able to use rather more processor cycles than it would otherwise??? seems like a marvelous denial of service threat here in the making.... Which? Smart Packets or the option itself? Smart Packets are authenticated. Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 22:16:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA10035; Mon, 28 Apr 1997 22:04:51 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA10028; Mon, 28 Apr 1997 22:04:38 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA20380; Mon, 28 Apr 1997 22:05:53 -0700 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA21473 for ; Mon, 28 Apr 1997 22:06:10 -0700 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id WAA19338; Mon, 28 Apr 1997 22:05:17 -0700 Received: from [171.68.179.24] (sj-dial-3-23.cisco.com [171.68.179.24]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id WAA07950; Mon, 28 Apr 1997 22:05:12 -0700 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: References: Your message of "Mon, 28 Apr 1997 14:56:54 PDT." <199704282156.OAA08685@aland.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 22:02:54 -0700 To: "Mike O'Dell" From: Fred Baker Subject: (IPng 3583) Re: Router Alert Option Cc: Craig Partridge , Matt Crawford , "Alden W. Jackson" , dkatz@jnx.com, rja@inet.org, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1213 At 8:29 PM -0400 4/28/97, Mike O'Dell wrote: >and how, pray tell, do you authenticate who is allowed to use >this marvelous new feature which would seem to be able to use >rather more processor cycles than it would otherwise??? seems >like a marvelous denial of service threat here in the making.... My question to Tom Kalil, when he asked me if I wouldn't mind supporting it in the NGI proposal, was "and when the router stops forwarding packets, who do you call?" Certainly not the vendor of the router, as he hasn't provided the forwarding code. Probably the folks who sent the past 25,000 packets. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The surest sign that intelligent life exists elsewhere in the universe is that it has never tried to contact us. Calvin and Hobbes (Bill Watterson) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 22:15:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA10026; Mon, 28 Apr 1997 22:04:27 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA10019; Mon, 28 Apr 1997 22:04:19 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA20359; Mon, 28 Apr 1997 22:05:34 -0700 Received: from nacho.cisco.com (nacho.Cisco.com [171.69.1.160]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA21424 for ; Mon, 28 Apr 1997 22:05:51 -0700 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id WAA19334; Mon, 28 Apr 1997 22:05:11 -0700 Received: from [171.68.179.24] (sj-dial-3-23.cisco.com [171.68.179.24]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id WAA07947; Mon, 28 Apr 1997 22:05:06 -0700 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <199704282058.PAA02742@gungnir.fnal.gov> References: "28 Apr 1997 14:35:06 EDT." <"199704281835.OAA10428"@endo.BBN.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 22:01:00 -0700 To: Matt Crawford From: Fred Baker Subject: (IPng 3582) Re: Router Alert Option Cc: "Alden W. Jackson" , dkatz@jnx.com, rja@inet.org, craig@aland.bbn.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1125 At 3:58 PM -0500 4/28/97, Matt Crawford wrote: >Presumably, Smart Packets* will use yet-to-be-defined hop-by-hop or >other extension headers, which the router is instructed to examine in >full by the presence of the Router Alert option. You don't say so, >but I'm guessing you're concerned about the case of a router that >doesn't understand your new headers. no, this is a variation of active objects research. The packet actually has its own methods for forwarding embedded in it, in some generalized language. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The surest sign that intelligent life exists elsewhere in the universe is that it has never tried to contact us. Calvin and Hobbes (Bill Watterson) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 22:17:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA10044; Mon, 28 Apr 1997 22:05:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA10037; Mon, 28 Apr 1997 22:05:17 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA20440; Mon, 28 Apr 1997 22:06:32 -0700 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA21581 for ; Mon, 28 Apr 1997 22:06:50 -0700 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id WAA19330; Mon, 28 Apr 1997 22:05:05 -0700 Received: from [171.68.179.24] (sj-dial-3-23.cisco.com [171.68.179.24]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id WAA07944; Mon, 28 Apr 1997 22:05:00 -0700 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <199704281835.OAA10428@endo.BBN.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 22:03:01 -0700 To: "Alden W. Jackson" From: Fred Baker Subject: (IPng 3584) Re: Router Alert Option Cc: jburgan@baynetworks.com, dkatz@jnx.com, rja@inet.org, craig@aland.bbn.com, Bob Hinden , narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1379 At 2:35 PM -0400 4/28/97, Alden W. Jackson wrote: > What we need is a version of Router Alert in which the semantics > of the option are to intercept the datagram -- i.e. to receive it > and *not* send on a copy. We need this for use for a technology > called Smart Packets, in which the datagram contains some code that > is evaluated at the router and determines if the datagram gets > forwarded on. (Thus the need to terminate the datagram at the router, > because if it is forwarded, it may get forwarded more than once). the router alert simply intercepts the packet - what is done with it once intercepted is defined by the interceptor. RSVP, for example, does not forward it on, but may later send another packet as though it were forwarding the original. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The surest sign that intelligent life exists elsewhere in the universe is that it has never tried to contact us. Calvin and Hobbes (Bill Watterson) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 29 03:57:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA10237; Tue, 29 Apr 1997 03:49:54 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA10230; Tue, 29 Apr 1997 03:49:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA13003; Tue, 29 Apr 1997 03:51:01 -0700 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA06119 for ; Tue, 29 Apr 1997 03:51:17 -0700 Received: from rodan.UU.NET by relay3.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQcnix26040; Tue, 29 Apr 1997 06:50:56 -0400 (EDT) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcnix22119; Tue, 29 Apr 1997 06:50:51 -0400 (EDT) Message-Id: To: Fred Baker cc: "Mike O'Dell" , Craig Partridge , Matt Crawford , "Alden W. Jackson" , dkatz@jnx.com, rja@inet.org, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Subject: (IPng 3585) Re: Router Alert Option In-reply-to: Your message of "Mon, 28 Apr 1997 22:02:54 PDT." Date: Tue, 29 Apr 1997 06:50:50 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 429 certainly sounds about .1% baked to me.... -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 29 06:54:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA10444; Tue, 29 Apr 1997 06:46:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA10437; Tue, 29 Apr 1997 06:46:38 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA00735; Tue, 29 Apr 1997 06:47:53 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA11610 for ; Tue, 29 Apr 1997 06:48:09 -0700 Received: from gungnir.fnal.gov ("port 36553"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01II9SM38GB0000ZO9@FNAL.FNAL.GOV>; Tue, 29 Apr 1997 08:47:52 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA04194; Tue, 29 Apr 1997 08:46:42 -0500 Date: Tue, 29 Apr 1997 08:46:42 -0500 From: Matt Crawford Subject: (IPng 3586) Re: Router Alert Option In-reply-to: "28 Apr 1997 20:29:56 EDT." <"QQcnhh11693.199704290029"@rodan.UU.NET> To: "Mike O'Dell" Cc: Craig Partridge , "Alden W. Jackson" , ipng@sunroof.eng.sun.com Message-id: <199704291346.IAA04194@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ and how, pray tell, do you authenticate who is allowed to use > this marvelous new feature which would seem to be able to use > rather more processor cycles than it would otherwise??? seems > like a marvelous denial of service threat here in the making.... Or worse, depending on the power of this little program in the payload. The footnote I forgot to add for "Smart Packet*" was a reference to Vernor Vinge's "A Fire Upon the Deep." Vinge is an SF writer who has, apparently, attended at least one IETF meeting. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 29 12:25:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA00398; Tue, 29 Apr 1997 12:17:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA00391; Tue, 29 Apr 1997 12:17:41 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA24866; Tue, 29 Apr 1997 12:18:58 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA04247 for ; Tue, 29 Apr 1997 12:19:14 -0700 Received: from fra-e.isi.edu by zephyr.isi.edu (5.65c/5.61+local-24) id ; Tue, 29 Apr 1997 12:16:37 -0700 Message-Id: <199704291916.AA11789@zephyr.isi.edu> X-Mailer: exmh version 1.6.7 5/3/96 To: fred@cisco.com Cc: "Alden W. Jackson" , jburgan@baynetworks.com, dkatz@jnx.com, rja@inet.org, craig@aland.bbn.com, Bob Hinden , narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Subject: (IPng 3587) Re: Router Alert Option In-Reply-To: Your message of "Mon, 28 Apr 1997 22:03:01 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 29 Apr 97 12:17:52 PST From: Daniel Zappala Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1114 > Fred Baker > the router alert simply intercepts the packet - what is done with it once > intercepted is defined by the interceptor. RSVP, for example, does not > forward it on, but may later send another packet as though it were > forwarding the original. It sounds as if you are saying that the Router Alert option indicates a packet should always be "intercepted" rather than "copied-and-forwarded" for processing. If this is the case, the spec could use some clarifying text. Since the authors don't sound willing to make any substantial changes at this point, I expect that in the future if someone wants "copy-and-forward" semantics, they'll have to invent a new option. Daniel Zappala daniel@isi.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 29 13:28:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00680; Tue, 29 Apr 1997 13:19:52 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00671; Tue, 29 Apr 1997 13:19:45 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA10716; Tue, 29 Apr 1997 13:21:03 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09424; Tue, 29 Apr 1997 13:20:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00631; Tue, 29 Apr 1997 13:10:07 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA06734; Tue, 29 Apr 1997 13:11:23 -0700 Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA20509 for ; Tue, 29 Apr 1997 13:11:41 -0700 Received: from cirrus.jnx.com (cirrus.jnx.com [208.197.169.237]) by red.jnx.com (8.8.5/8.8.5) with ESMTP id NAA18832; Tue, 29 Apr 1997 13:09:02 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.jnx.com (8.8.5/8.7.3) id NAA20588; Tue, 29 Apr 1997 13:09:02 -0700 (PDT) Date: Tue, 29 Apr 1997 13:09:02 -0700 (PDT) Message-Id: <199704292009.NAA20588@cirrus.jnx.com> From: Dave Katz To: craig@aland.bbn.com CC: awjacks@bbn.com, jburgan@baynetworks.com, rja@inet.org, craig@aland.bbn.com, hinden@ipsilon.com, narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com, dkatz@jnx.com In-reply-to: <199704282154.OAA08675@aland.bbn.com> (message from Craig Partridge on Mon, 28 Apr 97 14:54:14 -0700) Subject: (IPng 3590) Re: Router Alert Option Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4369 I'm not sure what you're getting at here. Are you saying that you want the fastfast path to only have to recognize the high bit in order to know whether to forward a copy in addition to kicking up the packet, and leave any further analysis of the packet to the slow path? I'm not sure what this ultimately buys you over never forwarding a copy of the packet until the entire packet has been parsed, unless you expect there to be a very large volume of packets with the option set (in which case the cost of actually forwarding the packet from the slow path is likely to be dwarfed by the cost of the detailed packet analysis in any case). I guess my intention for the option was that the router *not* forward a packet containing this option from the fast path; for it to be ultimately forwarded would be at the behest of some slower path. This is the behavior for most option-bearing packets today (since the semantics on whether, or where, to forward the packet may be buried in the option). What all this underscores is the need to be more specific about the semantics of the option. In particular, the existing code point should be further explained to imply that the packet must not be forwarded until and unless the slow path decides to. I don't have any particular objection to defining a code point, or a bit in the code points, that says "always forward a copy" if you find this useful. --Dave cc: awjacks@bbn.com, jburgan@baynetworks.com, rja@inet.org, craig@aland.bbn.com, hinden@ipsilon.com, narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Date: Mon, 28 Apr 97 14:54:14 -0700 From: Craig Partridge First, is it the intention that a packet received with an unrecognized code (with the high order bit set) should be dropped by the router? No. If not, then you may simply want to define a single type code for your application and leave it at that. A router that understands this type code will Do the Right Thing with the packet (intercept it and eat it) and a router that doesn't understand the type code will helplessly pass it on as it does today. I re-read the Router Alert Option RFC and I can see why you say that, but I think that's the wrong way to think about the problem (it specifies a particular architecture for IPv6 routers which isn't a good thing). Basically the question is what does the IPv6 layer do when it gets this option. As I read the document now it says "throw the datagram into a slow path." Now the problem is that "slow path" isn't well defined. Upleveling a moment, the goal is to have the contents of the datagram processed locally, and pass the datagram on. In a BSD router, an obvious way to do that is to copy the datagram to a raw socket (or application socket) and also forward the datagram. "Slow path" has no meaning here (unless one means to say RSVP has to be in the kernel processing path). In the multigigabit router I'm building, we have a fast path, mid-path, slow path and very slow path. It turns out that the option, as currently spec'd could cause the datagram to be copied onto both fast and very slow path simultaneously. Anyway, my point is the IPv6 semantics aren't perfectly clear in the draft and that I'd originally read them as saying "forward this datagram on, AND process it locally" which where I come from, means make a copy and pass on the original, since that's the natural way in BSD and my router to handle a desire to process data that passed by. Our goal is to have the option cause the datagram to terminate (be delivered to a client process/bit of software/whatever) at the node, rather than be processed and passed on. If unrecognized, the datagram just keeps going until it hits some node that knows how to process it. Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 29 13:41:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00704; Tue, 29 Apr 1997 13:30:26 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00697; Tue, 29 Apr 1997 13:30:20 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA12956; Tue, 29 Apr 1997 13:31:38 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09464; Tue, 29 Apr 1997 13:30:37 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00642; Tue, 29 Apr 1997 13:12:43 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA07467; Tue, 29 Apr 1997 13:13:59 -0700 Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA21339 for ; Tue, 29 Apr 1997 13:14:16 -0700 Received: from cirrus.jnx.com (cirrus.jnx.com [208.197.169.237]) by red.jnx.com (8.8.5/8.8.5) with ESMTP id NAA18883; Tue, 29 Apr 1997 13:11:30 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.jnx.com (8.8.5/8.7.3) id NAA20599; Tue, 29 Apr 1997 13:11:30 -0700 (PDT) Date: Tue, 29 Apr 1997 13:11:30 -0700 (PDT) Message-Id: <199704292011.NAA20599@cirrus.jnx.com> From: Dave Katz To: daniel@ISI.EDU CC: fred@cisco.com, awjacks@bbn.com, jburgan@baynetworks.com, rja@inet.org, craig@aland.bbn.com, hinden@ipsilon.com, narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com In-reply-to: <199704291916.AA11789@zephyr.isi.edu> (message from Daniel Zappala on Tue, 29 Apr 97 12:17:52 PST) Subject: (IPng 3591) Re: Router Alert Option Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1784 X-Mailer: exmh version 1.6.7 5/3/96 Cc: "Alden W. Jackson" , jburgan@baynetworks.com, dkatz@jnx.com, rja@inet.org, craig@aland.bbn.com, Bob Hinden , narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 29 Apr 97 12:17:52 PST From: Daniel Zappala > Fred Baker > the router alert simply intercepts the packet - what is done with it once > intercepted is defined by the interceptor. RSVP, for example, does not > forward it on, but may later send another packet as though it were > forwarding the original. It sounds as if you are saying that the Router Alert option indicates a packet should always be "intercepted" rather than "copied-and-forwarded" for processing. If this is the case, the spec could use some clarifying text. Since the authors don't sound willing to make any substantial changes at this point, I expect that in the future if someone wants "copy-and-forward" semantics, they'll have to invent a new option. Nobody's unwilling, and I don't think that any of this is a substantial change. If somebody wants copy-and-forward, it's easy enough to add. We should clean up the semantics, as noted. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 29 15:38:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00912; Tue, 29 Apr 1997 15:29:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00904; Tue, 29 Apr 1997 15:29:48 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA08941; Tue, 29 Apr 1997 15:31:01 -0700 Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA02577 for ; Tue, 29 Apr 1997 15:31:16 -0700 Received: from rodan.UU.NET by relay7.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQcnks15466; Tue, 29 Apr 1997 18:31:01 -0400 (EDT) Received: by rodan.UU.NET id QQcnkh01113; Tue, 29 Apr 1997 15:53:02 -0400 (EDT) Date: Tue, 29 Apr 1997 15:53:02 -0400 (EDT) From: mo@UU.NET (Mike O'Dell) Message-Id: To: ipng@sunroof.eng.sun.com Subject: (IPng 3592) re: Router Alert Option..... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 693 nobody has yet explained to me how this "Router Alert Option" isn't a denial-of-service attack just waiting to happen. ie: a healthy flow marked "Please flog the processor" could be catastrophic. The notion of standardizing something which is an intrinsic threat to the network work seems a bit curious. -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 30 06:49:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA01834; Wed, 30 Apr 1997 06:40:28 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA01827; Wed, 30 Apr 1997 06:40:17 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA10729; Wed, 30 Apr 1997 06:41:35 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA01991 for ; Wed, 30 Apr 1997 06:41:52 -0700 Received: from gungnir.fnal.gov ("port 36837"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IIB6OMQU7U0010A7@FNAL.FNAL.GOV>; Wed, 30 Apr 1997 08:41:35 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA06946; Wed, 30 Apr 1997 08:40:21 -0500 Date: Wed, 30 Apr 1997 08:40:21 -0500 From: Matt Crawford Subject: (IPng 3594) Re: Router Alert Option..... In-reply-to: "29 Apr 1997 15:53:02 EDT." <"QQcnkh01113.199704291953"@rodan.UU.NET> To: ipng@sunroof.eng.sun.com Cc: iesg@ietf.org Message-id: <199704301340.IAA06946@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ nobody has yet explained to me how this "Router Alert Option" > isn't a denial-of-service attack just waiting to happen. > ie: a healthy flow marked "Please flog the processor" > could be catastrophic. I can see implementations avoiding that problem by management of the "divert-to-cpu" queue ... maybe. But what I don't like is the way the draft is couched in implementation-specific, yet at the same time very vague terms. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 30 06:52:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA01843; Wed, 30 Apr 1997 06:43:35 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA01836; Wed, 30 Apr 1997 06:43:22 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA11501; Wed, 30 Apr 1997 06:44:39 -0700 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA02629 for ; Wed, 30 Apr 1997 06:44:57 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id JAA21641; Wed, 30 Apr 1997 09:44:36 -0400 Date: Wed, 30 Apr 1997 09:44:36 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9704300944.ZM21639@seawind.bellcore.com> In-Reply-To: mo@UU.NET (Mike O'Dell) "(IPng 3592) re: Router Alert Option....." (Apr 29, 3:53pm) References: X-Mailer: Z-Mail (3.2.1 10oct95) To: mo@UU.NET (Mike O'Dell), ipng@sunroof.eng.sun.com Subject: (IPng 3595) Re: Router Alert Option..... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 967 On Apr 29, 3:53pm, Mike O'Dell wrote: > Subject: (IPng 3592) re: Router Alert Option..... > > nobody has yet explained to me how this "Router Alert Option" > isn't a denial-of-service attack just waiting to happen. Not anymore than any other hop by hop option, in fact. Clearly, access to any slow resource such as a "slow path" has to be rate limited. But I would think we know how to do that. Also, the option affects the next hop, and the buck probably stops there. That makes it a poor vehicle for attacks -- tracing one hop back is not rocket science... -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 30 07:12:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA01901; Wed, 30 Apr 1997 07:05:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA01894; Wed, 30 Apr 1997 07:04:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA17323; Wed, 30 Apr 1997 07:06:07 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA07605 for ; Wed, 30 Apr 1997 07:06:19 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA09833; Thu, 1 May 1997 00:04:03 +1000 (from kre@munnari.OZ.AU) To: Dave Katz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3596) Re: Router Alert Option In-Reply-To: Your message of "Tue, 29 Apr 1997 13:11:30 MST." <199704292011.NAA20599@cirrus.jnx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 May 1997 00:04:02 +1000 Message-Id: <24276.862409042@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 6420 Date: Tue, 29 Apr 1997 13:11:30 -0700 (PDT) From: Dave Katz Message-ID: <199704292011.NAA20599@cirrus.jnx.com> Nobody's unwilling, and I don't think that any of this is a substantial change. If somebody wants copy-and-forward, it's easy enough to add. We should clean up the semantics, as noted. Sounds like a good idea, I also don't think any major changes are needed, probably none to the basics, just to how it is described. I would get rid of most, if not all, mention of fast paths and slow paths, that's just implementation detail, and while it fits many people's model of how routers should work, it doesn't fit everyone's. Better to just say that the option is a request to the router to examine the packet more carefully than it otherwise might, as it might find interesting data in there somewhere... And to Mike O'Dell - no, this is no denial of service hole at all. The way to best view this is that the absence of the option is a promise to the routers along the path from the source host that there is nothing worth looking at in the packet other than the IPv6 header, hop by hop options, and the routing header when it is relevant. Of course there is no requirement that routers take any notice of this promise if they want to examine more of the packet. When the option is there, the host says nothing to the router at all about whether the packet might contain data that might be of interest to the router. That's exactly what would be the case if the option did not exist at all, routers would have to look in every packet to see whether there may be rsvp, or other, data that may be of interest to them. In some sense it is easier to imagine a "Nothing exciting here" option, added to tell the router not to bother looking - that very clearly would not be a denial of service opening. The router alert option is just the inverse sense of this option, and is preferred as it is expected that the vast majority of packets would want to carry the "nothing exciting here" option, if it was defined. By inverting it, bandwidth is saved (both because less bytes need to be transferred around, and because with less header noise, more payload will actually fit in each PMTU sized packet). It might actually be a good idea to describe the router alert option more in this negative sense (what it means when the option is not there) than in the positive (what it means when it is there). I know that is already there, but very briefly, and seems more of a throwaway than the actual definition. The draft could also usefully say whether it makes sense for more than one of these options to be present. Without the value field it would clearly be meaningless, but with that there indicating to the router why it might want to look inside the packet (what kind of data is there) it is possible that there may be several reasons why the router might want to look at the packet, not just one. If there are, is the presence of a single router alert option supposed to indicate all of them (the router really needs to look) and the value field just to provide a hint as to one reason, or is the value field supposed to be useful to the router in deciding whether to examine the packet or not (so if a router doesn't care about rsvp in any way, it wouldn't need to examine a packet with the Router Alert(RSVP) option - but still might want to examine one with the Router Alert(CraigP) option set. What does it mean to "silently ignore" an unrecognised value field? Does this imply silently ignore the router alert option, and simply act as if it wasn't there (which makes sense if a new router alert value is added, to support some new router feature, old routers which know nothing about this, don't recognise the value, and wouldn't know what to do with the new stuff anyway), or simply silently ignore the value field, and go ahead and examine the packet anyway. Next, I don't think it is "hosts" and "routers" for which the former ignores the option, and the latter examines it - but rather the entity which is the destination of the packet ignores the option (whether that is a host or a router), and other nodes examine it (they're more or less routers by definition, but the routing header complicates this). Then I'm also not sure that if this is to be a mandatory option (everyone must know about it) it makes much sense to say what routers that don't recognise it should do - there should be none. Further, the behaviour of a router when encountering an unknown option can't really be specified in the doc for the unknown option (if the doc for the option was examined, the option would be known, not unknown), that has to be in the base IPv6 spec. Finally, three boilerplate items which I predict will get this into trouble when it gets to the IESG for consideration, so may as well be fixed now. First, it uses MUST a couple of times (and MUST NOT), but doesn't define what that means. I personally believe this is pretty silly, but that is always cause to have the draft returned for fixing... Either change it to "must", (RFCs are not case insensitive), or define what MUST means, which you can do by referring to rfc2119, if the definitions there suit, or by defining it. Second, the draft adds a new registry for the IANA to maintain. Even if the IESG don't notice that, I suspect that the RFC editor might! When the IANA is asked to do something like this, it needs instructions on what to register. That can be as simple as saying that new value fields will be registered as the result of an standards track RFC being published. You might also want to reserve a range of values for local experimentation, of then again, you might not. Third, "security is not considered" is not going to be good enough. You really have to consider security, not ignore it. Now I see no way that this option can affect security any way at all, and if no-one else does, the draft should say that, not that no-one bothered to think about it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 30 07:48:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA01946; Wed, 30 Apr 1997 07:41:18 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA01939; Wed, 30 Apr 1997 07:41:07 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA27175; Wed, 30 Apr 1997 07:42:26 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA17372 for ; Wed, 30 Apr 1997 07:42:42 -0700 Received: from gungnir.fnal.gov ("port 37017"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IIB8T1W8L4000Y4L@FNAL.FNAL.GOV>; Wed, 30 Apr 1997 09:42:25 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA07116; Wed, 30 Apr 1997 09:41:10 -0500 Date: Wed, 30 Apr 1997 09:41:10 -0500 From: Matt Crawford Subject: (IPng 3597) Re: Router Alert Option In-reply-to: "01 May 1997 00:04:02 +1000." <"24276.862409042"@munnari.OZ.AU> To: Robert Elz Cc: Dave Katz , ipng@sunroof.eng.sun.com Message-id: <199704301441.JAA07116@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA02047; Wed, 30 Apr 1997 08:29:32 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA02040; Wed, 30 Apr 1997 08:29:24 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA09006; Wed, 30 Apr 1997 08:30:42 -0700 Received: from endo.BBN.COM (ENDO.BBN.COM [128.89.10.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA02470 for ; Wed, 30 Apr 1997 08:30:57 -0700 Received: from endo.bbn.com (LOCALHOST.BBN.COM [127.0.0.1]) by endo.BBN.COM (8.6.10/8.6.5) with ESMTP id LAA24599; Wed, 30 Apr 1997 11:30:34 -0400 Message-Id: <199704301530.LAA24599@endo.BBN.COM> To: Robert Elz cc: ipng@sunroof.eng.sun.com Subject: (IPng 3598) Re: Router Alert Option In-reply-to: Your message of "Thu, 01 May 1997 00:04:02 +1000." <24276.862409042@munnari.OZ.AU> Date: Wed, 30 Apr 1997 11:30:32 -0400 From: "Alden W. Jackson" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1184 Robert Elz states: [snip...] The draft could also usefully say whether it makes sense for more than one of these options to be present. What about the behavior of the alerted router wrt other extension headers? Below Robert alludes to the potential confusion than can occur with processing a packet with a routing header. [snip...] Next, I don't think it is "hosts" and "routers" for which the former ignores the option, and the latter examines it - but rather the entity which is the destination of the packet ignores the option (whether that is a host or a router), and other nodes examine it (they're more or less routers by definition, but the routing header complicates this). [snip...] alden w jackson awjacks@bbn.com BBN Systems and Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 30 09:14:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02124; Wed, 30 Apr 1997 09:06:31 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02116; Wed, 30 Apr 1997 09:06:26 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15212; Wed, 30 Apr 1997 09:07:48 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA12066; Wed, 30 Apr 1997 09:06:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA01586; Tue, 29 Apr 1997 22:36:02 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA04033; Tue, 29 Apr 1997 22:37:18 -0700 Received: from epilogue.com (rurha-pente.epilogue.com [128.224.2.24]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA23838 for ; Tue, 29 Apr 1997 22:37:33 -0700 Received: from rurha-pente.epilogue.com by rurha-pente.epilogue.com id aa25328; 30 Apr 97 01:37 -0400 To: ipng@sunroof.eng.sun.com Subject: (IPng 3599) DNS RG + aAA extensions and ICMP "who are you?" message Date: Wed, 30 Apr 1997 01:37:11 -0400 From: Rob Austein Message-ID: <9704300137.aa25328@rurha-pente.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 6414 Since the rumors of the RG+aAA proposal's impending defenestration appear to have been exaggerated, I guess I'll have to push. I have serious reservations about the proposed RG+aAA RR synthesis mechanism. I also have reservations about relying on the proposed ICMP "who are you?" message as the sole method of doing inverse mappings from addresses to DNS names. The two issues are somewhat related, which is why I'm dragging them both into the same message. While I can certainly understand with the goal of constructing AAAA RRs from multiple data sources to support renumbering, etcetera, I don't think that this is the way to go about it. The proposal adds a burden to the DNS, without a real compensating benefit that I can see. There are three times/places that the RR synthesis could take place: 1) When RRs are added to the zone, whether by writing a new zone file or by dynamic update 2) When an authoritative name server receives a query 3) When an application calls gethostbymumble() [or its equivalent on non-BSD systems]. I agree with Jim that (3) is probably not a good idea in this case. The current proposal is for (2). I think the right place is (1). In order for the current proposal to work, the aAA and the RG RRs must be at the same node in the DNS tree (the one indexed by the hostname). Thus, the two RRs must be in the same zone, and are under the same administrative control even with secure dynamic update, so the AAAA could equally well have been synthesized when the zone was updated. The only benefit I see here is that the update tools become a little simpler, at the expense of the name server itself. This seems like a bad trade, particularly if the name server really is supposed to do this synthesis every time it receives a query (optimizing "compile time" at the expense of "run time", basicly). Furthermore, this business of having the "master server" do the synthesis is, um, broken. DNS queries don't just go to the master. Contrary to folk myth, there's no requirement that there even BE a single master server, except in the DNS dynamic update protocol, which isn't a required part of the DNS architecture. So is it every authoritative server that's doing the synthesis, or the ones that happen to find RG and aAA RRs in their zone files, or is the propsal imposing a new restriction on the DNS, or what? How about the DNSSEC implications? Who signs these synthesized AAAA RRs? How can this be reconciled this with the DNSSEC recommendation that highly secure zones be signed offline and conveyed to the name servers via sneakernet, so that the zone private key will never be on the network? I'm pretty sure that last one is a show stopper. In short, I think the RG+aAA proposal opens up a large barrel of worms with little compensating benefit, since there are other ways of accomplishing the high-level goal. Last, a pedantic nit: DNS type names are case-insensitive and by convention have always been named in upper case, so that's "AAA". Regarding the ICMP "who are you?" message: I'm aware of three principle motivations for this mechanism: a) Some people have expressed a belief that the inverse tree is full of garbage, always will be full of garbage, hosts will always have a better idea of what their names are than the inverse tree will, and there's no other purpose in having the reverse tree. b) Discarding the reverse DNS tree would make it easier to do things like the aAA & RG RR hacks, since it would remove the requirement to figure out how to apply these hacks to the inverse tree. c) The inverse tree is ugly. I'm going to assume that (a) is the only one I need to refute. The DNSIND WG discussed this at some length several years ago (Danvers IETF, if I recall correctly, in any case it should be in the minutes). Our conclusion was that there is no one right answer to this problem. For either the ICMP "who are you?" query or the DNS inverse tree, the question is "who do you trust?". Who do you trust to be: available? configured correctly? truthful? At some sites the hosts are better informed/more likely to be available/more truthful than the DNS reverse tree, but at other sites the opposite is true. Our guess was that the there were enough cases of each kind of site that both mechanisms are useful. Since, in theory, it's possible to populate either mechanism from the other, the net result of having both should be an overall improvement in the reliability of the reverse mapping data. The WG's conclusion at that meeting was that the only real answer would be to implement both mechanisms and let the market decide which one, if either, should be deprecated. Given this conclusion, we weren't sure whether it was worth doing the ICMP message at all, given the potential implementation headaches involved in stuffing a relatively high-level function like name translation into the implementation of a low-level protocol like ICMP, but we decided to leave that up to the folks who'd proposed the ICMP message to decide. Since that meeting, DNSSEC has progressed, and there's been some interest in using DNSSEC and the reverse mapping tree to validate addresses. I don't know a lot about this one (ask Bill Manning), but the point is that if we throw out the reverse tree, we lose this capability, which may upset current plans outside the IPng WG. There have also been proposals to use the DNS reverse mapping tree for things like policy routing information; the first of these (for IDPR) went under due to a circular dependency problem, but later ones with more limited goals were quite feasible, if perhaps controversial. So that's another community that probably would not let the reverse mapping tree go away without a fight. So, in summary, my recommendations: - Scrap aAA and RG, instead build better tools for synthesising AAAA RRs when inserting new data into the DNS. - ICMP "who are you?" should go forward if enough people think it's worth doing, but keep the IP6.INT tree too. --Rob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 30 09:50:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02197; Wed, 30 Apr 1997 09:41:39 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02190; Wed, 30 Apr 1997 09:41:28 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA25945; Wed, 30 Apr 1997 09:42:46 -0700 Received: from london.cisco.com (london.cisco.com [144.254.32.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA27362 for ; Wed, 30 Apr 1997 09:43:03 -0700 Received: from [144.254.38.159] (london-async20.cisco.com [144.254.38.159]) by london.cisco.com (8.8.5/8.8.5) with ESMTP id SAA07156; Wed, 30 Apr 1997 18:34:18 +0200 (METDST) X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <199704291916.AA11789@zephyr.isi.edu> References: Your message of "Mon, 28 Apr 1997 22:03:01 MST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Apr 1997 16:03:28 +0000 To: Daniel Zappala From: Fred Baker Subject: (IPng 3600) Re: Router Alert Option Cc: "Alden W. Jackson" , jburgan@baynetworks.com, dkatz@jnx.com, rja@inet.org, craig@aland.bbn.com, Bob Hinden , narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1253 At 12:17 PM -0800 4/29/97, Daniel Zappala wrote: >> the router alert simply intercepts the packet - what is done with it once >> intercepted is defined by the interceptor. RSVP, for example, does not >> forward it on, but may later send another packet as though it were >> forwarding the original. > >It sounds as if you are saying that the Router Alert option indicates >a packet should always be "intercepted" rather than "copied-and-forwarded" >for processing. If this is the case, the spec could use some clarifying >text. Could be. The semantics of whether it is forwarded or not is absolutely up to the application that intercepts it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The surest sign that intelligent life exists elsewhere in the universe is that it has never tried to contact us. Calvin and Hobbes (Bill Watterson) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 30 09:56:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02213; Wed, 30 Apr 1997 09:46:16 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02206; Wed, 30 Apr 1997 09:46:01 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA27041; Wed, 30 Apr 1997 09:47:19 -0700 Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA28976 for ; Wed, 30 Apr 1997 09:47:35 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id JAA10459; Wed, 30 Apr 1997 09:46:41 -0700 (PDT) Message-Id: <199704301646.JAA10459@aland.bbn.com> To: Fred Baker cc: "Mike O'Dell" , Craig Partridge , Matt Crawford , "Alden W. Jackson" , ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Subject: (IPng 3601) Re: Router Alert Option In-reply-to: Your message of Mon, 28 Apr 97 22:02:54 -0700. Date: Wed, 30 Apr 97 09:46:40 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1543 At 8:29 PM -0400 4/28/97, Mike O'Dell wrote: >and how, pray tell, do you authenticate who is allowed to use >this marvelous new feature which would seem to be able to use >rather more processor cycles than it would otherwise??? seems >like a marvelous denial of service threat here in the making.... My question to Tom Kalil, when he asked me if I wouldn't mind supporting it in the NGI proposal, was "and when the router stops forwarding packets, who do you call?" Certainly not the vendor of the router, as he hasn't provided the forwarding code. Probably the folks who sent the past 25,000 packets. There is a large spectrum in the Active Networking community. At one end are folks who want to treat routers as programmable devices, programmed by the applications. (I.e., you need some special handling, download your own routing code!). At the other end are folks who think that allowing people to put some programming into selected packets (and we can debate about which packets would benefit) adds useful flexibility. Smart Packets is an experiment with adding programmability to network management packets. Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 30 10:59:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02447; Wed, 30 Apr 1997 10:47:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02440; Wed, 30 Apr 1997 10:47:48 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA13690; Wed, 30 Apr 1997 10:49:06 -0700 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA20223 for ; Wed, 30 Apr 1997 10:49:22 -0700 Received: from rodan.UU.NET by relay5.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQcnnr22948; Wed, 30 Apr 1997 13:49:17 -0400 (EDT) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcnnr09591; Wed, 30 Apr 1997 13:49:04 -0400 (EDT) Message-Id: To: Craig Partridge cc: Fred Baker , Matt Crawford , "Alden W. Jackson" , ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 3602) Re: Active Networking - a spectrum of people In-reply-to: Your message of "Wed, 30 Apr 1997 09:46:40 PDT." <199704301646.JAA10459@aland.bbn.com> Date: Wed, 30 Apr 1997 13:49:03 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 480 from where I sit, they all appear to be enjoying the same (psycho)Active Pharmeceuticals sigh -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 30 11:01:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02456; Wed, 30 Apr 1997 10:49:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02449; Wed, 30 Apr 1997 10:48:43 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA13870; Wed, 30 Apr 1997 10:50:01 -0700 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA20558 for ; Wed, 30 Apr 1997 10:50:17 -0700 Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.5/8.6.12) with SMTP id NAA01684; Wed, 30 Apr 1997 13:48:43 -0400 (EDT) Message-Id: <199704301748.NAA01684@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Craig Partridge cc: Fred Baker , "Mike O'Dell" , Matt Crawford , "Alden W. Jackson" , ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Subject: (IPng 3603) Re: Router Alert Option In-reply-to: Your message of "Wed, 30 Apr 1997 09:46:40 PDT." <199704301646.JAA10459@aland.bbn.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 30 Apr 1997 13:48:37 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1145 Craig Partridge writes: > There is a large spectrum in the Active Networking community. At one > end are folks who want to treat routers as programmable devices, programmed > by the applications. (I.e., you need some special handling, download your > own routing code!). At the other end are folks who think that allowing > people to put some programming into selected packets (and we can debate about > which packets would benefit) adds useful flexibility. > > Smart Packets is an experiment with adding programmability to network > management packets. The security implications terrify me, personally. I have no clue how anyone is going to be able to prevent really horrible network infrastructure attacks in an environment that permits such things. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 30 11:04:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02469; Wed, 30 Apr 1997 10:52:23 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02462; Wed, 30 Apr 1997 10:52:02 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA14682; Wed, 30 Apr 1997 10:53:20 -0700 Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA21617 for ; Wed, 30 Apr 1997 10:53:37 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id KAA10999; Wed, 30 Apr 1997 10:53:13 -0700 (PDT) Message-Id: <199704301753.KAA10999@aland.bbn.com> To: perry@piermont.com cc: Craig Partridge , Fred Baker , "Mike O'Dell" , Matt Crawford , "Alden W. Jackson" , ipng@sunroof.eng.sun.com, wzhou@bbn.com, bschwartz@bbn.com Subject: (IPng 3604) Re: Router Alert Option In-reply-to: Your message of Wed, 30 Apr 97 13:48:37 -0400. <199704301748.NAA01684@jekyll.piermont.com> Date: Wed, 30 Apr 97 10:53:12 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 893 I have no clue how anyone is going to be able to prevent really horrible network infrastructure attacks in an environment that permits such things. It wasn't clear which "such things" you intended to cite. If you're allowing completely programmable routers, yes I agree, that's a mindboggling hard problem. If you're just allowing a little bit of smarts (in a constrained programming language) that doesn't affect long-term router state, then clearly the threat can be made very very small. Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 30 19:03:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA03211; Wed, 30 Apr 1997 18:55:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA03204; Wed, 30 Apr 1997 18:55:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA02268; Wed, 30 Apr 1997 18:57:01 -0700 Received: from ns.research.att.com (ns.research.att.com [192.20.225.4]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA07373 for ; Wed, 30 Apr 1997 18:57:19 -0700 Received: from research.att.com ([135.205.32.20]) by ns; Wed Apr 30 21:56:06 EDT 1997 Received: from smb.research.att.com ([135.37.243.148]) by research; Wed Apr 30 21:55:26 EDT 1997 Message-Id: <3.0.32.19970501014539.0079fdb0@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 01 May 1997 01:55:25 +0000 To: huitema@bellcore.com (Christian Huitema) From: "Steven M. Bellovin" Subject: (IPng 3605) Re: Router Alert Option..... Cc: mo@UU.NET (Mike O'Dell), ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1396 At 09:44 AM 4/30/97 -0400, Christian Huitema wrote: >On Apr 29, 3:53pm, Mike O'Dell wrote: >> Subject: (IPng 3592) re: Router Alert Option..... >> >> nobody has yet explained to me how this "Router Alert Option" >> isn't a denial-of-service attack just waiting to happen. > >Not anymore than any other hop by hop option, in fact. Clearly, access to >any slow resource such as a "slow path" has to be rate limited. But I >would think we know how to do that. "Not anymor ethan any other hop by hop option" scares me. Clearly, we should know how to do that. Demonstrably, router vendors either don't or choose not to. > >Also, the option affects the next hop, and the buck probably stops there. > That makes it a poor vehicle for attacks -- tracing one hop back is not >rocket science... In a world with IP tunneling, this is far from clear. (It also pays to wonder if your router's CPU scheduler is smart enough to give the console or other management processes priority over these numerous annoying packets.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------