From owner-ipng Wed Jan 1 06:10:21 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02005; Wed, 1 Jan 97 06:10:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01999; Wed, 1 Jan 97 06:10:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA29325; Wed, 1 Jan 1997 06:01:52 -0800 Received: from tera.csl.sony.co.jp (tera.csl.sony.co.jp [133.138.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA24170 for ; Wed, 1 Jan 1997 06:01:53 -0800 Received: from vega.csl.sony.co.jp ([133.138.197.24]) by tera.csl.sony.co.jp (8.8.3/3.3W3) with SMTP id XAA13296; Wed, 1 Jan 1997 23:01:27 +0900 (JST) Message-Id: <199701011401.XAA13296@tera.csl.sony.co.jp> X-Sender: tera@tera.csl.sony.co.jp X-Mailer: Windows Eudora Pro Version 2.2-Jr2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Date: Wed, 01 Jan 1997 23:00:45 +0900 To: Charlie Perkins From: Fumio Teraoka Subject: (IPng 2665) Re: Discussion about new direction for mobile IP Cc: ipng@sunroof.eng.sun.com, mobile-ip@SmallWorks.COM, dbj@cs.cmu.edu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, I don't understand why my idea is called "source rebinding". Abstractly, my idea is separation of node identifiers and locators, or home addresses and care-of addresses in your terminology. The address fields of the IPv6 base header should be used only for routing. Information to identify src/dst nodes should be kept in other fields, e.g., src/dst ID options in the Dst Header. I don't agree with your poposal. It is very complicated. In addition, If the authentication header isn't used, impersonation can easily be done. If the authentication header or ESP is used, security association must be re-established every time a mobile node moves. A better solution is to take Ohta-san's 8+8 addressing architecture. In this addressing, an IPv6 address has both the node identifier and locator. I think that this addressing can solve not only mobility but also security in mobility and multihoming, etc. Fumio TERAOKA. # A happy new year! At 15:00 96/12/31 -0500, Charlie Perkins wrote: > > Dave Johnson and I have been puzzling lately over how mobile IPv6 > can handle ingress filtering by border routers. For IPv4, there > is a concerted effort going on now within the mobile-IP group > to solve this problem. Results are supposed to be forthcoming > before the next IETF meeting, and will likely involve reverse > tunneling along with some new controls. > > Since recent history indicates that such filtering will be > common in the future Internet, I think that we can expect > similar operations for IPv6 routers. The bottom line is > that expecting the mobile node to use its home address as the > source IPv6 address when delivering packets to correspondent > nodes is asking for trouble. If this is true, our current > mobile IP has to change. > > Some time ago, a proposal was floated by Fumio Teraoka to > do mobility by a "source rebinding" procedure. We had a number > of objections to his proposal, based on the need for way too > many authentications and amount of overhead in each packet. > However, taken more abstractly, the ideas of rebinding the > source address versus "rebinding" (say, by way of a routing header) > the destination address are dual (as has been noted by Christian > Huitema and others). Thus, we (Dave and I) have been drawn to > reconsider the merits of source rebinding. It is, of course, > essential in this regard to remember that a mobile node can > use the methods of stateless or stateful autoconfiguration to > obtain a topologically significant, but temporary, "care-of > address" (to use our existing terminology). What we propose > to change is the way that the care-of address is used. > > Briefly, we would like to send a new kind of Binding Update > to the correspondent node, so that it translates the source > address of received packets from the mobile node's care-of > address into the mobile node's home address. This care-of > address could, symmetrically, be used as the destination address > of packets sent from the correspondent node to the mobile node. > All of the connection state information (e.g., in the correspondent > node's PCBs) would still be kept in terms of the mobile node's > care-of address. The translation would occur as part of the > operation of the IPv6-layer destination-cache lookup for the > mobile node's home address. > > One benefit of the above, is that routing headers are no longer > needed. In fact, if life were sufficiently good and correspondent > nodes could be counted on to maintain all such source rebinding > information in nonvolatile storage, such a scheme is practically > minimal as far as packet overhead is concerned. > > However, if the correspondent node loses track of the source > rebinding information for the mobile node, it will start to > get perfectly good packets that seem to emanate from the > mobile node's care-of address. If that (rare) occurrence would > be acceptable, then life is good. This note can be considered > over and done with. > > ======================================================================== > > If, on the other hand, the mobile node needs to protect against > such losses at the correspondent node, then we have to design more > protocol. > > There are several possibilities: > > 1) We can require the mobile node to indicate, in each packet sent > to the correspondent node, that the source address is not > the "real" source address. Then if the correspondent does > not have a binding, it returns ICMP to the source address > of the packet, and the mobile node (after receiving the ICMP) > knows to reissue the source rebinding information. > 1a) We can have a bit in the header. > 1b) We design a new destination option for the forward indication > by the mobile node. > 2) The correspondent node can be required to use routing headers > anyway. Then, the mobile node will know that if it gets > a datagram without a routing header, something is wrong. > This strategy fails when the mobile node cannot expect to > get an answer from the correspondent node. Thus, it is > really not acceptable. > > If (1), it would be REALLY NICE to have a bit in the header for > this indication. Especially before they get solidly used up. > Perhaps one of the bits earmarked for private use by ISPs in the > last IETF could be allocated for this use (the "source address > should actually be bound to something else" bit). Otherwise, > if the mobile node has to use a destination option for this > purpose, the typical case will require enough padding to make > this an 8-byte overhead, by the rules for aligning options. > Note that the asymmetric 8-byte overhead is still better than > the asymmetric 24-byte overhead required by current mobile IPv6, > because routing headers take 24 bytes (minimum). > > ======================================================================== > > There are some other issues that need to be worked out, but > I think they are minor (involving, for instance, address lifetime > and multihoming at the mobile node). At least I think we can > solve them. > > The purpose of this note is to float this change in direction > for consideration by the working groups, and ask for comments. > It seems a shame to take on such a major change at this late > date, when we are practically done with the protocol. However, > the need is great, given the ingress filtering we can expect. > To mitigate the impact of the change, I will observe that we > will actually be able to use quite a bit of the existing protocol > mechanism that already exists in the current Internet Drafts. > > Your comments are earnestly solicited. > > Thanks in advance, > Charlie P. > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ 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 Wed Jan 1 06:29:32 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02018; Wed, 1 Jan 97 06:29:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02012; Wed, 1 Jan 97 06:29:16 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA29928; Wed, 1 Jan 1997 06:21:04 -0800 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 GAA25366 for ; Wed, 1 Jan 1997 06:21:04 -0800 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 JAA15500; Wed, 1 Jan 1997 09:21:38 -0500 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.8.2/11-26-96) with SMTP id JAA44820; Wed, 1 Jan 1997 09:21:01 -0500 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA116592; Wed, 1 Jan 1997 09:21:01 -0500 From: Charlie Perkins Message-Id: <9701011421.AA116592@hawpub1.watson.ibm.com> To: ipng@sunroof.eng.sun.com, mobile-ip@hosaka.SmallWorks.COM Subject: (IPng 2666) Re: (mobile-ip) Discussion about new direction for mobile IP In-Reply-To: Your message of Tue, 31 Dec 96 15:00:45 EST. <9612312000.AA90023@hawpub1.watson.ibm.com> Date: Wed, 01 Jan 97 09:21:00 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Upon re-reading my initial submission on this topic, I found a _really serious_ "typo", which needs to be corrected in order to understand the proposal... > Briefly, we would like to send a new kind of Binding Update > to the correspondent node, so that it translates the source > address of received packets from the mobile node's care-of > address into the mobile node's home address. This care-of > address could, symmetrically, be used as the destination address > of packets sent from the correspondent node to the mobile node. > All of the connection state information (e.g., in the correspondent > node's PCBs) would still be kept in terms of the mobile node's > care-of address. The translation would occur as part of the ^^^^^^^^^^^^^^^ > operation of the IPv6-layer destination-cache lookup for the > mobile node's home address. The indicated text is wrong. It should have said instead "home address". Please accept my regrets for this error. I hope it hasn't been too confusing, although I fear that it could well have been. Regards, Charlie P. ------------------------------------------------------------------------------ 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 Wed Jan 1 07:12:52 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02038; Wed, 1 Jan 97 07:12:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02032; Wed, 1 Jan 97 07:12:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA01107; Wed, 1 Jan 1997 07:04:23 -0800 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 HAA27008 for ; Wed, 1 Jan 1997 07:04:23 -0800 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 KAA16908; Wed, 1 Jan 1997 10:04:42 -0500 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.8.2/11-26-96) with SMTP id KAA09306; Wed, 1 Jan 1997 10:04:05 -0500 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA175181; Wed, 1 Jan 1997 10:04:04 -0500 From: Charlie Perkins Message-Id: <9701011504.AA175181@hawpub1.watson.ibm.com> To: Fumio Teraoka Cc: ipng@sunroof.eng.sun.com, mobile-ip@hosaka.SmallWorks.COM, dbj@cs.cmu.edu Subject: (IPng 2667) Re: (mobile-ip) Re: Discussion about new direction for mobile IP In-Reply-To: Your message of Wed, 01 Jan 97 23:00:45 V. <199701011401.XAA13296@tera.csl.sony.co.jp> Date: Wed, 01 Jan 97 10:04:04 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fumio, > I don't understand why my idea is called "source rebinding". I just used the terminology because I heard other people describing the idea that way. It's not a big deal. It seems to correctly identify the notion that the source IP address of an incoming packet needs to be associated with (or, "bound to") some other IP address. If this does not describe your approach, then I should not have attributed the idea to you. > Abstractly, my idea is separation of node identifiers and locators, > or home addresses and care-of addresses in your terminology. > The address fields of the IPv6 base header should be used only for > routing. Information to identify src/dst nodes should be kept in other > fields, e.g., src/dst ID options in the Dst Header. I understand your proposal, and view it as a valid addressing model in competition with other valid addressing models. I think the discussion has evolved to the point of making engineering tradeoffs between the various valid models, to see which ones are best suited for the highly mobile future. > I don't agree with your poposal. It is very complicated. Would, perhaps, my correction of a lethal typo make the proposal seem less complicated? Please see my immediately previous note in which I make the correction. > In addition, > If the authentication header isn't used, impersonation can easily be > done. If the authentication header or ESP is used, security association > must be re-established every time a mobile node moves. Yes, the binding (not the security association) must be re-established every time the mobile node moves. However, authentication is not required every time the binding is _used_, only when it is _established_. > A better solution is to take Ohta-san's 8+8 addressing architecture. > In this addressing, an IPv6 address has both the node identifier and > locator. I think that this addressing can solve not only mobility but > also security in mobility and multihoming, etc. I follow with interest the O'Dell/Ohta-san or Ohta-san/O'Dell addressing architecture development (maybe we should call it the O+O architecture instead). As you are aware, one key facet of all the proposed mobility architectures is the attempt to associate a topologically significant address ("locator") with another address used to identify the mobile network entity. Separating both functions into different fields of the address looks like a great idea to me. However, it's clear that the proposal has a long way to go before it's "done". And, even when it's done, something perhaps similar to the "binding update" operation proposed in our IPv6 mobility support draft would have to be done to change the "routing goop" part of the address. Even if O+O is a better way to organize and manage the two essential roles of IPv6 addressing for mobile nodes, there is no free lunch when it comes to updating the "locator" address bits. I expect that the main difference would be that the data field of the binding update option would be shortened by the number of bits taken up by the "identifier" part of the address. In this discussion, it is important to observe that the mobile node itself is probably going to be in charge of initiating the modifications to the routing goop portion of its address, even if that only means some kind of extended process of "address autoconfiguration". In fact, I imagine that the process of adapting the existing address autoconfiguration procedures to work with O+O will begin the emphasize the need to fill in the security architecture which is currently missing from Neighbor Discovery. After all, what we are talking about is letting a node suddenly "appear" anywhere in the v6 Internet, get some cool routing goop, and maintain its unchanged identity at the new location. The potential for misuse here should be obvious. Request: Isn't there some hope of better terminology to supersede "routing goop"? I hated to miss the IETF working group session where this stuff was discussed, but I had to attend mobile-IP instead. > Fumio TERAOKA. > > # A happy new year! Regards, Charlie P. PS. Indeed, I wish you all a prosperous and fulfilling new year. ------------------------------------------------------------------------------ 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 Wed Jan 1 20:05:26 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02222; Wed, 1 Jan 97 20:05:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02216; Wed, 1 Jan 97 20:05:10 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA25791; Wed, 1 Jan 1997 19:56:56 -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 TAA17677 for ; Wed, 1 Jan 1997 19:56:56 -0800 From: Masataka Ohta Message-Id: <199701020355.MAA06017@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA06017; Thu, 2 Jan 1997 12:54:50 +0859 Subject: (IPng 2668) Re: (mobile-ip) Re: Discussion about new direction for mobile IP To: charliep@watson.ibm.com (Charlie Perkins) Date: Thu, 2 Jan 97 12:54:49 JST Cc: tera@csl.sony.co.jp, ipng@sunroof.eng.sun.com, mobile-ip@hosaka.SmallWorks.COM, dbj@cs.cmu.edu In-Reply-To: <9701011504.AA175181@hawpub1.watson.ibm.com>; from "Charlie Perkins" at Jan 1, 97 10:04 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I follow with interest the O'Dell/Ohta-san or Ohta-san/O'Dell addressing > architecture development (maybe we should call it the O+O architecture > instead). How about "MOs'"? :-) MO ------------------------------------------------------------------------------ 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 Wed Jan 1 20:10:13 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02234; Wed, 1 Jan 97 20:10:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02228; Wed, 1 Jan 97 20:09:57 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA26005; Wed, 1 Jan 1997 20:01: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 UAA18186 for ; Wed, 1 Jan 1997 20:01:43 -0800 From: Masataka Ohta Message-Id: <199701020400.MAA06073@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA06073; Thu, 2 Jan 1997 12:59:52 +0859 Subject: (IPng 2669) Re: Discussion about new direction for mobile IP To: charliep@watson.ibm.com (Charlie Perkins) Date: Thu, 2 Jan 97 12:59:51 JST Cc: ipng@sunroof.eng.sun.com, mobile-ip@SmallWorks.COM, dbj@cs.cmu.edu In-Reply-To: <9612312000.AA90023@hawpub1.watson.ibm.com>; from "Charlie Perkins" at Dec 31, 96 3:00 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie; > Dave Johnson and I have been puzzling lately over how mobile IPv6 > can handle ingress filtering by border routers. For IPv4, there > is a concerted effort going on now within the mobile-IP group > to solve this problem. Results are supposed to be forthcoming > before the next IETF meeting, and will likely involve reverse > tunneling along with some new controls. Could you explain what is "ingress filtering by border routers" for those of us who are not in mobile WG? So far, your proposal seems to be to make the current protocol not work and build an additional one on top of the broken current one. 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 Thu Jan 2 06:41:09 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02477; Thu, 2 Jan 97 06:41:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02471; Thu, 2 Jan 97 06:40:52 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA18582; Thu, 2 Jan 1997 06:32:38 -0800 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 GAA13660 for ; Thu, 2 Jan 1997 06:32:38 -0800 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 JAA17080; Thu, 2 Jan 1997 09:32:51 -0500 Received: from np5.watson.ibm.com (np5.watson.ibm.com [9.2.19.21]) by mailhub1.watson.ibm.com (8.8.2/11-26-96) with SMTP id JAA62709; Thu, 2 Jan 1997 09:32:14 -0500 Received: by np5.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA20957; Thu, 2 Jan 1997 09:32:13 -0500 From: Charlie Perkins Message-Id: <9701021432.AA20957@np5.watson.ibm.com> To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com, mobile-ip@hosaka.SmallWorks.COM, dbj@cs.cmu.edu Subject: (IPng 2670) Re: (mobile-ip) Re: Discussion about new direction for mobile IP In-Reply-To: Your message of Thu, 02 Jan 97 12:59:51 O. <199701020400.MAA06073@necom830.hpcl.titech.ac.jp> Date: Thu, 02 Jan 97 09:32:13 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Dave Johnson and I have been puzzling lately over how mobile IPv6 >> can handle ingress filtering by border routers. For IPv4, there >> is a concerted effort going on now within the mobile-IP group >> to solve this problem. Results are supposed to be forthcoming >> before the next IETF meeting, and will likely involve reverse >> tunneling along with some new controls. > > Could you explain what is "ingress filtering by border routers" > for those of us who are not in mobile WG? The subject is not really part of the mobile-IP working group charter. However, it has become relevant. Take a look at the following draft: draft-ferguson-ingress-filtering-01.txt Briefly, network administrators are urged to configure their border routers so that all packets emanating from their administrative domain are guaranteed to have a source address which belongs to one of the networks in their domain. > So far, your proposal seems to be to make the current protocol > not work The current proposal does work. It will be much harder to operate with ingress filtering. > and build an additional one on top of the broken current > one. No, we want to take the same basic algorithms and apply a significant change to the way that the care-of address is interpreted and used. I'm not quite sure how to constructively interpret your use of the word "broken" here. > Masataka Ohta Charlie P. ------------------------------------------------------------------------------ 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 Thu Jan 2 08:19:38 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02529; Thu, 2 Jan 97 08:19:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02523; Thu, 2 Jan 97 08:19:27 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA27163; Thu, 2 Jan 1997 08:11:13 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA07379 for ; Thu, 2 Jan 1997 08:11:12 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA23725; Thu, 2 Jan 1997 11:02:14 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA05755; Thu, 2 Jan 1997 11:02:11 -0500 Message-Id: <9701021602.AA05755@wasted.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2671) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: Your message of "Tue, 31 Dec 96 09:18:37 EST." <199612311418.JAA01102@hygro.raleigh.ibm.com> Date: Thu, 02 Jan 97 11:02:11 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, I will work with Richard et al to clear up the wording and semantics... I think we were trying to appease all and left room for wide interpretation and we need to fix that... good suggestions.. p.s. shell environment is looked at before any external files are read so that is my assumption (/etc/resolv.conf question) and even when I programmed on PDP 8's 20 years ago I would always access my in memory overlay before bringing in another overlay (reading a file back then), but we should specify the behavior. ---> good point... 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 Thu Jan 2 11:18:42 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00540; Thu, 2 Jan 97 11:18:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28731; Tue, 24 Dec 96 11:45:21 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA04561; Tue, 24 Dec 1996 11:37:20 -0800 Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA20854 for ; Tue, 24 Dec 1996 11:37:20 -0800 Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.8.3/8.8.3) with ESMTP id LAA17021; Tue, 24 Dec 1996 11:36:48 -0800 (PST) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id LAA04664; Tue, 24 Dec 1996 11:36:07 -0800 (PST) Date: Tue, 24 Dec 1996 11:36:07 -0800 (PST) Message-Id: <199612241936.LAA04664@chimp.jnx.com> From: Tony Li To: bound@zk3.dec.com Cc: dhaskin@baynetworks.com (Dimitry Haskin), ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2672) Re: larger AS/RD space for v6? References: <199612201747.MAA20792@elmo.uu.net> <9612241630.AA00902@wasted.zk3.dec.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't know if more is needed. But preparing to implement your 8+8 proposal I can't see more than 14bits needed for the LSID. Then the rest of bits is a real lot for subscribers. Then in the low order 8bytes we only have 15 for the partition. SHould someone use up that partition I see no reason why the subscriber could not provide some of the subscriber bits to the private topology if needed? This affects how I would implement the transport and dns stuff fyi... I'd like to point out that ANYTHING that "knows" about the internal structure of the address is probably a mistake. It constrains the future flexibility of the system, thereby eliminating future adaptability. Basic engineering demands that create the absolute minimum in internal interdependencies. Thus, the address should be wholly opaque outside of the routing system. Imagine what would have happened if, for example, TCP _knew_ about Class B addresses. Tony p.s.: You shouldn't even know the length of it. Hint, hint. ;-) From owner-ipng@sunroof.eng.sun.com Mon Dec 30 06:58:19 1996 Return-Path: Received: from sunroof.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA15450; Mon, 30 Dec 1996 06:58:18 -0800 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00724; Mon, 30 Dec 96 07:06:26 PST Date: Mon, 30 Dec 96 07:06:26 PST Message-Id: <9612301506.AA00724@sunroof.eng.sun.com> To: owner-ipng@sunroof.eng.sun.com From: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Non-member submission from [The IESG ] Content-Length: 1351 X-Lines: 29 Status: RO From scoya@ietf.org Mon Dec 30 07:06:10 1996 Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00718; Mon, 30 Dec 96 07:06:10 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA29043; Mon, 30 Dec 1996 06:58:01 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA13715 for ; Mon, 30 Dec 1996 06:58:01 -0800 Received: from ietf.ietf.org by ietf.org id aa17501; 30 Dec 96 9:32 EST To: IETF-Announce:;@ietf.org Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: Last Call: Generic Packet Tunneling in IPv6 Specification to Proposed Standard Reply-To: iesg@ietf.org Date: Mon, 30 Dec 1996 09:32:57 -0500 Sender: scoya@ietf.org Message-Id: <9612300932.aa17501@ietf.org> The IESG has received a request from the IPNG Working Group to consider "Generic Packet Tunneling in IPv6 Specification" 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 January 13, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/ ------------------------------------------------------------------------------ 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 Thu Jan 2 11:22:26 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00552; Thu, 2 Jan 97 11:22:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00728; Mon, 30 Dec 96 07:06:44 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA29073; Mon, 30 Dec 1996 06:58:35 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA13853 for ; Mon, 30 Dec 1996 06:58:34 -0800 Received: from ietf.ietf.org by ietf.org id aa22624; 30 Dec 96 9:54 EST 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 2673) I-D ACTION:draft-ietf-ipngwg-ipv6-over-ppp-00.txt Date: Mon, 30 Dec 1996 09:54:41 -0500 Message-Id: <9612300954.aa22624@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-ipv6-over-ppp-00.txt Pages : 10 Date : 12/27/1996 The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-over-ppp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.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-ipv6-over-ppp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19961227143718.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-over-ppp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961227143718.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ 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 Thu Jan 2 14:13:45 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01101; Thu, 2 Jan 97 14:13:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01095; Thu, 2 Jan 97 14:13:32 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA25523; Thu, 2 Jan 1997 14:05:17 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA02842 for ; Thu, 2 Jan 1997 14:05:15 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id PAA12605; Thu, 2 Jan 1997 15:05:12 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id PAA07273; Thu, 2 Jan 1997 15:05:12 -0700 (MST) Message-Id: <199701022205.PAA07273@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 2 Jan 1997 15:05:12 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Thomas Narten , ipng@sunroof.eng.sun.com Subject: (IPng 2674) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > To: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 2635) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" > Date: Fri, 20 Dec 1996 17:33:17 -0400 > From: Thomas Narten > > OK, here's my $0.02 on the document. Many thanks for the detailed comments, Thomas. I've elided all the simple typos that we will, of course, fix. > First, Neither the basic or advanced API spec seems to provide a way > to obtain the Hop Limit on a *received* datagram. I think this is > something we should provide, since some routing protocols may want to > verify that updates they are receiving are from directly attached > neighbors. They could use the same Hop Limit == 255 trick as ND. I > don't really care which document it goes in, though it would seem to > fit with advanced API and ancillary data. > > Having said that, however, however, it seems OSPFv6 just multicasts to > the link-local address with a Hop Limit of 1, and RIPng doesn't > bother. So maybe this point is moot now. :-( Obviously we could provide a way to return the received hop limit, if people think it's needed. I've never needed it, and traceroute is the only application that I am familiar with that uses it. > > While IPv4 addresses are 32 bits long, IPv6 nodes are identified by > ^^^^^ > Shouldn't that say "interfaces"? Yes. > > u_char s6_addr[16]; /* IPv6 address */ > > Don't some folks get bent out shape when they see "u_char" in a spec? > Why isn't this a u_int8_t? (This comment applies throughout.) You are correct. > > #define SIN6_LEN > > > > struct sockaddr_in6 { > > u_char sin6_len; /* length of this struct */ > > u_char sin6_family; /* AF_INET6 */ > > The only place in the draft where sin6_len is mentioned is in this > section. If we want to promote application portability, then we might > want to add "#ifdef SIN6_LEN" code snippets throughout the document > (where appropriate) so that folks on non-4.4 systems do the right > thing with the sin6_len field as they develope code on 4.3-derived > systems. I don't see anywhere in the document where this #ifdef is needed. Normally you need not be aware of this member unless you receive socket address strucutres from the kernel (SIOCGIFCONF, for example). > > 0:0:0:0:0:FFFF. IPv4-mapped addresses are written as follows: > > > > ::FFFF: > > > > These addresses are often generated automatically by the > > gethostbyname() function when the specified host has only IPv4 > > addresses (as described in Section 6.1). > > Is this paragraph needed? It seems a bit misleading (is gethostbyname > really the routine that does this, or is this buried elsewhere in the > DNS code?) and doesn't strike me as being particularly relevant to > programmers anyway. I added it for clarity, as I recall way back not knowing where these addresses came from. The resolver generates them, as described in section 6.1. Yes, I can remove the paragraph, if desired? > > and priority from the packets they receive. The header fields of an > > actively opened TCP connection are set by assigning in the > > sin6_flowinfo field of the destination address sockaddr_in6 structure > > passed in the connect() function. The same technique can be used > > I have some concerns with the above. I don't think we really > understand (yet) all the pieces for making Flow Labels work. That is, > it is clear that the kernel will have some say in what Flow Labels get > used (for uniqueness if nothing else). So I don't think we are in a > position to say right now that the user can specify the Flow Label > simply by putting in random values in the field. The OS kernel may > want to restrict who uses what Flow Id. For instance, it might not > want some random user to piggy back its packets on the Flow used by a > video server. > > > recvfrom(), recvmsg(), and accept() functions. An application may > > specify the flow label and priority to use in transmitted packets of > > a passively accepted TCP connection, by setting the sin6_flowinfo > > field of the address passed to the bind() function. > > I think its premature to say this as well. Well first I need to reread the minutes and what was finally decided on the priority field. Effort went into making certain that the flow label and priority fields could be set by both TCP and UDP clients, and returned to both TCP and UDP servers. I hate to rip out the text now, only to find a need to add it in one year. Obviously we need to change the handling of the priority field to what was decided by the Working Group, and perhaps we could add some text about the flow lavel stating that it's use is still experimental and there may be restrictions as to what an application can set its value to? > > IPV6_FLOWINFO_FLOWLABEL > > IPV6_FLOWINFO_PRIORITY > > How about defining macros for manipulating these fields? The advanced > API document is full of such macros. For example, how about changing: > > > recv_flow = ntohl(sin6.sin6_flowinfo & IPV6_FLOWINFO_FLOWLABEL); > > recv_prio = ntohl(sin6.sin6_flowinfo & IPV6_FLOWINFO_PRIORITY) >> 24; > > to > > recv_flow = ntohl(EXTRACT_FLOW_LABEL(&sin6)); > recv_prio = ntohl(EXTRACT_PRIORITY(&sin6)); > > I think this would reduce programming errors me thinks. I agree. > > Be aware that the IPv4 INADDR_xxx constants are all defined in host > > byte order but the IPv6 IN6ADDR_xxx constants and the IPv6 > > in6addr_xxx externals are defined in network byte order. > > What other INADDR_xxx addresses are there besides loopback (the only > other one mentioned in the document)? Does it make sense to define > some of the pre-defined link-local multicast groups for instance? I find these on a 4.4BSD-derived kernel: #define INADDR_ANY (u_long)0x00000000 #define INADDR_BROADCAST (u_long)0xffffffff /* must be masked */ #define INADDR_NONE 0xffffffff /* -1 return */ #define INADDR_UNSPEC_GROUP (u_long)0xe0000000 /* 224.0.0.0 */ #define INADDR_ALLHOSTS_GROUP (u_long)0xe0000001 /* 224.0.0.1 */ #define INADDR_MAX_LOCAL_GROUP (u_long)0xe00000ff /* 224.0.0.255 */ > > struct sockaddr_in6 sin6; > > . . . > > sin6.sin6_family = AF_INET6; > > sin6.sin6_flowinfo = 0; > > sin6.sin6_port = htons(23); > > sin6.sin6_addr = in6addr_loopback; /* structure assignment */ > > . . . > > How about adding "#ifdef SIN6_LEN" code to the example. It's not needed: the sin6_len field need not be set. (The previous version of the I-D showed it being set, but that's not needed and just confuses the code.) > > IPV6_ADD_MEMBERSHIP > > > > Join a multicast group on a specified local interface. If > > the interface index is specified as 0, the kernel chooses the > > local interface by looking up the multicast group in the > > normal IPv6 routing table and using the resulting interface. > > The wording of the last sentence seems awfully implementation > dependent (and thus possibly incorrect). Shouldn't the API simply say > the kernel picks an interface in this case? We can certainly leave it out, but again, I always opt for adding more for clarity, than leaving something out (obscurity). The original IPv4 (Deering) multicast code does it this way for IPv4. We could either add a disclaimer ("For example, one way might be ...") or delete it. > > - The second way to set this option is to set the environment > > variable RES_OPTIONS, as in RES_OPTIONS=inet6. This method > > affects any processes that see this environment variable. > > Hmm. Which shell are you assuming above? :-) How about adding a "for > example, in my_fave_shell, ..." Fine. The example works in either the Bourne or Korn shells. > Also, I wasn't entirely clear what precedence applied when various > combinations of the "three ways to set RES_USE_INET6" were in > use. It's not too hard to make a guess at what a reasonable ordering > should be, but I think the document should spell this out. Agreed, but realize that since there is just an "inet6" option and not a "noinet6" option, if the option is turned on by any of the three methods, it's on. I think what's important is the scope of what the option affects when it's turned on with the three different methods, and I think that is spelled out already (p. 21): setting res_options affects only that process; setting the environment variable affects any process that sees that environment variable (depends on the shell and whether you export it or not), and setting the "options" in the resolver configuration file affects all applications on the host. I'm not sure what else to say? > > When the RES_USE_INET6 option is set, two changes occur: > > > > - gethostbyname(host) first calls gethostbyname2(host, AF_INET6) > > looking for AAAA records, and if this fails it then calls > > gethostbyname2(host, AF_INET) looking for A records. > > I'm a bit confused. Is the above saying that gethostname returns A > records only if no AAAA records exist? Yes, but only if the RES_USE_INET6 option is set. > I think this may be broken. If a host has both v4 and v6 addresses, it > seems to me that gethostbyname() should return both types of > addresses. This is important if some of the addresses aren't > working. When opening TCP connections, for instance, an application is > supposed to try all the addresses until if finds one that work. The > above doesn't permit that. If none of the AAAA records work, the A > records aren't tried (i.e., they weren't returned). Your summary is correct but I am not certain if this is "broken" or a "feature" :-) What's described is what Paul Vixie has had implemented for the past 6 months. It does return multiple AAAA records (if one or more found) or multiple A records (if no AAAA records, and RES_USE_INET6 is set), but it does not mix A and AAAA records. Doing so would require multiple queries to the name server. > > - gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6 > > addresses with the h_length member of the hostent structure set > > to 16. > > Does it continue to also supply regular (non IPv4-mapped) AAAA > addresses as well? (I suspect that it does, but it might help to add > a sentence to that effect.) Yes, but only if the 2nd argument is AF_INET6. When the 2nd argument is AF_INET it does just what it says above. > > struct hostent *gethostbyaddr(const char *src, int len, int af); > > > > One possible source of confusion is the handling of IPv4-mapped IPv6 > > addresses and IPv4-compatible IPv6 addresses. Current thinking > > involves the following logic: > > Not what is meant by "current thinking". Is this an open issue we need > to nail down? It was bashed around on this mailing list starting around May 20, 1996 by Paul Vixie and a few others. I am not aware of any "final/official" decision (I wasn't at Montreal and didn't see anything in the minutes about this) but what is described is again what Paul finally implemented. > Also, I found the "current thinking" rules confusing. Is this a > proposal for what gethostbyaddr() should do? It describes what Paul has implemented. > > - If af is AF_INET6, and if len equals 16, and if the IPv6 address > > is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 > > address, then skip over the first 12 bytes of the IPv6 address, > > set af to AF_INET, and set len to 4. > > And then what, query the DNS for a PTR record? Yes. What I should have done is label the four bullets at the top of p. 23 as 1, 2, 3, and 4, and then state that all four steps are executed in order. > > The return value from the function is 0 upon success or a nonzero > > error code. The following names are the nonzero error codes from > > getaddrinfo(): > > And how do programmers know what (integer) codes map to which (string) > errors? strerror()? Unfortunately all Posix specifies is the names. I do have a functions similar to strerror() for these codes, and it's just a bunch of if's comparing against the names (i.e., not a simple index into an array). > > int getaddrinfo(const char *hostname, const char *servname, > > const struct addrinfo *hints, > > struct addrinfo **res); > > What happens if the user supplies hostname and servname, but in the > hints section doesn't specific ai_socktype. Is this legal? What does > the call return? The DNS is an example and in this case (assuming a host with one interface) you'll get back two addrinfo structures (remember, this function returns a linked list of addrinfo structures), one for TCP port 53 and one for UDP port 53. So it's legal, but not too practical, because most applications know whether they want a stream socket or a datagram socket, and should then say so. > > structures. To return this information to the system the function > > freeaddrinfo() is called: > > In light of the discussion about using free() to return storage > obtained indirectly via another call (to the library), I'm surprised > that we have a freeaddrinfo() but no freenameindex(). I plan to add a freenameindex() function, after the discussions on this list a few weeks back. > Should we then go the whole nine yards and provide > "free" routines for all the routines that return dynamically allocated > storage? Yes. Apparently there are environments where one version of malloc/free is used by some library and another version of the same functions is used by the main function. > > int getnameinfo(const struct sockaddr *sa, size_t salen, > > char *host, size_t hostlen, > > char *serv, size_t servlen); > > Shouldn't the "char *host" and "char *serv" be "const" as well? No--those are the returned strings. > > Note that this function does not know the protocol of the socket > > address structure. Normally this is not a problem because the same > > port is assigned to a given service for both TCP and UDP. But there > > exist historical artifacts that violate this rule (e.g., ports 512, > > As others have noted, this is not true. The TCP and UDP port numbering > spaces are independent. Yes, and currently I plan to add a 7th argument, as Craig Metz has done. > > The function does not > > modify the buffer pointed to by dst if the conversion fails. The > > The above appears in at least two places. Is there any reason for this > requirement? It seems like an implementation detail to me. Why would > an application care? Why is that specified in the API? The first time I started seeing this was in the ANSI C standard, years ago. I assume the statement is added so that users can count on this behavior, else it's implementation-dependent. > > const char *inet_ntop(int af, const void *src, > > char *dst, size_t size); > > > will store the resulting text string. The size argument specifies > > the size of this buffer. The application must specify a non-NULL dst > > argument. For IPv6 addresses, the buffer must be at least 46-octets. > > For IPv4 addresses, the buffer must be at least 16-octets. In order > > I don't understand why the size argument is included. We hashed over this months ago and while there was no official resolution the end-result appears to be that all variable-length text strings require a length field (as here), while fixed-size result fields (e.g., the binary IPv4 or IPv6 addresses returned by inet_pton()) do not. > There are other functions (e.g., if_indextoname(unsigned > int ifindex, char *ifname)) that don't include a size argument. I'll add a length field here, if requested, but email since the draft was sent out indicate that the existing IFNAMSIZ can be used by the caller to set the size of the array. > > For IPv4 addresses, the buffer must be at least 16-octets. In order > > to allow applications to easily declare buffers of the proper size to > > store IPv4 and IPv6 addresses in string form, implementations should > > provide the following constants, made available to applications that > > include : > > > > #define INET_ADDRSTRLEN 16 > > #define INET6_ADDRSTRLEN 46 > > Any chance we can generalize that into a macro that takes "af" as an > arg, and returns the number of bytes the af needs? The problem with this is that the size is normally needed for an array declaration, and sometimes the address family is not yet specified. > Or has it been > decided that the inet_* routines can't be made to work for types other > than INET and INET6, so trying making the general is pointless? I don't think we've decided this yet, and this will probably wait until someone tries to add support for another address family to the functions. Rich Stevens ------------------------------------------------------------------------------ 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 Thu Jan 2 14:45:32 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01157; Thu, 2 Jan 97 14:45:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01151; Thu, 2 Jan 97 14:45:18 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA00794; Thu, 2 Jan 1997 14:37:03 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA12429 for ; Thu, 2 Jan 1997 14:37:03 -0800 Received: from inner.net (beavis.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.8.2/42) with ESMTP id WAA05596; Thu, 2 Jan 1997 22:36:35 GMT Message-Id: <199701022236.WAA05596@inner.net> To: "W. Richard Stevens" Cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: (IPng 2675) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: Your message of "Thu, 02 Jan 1997 15:05:12 MST." <199701022205.PAA07273@kohala.kohala.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Thu, 02 Jan 1997 17:36:29 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199701022205.PAA07273@kohala.kohala.com>, you write: >Obviously we could provide a way to return the received hop limit, if >people think it's needed. I've never needed it, and traceroute is the >only application that I am familiar with that uses it. I've implemented an IPPROTO_IPV6/IPV6_HOPLIMIT control message similar to the messages in the advanced API. cmsg_data is an int. On send, -1 means use the default hop limit, 0 <= x <= 255 use hop limit x. On receive, the value is the received hop limit of the inner IPv6 header. Receiving requires setting an IPPROTO_IPV6/IPV6_HOPLIMIT sockopt to 1 first. This is useful for ping, traceroute, RIPng, and radvd. >Well first I need to reread the minutes and what was finally decided on >the priority field. Effort went into making certain that the flow label >and priority fields could be set by both TCP and UDP clients, and returned >to both TCP and UDP servers. I hate to rip out the text now, only to find >a need to add it in one year. Obviously we need to change the handling of >the priority field to what was decided by the Working Group, and perhaps >we could add some text about the flow lavel stating that it's use is still >experimental and there may be restrictions as to what an application can >set its value to? I would like to see the priority stuff go away, at least until it's better baked. The flow IDs continue to make me slightly nervous, since nobody has really made it clear how I'm supposed to get the magic cookies I'm supposed to be putting in there (especially in the context of, for example, the getaddrinfo() function). >It's not needed: the sin6_len field need not be set. (The previous version >of the I-D showed it being set, but that's not needed and just confuses >the code.) While POSIX may not require it, it is, IMO, good practice. And some people's library functions won't forgive you if you fail to do it ;) >Unfortunately all Posix specifies is the names. I do have a functions >similar to strerror() for these codes, and it's just a bunch of if's >comparing against the names (i.e., not a simple index into an array). I'd suggest a "gai_strerror()" function for this purpose. Look at the NRL source tree and see how many times I use "nrl_gai_strerror()". It has proven very useful. Strictly speaking, it's outside the scope of the spec. But so's getnameinfo(). >The DNS is an example and in this case (assuming a host with one interface) >you'll get back two addrinfo structures (remember, this function returns a >linked list of addrinfo structures), one for TCP port 53 and one for UDP >port 53. So it's legal, but not too practical, because most applications >know whether they want a stream socket or a datagram socket, and should >then say so. By my read of the POSIX spec, it's just as valid for you to only get the TCP one back (the spec really doesn't define well what you end up getting back). >> Or has it been >> decided that the inet_* routines can't be made to work for types other >> than INET and INET6, so trying making the general is pointless? > >I don't think we've decided this yet, and this will probably wait until >someone tries to add support for another address family to the functions. The inet_pton and inet_ntop functions in the NRL support library support AF_INET, AF_INET6, AF_LINK, AF_NS, and AF_ISO (though the last three are untested). With addr2ascii and ascii2addr, I believe the plan was to make the functions support all families. Then some people started whining that an IETF spec shouldn't be defining API functions for ISO or XNS protocols, and we ended up with the current situation where the functions are really only supposed to support AF_INET and AF_INET6. Personally, I use getaddrinfo() and getnameinfo(). -Craig ------------------------------------------------------------------------------ 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 Thu Jan 2 15:53:13 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01263; Thu, 2 Jan 97 15:53:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01257; Thu, 2 Jan 97 15:53:01 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA09507; Thu, 2 Jan 1997 15:44:46 -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 PAA24552 for ; Thu, 2 Jan 1997 15:43:43 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA90314; Thu, 2 Jan 1997 18:40:45 -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 SAA36932; Thu, 2 Jan 1997 18:43:20 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15202; Thu, 2 Jan 1997 18:43:31 -0500 Message-Id: <9701022343.AA15202@ludwigia.raleigh.ibm.com> To: "W. Richard Stevens" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2676) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: Your message of "Thu, 02 Jan 1997 15:05:12 MST." <199701022205.PAA07273@kohala.kohala.com> Date: Thu, 02 Jan 1997 18:43:31 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Obviously we could provide a way to return the received hop limit, if >people think it's needed. I've never needed it, and traceroute is the >only application that I am familiar with that uses it. The idea was for routing protocols to be able to receive packets (e.g., updates from neighboring routers) and verify that the hopcount was 255 on receipt, guaranteeing that the packet had not been *forwarded* by a router. This is a stronger check than sending a packet to/from a link-local address, since a tunneled packet might get resent on a link even though it originated from a remote link. If we could insure that routers never did such things, the check wouldn't be needed. But such checks must be made explicitely by routers, which means there will be cases where some products neglect to check for all the cases. I think it would be useful, but have to admit that with both RIP and OSPF not using it, the likelihood of it actually being used in practice has gone down. Given that it doesn't seem hard to implement, and may yet find a use, I'd say put it in the spec. We may regret leaving it out. >Well first I need to reread the minutes and what was finally decided on >the priority field. Unfortunately, this issue still appears to be open. It's not that I don't want to see this stuff defined. I just feel like we're guessing a little too much about how to make it work right (e.g., there are questions about who allocates (unique) Flow Labels and how an application requests them). I get uncomfortable defining APIs for things that are not a done deal. I'd not defining anything to defining it wrong (in which case it would have to be redefined anyway). Would it be feasible to pull out all the stuff on setting/using the Priority/Flow Label fields with the intent of issuing a followup document that covers just those parts? Getting some implementation experience here might be a good thing. We'd need to leave some stuff in obviously (e.g., space in the sockaddr_in6 definition) but could we remove just the part of the API that deals with the semantics of how they are used? (I'm thinking out loud a bit here - this may not be all that easy.) >I find these on a 4.4BSD-derived kernel: >#define INADDR_ANY (u_long)0x00000000 >#define INADDR_BROADCAST (u_long)0xffffffff /* must be masked */ >#define INADDR_NONE 0xffffffff /* -1 return */ >#define INADDR_UNSPEC_GROUP (u_long)0xe0000000 /* 224.0.0.0 */ >#define INADDR_ALLHOSTS_GROUP (u_long)0xe0000001 /* 224.0.0.1 */ >#define INADDR_MAX_LOCAL_GROUP (u_long)0xe00000ff /* 224.0.0.255 */ Perhaps we should add definitions for the well-known addresses that have already been defined? RFC 1884 defines link-local multicast addresses for all-nodes, all-routers and dhcp-server. Service location has one (or more?) as well. I don't feel real strongly about adding these. > >> > struct sockaddr_in6 sin6; >> > . . . >> > sin6.sin6_family = AF_INET6; >> > sin6.sin6_flowinfo = 0; >> > sin6.sin6_port = htons(23); >> > sin6.sin6_addr = in6addr_loopback; /* structure assignment */ >> > . . . >> >> How about adding "#ifdef SIN6_LEN" code to the example. >It's not needed: the sin6_len field need not be set. (The previous version >of the I-D showed it being set, but that's not needed and just confuses >the code.) But the above code wouldn't work on a 4.4 BSD system. Right? Because the length field is not explicitely set, it contains a random value (in a 4.4 system). That will surely confuse the followup code (e.g., a subsequent connect). My point was to try to encourage programmers to include the ifdef code, even if they didn't need it on their 4.3-derived system, to facilitate portability. > >> > IPV6_ADD_MEMBERSHIP >> > >> > Join a multicast group on a specified local interface. If >> > the interface index is specified as 0, the kernel chooses the >> > local interface by looking up the multicast group in the >> > normal IPv6 routing table and using the resulting interface. >> >> The wording of the last sentence seems awfully implementation >> dependent (and thus possibly incorrect). Shouldn't the API simply say >> the kernel picks an interface in this case? >We can certainly leave it out, but again, I always opt for adding more >for clarity, than leaving something out (obscurity). The original IPv4 >(Deering) multicast code does it this way for IPv4. We could either add >a disclaimer ("For example, one way might be ...") or delete it. This was minor nit for me. Adding a "for example" would be great, since I felt that the existing text suggested a bit too much how it *had* to be implemented. >Fine. The example works in either the Bourne or Korn shells. But not in csh, bash, ... > >> Also, I wasn't entirely clear what precedence applied when various >> combinations of the "three ways to set RES_USE_INET6" were in >> use. It's not too hard to make a guess at what a reasonable ordering >> should be, but I think the document should spell this out. >Agreed, but realize that since there is just an "inet6" option and not a >"noinet6" option, if the option is turned on by any of the three methods, >it's on. I think what's important is the scope of what the option affects >when it's turned on with the three different methods, and I think that is >spelled out already (p. 21): setting res_options affects only that process; >setting the environment variable affects any process that sees that >environment variable (depends on the shell and whether you export it or >not), and setting the "options" in the resolver configuration file affects >all applications on the host. I'm not sure what else to say? I'm probably making too big a deal about this. However, the current specification doesn't allow the user to override the setting in the resolver configuration file (i.e.., to turn it off). Maybe this is a good thing though? >Your summary is correct but I am not certain if this is "broken" or a >"feature" :-) What's described is what Paul Vixie has had implemented >for the past 6 months. Hmm, it only becomes a feature if it is too hard to change at this point, and I'd hope we aren't that far along yet... :-) >It does return multiple AAAA records (if one or more found) or multiple >A records (if no AAAA records, and RES_USE_INET6 is set), but it does >not mix A and AAAA records. Doing so would require multiple queries >to the name server. Actually, I'm pretty uncomfortable with the notion of gethostbyname() *ever* returning v6 addresses at all. This has the potential of breaking existing v4 applications that aren't modified, which seems like a show-stopper. Am I the only one with this concern? The way I see it, there are some legacy applications that may (essentially) never change (e.g., binaries for which the source can't be located). To prevent them from breaking as a site transitions to v6, a system administrator will *never* be able to set RES_USE_INET6 globally without risking breaking something somewhere. At the very least, applications *must* be recompiled, so they get properly sized sockaddr_in6, if they are actually going to use v6. Thus, I fear that in practice RES_USE_INET6 can't ever be set globally. Which leads me to question whether we've defined it right. Once someone goes to the trouble of upgrading the application, they should be using gethostbyname2() and stop using the older form (this is a *trivial* change, since it's pretty much textual). The right thing to do then would be to try v6 addresses (first), and if none of them worked (e.g., connect failed), then invoke gethostbyname2("foo", AF_INET) and repeat the process. Do folks agree/disagree that this is the behavior we want to encourage? >> > - gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6 >> > addresses with the h_length member of the hostent structure set >> > to 16. >> >> Does it continue to also supply regular (non IPv4-mapped) AAAA >> addresses as well? (I suspect that it does, but it might help to add >> a sentence to that effect.) >Yes, but only if the 2nd argument is AF_INET6. When the 2nd argument is >AF_INET it does just what it says above. OK. I think I misunderstood this before. It is not possible to invoke gethostbyname2() and get back *both* normal v6 address and v4-mapped addresses simultaneously. You have to make two calls. >> Not what is meant by "current thinking". Is this an open issue we need >> to nail down? >It was bashed around on this mailing list starting around May 20, 1996 >by Paul Vixie and a few others. I am not aware of any "final/official" >decision (I wasn't at Montreal and didn't see anything in the minutes >about this) but what is described is again what Paul finally >implemented. Part of my concern with this text is it the way it is written (i.e., the words "current thinking") suggests a lack of confidence that we have defined it right. If there is agreement that the current text is OK, then we should make the text more definitive. If we're not sure, ... >Yes. What I should have done is label the four bullets at the top of p. 23 >as 1, 2, 3, and 4, and then state that all four steps are executed in order. Yes, that would help. >> > int getaddrinfo(const char *hostname, const char *servname, >> > const struct addrinfo *hints, >> > struct addrinfo **res); >> >> What happens if the user supplies hostname and servname, but in the >> hints section doesn't specific ai_socktype. Is this legal? What does >> the call return? >The DNS is an example and in this case (assuming a host with one interface) >you'll get back two addrinfo structures (remember, this function returns a >linked list of addrinfo structures), one for TCP port 53 and one for UDP >port 53. So it's legal, but not too practical, because most applications >know whether they want a stream socket or a datagram socket, and should >then say so. Here is a suggestion. If the user fails to specify either stream or datagram, have the call return FAIL. That would force the programmer to do it right. What I want to prevent is a programmer neglecting to set stream/datagram, have FreeBSD return the TCP one first (where the program works fine), but have Linux return UDP first, causing the program to fail when run Linux platforms. >> Shouldn't the "char *host" and "char *serv" be "const" as well? >No--those are the returned strings. Right. my mistake. >> > The function does not >> > modify the buffer pointed to by dst if the conversion fails. The >> >> The above appears in at least two places. Is there any reason for this >> requirement? It seems like an implementation detail to me. Why would >> an application care? Why is that specified in the API? >The first time I started seeing this was in the ANSI C standard, years >ago. I assume the statement is added so that users can count on this >behavior, else it's implementation-dependent. OK. Seems a bit strange to me though. >> There are other functions (e.g., if_indextoname(unsigned >> int ifindex, char *ifname)) that don't include a size argument. >I'll add a length field here, if requested, but email since the draft >was sent out indicate that the existing IFNAMSIZ can be used by the caller >to set the size of the array. Right. I agree its *not* needed, but the same argument can be made for the strings passed into inet_ntop routines, and the draft does require lengths there. I dislike uncompelling inconsistencies. :-( Thanks, 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 Thu Jan 2 17:28:55 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01505; Thu, 2 Jan 97 17:28:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01499; Thu, 2 Jan 97 17:28:43 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA21062; Thu, 2 Jan 1997 17:20:29 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA09861 for ; Thu, 2 Jan 1997 17:20:20 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id SAA12685; Thu, 2 Jan 1997 18:19:06 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id SAA07533; Thu, 2 Jan 1997 18:19:04 -0700 (MST) Message-Id: <199701030119.SAA07533@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 2 Jan 1997 18:19:03 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Craig Metz Subject: (IPng 2677) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" Cc: Thomas Narten , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Jan 2, 5:36pm you write:] > > >It's not needed: the sin6_len field need not be set. (The previous version > >of the I-D showed it being set, but that's not needed and just confuses > >the code.) > > While POSIX may not require it, it is, IMO, good practice. And some > people's library functions won't forgive you if you fail to do it ;) I disagree strongly. Every socket function provides the length of the socket address structure as either an input argument or a value-result argument. The only use of this field is when multiple sockaddrs are being passed one after the other, as is done with some of the 4.4BSD interface functions. Normal code should never have to set this field, or look at it. Period. It's too late in the game to start passing the length of these structures in the sinX_len member, instead of as an argument, or you'll start defining functions that only work with the 4.4BSD extended structures (which aren't required by Posix) and break all existing applications at the source level. Rich Stevens ------------------------------------------------------------------------------ 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 Thu Jan 2 19:20:18 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01634; Thu, 2 Jan 97 19:20:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01628; Thu, 2 Jan 97 19:20:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA00750; Thu, 2 Jan 1997 19:11:51 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA04872 for ; Thu, 2 Jan 1997 19:11:51 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA09698; Thu, 2 Jan 1997 22:03:04 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA15653; Thu, 2 Jan 1997 22:03:04 -0500 Message-Id: <9701030303.AA15653@wasted.zk3.dec.com> To: Thomas Narten Cc: "W. Richard Stevens" , ipng@sunroof.eng.sun.com Subject: (IPng 2678) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: Your message of "Thu, 02 Jan 97 18:43:31 -0400." <9701022343.AA15202@ludwigia.raleigh.ibm.com> Date: Thu, 02 Jan 97 22:03:03 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Would it be feasible to pull out all the stuff on setting/using the >Priority/Flow Label fields with the intent of issuing a followup >document that covers just those parts? Getting some implementation >experience here might be a good thing. We'd need to leave some stuff >in obviously (e.g., space in the sockaddr_in6 definition) but could we >remove just the part of the API that deals with the semantics of how >they are used? (I'm thinking out loud a bit here - this may not be all >that easy.) I don't really care as long as room is left in sockaddr_in6 but IPv6 implemetors need the flow-id for RSVP work today right now. >>I find these on a 4.4BSD-derived kernel: > >>#define INADDR_ANY (u_long)0x00000000 >>#define INADDR_BROADCAST (u_long)0xffffffff /* must be masked */ >>#define INADDR_NONE 0xffffffff /* -1 return */ >>#define INADDR_UNSPEC_GROUP (u_long)0xe0000000 /* 224.0.0.0 */ >>#define INADDR_ALLHOSTS_GROUP (u_long)0xe0000001 /* 224.0.0.1 */ >>#define INADDR_MAX_LOCAL_GROUP (u_long)0xe00000ff /* 224.0.0.255 */ >Perhaps we should add definitions for the well-known addresses that >have already been defined? OK your repeating your self. I say read the spec where addresses are defined for the second time. So NO. > >> > struct sockaddr_in6 sin6; >> > . . . >> > sin6.sin6_family = AF_INET6; >> > sin6.sin6_flowinfo = 0; >> > sin6.sin6_port = htons(23); >> > sin6.sin6_addr = in6addr_loopback; /* structure assignment */ >> > . . . >> >> How about adding "#ifdef SIN6_LEN" code to the example. >It's not needed: the sin6_len field need not be set. (The previous version >of the I-D showed it being set, but that's not needed and just confuses >the code.) >But the above code wouldn't work on a 4.4 BSD system. Right? Because >the length field is not explicitely set, it contains a random value >(in a 4.4 system). That will surely confuse the followup code (e.g., a >subsequent connect). My point was to try to encourage programmers to >include the ifdef code, even if they didn't need it on their >4.3-derived system, to facilitate portability. Its not necessary the addresses are not variable length. >>Fine. The example works in either the Bourne or Korn shells. >But not in csh, bash, ... Yes it does in csh. >> >>> Also, I wasn't entirely clear what precedence applied when various >>> combinations of the "three ways to set RES_USE_INET6" were in >>> use. It's not too hard to make a guess at what a reasonable ordering >>> should be, but I think the document should spell this out. >>Agreed, but realize that since there is just an "inet6" option and not a >>"noinet6" option, if the option is turned on by any of the three methods, >>it's on. I think what's important is the scope of what the option affects >>when it's turned on with the three different methods, and I think that is >>spelled out already (p. 21): setting res_options affects only that process; >>setting the environment variable affects any process that sees that >>environment variable (depends on the shell and whether you export it or >>not), and setting the "options" in the resolver configuration file affects >>all applications on the host. I'm not sure what else to say? >I'm probably making too big a deal about this. However, the current >specification doesn't allow the user to override the setting in the >resolver configuration file (i.e.., to turn it off). Maybe this is a >good thing though? I think so too. >>Your summary is correct but I am not certain if this is "broken" or a >>"feature" :-) What's described is what Paul Vixie has had implemented >>for the past 6 months. > >Hmm, it only becomes a feature if it is too hard to change at this >point, and I'd hope we aren't that far along yet... :-) Its not like Paul did this in a vaccum there was a discussion and he went forward if its wrong it will get fixed. Thank god progress is happening in BIND T8.1A and its still being discussed here. I think thats great as a lot of this IETF discussion is simply bogus at this point IMO. >Actually, I'm pretty uncomfortable with the notion of gethostbyname() >*ever* returning v6 addresses at all. This has the potential of >breaking existing v4 applications that aren't modified, which seems >like a show-stopper. Am I the only one with this concern? I am not this cannot happen as long as the option is not set. >The way I see it, there are some legacy applications that may >(essentially) never change (e.g., binaries for which the source can't >be located). To prevent them from breaking as a site transitions to >v6, a system administrator will *never* be able to set RES_USE_INET6 >globally without risking breaking something somewhere. At the very >least, applications *must* be recompiled, so they get properly sized >sockaddr_in6, if they are actually going to use v6. Thus, I fear that >in practice RES_USE_INET6 can't ever be set globally. Which leads me >to question whether we've defined it right. It says right in the spec the above should not be globally set until all applications are capable of dealing with IPv6. I think its covered. >Once someone goes to the trouble of upgrading the application, they >should be using gethostbyname2() and stop using the older form (this >is a *trivial* change, since it's pretty much textual). The right >thing to do then would be to try v6 addresses (first), and if none of >them worked (e.g., connect failed), then invoke gethostbyname2("foo", >AF_INET) and repeat the process. Do folks agree/disagree that this is >the behavior we want to encourage? I can do this without anyone agreeing with you on this list with the spec the way it is now. In fact this is exactly how I used it in an application. But if you don't want to do it this way then you have other options. Which we are told folks would like to have. What you want is possible right now with the spec. Whats your issue? I don't get it? Or is it you want to make it that there is not other behavior possible? I hope not??? >>> > - gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6 >>> > addresses with the h_length member of the hostent structure set >>> > to 16. >>> >>> Does it continue to also supply regular (non IPv4-mapped) AAAA >>> addresses as well? (I suspect that it does, but it might help to add >>> a sentence to that effect.) > >>Yes, but only if the 2nd argument is AF_INET6. When the 2nd argument is >>AF_INET it does just what it says above. > >OK. I think I misunderstood this before. It is not possible to invoke >gethostbyname2() and get back *both* normal v6 address and v4-mapped >addresses simultaneously. You have to make two calls. I could implement my resolver that way but again I would not. Laissez-Faire.... >Part of my concern with this text is it the way it is written (i.e., >the words "current thinking") suggests a lack of confidence that we >have defined it right. If there is agreement that the current text is >OK, then we should make the text more definitive. If we're not sure, >... Current thinking means we are off implementing and it appears to be a good idea. Next year or at Connectathon we may learn new ideas. Transition is not finite and cannot be 100% defined until many many users have actually done it and lived through it. All we can do is give it our best shot and that is "current thinking". The good news is many of us have spent 4 years preparing this spec first defined by Bob Gilligan and has been implemented a number of times since SIP and was even implemented to support TUBA. /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 Fri Jan 3 06:35:28 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00431; Fri, 3 Jan 97 06:35:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00425; Fri, 3 Jan 97 06:35:15 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA08750; Fri, 3 Jan 1997 06:27:00 -0800 Received: from ) by Sun.COM (4.1/mail.byaddr) id AA12199 for ipng@sunroof.Eng; Thu, 2 Jan 97 20:29:58 PST Received: from kalae.kohala.com(206.62.226.35) by sun-barr.EBay.Sun.COM (SMI-8.7.4/SMI-SVR4) id IAA14415; Thu Jan 2 17:37:45 1997 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id SAA12697; Thu, 2 Jan 1997 18:34:49 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id SAA07570; Thu, 2 Jan 1997 18:34:47 -0700 (MST) Message-Id: <199701030134.SAA07570@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 2 Jan 1997 18:34:47 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Thomas Narten Subject: (IPng 2679) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Jan 2, 6:43pm you write:] > >> > struct sockaddr_in6 sin6; > >> > . . . > >> > sin6.sin6_family = AF_INET6; > >> > sin6.sin6_flowinfo = 0; > >> > sin6.sin6_port = htons(23); > >> > sin6.sin6_addr = in6addr_loopback; /* structure assignment */ > >> > . . . > >> > >> How about adding "#ifdef SIN6_LEN" code to the example. > > >It's not needed: the sin6_len field need not be set. (The previous version > >of the I-D showed it being set, but that's not needed and just confuses > >the code.) > > But the above code wouldn't work on a 4.4 BSD system. Right? No, it would work just fine. There is a magic piece of code in 4.4BSD, the sockargs() function in the kernel, that always copies the length argument from the process (i.e., the 3rd argument to bind(), connect(), the 6th argument to sendto()) and stores this in the sa_len member, *overwriting* whatever the user stored there. This way the user process *never* has to set this field. It's only real use (from the top of my head) is upon return from some of the routing socket commands, when multiple socket address structures can be returned, and with some ioctls (SIOCGIFCONF) and then each socket address structure is self-defined by the family and length members. (The kernel also uses this field internally, but that's not of interest here.) It's always set by the kernel upon return from the functions that return a socket address structure (i.e., accept(), recvfrom(), getsockname(), getpeername()) but 100% of the applications that I've seen just ignore this and use the returned value-result argument instead. So the bottom line is that only nontrivial applications need to worry about this field, and then only upon return from a system call, and this should only affect a small number of applications. Thanks for bringing this up, as it's a common misconception. Rich Stevens ------------------------------------------------------------------------------ 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 Fri Jan 3 10:32:06 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00941; Fri, 3 Jan 97 10:32:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00935; Fri, 3 Jan 97 10:31:54 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA07590; Fri, 3 Jan 1997 10:23:40 -0800 Received: from inner.net ([198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA02550 for ; Fri, 3 Jan 1997 04:25:31 -0800 Received: from inner.net (beavis.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.8.2/42) with ESMTP id MAA05868; Fri, 3 Jan 1997 12:24:17 GMT Message-Id: <199701031224.MAA05868@inner.net> To: "W. Richard Stevens" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2680) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: Your message of "Thu, 02 Jan 1997 18:19:03 MST." <199701030119.SAA07533@kohala.kohala.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Fri, 03 Jan 1997 07:23:51 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199701030119.SAA07533@kohala.kohala.com>, you write: >I disagree strongly. Every socket function provides the length of the >socket address structure as either an input argument or a value-result >argument. The only use of this field is when multiple sockaddrs are >being passed one after the other, as is done with some of the 4.4BSD >interface functions. Normal code should never have to set this field, >or look at it. Period. It's too late in the game to start passing the >length of these structures in the sinX_len member, instead of as an >argument, or you'll start defining functions that only work with the >4.4BSD extended structures (which aren't required by Posix) and break >all existing applications at the source level. I don't argue that, for compatibility with systems lacking sa_len, functions need to provide a parameter for the sockaddr length as they do now. Most vendors lacking sa_len aren't in any rush to add it. I do argue with your assertion that "[T]he only use of this field is when multiple sockaddrs are being passed one after the other." The sa_len field has proven very useful in writing PF-independent code. It is usually not impossible to get around in practice, but doing so is less efficient. Once you fail to initialize this field, however, you have made it impossible to use the sa_len field to benefit your application. I see absolutely no reason not to initialize the sa_len field in an application if it is present (obviously, ifdefs need to wrap the store). At worst, it is a wasted byte store. This is a programming analog to the networking philosophy of "be conservative of what you send and liberal in what you accept." -Craig ------------------------------------------------------------------------------ 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 Fri Jan 3 14:10:41 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01479; Fri, 3 Jan 97 14:10:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01473; Fri, 3 Jan 97 14:10:29 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA14334; Fri, 3 Jan 1997 14:02:14 -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 OAA23271 for ; Fri, 3 Jan 1997 14:02:11 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA10179; Fri, 3 Jan 1997 16:54:51 -0500 (EST) Received: by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23183; Fri, 3 Jan 1997 16:54:50 -0500 Date: Fri, 3 Jan 1997 16:54:50 -0500 From: Jack McCann USG Message-Id: <9701032154.AA23183@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2681) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" Cc: mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten suggested adding a way to get the hop limit on received packets. I agree. I had been planning to suggest adding a hop limit field to the in6_pktinfo structure defined in the advance API spec. Thomas Narten also wrote: > Having said that, however, however, it seems OSPFv6 just multicasts to > the link-local address with a Hop Limit of 1, and RIPng doesn't > bother. So maybe this point is moot now. :-( draft-ietf-rip-ripng-04.txt specifies use of the hop limit 255 check, so adding this to the in6_pktinfo could be used here. (In fact that's what we've done in our implementation.) I was thinking OSPFv6 should also include the 255 check, and have an outstanding action for myself to bring that up on the ospf list. Richard Stevens wrote with regard to gethostbyname(): >It does return multiple AAAA records (if one or more found) or multiple >A records (if no AAAA records, and RES_USE_INET6 is set), but it does >not mix A and AAAA records. Doing so would require multiple queries >to the name server. Paul Vixie has been contemplating a way to get both AAAA and A records with a single query, sounds like a useful thing, I'm hoping we hear more from Paul on this. I'd also like to float the general suggestion that the structure definitions in at least the advanced API spec if not both basic and advanced be "softened". What I mean is specify the structure members that are required to be there, but allow an implementation to include addition fields if desired. For example, the in6_pktinfo structure is defined as: struct in6_pktinfo { int ipi6_ifindex; struct in6_addr ipi6_addr; }; The "softened" specification might read something like this: The header defines the in6_pktinfo structure that includes at least the following members: int ipi6_ifindex struct in6_addr ipi6_addr An implementation might choose to include additional fields. An application concerned with portability would rely only on the required fields, while another application might choose to sacrifice a bit of portability and use the added fields. - Jack McCann ------------------------------------------------------------------------------ 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 Fri Jan 3 14:42:54 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01542; Fri, 3 Jan 97 14:42:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01536; Fri, 3 Jan 97 14:42:42 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA20753; Fri, 3 Jan 1997 14:34:27 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA04954 for ; Fri, 3 Jan 1997 14:34:25 -0800 Received: from inner.net (beavis.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.8.2/42) with ESMTP id WAA06388; Fri, 3 Jan 1997 22:34:18 GMT Message-Id: <199701032234.WAA06388@inner.net> To: Jack McCann USG Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2682) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: Your message of "Fri, 03 Jan 1997 16:54:50 EST." <9701032154.AA23183@wasted.zk3.dec.com> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Fri, 03 Jan 1997 17:34:09 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <9701032154.AA23183@wasted.zk3.dec.com>, you write: >Paul Vixie has been contemplating a way to get both AAAA and A records >with a single query, sounds like a useful thing, I'm hoping we hear >more from Paul on this. There is a way to do this, getaddrinfo(). -Craig ------------------------------------------------------------------------------ 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 Fri Jan 3 16:54:17 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01729; Fri, 3 Jan 97 16:54:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01723; Fri, 3 Jan 97 16:54:05 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA12412; Fri, 3 Jan 1997 16:45:50 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA18773 for ; Fri, 3 Jan 1997 16:45:46 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id RAA14162; Fri, 3 Jan 1997 17:45:45 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id RAA09394; Fri, 3 Jan 1997 17:45:44 -0700 (MST) Message-Id: <199701040045.RAA09394@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Fri, 3 Jan 1997 17:45:43 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Jack McCann USG , ipng@sunroof.eng.sun.com Subject: (IPng 2683) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Fri, 3 Jan 1997 16:54:50 -0500 > From: Jack McCann USG > > I'd also like to float the general suggestion that the structure > definitions in at least the advanced API spec if not both basic > and advanced be "softened". What I mean is specify the structure > members that are required to be there, but allow an implementation > to include addition fields if desired. This is indeed, what all the Posix specs say for all the structures that they define. Makes sense. Rich Stevens ------------------------------------------------------------------------------ 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 Fri Jan 3 16:55:01 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01736; Fri, 3 Jan 97 16:55:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01730; Fri, 3 Jan 97 16:54:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA12519; Fri, 3 Jan 1997 16:46:23 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA18885 for ; Fri, 3 Jan 1997 16:46:22 -0800 From: Masataka Ohta Message-Id: <199701040044.JAA00735@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA00735; Sat, 4 Jan 1997 09:44:00 +0900 Subject: (IPng 2684) Re: larger AS/RD space for v6? To: tli@jnx.com (Tony Li) Date: Sat, 4 Jan 97 9:43:59 JST Cc: bound@zk3.dec.com, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, bgp@ans.net In-Reply-To: <199612241936.LAA04664@chimp.jnx.com>; from "Tony Li" at Dec 24, 96 11:36 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony; > I'd like to point out that ANYTHING that "knows" about the internal > structure of the address is probably a mistake. It constrains the future > flexibility of the system, thereby eliminating future adaptability. Basic > engineering demands that create the absolute minimum in internal > interdependencies. Thus, the address should be wholly opaque outside of > the routing system. Any policy routing system MUST "know" about the internal structure of the address to the extent necessary for (fine or coarse) policy control. For example, IPv4 routing systems know about lasses A, B and C. Or, do you think classfull addressing mistake? Then, with CIDRized class A, routing systems (even global ones) must know about the subnet masks. No, this is not a proper example, because CIDR is a mistake. :-) 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 Fri Jan 3 17:11:58 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01839; Fri, 3 Jan 97 17:11:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01833; Fri, 3 Jan 97 17:11:41 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA15014; Fri, 3 Jan 1997 17:03:25 -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 RAA22297 for ; Fri, 3 Jan 1997 17:03:25 -0800 From: Masataka Ohta Message-Id: <199701040101.KAA00799@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA00799; Sat, 4 Jan 1997 10:01:26 +0900 Subject: (IPng 2685) Re: (mobile-ip) Re: Discussion about new direction for mobile IP To: charliep@watson.ibm.com (Charlie Perkins) Date: Sat, 4 Jan 97 10:01:26 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com, mobile-ip@hosaka.SmallWorks.COM, dbj@cs.cmu.edu In-Reply-To: <9701021432.AA20957@np5.watson.ibm.com>; from "Charlie Perkins" at Jan 2, 97 9:32 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Could you explain what is "ingress filtering by border routers" > > for those of us who are not in mobile WG? > > The subject is not really part of the mobile-IP working group charter. > However, it has become relevant. Take a look at the following draft: > draft-ferguson-ingress-filtering-01.txt > Briefly, network administrators are urged to configure their > border routers so that all packets emanating from their > administrative domain are guaranteed to have a source address > which belongs to one of the networks in their domain. Thank you. But, the draft is bogus. It is only effective in small ISP configuration where "downstream" exists. Truly transit ISP's just don't have "downstream". The propoer protection is to make TCP and other protocols weakly secure, that is, make attack possible only when packets are "EXCHANGED", not just "RECEIVED". Making TCP connection table lager is a way. > > and build an additional one on top of the broken current > > one. > > No, we want to take the same basic algorithms and apply a significant > change to the way that the care-of address is interpreted and used. Yes. It seems to me that you apply same basic algorithm twice, once in a broken way and again in a proper way. > I'm not quite sure how to constructively interpret your use of the > word "broken" here. It is constructive to call unconstructive proposals "broken". 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 Sat Jan 4 07:06:10 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02296; Sat, 4 Jan 97 07:06:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02290; Sat, 4 Jan 97 07:05:57 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA23558; Sat, 4 Jan 1997 06:57:40 -0800 From: bound@ZK3.DEC.COM Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA18747 for ; Sat, 4 Jan 1997 06:57:40 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA28038; Sat, 4 Jan 1997 09:54:34 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23523; Sat, 4 Jan 1997 09:54:28 -0500 Message-Id: <9701041454.AA23523@wasted.zk3.dec.com> To: Masataka Ohta Cc: tli@jnx.com (Tony Li), bound@ZK3.DEC.COM, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2686) Re: larger AS/RD space for v6? In-Reply-To: Your message of "Sat, 04 Jan 97 09:43:59 +0200." <199701040044.JAA00735@necom830.hpcl.titech.ac.jp> Date: Sat, 04 Jan 97 09:54:28 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, I understood what you mean't... 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 Sat Jan 4 08:22:52 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02387; Sat, 4 Jan 97 08:22:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02381; Sat, 4 Jan 97 08:22:40 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA26744; Sat, 4 Jan 1997 08:14:22 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA24938 for ; Sat, 4 Jan 1997 08:14:23 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA26151; Sat, 4 Jan 1997 11:05:40 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27539; Sat, 4 Jan 1997 11:05:39 -0500 Message-Id: <9701041605.AA27539@wasted.zk3.dec.com> To: Brandon Black Cc: Masataka Ohta , Tony Li , bound@zk3.dec.com, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2687) Re: larger AS/RD space for v6? In-Reply-To: Your message of "Sat, 04 Jan 97 09:25:06 CST." Date: Sat, 04 Jan 97 11:05:39 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brandon, I agree. I also think 8+8 (or where it will end up) will add additional benefits to the CIDR paradigm and solves the Multihoming problem too for large organizations. The only part I don't like and will battle is that when a packet leaves a host I do not think anyone should step on any parts of the 128bit address space at site border routers or from ISP to ISP. I have given Mike this input at San Jose privately and also a means that this part of 8+8 is unnecessary and still can support the objectives of his proposal. It has a lot to do with how 8+8 is done for DNS and the root servers. I also do not believe we can assume any ESD can be globally unique by itself at any root Internet server (e.g. .com, edu, .arpa). I say this given the technology premises we have defined in IPv6 Neighbor Discovery and Autoconfiguration (Stateless and DHCPv6). But this does not mean 8+8 does not support dynamic renumbering by replacing the routing goop. It is all in the interpretation of 8+8 and what part the host transport mechanisms use (ESD) and what part the application layer uses (128bits). I think for our IPng Interim meeting Feb 27 and 28 we need to devote the entire two days to 8+8 and not even try to do other stuff. /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 Sat Jan 4 08:31:16 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02399; Sat, 4 Jan 97 08:31:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02393; Sat, 4 Jan 97 08:31:05 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA27297; Sat, 4 Jan 1997 08:22:48 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA25700 for ; Sat, 4 Jan 1997 08:22:49 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA00635; Sat, 4 Jan 1997 11:15:54 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28121; Sat, 4 Jan 1997 11:15:49 -0500 Message-Id: <9701041615.AA28121@wasted.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com, deering@cisco.com, deering@parc.xerox.com, bound@zk3.dec.com Subject: (IPng 2688) Re: Interim IPng Working Group Meeting In-Reply-To: Your message of "Fri, 20 Dec 96 15:26:56 PST." <3.0.32.19961220152614.0077a39c@mailhost.ipsilon.com> Date: Sat, 04 Jan 97 11:15:49 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, I would suggest that the entire two days be used for 8+8 and not even attempt any other agenda items. This is just too critical to IPv6. I also have a request of both you and Steve OK. At San Jose both of you presented new ideas or adjustments to working ideas (like source address selection) we are all working on and need to define in some cases. I know both of you are really busy and Steve switched companies. I would request that you both please select X amount of time as WG Chairs to be active on the email discussions and work with us as colleagues to send your individual ideas to the list for review before we get at an IETF meeting. IETF meetings are getting pretty useless to do serious technical work and analysis and we need ideas on the mail list prior to a meeting. So if Steve or you or any coalition wants to present a solution worked offline or just came into someones head I for one would like to see it on the mail list at least a few weeks before Feb 27 or 28 for the 8+8 discussion. In addition it will permit input from the WG that cannot attend or has not budgeted interim IPng WG travel with their source of funding for IETF meetings. Because one is a WG chair does not remove one from the un-documented community responsibility of getting ideas in time to the mail lists or a draft for discussion to the WG prior to an IETF meeting. 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 Sat Jan 4 08:37:39 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02411; Sat, 4 Jan 97 08:37:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02405; Sat, 4 Jan 97 08:37:28 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA27552; Sat, 4 Jan 1997 08:29:11 -0800 Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA26546 for ; Sat, 4 Jan 1997 08:29:11 -0800 Received: from psp.demon.co.uk ([158.152.26.54]) by relay-9.mail.demon.net id aa901227; 4 Jan 97 15:46 GMT Message-Id: Date: Sat, 4 Jan 1997 15:45:36 +0000 To: ipng@sunroof.eng.sun.com From: Thomas Lee Subject: (IPng 2689) Overhead of IPv6 ESP/AH Mime-Version: 1.0 X-Mailer: Turnpike Version 3.02 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am doing some writing about IPv6 and wonder if any one has any figures on the overhead likely to be encountered by using the AH and ESP headers. Now I can see the value of these in increasing the overall security of datagrams, but just how much overhead would adding both a AH and an EXP header add? I'm just lookin for a ball park estimate - are we taking 5%, 50% or 500%?? And - does anyone one have any similar figures for raw IPv6 (ie just the base header). How much faster/slower can an IPv6 datagram be transmitted? Any views or information would be gratefully received. Thomas -- Thomas Lee (email: tfl@psp.co.uk, web: http://www.psp.demon.co.uk/tfl/tfl.htm) Microsoft Certified Systems Engineer and Certified Trainer PS Partnership - A Microsoft Solution Provider Ph: +44 1628 850 077 Fax: +44 1628 850 143 ------------------------------------------------------------------------------ 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 Sat Jan 4 10:20:37 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02567; Sat, 4 Jan 97 10:20:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02561; Sat, 4 Jan 97 10:20:20 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA00939; Sat, 4 Jan 1997 10:12:02 -0800 Received: from ns.att.com (ns.research.att.com [192.20.225.4]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA04916 for ; Sat, 4 Jan 1997 10:12:04 -0800 Received: from research.att.com by ns; Sat Jan 4 13:11:13 EST 1997 Received: from raptor.research.att.com by research; Sat Jan 4 13:08:19 EST 1997 Received: from research.att.com (raptor.research.att.com [135.205.49.32]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id NAA07915; Sat, 4 Jan 1997 13:08:19 -0500 (EST) Message-Id: <199701041808.NAA07915@raptor.research.att.com> To: Thomas Lee Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2690) Re: Overhead of IPv6 ESP/AH Date: Sat, 04 Jan 1997 13:08:19 -0500 From: Steven Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am doing some writing about IPv6 and wonder if any one has any figur es on the overhead likely to be encountered by using the AH and ESP headers. Now I can see the value of these in increasing the overall security of datagrams, but just how much overhead would adding both a AH and an EXP header add? I'm just lookin for a ball park estimate - are we taking 5%, 50% or 500%?? And - does anyone one have any similar figures for raw IPv6 (ie just t he base header). How much faster/slower can an IPv6 datagram be transmitted? Any views or information would be gratefully received. I went through some calculations a while back that showed a 10-15% increase in size for IPv4. I derived those figures by looking at published packet size distributions, then adding in the extra bytes. Various folks on the ipsec mailing list have measured the performance, if that's what you mean. ------------------------------------------------------------------------------ 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 Sat Jan 4 10:41:12 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02604; Sat, 4 Jan 97 10:41:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02598; Sat, 4 Jan 97 10:41:00 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA01741; Sat, 4 Jan 1997 10:32:42 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA06753 for ; Sat, 4 Jan 1997 10:32:43 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA22508; Sat, 4 Jan 1997 13:28:18 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA15398; Sat, 4 Jan 1997 13:28:10 -0500 Message-Id: <9701041828.AA15398@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au, 6bone@isi.edu, host-conf@sol.eg.bucknell.edu, dhcp-v6@bucknell.edu, dhc-v6impl@bucknell.edu, iesg@cnri.reston.va.us, iab@isi.edu Cc: rdr@cs.unh.edu, rdb@cs.unh.edu, mattyc@leonis.nus.sg, qv@iol.unh.edu, whl@whitec.sr.unh.edu, yunzhou@ee.nus.sg, scip4166@leonis.nus.org, bound@zk3.dec.com, agn@flume.enet.dec.com, harrington@dragns.enet.dec.com, bglover@zk3.dec.com, mogul@pa.dec.com Subject: (IPng 2691) IPv6/DHCPv6 Public Domain on Alpha Netbsd 4.4 (64 bits!!!) Date: Sat, 04 Jan 97 13:28:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk DO NOT RESPOND TO THIS MAIL see below for implementation lists and contacts. Over the past 6 months Yunzhou Li from the University of Singapore working in conjunction with the University of New Hampshire, and Quaizar Vohra from the University of New Hampshire (UNH) developed a public domain version of DHCPv6 and IPv6 to run on the Carnegie Mellon port of Netbsd 4.4 on Digital Equipments Alpha 64 bit processor. Support to Yunzhou, Quaizar, and UNH for this effort was provided by the Digital IPv6 Alpha UNIX team to assist where we were able. This software is a 64bit version of IPv6 that is available to the public domain without any copyrights or other obligations other than the hope of sharing enhancements and ideas into the Internet Software Community. The DHCPv6 code is available now and the IPv6 stack will be available soon this month (January 1997). Though the DHCPv6 code is mean't for Quaizar's IPv6 stack he did at UNH, I believe that Yunzhou's code can be ported to other IPv6 stacks, using the IPv6 the Basic and Advanced API drafts as Yunzhou took the time to develop the code base in a most portable manner (e.g. using the database described in the book "Advanced Programming in the UNIX Environment" by Dr. Richard Stevens). You can access the DHCPv6 code base at: ftp://sun4.iol.unh.edu/pub/dhcpv6 There are two types of compressed packages inclusive: dhcpv6-1.0.tar.gz (for gunzip) dhcpv6-1.0.tar.Z (for uncompress) A documentation file exists based on the DHCPv6 draft but needs to be updated to reflect the next version of the draft Charlie Perkins (IBM Watson Labs) and I will submit for last call in January 1997 to reach Proposed Standard status. But the code base should not be affected in any significant manner. One objective we should have as a community is to add Dynamic Updates to DNS to the DHCPv6 Server code base Yunzhou has provided us using the latest release from Paul Vixie et al BIND T8.1A and the necessary security enhancements from the DNSSEC work and other implementation ideas being worked on in the community. If you want to contact Yunzhou you can reach him for now at yunzhou@ee.nus.sg or scip4166@leonis.nus.org. Yunzhou will be moving to the U.S. in late January 1997. You can reach Quaizar at qv@iol.unh.edu. Implementation discussion for DHCPv6 will be discussed on a mail list created for us by Ralph Droms Chair of the IETF DHC Working Group. The list will be dhc-v6impl@bucknell.edu and you can subscribe to that list as follows: Mail to listserv@bucknell.edu with body "help" or subscribe dhcp-v6impl Your Name Once Quaizar releases his code base we can use our IPv6 implementors list to discuss that software code base and report bugs etc... That list is ipv6imp@munnari.oz.au. This list has existed for some time for IPv6 implementors, and you can subscribe to it as follows: Mail to ipv6imp-request@munnari.oz.au. Quaizar's implementation is also documented very well as part of his Masters of Computer Science Thesis at UNH. Also a recent Digial Technical Journal (DTJ) is out and if you can get a copy it describes well what and how we built IPv6 on Alpha DUNIX (written by Dan Harrington [now at Lucent Technologies] Matt Thomas, Jack McCann, and Jim Bound). Its Volume 8 Number 3 1996. It is sent outside of Digital so what we wrote about is now public knowledge. It also discusses some of the paradigm and architectural trade-offs we made from an implementation perspective, like taking advantage of a 64bit architecture. I will announce a WWW page pointer and add a hotlink to our www.digital.com/info/ipv6/ page sometime in January 1997, where you will also be able to determine how to get hard copies if you want them, or view it online. As a community we need to give a big thanks to the University of New Hampshire (UNH), the UNH Interoperability Lab, University of Singapore, Yunzhou Li, Quaizar Vohra, Digital Equipement Corporation, and the Digital Alpha DUNIX IPv6 Team. This work will provide us a working IPv6 64 bit platform on Alpha to further develop the growing public domain of IPv6 software. A special thanks to Carnegie Mellon for the vision and on going work to port Netbsd 4.4 to the Alpha Platform, and Charlie Perkins and the IETF DHC Working Group for taking on DHCPv6 as the first IETF WG outside of the classic IPng Working group to produce an IPv6 spec that we think has rough consensus and "running code". Sincerely, /jim Jim Bound Consulting Software Engineer IPv6 Technical Director Digital Equipment Corporation bound@zk3.dec.com 603-881-0400 ------------------------------------------------------------------------------ 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 Sat Jan 4 12:25:36 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02711; Sat, 4 Jan 97 12:25:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02705; Sat, 4 Jan 97 12:25:20 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA05545; Sat, 4 Jan 1997 12:17:03 -0800 Received: from cornpuffs.cisco.com (cornpuffs.cisco.com [171.69.1.219]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA15198 for ; Sat, 4 Jan 1997 12:17:03 -0800 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id MAA23550; Sat, 4 Jan 1997 12:06:56 -0800 Message-Id: <199701042006.MAA23550@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Sat, 4 Jan 1997 12:06:56 PST In-Reply-To: bound@zk3.dec.com "[IPv6Imp] IPv6/DHCPv6 Public Domain on Alpha Netbsd 4.4 (64 bits!!!)" (Jan 4, 1:28pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, ipv6imp@munnari.OZ.AU, 6bone@ISI.EDU, host-conf@sol.eg.bucknell.edu, dhcp-v6@bucknell.edu, dhc-v6impl@bucknell.edu, iesg@cnri.reston.va.us, iab@ISI.EDU Subject: (IPng 2692) Re: [IPv6Imp] IPv6/DHCPv6 Public Domain on Alpha Netbsd 4.4 (64 bits!!!) Cc: rdr@cs.unh.edu, rdb@cs.unh.edu, mattyc@leonis.nus.sg, qv@iol.unh.edu, whl@whitec.sr.unh.edu, yunzhou@ee.nus.sg, scip4166@leonis.nus.org, agn@flume.enet.dec.com, harrington@dragns.enet.dec.com, bglover@zk3.dec.com, mogul@pa.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm glad to see this DHCPv6 port appear. As a matter of record, I'll note that the NRL IPv6 code has been running fine for some time now on DEC Alpha/NetBSD systems at NASA/Moffett Field, so this gives the DEC Alpha two different ports to work with (a good thing, IMHO). :-) Ran rja@cisco.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 Sat Jan 4 16:00:15 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03055; Sat, 4 Jan 97 16:00:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02963; Sat, 4 Jan 97 15:59:52 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA12995; Sat, 4 Jan 1997 15:51:34 -0800 Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA02129 for ; Sat, 4 Jan 1997 15:51:35 -0800 Received: from max103.frontier-networks.co.uk ([195.200.12.103]) by relay-10.mail.demon.net id ab1028780; 4 Jan 97 23:30 GMT Message-Id: <3QHOAMBkwszyEAfA@psp.co.uk> Date: Sat, 4 Jan 1997 21:31:16 +0000 To: ipng@sunroof.eng.sun.com From: Thomas Lee Subject: (IPng 2693) Re: Overhead of IPv6 ESP/AH In-Reply-To: <199701041808.NAA07915@raptor.research.att.com> Mime-Version: 1.0 X-Mailer: Turnpike Version 3.02 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk x-no-archive: yes In article <199701041808.NAA07915@raptor.research.att.com>, Steven Bellovin writes >I went through some calculations a while back that showed a 10-15% increase >in size for IPv4. I derived those figures by looking at published packet >size distributions, then adding in the extra bytes. Those are the raw numbers. What I was wondering was whether by doing better field alignment, was any of that extra processing clawed back? Thomas -- Thomas Lee (email: tfl@psp.co.uk, web: http://www.psp.demon.co.uk/tfl/tfl.htm) Microsoft Certified Systems Engineer and Certified Trainer PS Partnership - A Microsoft Solution Provider Ph: +44 1628 850 077 Fax: +44 1628 850 143 ------------------------------------------------------------------------------ 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 Sat Jan 4 16:32:37 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03099; Sat, 4 Jan 97 16:32:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03093; Sat, 4 Jan 97 16:32:20 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA13922; Sat, 4 Jan 1997 16:24:04 -0800 Received: from ns.att.com (ns.research.att.com [192.20.225.4]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA04719 for ; Sat, 4 Jan 1997 16:24:03 -0800 Received: from research.att.com by ns; Sat Jan 4 19:23:09 EST 1997 Received: from raptor.research.att.com by research; Sat Jan 4 19:20:44 EST 1997 Received: from research.att.com (raptor.research.att.com [135.205.49.32]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id TAA21847; Sat, 4 Jan 1997 19:20:43 -0500 (EST) Message-Id: <199701050020.TAA21847@raptor.research.att.com> To: Thomas Lee Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2694) Re: Overhead of IPv6 ESP/AH Date: Sat, 04 Jan 1997 19:20:43 -0500 From: Steven Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk x-no-archive: yes In article <199701041808.NAA07915@raptor.research.att.com>, Steven Bellovin writes >I went through some calculations a while back that showed a 10-15% in crease >in size for IPv4. I derived those figures by looking at published pa cket >size distributions, then adding in the extra bytes. Those are the raw numbers. What I was wondering was whether by doing better field alignment, was any of that extra processing clawed back? You're speaking of ``processing'', implying CPU time, while I spoke of space. But there's not really anything to claw back -- the layout of the ESP header was done with careful attention to alignments. There may be some room to optimize, but it would be at the implementation level, probably not the protocol design. (Btw -- I'm speaking of the newer unified ESP/AH transform, not the (obsolete) stuff described in RFCs 1825-1829.) ------------------------------------------------------------------------------ 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 Sat Jan 4 18:10:35 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03269; Sat, 4 Jan 97 18:10:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03263; Sat, 4 Jan 97 18:10:22 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA18584; Sat, 4 Jan 1997 18:02:01 -0800 Received: from osprey.nas.nasa.gov (osprey.nas.nasa.gov [129.99.34.52]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA12132 for ; Sat, 4 Jan 1997 18:02:01 -0800 Received: (from templin@localhost) by osprey.nas.nasa.gov (8.8.3/NAS.6.1) id RAA29916; Sat, 4 Jan 1997 17:49:16 -0800 (PST) Date: Sat, 4 Jan 1997 17:49:16 -0800 (PST) From: templin@nas.nasa.gov (Fred L. Templin) Message-Id: <199701050149.RAA29916@osprey.nas.nasa.gov> To: iab@ISI.EDU, iesg@cnri.reston.va.us, dhc-v6impl@bucknell.edu, dhcp-v6@bucknell.edu, host-conf@sol.eg.bucknell.edu, 6bone@ISI.EDU, ipv6imp@munnari.OZ.AU, ipng@sunroof.eng.sun.com, bound@zk3.dec.com, rja@cisco.com (Ran Atkinson) Subject: (IPng 2695) Re: [IPv6Imp] IPv6/DHCPv6 Public Domain on Alpha Netbsd 4.4 (64 bits!!!) Cc: mogul@pa.dec.com, bglover@zk3.dec.com, harrington@dragns.enet.dec.com, agn@flume.enet.dec.com, scip4166@leonis.nus.org, yunzhou@ee.nus.sg, whl@whitec.sr.unh.edu, qv@iol.unh.edu, mattyc@leonis.nus.sg, rdb@cs.unh.edu, rdr@cs.unh.edu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As a matter of record, I'll note that the NRL IPv6 code has been > running fine for some time now on DEC Alpha/NetBSD systems at > NASA/Moffett Field, so this gives the DEC Alpha two different > ports to work with (a good thing, IMHO). Yes, as Ran points out we've been running the NRL IPv6 and IPSEC implementations on DEC Alpha/NetBSD-1.2 (including my changes which make the NRL code 64-bit clean) for a couple of months now here at NASA Ames. See: http://www.ipv6.nas.nasa.gov/nrl64.html for a writeup of the porting project. Since our current research objectives require an IPv6 implementation which offeres both high performance and extensibility, however, we're very much interested in taking a look at the new public-domain release Jim Bound referred to in his announcement as well. It's still a bit early for us to run a "bakeoff" against the various implementations, so Jim's annoucement certainly gives us a new data point to consider. Regards, Fred templin@nas.nasa.gov ------------------------------------------------------------------------------ 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 Sun Jan 5 02:14:13 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03525; Sun, 5 Jan 97 02:14:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03519; Sun, 5 Jan 97 02:14:00 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA05822; Sun, 5 Jan 1997 02:05:43 -0800 Received: from tera.csl.sony.co.jp (tera.csl.sony.co.jp [133.138.1.13]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA17828 for ; Sun, 5 Jan 1997 02:05:42 -0800 Received: from vega.csl.sony.co.jp ([133.138.197.24]) by tera.csl.sony.co.jp (8.8.3/3.3W3) with SMTP id TAA17091; Sun, 5 Jan 1997 19:05:15 +0900 (JST) Message-Id: <199701051005.TAA17091@tera.csl.sony.co.jp> X-Sender: tera@tera.csl.sony.co.jp X-Mailer: Windows Eudora Pro Version 2.2-Jr2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Date: Sun, 05 Jan 1997 19:04:10 +0900 To: Charlie Perkins From: Fumio Teraoka Subject: (IPng 2696) Re: Discussion about new direction for mobile IP Cc: ipng@sunroof.eng.sun.com, mobile-ip@hosaka.SmallWorks.COM, dbj@cs.cmu.edu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, At 10:04 97/01/01 -0500, Charlie Perkins wrote: > > I don't understand why my idea is called "source rebinding". > > I just used the terminology because I heard other people > describing the idea that way. It's not a big deal. It seems > to correctly identify the notion that the source IP address > of an incoming packet needs to be associated with (or, "bound to") > some other IP address. If this does not describe your approach, > then I should not have attributed the idea to you. In terms of your terminology, my proposal could be called "source rebinding". In my proposal, however, a received packet includes both the source address and the source node identifier, and the IP layer notifies the transport layer only of the soruce node identifier. > > I don't agree with your poposal. It is very complicated. > > Would, perhaps, my correction of a lethal typo make the > proposal seem less complicated? Please see my immediately > previous note in which I make the correction. Yes, your correction made your proposal less complicated. (I don't know the word "complicated" is appropriate, because English is not my mother tongue.) I understood your proposal. You also separate addresses and identifiers and get rid of identifiers from the IP header. In a sense, this approach is reasonable. However, I believe that the IP header must include node identifiers in terms of security. In addition, your proposal requires one extra packet exchange when a correspondent node receives a packet from an unknown mobile node. If the packet includes both the address and identifier, this extra packet exchange is unnecessary. Moreover, your proposal requires an extra bit in the IPv6 header to specify that the source address isn't the home address (or the identifier). However, there is no reserved bit in the IPv6 base header. If an option is used for this purpose, why don't you send the source home address in this option? > > In addition, > > If the authentication header isn't used, impersonation can easily be > > done. If the authentication header or ESP is used, security association > > must be re-established every time a mobile node moves. > > Yes, the binding (not the security association) must be re-established > every time the mobile node moves. However, authentication is not > required every time the binding is _used_, only when it is _established_. If the security association is established based on the node identifier, re-establishment is unnecessary. Fumio Teraoka ------------------------------------------------------------------------------ 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 Sun Jan 5 17:56:46 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04563; Sun, 5 Jan 97 17:56:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04557; Sun, 5 Jan 97 17:56:28 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA08747; Sun, 5 Jan 1997 17:48:10 -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 RAA03331 for ; Sun, 5 Jan 1997 17:48:08 -0800 From: Masataka Ohta Message-Id: <199701060140.KAA03048@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA03048; Mon, 6 Jan 1997 10:40:02 +0900 Subject: (IPng 2697) MOs' 8+8 To: bound@zk3.dec.com Date: Mon, 6 Jan 97 10:40:01 JST Cc: photon@nol.net, mohta@necom830.hpcl.titech.ac.jp, tli@jnx.com, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, bgp@ans.net In-Reply-To: <9701041605.AA27539@wasted.zk3.dec.com>; from "bound@zk3.dec.com" at Jan 4, 97 11:05 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim; > I agree. I also think 8+8 (or where it will end up) will add additional > benefits to the CIDR paradigm and solves the Multihoming problem too for > large organizations. The only part I don't like and will battle is that > when a packet leaves a host I do not think anyone should step on any > parts of the 128bit address space at site border routers or from ISP to > ISP. Why? IETF is the place for technical and engineering discussion, not a place to express one's opinion without any valid reasoning. With DNS lookup, rewriting won't make weak security weaker. Moreover, mobility needs SOMETHING equivalent to distination rewriting, anyway. > It has a lot to do with how 8+8 is done for > DNS and the root servers. Maybe for DNS but no for the root servers. To make everything too much complex, the root servers should have constant locator. The root servers DOES worth additional 9 toplevel routing table entries. > I also do not believe we can assume any ESD can be globally unique by > itself at any root Internet server (e.g. .com, edu, .arpa). Stop using wrong terminologies. The root is ".", not ".com". And the uniqueness of the locators of the SECOND level servers depends on how many are the second level servers. > I think for our IPng Interim meeting Feb 27 and 28 we need to devote the > entire two days to 8+8 and not even try to do other stuff. You could have saved and still can save a lot of time by doing discussion in the mailing list. The idea has been around more than a year. Discuss! 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 Mon Jan 6 03:04:38 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05065; Mon, 6 Jan 97 03:04:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05059; Mon, 6 Jan 97 03:04:26 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA10468; Mon, 6 Jan 1997 02:56:07 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA04120 for ; Mon, 6 Jan 1997 02:56:01 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id KAA01617; Mon, 6 Jan 1997 10:40:02 GMT Date: Mon, 6 Jan 1997 10:40:02 GMT Message-Id: <199701061040.KAA01617@oberon.di.fc.ul.pt> From: Pedro Roque To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2698) MOs' 8+8 In-Reply-To: <199701060140.KAA03048@necom830.hpcl.titech.ac.jp> References: <9701041605.AA27539@wasted.zk3.dec.com> <199701060140.KAA03048@necom830.hpcl.titech.ac.jp> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Masataka" == Masataka Ohta writes: Masataka> You could have saved and still can save a lot of time by Masataka> doing discussion in the mailing list. Masataka> The idea has been around more than a year. Masataka> Discuss! In my humble opinion, to have a meaningful discussion it would be good to start by discussing what are the precise goals of the proposals on the table. To explain my point, IPv6 is, until now, based on the same architecture as IPv4. This was a design goal of the proposal in which IPv6 is based. I think that both Ohta's and O'Dell's proposals are essentially different network architectures, although they both apear as "Addressing policies". I don't think it would be that productive to discuss, in an isolated way, thinks like: - 64 bit routable addresses - router address rewriting - EIDs - etc. Specially with O'Dell's proposal i've the impression that the "Goals" section of the draft no longer stands, as per comments of Christian Huitema on the last IPng meeting. So i think there is a necessity to clarify, from start, what is the group trying to accomplish... While is terribly hard to say that a network architecture, like those being proposed, does or does not work i think it would be essential for the group to decide *definitively* if IPv6 will be a new instance of the base IP architecture or not. Also, i do think NIMROD should be considered when discussing a new architecture. After all they have been working on one for quite a while... 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 Mon Jan 6 04:27:27 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05231; Mon, 6 Jan 97 04:27:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05225; Mon, 6 Jan 97 04:27:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA15201; Mon, 6 Jan 1997 04:18:48 -0800 Received: from sundance.itd.nrl.navy.mil (sundance.itd.nrl.navy.mil [132.250.92.89]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA13769 for ; Mon, 6 Jan 1997 04:18:48 -0800 Received: from beavis.ipv6.nrl.navy.mil by sundance.itd.nrl.navy.mil id aa21675; 6 Jan 97 7:20 EST To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2699) Re: IPv6/DHCPv6 Public Domain on Alpha Netbsd 4.4 (64 bits!!!) In-Reply-To: Your message of "Sat, 04 Jan 1997 13:28:10 EST." <9701041828.AA15398@wasted.zk3.dec.com> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Mon, 06 Jan 1997 07:18:32 -0500 From: Craig Metz Message-Id: <9701060720.aa21675@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <9701041828.AA15398@wasted.zk3.dec.com>, you write: >Charlie Perkins >and the IETF DHC Working Group for taking on DHCPv6 as the first IETF WG >outside of the classic IPng Working group to produce an IPv6 spec that >we think has rough consensus and "running code". Just for the record, I believe that IPsec had both IPv6 support in the spec and working code on the streets a year and a half ago. In any case, it is good to see IPv6 support in non-IPngwg standards and freely available code to back it up. -Craig ------------------------------------------------------------------------------ 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 Mon Jan 6 05:11:08 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05260; Mon, 6 Jan 97 05:11:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05254; Mon, 6 Jan 97 05:10:56 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA18736; Mon, 6 Jan 1997 05:02:36 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA19660 for ; Mon, 6 Jan 1997 05:02:36 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id OAA25043; Mon, 6 Jan 1997 14:02:23 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA17065; Mon, 6 Jan 1997 14:02:22 +0100 Message-Id: <9701061302.AA17065@dxcoms.cern.ch> Subject: (IPng 2700) Re: BGP/IDRP/IPv6 To: dkatz@Cisco.COM (Dave Katz) Date: Mon, 6 Jan 1997 14:02:22 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com, bgp@ans.net In-Reply-To: <199612202042.MAA11174@puli.cisco.com> from "Dave Katz" at Dec 20, 96 12:42:36 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >--------- Text sent by Dave Katz follows: > ... > > IMHO, the right course of action is to do the multiprotocol extension > to BGP4 quickly so that interdomain routing would not stand in the way > of IPv6 deployment. This can be done independently of any other work. > ... > > I'd like to hear what the ISPs (who will be the ones to deploy this > stuff) have to say about the subject. It seems to me as though IPv6 > will be easier to deploy as an incremental add-on to the existing BGP4 > then if it were bundled in an incompatible (if perhaps almost-compatible) > protocol, but I'll let the ISPs speak for themselves. > They haven't, at least on lists that I watch, but what you say makes a lot of sense to me. The key issue is to have a BGP4 extension that doesn't break the deployed BGP4 system - that is IMHO the only reasonable way forward in the short term. Brian Carpenter ------------------------------------------------------------------------------ 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 Mon Jan 6 05:20:21 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05276; Mon, 6 Jan 97 05:20:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05270; Mon, 6 Jan 97 05:20:09 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA19500; Mon, 6 Jan 1997 05:11:49 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA21063 for ; Mon, 6 Jan 1997 05:11:48 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id OAA28626; Mon, 6 Jan 1997 14:11:39 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA17605; Mon, 6 Jan 1997 14:11:38 +0100 Message-Id: <9701061311.AA17605@dxcoms.cern.ch> Subject: (IPng 2701) Re: 8+8 and TCP connections To: Kim.Wohlert@mainz.dk (Kim Wohlert) Date: Mon, 6 Jan 1997 14:11:38 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "Kim Wohlert" at Dec 23, 96 04:05:59 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kim, Nobody seems to have answered this. I don't quite understand why you single out TCP as a problem case. When the RG changes, the question is how quickly the routing system adapts, whatever the upper layer protocol is. Brian Carpenter >--------- Text sent by Kim Wohlert follows: > > One of the concerns brought up re: Mike O'Dell's 8+8 proposal was how > TCP connections would survive changes in the RG. > > The problem can be divided into two distinct cases 1) rehoming of the > site or of an up-stream ISP or 2) cut-over of a multihomed site. > > For case 1) it can be assumed that this would be a planned event that > the site is able to prepare for. The survival of long-lived TCP > connections could be ensured by creating an option to be inserted by the > router were the RG is about to change, indicating what the new RG will > be. The receiving node would then store this information in a cache > connected to the information about the socket in question and when the > cut-over did occur (indicated by packets with the new RG in the source > address arriving), replace the old RG with the new RG in the return > address. > > The option would only be needed during the transition period, so it > would only be a rare burden. > > For the second case, where one link out of a multihomed site fails, this > is of cause usually an unplanned event, so the information about > possible RGs must be distributed continuously. This can be done with the > same type of option as for case 1), but will require all boundary > routers for the site to know about each other, and insert the option to > indicate the list of possible RGs that could at any time replace the > current RG. > > In this case, the option must be sent with all packets, since teh change > in RG may take placea t any time. > > The above mechanism can probably be implemented as a generalization of > the methods described by Jim Bound and Pedro Roque in "Dynamic > Reassignment of IP Addresses for TCP and UDP" > (). > > The issue of how the router gets this information in the first place can > be solved along the lines presented by (I think) Geert Jan de Groot and > Bob Hinden in San Jose. > > It should be noted that the mechanisms described here pose no additional > risk of the connection being hijacked, because the router that inserts > the option is also the router that inserts the RG in the first place. > > - Kim > > Kim Wohlert |Internet:Kim.Wohlert@mainz.dk > erik mainz a/s | > Dortheavej 7 | > DK-2400 Copenhagen |Phone: +45 38 34 77 88 > Denmark |Fax: +45 31 19 16 25 > --- > "Cast it in stone and it will float like a rock." > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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 Mon Jan 6 05:35:54 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05300; Mon, 6 Jan 97 05:35:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05294; Mon, 6 Jan 97 05:35:42 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA20763; Mon, 6 Jan 1997 05:27:21 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA23594 for ; Mon, 6 Jan 1997 05:27:22 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id OAA32496; Mon, 6 Jan 1997 14:27:16 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA18519; Mon, 6 Jan 1997 14:27:10 +0100 Message-Id: <9701061327.AA18519@dxcoms.cern.ch> Subject: (IPng 2702) Re: MOs' 8+8 To: roque@di.fc.ul.pt (Pedro Roque) Date: Mon, 6 Jan 1997 14:27:09 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <199701061040.KAA01617@oberon.di.fc.ul.pt> from "Pedro Roque" at Jan 6, 97 10:40:02 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, > > Specially with O'Dell's proposal i've the impression that the "Goals" section > of the draft no longer stands, as per comments of Christian Huitema on the > last IPng meeting. So i think there is a necessity to clarify, from start, > what is the group trying to accomplish... > > While is terribly hard to say that a network architecture, like those being > proposed, does or does not work i think it would be essential for the > group to decide *definitively* if IPv6 will be a new instance of > the base IP architecture or not. > Please have another look at draft-iab-ip-ad-today-01.txt, including its short section on IPv6. Brian Carpenter ------------------------------------------------------------------------------ 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 Mon Jan 6 07:06:19 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05374; Mon, 6 Jan 97 07:06:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05367; Mon, 6 Jan 97 07:06:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA29575; Mon, 6 Jan 1997 06:57:47 -0800 Received: from snoopy.agile.com ([198.3.105.68]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA13807; Mon, 6 Jan 1997 06:57:44 -0800 Received: by snoopy.agile.com with Microsoft Exchange (IMC 4.0.837.3) id <01BBFBB8.3CF84B40@snoopy.agile.com>; Mon, 6 Jan 1997 09:58:59 -0500 Message-Id: From: "Harrington, Dan" To: "'bound@zk3.dec.com'" , "'owner-ipng@sunroof.Eng.Sun.COM'" Cc: "'photon@nol.net'" , "'mohta@necom830.hpcl.titech.ac.jp'" , "'tli@jnx.com'" , "'dhaskin@baynetworks.com'" , "'ipng@sunroof.Eng.Sun.COM'" , "'bgp@ans.net'" Subject: (IPng 2703) RE: MOs' 8+8 Date: Mon, 6 Jan 1997 09:58:58 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka wrote: > Jim; > > > I agree. I also think 8+8 (or where it will end up) will add additional > > benefits to the CIDR paradigm and solves the Multihoming problem too for > > large organizations. The only part I don't like and will battle is that > > when a packet leaves a host I do not think anyone should step on any > > parts of the 128bit address space at site border routers or from ISP to > > ISP. > > Why? I've been wondering about the "router rewriting" portion of the 8+8 proposal, which clearly has the potential to polarize opinions. But is this aspect of the proposed architecture fundamental? Couldn't it be just another policy decision? It seems to me that one site could take their RG prefixes and leak them into their site (via whatever mechanism as yet undefined), so that hosts learn them from their immediately adjacent default routers. This site would incur the overhead of distributing and maintaining this information amongst their systems, but as benefit the individual hosts would know exactly what their global addresses were, and could select an appropriate source on their own. Another site could choose to permit their ISP's routers to rewrite the RG portion of source addresses as they exit the site, thus relieving their hosts of what source address to choose...they would just use the (as yet undefined) Exportable-Site-Local-Prefix for any communications with globally addressed destinations. As stated by Mike in his draft, this is not terribly different from the way NAT boxes work today. So long as implementations at both sites are using the same rules for checksums and security associations (and whatever else is identified), it wouldn't seem to matter to the network which mechanism is used by individual sites. This would seem to be the key decision we need to make as a working group. So is this really a question of all or nothing? Or can we leave the ultimate decision in the hands of the network managers? Or have I completely misunderstood the situation (yet again)? Dan ------------------------------------------------------------------------------ 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 Mon Jan 6 07:12:16 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05417; Mon, 6 Jan 97 07:12:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05400; Mon, 6 Jan 97 07:12:01 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA00748; Mon, 6 Jan 1997 07:03:42 -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 HAA15401 for ; Mon, 6 Jan 1997 07:03:42 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA15139; Mon, 6 Jan 1997 09:59:05 -0500 (EST) Received: by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA20197; Mon, 6 Jan 1997 09:58:57 -0500 Date: Mon, 6 Jan 1997 09:58:57 -0500 From: Jack McCann USG Message-Id: <9701061458.AA20197@wasted.zk3.dec.com> To: cmetz@inner.net Subject: (IPng 2704) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" Cc: ipng@sunroof.eng.sun.com, mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Date: Fri, 03 Jan 1997 17:34:09 -0500 >From: Craig Metz > >In message <9701032154.AA23183@wasted.zk3.dec.com>, you write: >>Paul Vixie has been contemplating a way to get both AAAA and A records >>with a single query, sounds like a useful thing, I'm hoping we hear >>more from Paul on this. > > There is a way to do this, getaddrinfo(). > > -Craig I was referring to the actual BIND queries, not the application API call. - 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 Mon Jan 6 07:44:05 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05498; Mon, 6 Jan 97 07:44:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05492; Mon, 6 Jan 97 07:43:54 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04979; Mon, 6 Jan 1997 07:35:35 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA25778 for ; Mon, 6 Jan 1997 07:35:34 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA23318; Mon, 6 Jan 1997 10:27:21 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23361; Mon, 6 Jan 1997 10:27:17 -0500 Message-Id: <9701061527.AA23361@wasted.zk3.dec.com> To: Craig Metz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2705) Re: IPv6/DHCPv6 Public Domain on Alpha Netbsd 4.4 (64 bits!!!) In-Reply-To: Your message of "Mon, 06 Jan 97 07:18:32 EST." <9701060720.aa21675@sundance.itd.nrl.navy.mil> Date: Mon, 06 Jan 97 10:27:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Just for the record, I believe that IPsec had both IPv6 support in >the spec and working code on the streets a year and a half ago. Good point. The architecture was defined and worked on in the IPng WG first though was my thought when I wrote the mail. I could have written it different based on your mail though... /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 Mon Jan 6 08:25:42 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05651; Mon, 6 Jan 97 08:25:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05645; Mon, 6 Jan 97 08:25:29 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA11589; Mon, 6 Jan 1997 08:17:10 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA09841 for ; Mon, 6 Jan 1997 08:17:07 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA03980; Mon, 6 Jan 1997 17:17:00 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA29972; Mon, 6 Jan 1997 17:16:59 +0100 Message-Id: <9701061616.AA29972@dxcoms.cern.ch> Subject: (IPng 2706) Re: MOs' 8+8 To: ipng@sunroof.eng.sun.com, bgp@ans.net Date: Mon, 6 Jan 1997 17:16:59 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: from "Harrington, Dan" at Jan 6, 97 09:58:58 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, > > Another site could choose to permit their ISP's routers to rewrite > the RG portion of source addresses as they exit the site, thus > relieving their hosts of what source address to choose...they would > just use the (as yet undefined) Exportable-Site-Local-Prefix for > any communications with globally addressed destinations. As stated > by Mike in his draft, this is not terribly different from the way > NAT boxes work today. > It's different in one vital way: since the RG is *not* used in pseudo-headers, stamping on it doesn't break anything vital. Brian Carpenter ------------------------------------------------------------------------------ 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 Mon Jan 6 08:26:36 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05658; Mon, 6 Jan 97 08:26:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05652; Mon, 6 Jan 97 08:26:21 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA11720; Mon, 6 Jan 1997 08:18:01 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA10204 for ; Mon, 6 Jan 1997 08:18:01 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA28269; Mon, 6 Jan 1997 11:09:58 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28270; Mon, 6 Jan 1997 11:09:35 -0500 Message-Id: <9701061609.AA28270@wasted.zk3.dec.com> To: templin@nas.nasa.gov (Fred L. Templin) Cc: iab@ISI.EDU, iesg@cnri.reston.va.us, dhc-v6impl@bucknell.edu, dhcp-v6@bucknell.edu, host-conf@sol.eg.bucknell.edu, 6bone@ISI.EDU, ipv6imp@munnari.OZ.AU, ipng@sunroof.eng.sun.com, bound@zk3.dec.com, rja@cisco.com (Ran Atkinson), mogul@pa.dec.com, bglover@zk3.dec.com, harrington@dragns.enet.dec.com, agn@flume.enet.dec.com, scip4166@leonis.nus.sg, yunzhou@ee.nus.sg, whl@whitec.sr.unh.edu, qv@iol.unh.edu, mattyc@leonis.nus.sg, rdb@cs.unh.edu, rdr@cs.unh.edu Subject: (IPng 2707) Re: [IPv6Imp] IPv6/DHCPv6 Public Domain on Alpha Netbsd 4.4 (64 bits!!!) In-Reply-To: Your message of "Sat, 04 Jan 97 17:49:16 PST." <199701050149.RAA29916@osprey.nas.nasa.gov> Date: Mon, 06 Jan 97 11:09:35 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, >Yes, as Ran points out we've been running the NRL IPv6 and IPSEC >implementations on DEC Alpha/NetBSD-1.2 (including my changes which >make the NRL code 64-bit clean) for a couple of months now here at >NASA Ames. See: > http://www.ipv6.nas.nasa.gov/nrl64.html I knew about this from you as you know for sometime. Was not clear until now you and NRL were updating the sources. More 64 bit code bases on Alpha is always a good thing. Also my mistake its release Netbsd 1.2 (not 4.4 but is based on 4.4). >for a writeup of the porting project. Since our current research >objectives require an IPv6 implementation which offeres both high >performance and extensibility, however, we're very much interested >in taking a look at the new public-domain release Jim Bound referred >to in his announcement as well. It's still a bit early for us to run >a "bakeoff" against the various implementations, so Jim's annoucement >certainly gives us a new data point to consider. I think you should check out the UNH code at NASA once its out. Connectathon is the first week in March and the next IPv6 interoperability testing will take place there in the Bay Area. I do feel unless an implementation goes to an IPv6 interoperability event it is not tempered to the test of fire and if I were a user I would ask if an implementation has been at these events. These events really test an implementation which cannot be done or verified by just being on the 6bone (e.g. address configuration, Neighbor Discovery, API) and really helps with development. Also IPsec still has yet to be tested at these IPv6 interoperability events and Multicast Routing so we still have a ways to go. Right now the only public domain that has been tested with the UNH test suites is INRIA's version. /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 Mon Jan 6 08:56:25 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05763; Mon, 6 Jan 97 08:56:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05757; Mon, 6 Jan 97 08:56:13 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA17118; Mon, 6 Jan 1997 08:47:53 -0800 Received: from snoopy.agile.com ([198.3.105.68]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA21521 for ; Mon, 6 Jan 1997 08:47:52 -0800 Received: by snoopy.agile.com with Microsoft Exchange (IMC 4.0.837.3) id <01BBFBC7.9E60D370@snoopy.agile.com>; Mon, 6 Jan 1997 11:49:05 -0500 Message-Id: From: "Harrington, Dan" To: "'ipng@sunroof.Eng.Sun.COM'" , "'bgp@ans.net'" Subject: (IPng 2708) Re: MOs' 8+8 Date: Mon, 6 Jan 1997 11:49:04 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, > It's different in one vital way: since the RG is *not* used in > pseudo-headers, stamping on it doesn't break anything vital. Correct...I was perhaps too sweeping in my statement. But the point remains that all sides agree to the rules, the mechanism in place at an individual site doesn't matter. Dan ------------------------------------------------------------------------------ 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 Mon Jan 6 09:06:42 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05815; Mon, 6 Jan 97 09:06:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05809; Mon, 6 Jan 97 09:06:31 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA19043; Mon, 6 Jan 1997 08:58:11 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA25203 for ; Mon, 6 Jan 1997 08:58:11 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA09940; Mon, 6 Jan 1997 11:35:02 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA26637; Mon, 6 Jan 1997 11:34:54 -0500 Message-Id: <9701061634.AA26637@wasted.zk3.dec.com> To: Masataka Ohta Cc: bound@zk3.dec.com, photon@nol.net, tli@jnx.com, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2709) Re: MOs' 8+8 In-Reply-To: Your message of "Mon, 06 Jan 97 10:40:01 +0200." <199701060140.KAA03048@necom830.hpcl.titech.ac.jp> Date: Mon, 06 Jan 97 11:34:54 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka, [ Dan/Joe : I take this to respond to your mails and Dan I have no issue if folks want to permit such a policy but I think there are some security and business practice issues for users that are unneccessary]. >> I agree. I also think 8+8 (or where it will end up) will add additional >> benefits to the CIDR paradigm and solves the Multihoming problem too for >> large organizations. The only part I don't like and will battle is that >> when a packet leaves a host I do not think anyone should step on any >> parts of the 128bit address space at site border routers or from ISP to >> ISP. >Why? >IETF is the place for technical and engineering discussion, not a >place to express one's opinion without any valid reasoning. Well I was testing the waters and you did exactly what your accusing me of below )--->.... I do not believe for security reasons that the application should rely only on the ESD. It must use the entire 128bits as one reason. It permits a node to speak to an application and impersonate the routing goop just securing the ESD at the application layer is simply not enough. The other reason is that from a business perspective I don't want to deal with the security ramifications of a packet being altered from my site to an ISP and brings up an entire discussion of permitting and external entity to my site or home changing my packets in transit which I may not trust. I also believe if I sent a packet to dcdd::11:edcdba I want to find that address in by application dns lookup and it will be received only by dcdd::11:edcdba. This gets to the DNS issue I will discuss further below. Finally I believe it is not necessary to achieve the goals of 8+8 in this manner. The benefits outlined in that spec can be done by simply using it without changing the goop. When a site gets a new prefix the goop can be changed quite easily by advertising the new goop to the site and renumbering in the routing system using ND and autoconfiguration can take place with minimum of effort as opposed to the effort of securing the environment from altering the goop on the fly. >With DNS lookup, rewriting won't make weak security weaker. Now as you asked me? Please explain in detail what you mean? I don't know where your coming from on this? >Moreover, mobility needs SOMETHING equivalent to distination >rewriting, anyway. This is another thread. I would like to see the resolution on Charlies care-of-address discussion resolved first persoanlly before we enter this discussion. I think that may make this a moot point????? >> It has a lot to do with how 8+8 is done for >> DNS and the root servers. >Maybe for DNS but no for the root servers. >To make everything too much complex, the root servers should >have constant locator. Please explain why as you asked me? >The root servers DOES worth additional 9 toplevel routing >table entries. I can't parse your english statement here at all? >> I also do not believe we can assume any ESD can be globally unique by >> itself at any root Internet server (e.g. .com, edu, .arpa). > >Stop using wrong terminologies. > >The root is ".", not ".com". Fine. I am more concerned about the next level though and the PRT records. I do not believe 0::11:ddcabb (2+6 without the goop --> ESD) will be gloablly unique at the root servers or next level domains. It must contain the entire 128bits. >And the uniqueness of the locators of the SECOND level servers >depends on how many are the second level servers. Why? >> I think for our IPng Interim meeting Feb 27 and 28 we need to devote the >> entire two days to 8+8 and not even try to do other stuff. >You could have saved and still can save a lot of time by doing >discussion in the mailing list. We are but we will round it up at the meeting. >The idea has been around more than a year. Whats this have to do with anything? WHy do you make this statement? /jim >Discuss! We 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 Mon Jan 6 09:19:11 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05857; Mon, 6 Jan 97 09:19:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05851; Mon, 6 Jan 97 09:18:59 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA21717; Mon, 6 Jan 1997 09:10:39 -0800 Received: from snoopy.agile.com ([198.3.105.68]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA29715 for ; Mon, 6 Jan 1997 09:10:37 -0800 Received: by snoopy.agile.com with Microsoft Exchange (IMC 4.0.837.3) id <01BBFBCA.CCF7FB70@snoopy.agile.com>; Mon, 6 Jan 1997 12:11:52 -0500 Message-Id: From: "Harrington, Dan" To: "'photon@nol.net'" Cc: "'bound@zk3.dec.com'" , "'mohta@necom830.hpcl.titech.ac.jp'" , "'tli@jnx.com'" , "'dhaskin@baynetworks.com'" , "'ipng@sunroof.Eng.Sun.COM'" , "'bgp@ans.net'" Subject: (IPng 2710) RE: MOs' 8+8 Date: Mon, 6 Jan 1997 12:11:51 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk photon@nol.net wrote: > I would think rewriting network adresses in transit would certainly affect > the heart of any routing system's integrity, if it were not a defined and > controlled part of a standard. You'll get no argument from me... > I don't like the idea of the host having to know so much about network > adresses or topology, which it would have to do to intelligently make that > decision. Hosts should only care about one thing: Sending their traffic > to an opaque destination IP address through the appropriate (and probably > default and only) gateway. The translation of addresses, tunneling, > routing decisions, etc. are the jobs of routers, which are more incline to > be aware of the factors involved and the current network topology. It's swell that you have such a clear vision of what hosts should be and what they should be capable of. But I don't think your view is necessarily universal, and some folks might disagree with your position. In any event, I'm merely trying to point out that both views can be accomodated (I think), while preserving the primary benefits of the 8+8 plan (or whatever it's called today). > There are some great network managers out there, but probably a good half > or more of them don't really understand IPv4 right now, much less are they > likely to understand the nuances of v6... You've got to assume they are > all stupid when designing the protocol and the software... don't put the > integrity of the protocol in a network admin's hands... or least leave it > open to interpretation in the protocol standard, but encourage the vendors > to implement a standard easy method in their software. I'm all for robust network and protocol design, though I would not necessarily base it upon the alleged shortcomings of any class of persons. That doesn't strike me as particularly polite (at least). I do think flexibility is a worthwhile goal, and that's all I'm trying to encourage. Dan ------------------------------------------------------------------------------ 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 Mon Jan 6 09:26:06 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05884; Mon, 6 Jan 97 09:26:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02343; Sat, 4 Jan 97 07:44:47 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA24728; Sat, 4 Jan 1997 07:36:30 -0800 Received: from nol.net (dazed.nol.net [206.126.32.101]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA21743 for ; Sat, 4 Jan 1997 07:36:31 -0800 Received: from localhost (photon@localhost) by nol.net (8.8.4/NOL - 8.*) with SMTP id JAA00544; Sat, 4 Jan 1997 09:25:06 -0600 (CST) X-Auth: NOLNET SENDMAIL AUTH Date: Sat, 4 Jan 1997 09:25:06 -0600 (CST) From: Brandon Black To: Masataka Ohta Cc: Tony Li , bound@zk3.dec.com, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2711) Re: larger AS/RD space for v6? In-Reply-To: <199701040044.JAA00735@necom830.hpcl.titech.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 4 Jan 1997, Masataka Ohta wrote: > Tony; > > > I'd like to point out that ANYTHING that "knows" about the internal > > structure of the address is probably a mistake. It constrains the future > > flexibility of the system, thereby eliminating future adaptability. Basic > > engineering demands that create the absolute minimum in internal > > interdependencies. Thus, the address should be wholly opaque outside of > > the routing system. > > Any policy routing system MUST "know" about the internal structure > of the address to the extent necessary for (fine or coarse) policy > control. > > For example, IPv4 routing systems know about lasses A, B and C. > > Or, do you think classfull addressing mistake? > > Then, with CIDRized class A, routing systems (even global ones) must > know about the subnet masks. > > No, this is not a proper example, because CIDR is a mistake. :-) > > Masataka Ohta > CIDR is not a mistake IMHO. I think the original classes were a mistake, althought probably an unforseeable one. Every network address should carry a mask, and how large or small that mask is should be up to individual network needs. Limiting network address sizes to being 16M nodes, 64k nodes, or 255 nodes means that most people would waste a lot of space, or have to use a bunch of C's as seperate networks when they may have wanted a single continous network. The concept of classes, and their ability to make it unnecessary to transmit masks (with a classful address space, the mask of any netework is obvious), is a good one at first.... but to be effective, there would have to be many more than 3 classes, and probably nobody can predict ahead of time when designing a protocol how much space should go to each class. Given that dilemma, the only reasonable classy solution would to be to give a huge chunk of space to every class, which would result in being wasteful of space. As far as the backbone having to know too much, That's not really true in many cases. i.e. If I'm a backbone bgp speaker, and I'm advertising 130.130.0.0/16, then that is all the backbone needs to know and does know... even if in reality that single route represents a routing heirarchy of hundreds of subnets within my AS. But I don't think Tony was referring really to the routing system knowing (were you?)... it seems to me he was referring to the address itself carrying inherent information... i.e. if someone just read off an IP to me, I shouldn't be able to automatically know from that number the AS it belongs to, its netmask, etc.... the adress should just be an address to the user or host, and the routers should be the ones implementing a routing policy on those addresses, which is flexible and not constrained to a certain view of address structure. ................................. .............. : Brandon Lee Black : [Office] :.............: [Personal] :.... :....................: brandon.black@wcom.com : photon@nol.net :....... : "Sanity is the : +1.281.362.6466 .......: photon@gnu.ai.mit.edu : : trademark of a :.................:..../\: vis_blb@unx1.shsu.edu : : weak mind. . ." : LDDS WorldCom, Inc. :\/: +1.281.397.3490 ......: :....................:.....................:..:.................: ------------------------------------------------------------------------------ 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 Mon Jan 6 10:54:00 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06253; Mon, 6 Jan 97 10:54:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05499; Mon, 6 Jan 97 07:45:10 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA05196; Mon, 6 Jan 1997 07:36:51 -0800 Received: from odin.UU.NET (odin.UU.NET [153.39.242.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA26171; Mon, 6 Jan 1997 07:36:48 -0800 Received: from tenebrous.uu.net by odin.UU.NET with ESMTP (peer crosschecked as: tenebrous.UU.NET [153.39.253.123]) id QQbxik04759; Mon, 6 Jan 1997 10:32:59 -0500 (EST) Received: by tenebrous.uu.net id QQbxik00341; Mon, 6 Jan 1997 10:32:58 -0500 (EST) Date: Mon, 6 Jan 1997 10:32:58 -0500 (EST) Message-Id: From: Joseph Malcolm To: "Harrington, Dan" Cc: "'bound@zk3.dec.com'" , "'owner-ipng@sunroof.Eng.Sun.COM'" , "'photon@nol.net'" , "'mohta@necom830.hpcl.titech.ac.jp'" , "'tli@jnx.com'" , "'dhaskin@baynetworks.com'" , "'ipng@sunroof.Eng.Sun.COM'" , "'bgp@ans.net'" Subject: (IPng 2712) RE: MOs' 8+8 In-Reply-To: References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Harrington writes: >I've been wondering about the "router rewriting" portion of >the 8+8 proposal, which clearly has the potential to polarize >opinions. But is this aspect of the proposed architecture >fundamental? Couldn't it be just another policy decision? > >It seems to me that one site could take their RG prefixes and >leak them into their site (via whatever mechanism as yet undefined), >so that hosts learn them from their immediately adjacent default >routers. This site would incur the overhead of distributing and >maintaining this information amongst their systems, but as benefit >the individual hosts would know exactly what their global addresses >were, and could select an appropriate source on their own. I think your analysis is pretty much correct, but remember that in the current 8+8 design, as I understand it, when the connecting outside topology changes only the border routers need to know. If sites were to elect your proposed alternative, this information needs to be propagated to all hosts, which seems to me likely to involve substantial protocol machinery. So I think there is a significant cost to allowing the alternative. I don't see any problem with allowing the border routers to rewrite the addresses personally, but I'd be interested in hearing reasons from those who don't agree as to why this is a bad idea. ------------------------------------------------------------------------------ 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 Mon Jan 6 11:38:12 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06347; Mon, 6 Jan 97 11:38:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05773; Mon, 6 Jan 97 09:02:13 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA18299; Mon, 6 Jan 1997 08:53:53 -0800 Received: from nol.net (dazed.nol.net [206.126.32.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA23672; Mon, 6 Jan 1997 08:53:52 -0800 Received: from localhost (photon@localhost) by nol.net (8.8.4/NOL - 8.*) with SMTP id KAA22692; Mon, 6 Jan 1997 10:43:34 -0600 (CST) X-Auth: NOLNET SENDMAIL AUTH Date: Mon, 6 Jan 1997 10:43:34 -0600 (CST) From: Brandon Black To: "Harrington, Dan" Cc: "'bound@zk3.dec.com'" , "'owner-ipng@sunroof.Eng.Sun.COM'" , "'mohta@necom830.hpcl.titech.ac.jp'" , "'tli@jnx.com'" , "'dhaskin@baynetworks.com'" , "'ipng@sunroof.Eng.Sun.COM'" , "'bgp@ans.net'" Subject: (IPng 2713) RE: MOs' 8+8 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 6 Jan 1997, Harrington, Dan wrote: > > > > Why? > > I've been wondering about the "router rewriting" portion of > the 8+8 proposal, which clearly has the potential to polarize > opinions. But is this aspect of the proposed architecture > fundamental? Couldn't it be just another policy decision? > I would think rewriting network adresses in transit would certainly affect the heart of any routing system's integrity, if it were not a defined and controlled part of a standard. > It seems to me that one site could take their RG prefixes and > leak them into their site (via whatever mechanism as yet undefined), > so that hosts learn them from their immediately adjacent default > routers. This site would incur the overhead of distributing and > maintaining this information amongst their systems, but as benefit > the individual hosts would know exactly what their global addresses > were, and could select an appropriate source on their own. > I don't like the idea of the host having to know so much about network adresses or topology, which it would have to do to intelligently make that decision. Hosts should only care about one thing: Sending their traffic to an opaque destination IP address through the appropriate (and probably default and only) gateway. The translation of addresses, tunneling, routing decisions, etc. are the jobs of routers, which are more incline to be aware of the factors involved and the current network topology. > Another site could choose to permit their ISP's routers to rewrite > the RG portion of source addresses as they exit the site, thus > relieving their hosts of what source address to choose...they would > just use the (as yet undefined) Exportable-Site-Local-Prefix for > any communications with globally addressed destinations. As stated > by Mike in his draft, this is not terribly different from the way > NAT boxes work today. > > So long as implementations at both sites are using the same rules > for checksums and security associations (and whatever else is > identified), it wouldn't seem to matter to the network which > mechanism is used by individual sites. This would seem to be > the key decision we need to make as a working group. > > So is this really a question of all or nothing? Or can we leave > the ultimate decision in the hands of the network managers? Or > have I completely misunderstood the situation (yet again)? > There are some great network managers out there, but probably a good half or more of them don't really understand IPv4 right now, much less are they likely to understand the nuances of v6... You've got to assume they are all stupid when designing the protocol and the software... don't put the integrity of the protocol in a network admin's hands... or least leave it open to interpretation in the protocol standard, but encourage the vendors to implement a standard easy method in their software. > Dan > Devil's Advocate ................................. .............. : Brandon Lee Black : [Office] :.............: [Personal] :.... :....................: brandon.black@wcom.com : photon@nol.net :....... : "Sanity is the : +1.281.362.6466 .......: photon@gnu.ai.mit.edu : : trademark of a :.................:..../\: vis_blb@unx1.shsu.edu : : weak mind. . ." : LDDS WorldCom, Inc. :\/: +1.281.397.3490 ......: :....................:.....................:..:.................: ------------------------------------------------------------------------------ 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 Mon Jan 6 13:18:00 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06600; Mon, 6 Jan 97 13:18:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06594; Mon, 6 Jan 97 13:17:43 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA18902; Mon, 6 Jan 1997 13:09:23 -0800 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 NAA04719 for ; Mon, 6 Jan 1997 13:09:19 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id MAA08354 Posted-Date: Mon, 6 Jan 1997 12:57:13 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (SMI-8.6/SMI-SVR4) with ESMTP id MAA05981; Mon, 6 Jan 1997 12:59:00 -0800 for Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id PAA26046; Mon, 6 Jan 1997 15:59:00 -0500 for Date: Mon, 6 Jan 1997 15:59:00 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701062059.PAA26046@pobox.engeast.BayNetworks.COM> To: ip6mib@Research.Ftp.Com, daniele@zk3.dec.com Subject: (IPng 2714) Re: Per-interface and summed counters Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I added the ipng list since some people who may voice an opinion on this subject might not be on the ip6mib list]. Mike, > Hello, > > Many counters in the general group seem to be > summations of the same counter defined per interface > in the ipv6IfStatsTable. > > For instance, if you sum all the values of ipv6IfStatsInDiscards > across all ipv6 interfaces, you get the value of ipv6InDiscards. > > Is it necessary to have both sets of counters? > Is it necessary to have per-interface IP counters? > These same questions came up during the IPv6 MIB presentation at San Jose. My view (which aggrees with other router code implementors I talked to) is that per-interface statistics counters are important on routers and can not be removed. As to the per-entity counters, then they indeed can be derived from the per-interface counters and are a subject for removal from the mib. The tradeoff of the removing per-entity counters from the mib would be that summations have to be done at management stations rather than at the managed v6 nodes. If there is a consensus that it is the right approach, I'll gladly remove the per-entity counters from the next iteration of the IPv6 mib draft. > Also, the description of the per-interface counters seems to > be identical in some cases to the general counter, referring to > "the entity" etc. Should refer to the interface, etc. > Thanks, I'll fix it. > Mike > 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 Mon Jan 6 14:24:56 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06764; Mon, 6 Jan 97 14:24:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06758; Mon, 6 Jan 97 14:24:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA02732; Mon, 6 Jan 1997 14:16:25 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA23324 for ; Mon, 6 Jan 1997 14:16:24 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id RAA28800; Mon, 6 Jan 1997 17:07:52 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24922; Mon, 6 Jan 1997 17:07:48 -0500 Message-Id: <9701062207.AA24922@wasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2715) Re: MOs' 8+8 In-Reply-To: Your message of "Mon, 06 Jan 97 17:16:59 +0100." <9701061616.AA29972@dxcoms.cern.ch> Date: Mon, 06 Jan 97 17:07:48 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> >> Another site could choose to permit their ISP's routers to rewrite >> the RG portion of source addresses as they exit the site, thus >> relieving their hosts of what source address to choose...they would >> just use the (as yet undefined) Exportable-Site-Local-Prefix for >> any communications with globally addressed destinations. As stated >> by Mike in his draft, this is not terribly different from the way >> NAT boxes work today. >> >It's different in one vital way: since the RG is *not* used in >pseudo-headers, stamping on it doesn't break anything vital. I don't agree. I don't think the Protocol Control Blocks can deal globally with just the ESD they are simply not "unique" on the "Internet" but can only be 100% guranteed in a site. Also I believe doing this will break lots of vital thinks like end-to-end connectivity and open an entirely new set of security problems, when we still have not solved the ones we have now "completely". /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 Mon Jan 6 14:26:54 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06775; Mon, 6 Jan 97 14:26:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06769; Mon, 6 Jan 97 14:26:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA03083; Mon, 6 Jan 1997 14:18:19 -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 OAA23924 for ; Mon, 6 Jan 1997 14:18:11 -0800 Received: from muggsy.lkg.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id RAA08491; Mon, 6 Jan 1997 17:15:00 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA16533; Mon, 6 Jan 1997 17:14:57 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id SAA18428; Mon, 6 Jan 1997 18:22:48 GMT Message-Id: <199701061822.SAA18428@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ip6mib@research.ftp.com, daniele@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2716) Re: Per-interface and summed counters In-Reply-To: Your message of "Mon, 06 Jan 1997 15:59:00 EST." <199701062059.PAA26046@pobox.engeast.BayNetworks.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Jan 1997 18:22:38 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hello, > > Many counters in the general group seem to be > summations of the same counter defined per interface > in the ipv6IfStatsTable. > > For instance, if you sum all the values of ipv6IfStatsInDiscards > across all ipv6 interfaces, you get the value of ipv6InDiscards. Maybe, maybe not. > Is it necessary to have both sets of counters? > Is it necessary to have per-interface IP counters? > What happens with interfaces that are deleted? Do their counters disappear? The advantage of a top-level counter is that they can historical usage even after reconfiguration. Per-interface counters are mandatory. My 2 cents, -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own 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 Mon Jan 6 17:05:42 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07285; Mon, 6 Jan 97 17:05:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07279; Mon, 6 Jan 97 17:05:25 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA11448; Mon, 6 Jan 1997 16:57:07 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA17444 for ; Mon, 6 Jan 1997 16:57:06 -0800 Received: (dkatz@localhost) by puli.cisco.com (8.6.12/8.6.5) id QAA28008; Mon, 6 Jan 1997 16:57:05 -0800 Date: Mon, 6 Jan 1997 16:57:05 -0800 From: Dave Katz Message-Id: <199701070057.QAA28008@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2717) a different proposal for ipv6 in bgp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 6 Jan 1997 16:53:05 -0800 From: Dave Katz Message-Id: <199701070053.QAA27780@puli.cisco.com> To: jstewart@metro.isi.edu CC: 6bone@isi.edu, bgp@ans.net, jstewart@isi.edu, ipng@sunroof.eng.sun.como In-reply-to: "John W. Stewart III"'s message of Mon, 30 Dec 1996 14:05:41 EST <199612301905.AA24223@metro.isi.edu> Subject: a different proposal for ipv6 in bgp It remains unclear to me why it is desirable to couple multiprotocol support and the AS number space increase. The two functions are completely orthogonal and as far as I can tell there is no benefit for *mandating* that the two changes be made at the same time. Clearly the multiprotocol stuff could be deployed and become useful more quickly than the AS number extension, due to the fact that it can be done in a backward compatible, pairwise fashion. The deployment considerations for multiprotocol support are far less onerous than the AS number stuff. Operators who are concerned about deploying new software twice could always wait until BGP5 deployment and turn on both features at the same time. However, I think that the deployment timing for each feature is difficult to predict in advance (will IPv6 take off? Are we really under pressure for AS numbers?) so keeping them decoupled keeps things more flexible. So, what is it that makes it preferable to entwine the changes? --Dave X-Phone: +1 703 812 3704 Date: Mon, 30 Dec 1996 14:05:41 EST From: "John W. Stewart III" Sender: owner-idr@merit.edu Precedence: bulk attached below is a proposal for a multi-protocol (including ipv6) bgp while there are a number of differences between this one and the bates/chandra/katz/rekhter one, one of the main motivating factors for this one is to support longer-than-two-byte ASs. it is our view that making bgp multi-protocol significantly extends its life. so, although in a narrow sense the length of the AS is orthogonal to being multi-protocol, the logistics of transitions and the need to adequeately engineer the protocol up-front, to us, suggests the need for longer-than- two-byte ASs /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 Mon Jan 6 18:04:20 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07509; Mon, 6 Jan 97 18:04:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07503; Mon, 6 Jan 97 18:04:03 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA22186; Mon, 6 Jan 1997 17:55:44 -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 RAA02097 for ; Mon, 6 Jan 1997 17:55:28 -0800 From: Masataka Ohta Message-Id: <199701070150.KAA05068@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA05068; Tue, 7 Jan 1997 10:50:37 +0900 Subject: (IPng 2718) Re: MOs' 8+8 To: bound@zk3.dec.com Date: Tue, 7 Jan 97 10:50:36 JST Cc: brian@dxcoms.cern.ch, ipng@sunroof.eng.sun.com, bgp@ans.net In-Reply-To: <9701062207.AA24922@wasted.zk3.dec.com>; from "bound@zk3.dec.com" at Jan 6, 97 5:07 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim; > >It's different in one vital way: since the RG is *not* used in > >pseudo-headers, stamping on it doesn't break anything vital. > > I don't agree. I don't think the Protocol Control Blocks can deal > globally with just the ESD they are simply not "unique" on the > "Internet" but can only be 100% guranteed in a site. One of the agreement at San Jose meeting was that lower 8 byte should be globally unique. > Also I believe doing this will break lots of vital thinks like > end-to-end connectivity and open an entirely new set of security > problems, when we still have not solved the ones we have now > "completely". You are completely out of date. As discussed last year and I stated in my mail yesterday, rewriting does not break the weak security. 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 Mon Jan 6 19:52:07 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07579; Mon, 6 Jan 97 19:52:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07573; Mon, 6 Jan 97 19:51:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA05609; Mon, 6 Jan 1997 19:43:30 -0800 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 TAA22142 for ; Mon, 6 Jan 1997 19:43:30 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id TAA24178; Mon, 6 Jan 1997 19:41:39 -0800 (PST) for Posted-Date: Mon, 6 Jan 1997 19:41:39 -0800 (PST) Received: from pobox.corpwest.BayNetworks.COM (mailhost.corpwest.baynetworks.com [134.177.1.95]) by ns1.BayNetworks.COM (SMI-8.6/SMI-SVR4) with ESMTP id TAA01765; Mon, 6 Jan 1997 19:43:27 -0800 for Received: from dhaskin.baynetworks.com ([192.32.171.165]) by pobox.corpwest.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id TAA20669; Mon, 6 Jan 1997 19:43:24 -0800 for Message-Id: <2.2c.32.19970107033942.00af22c4@pobox.corpeast.baynetworks.com> X-Sender: dhaskin@pobox.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 2.2c (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Jan 1997 22:39:42 -0500 To: ipng@sunroof.eng.sun.com From: Dimitry Haskin Subject: (IPng 2719) Re: a different proposal for ipv6 in bgp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 04:53 PM 1/6/97 -0800, Dave Katz wrote: >It remains unclear to me why it is desirable to couple multiprotocol >support and the AS number space increase. The two functions are >completely orthogonal and as far as I can tell there is no benefit for >*mandating* that the two changes be made at the same time. > >Clearly the multiprotocol stuff could be deployed and become useful >more quickly than the AS number extension, due to the fact that it >can be done in a backward compatible, pairwise fashion. > I don't believe that this assessment is accurate. The BGP5 proposal is as backward compatible (if not more) with BGP4 as the proposed multiprotocol extension to BGP4. I.e., v4 routing information exchanged between BGP5 peers can be fully re-advertised via BGP4 and vise versa. As you might notice we even didn't require to immediately extend AS number space for v4 to keep the v4 related changes to a bare minimum. To support v6, bgp data structures need to change any way and v6 has no backward compatibility issue at this point. Thus it only makes sense to get a larger AS space for v6 now to avoid another transition later. >The deployment considerations for multiprotocol support are far less >onerous than the AS number stuff. > Care elaborate (in light of the BGP5 proposal)? >Operators who are concerned about deploying new software twice could >always wait until BGP5 deployment and turn on both features at the >same time. However, I think that the deployment timing for each >feature is difficult to predict in advance (will IPv6 take off? Are >we really under pressure for AS numbers?) so keeping them decoupled >keeps things more flexible. > >So, what is it that makes it preferable to entwine the changes? > Once again, the way the BGP5 proposal written I don't believe this larger AS space for v6 introduces more implementation and/or deployment burdens than yours multiprotocol stuff does... unless I miss some vital points. My point is that there is no additional penalty for the introducing a larger AS number space for v6 now and, to boot, BGP5 provides an optional mechanism to gradually introduce a larger AS number space for v4 too. So why not? >--Dave Dimitry > > X-Phone: +1 703 812 3704 > Date: Mon, 30 Dec 1996 14:05:41 EST > From: "John W. Stewart III" > Sender: owner-idr@merit.edu > Precedence: bulk > > > attached below is a proposal for a multi-protocol (including > ipv6) bgp > > while there are a number of differences between this one and > the bates/chandra/katz/rekhter one, one of the main motivating > factors for this one is to support longer-than-two-byte ASs. > it is our view that making bgp multi-protocol significantly > extends its life. so, although in a narrow sense the length > of the AS is orthogonal to being multi-protocol, the logistics > of transitions and the need to adequeately engineer the > protocol up-front, to us, suggests the need for longer-than- > two-byte ASs > > /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 Mon Jan 6 21:26:27 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07732; Mon, 6 Jan 97 21:26:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07726; Mon, 6 Jan 97 21:26:15 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA14525; Mon, 6 Jan 1997 21:17:54 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA07249 for ; Mon, 6 Jan 1997 21:17:55 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id AAA11273; Tue, 7 Jan 1997 00:13:15 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16969; Tue, 7 Jan 1997 00:13:13 -0500 Message-Id: <9701070513.AA16969@wasted.zk3.dec.com> To: Masataka Ohta Cc: bound@zk3.dec.com, brian@dxcoms.cern.ch, ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2720) Re: MOs' 8+8 In-Reply-To: Your message of "Tue, 07 Jan 97 10:50:36 +0200." <199701070150.KAA05068@necom830.hpcl.titech.ac.jp> Date: Tue, 07 Jan 97 00:13:13 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka, >One of the agreement at San Jose meeting was that lower 8 byte >should be globally unique. It can't be done and no one has given an algorithm to do it. ALso if you would read mail more carefully you would note I said based on the "premises" for IPv6 in ND and Addrconf the low order 6bytes cannot in fact be unique which is why we do Duplicate Address Detection if this should happen. With the 2 extra bytes it can be unique within a site even if the low order 6 bytes are duplicated on two different links (which is permitted in IPv6). But I claim it cannot be unique outside of the site on the Internet. It may be your in a discussion for IPv6 that your are not qualified to be in or you would not have made the above statement so lightly. Mike in his spec states he does not want to break the machinery for existing IPv6 in the specs but develop an addressing architecture that can exist within it. I think that can be done as long as the 128bits are used. >> Also I believe doing this will break lots of vital thinks like >> end-to-end connectivity and open an entirely new set of security >> problems, when we still have not solved the ones we have now >> "completely". >You are completely out of date. Your being rude and you obviously don't have the integrity to defend your own statements. Your the one who is just talking and taking up much valuable Internet-waves with your one line sentences that are meaningless technically. I had other text to my sentence above to draw my conclusion which are called premises. You just keep giving me conclusions. Didn't you take any deductive logic course in your life. >As discussed last year and I stated in my mail yesterday, rewriting >does not break the weak security. I read your mail yesterday. I did have a site outage though I hear from colleagues on other mail lists, so humor me and resend it. /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 Mon Jan 6 23:44:40 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07780; Mon, 6 Jan 97 23:44:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07774; Mon, 6 Jan 97 23:44:23 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA25395; Mon, 6 Jan 1997 23:36:03 -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 XAA24925 for ; Mon, 6 Jan 1997 23:36:02 -0800 From: Masataka Ohta Message-Id: <199701070733.QAA05489@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA05489; Tue, 7 Jan 1997 16:33:24 +0900 Subject: (IPng 2721) Re: MOs' 8+8 To: bound@zk3.dec.com Date: Tue, 7 Jan 97 16:33:23 JST Cc: mohta@necom830.hpcl.titech.ac.jp, brian@dxcoms.cern.ch, ipng@sunroof.eng.sun.com, bgp@ans.net In-Reply-To: <9701070513.AA16969@wasted.zk3.dec.com>; from "bound@zk3.dec.com" at Jan 7, 97 12:13 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim; > >One of the agreement at San Jose meeting was that lower 8 byte > >should be globally unique. > > It can't be done and no one has given an algorithm to do it. As discussed in San Jose, it can be and is being algorithmically done with IPv4 through in-addr.arpa. > ALso if > you would read mail more carefully you would note I said based on the > "premises" for IPv6 in ND and Addrconf the low order 6bytes cannot in > fact be unique which is why we do Duplicate Address Detection if this > should happen. We don't have Duplicate Address Detection to encourage duplication. > Mike in his spec states he does not want to You apparently missed discussion in San Jose and later. > >As discussed last year and I stated in my mail yesterday, rewriting > >does not break the weak security. > > I read your mail yesterday. I did have a site outage though I hear from > colleagues on other mail lists, so humor me and resend it. No. Unless you want to be the rude, don't bother us all the members of IPNG and BGP MLs only because of your site local mail failure. Dig ML archive (starting from last December) by yourself. Masatkaa 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 Tue Jan 7 01:55:15 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07905; Tue, 7 Jan 97 01:55:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07899; Tue, 7 Jan 97 01:54:58 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA06378; Tue, 7 Jan 1997 01:46:38 -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 BAA12814 for ; Tue, 7 Jan 1997 01:46:37 -0800 From: Masataka Ohta Message-Id: <199701070932.SAA05919@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA05919; Tue, 7 Jan 1997 18:31:48 +0859 Subject: (IPng 2722) Re: larger AS/RD space for v6? To: photon@nol.net (Brandon Black) Date: Tue, 7 Jan 97 18:31:46 JST Cc: mohta@necom830.hpcl.titech.ac.jp, tli@jnx.com, bound@zk3.dec.com, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, bgp@ans.net In-Reply-To: ; from "Brandon Black" at Jan 4, 97 9:25 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brandon; > But I don't think Tony was referring really to the routing system knowing > (were you?)... it seems to me he was referring to the address itself > carrying inherent information... i.e. if someone just read off an IP to > me, I shouldn't be able to automatically know from that number the AS it > belongs to, its netmask, etc.... Then, perhaps, Tony now think renumbering mistake or, at least, hard. The problem is that dynamic mapping between AS and aggregated address prefix is also hard. It's no good to introduce another level of indirection only to delay facing the problem. Let's face the issue and make renumbering easy. 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 Tue Jan 7 02:24:45 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07954; Tue, 7 Jan 97 02:24:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07948; Tue, 7 Jan 97 02:24:27 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA08670; Tue, 7 Jan 1997 02:16:07 -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 CAA16994 for ; Tue, 7 Jan 1997 02:15:52 -0800 From: Masataka Ohta Message-Id: <199701071010.TAA06148@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA06148; Tue, 7 Jan 1997 19:10:14 +0900 Subject: (IPng 2723) Re: MOs' 8+8 To: bound@zk3.dec.com Date: Tue, 7 Jan 97 19:10:13 JST Cc: mohta@necom830.hpcl.titech.ac.jp, photon@nol.net, tli@jnx.com, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, bgp@ans.net In-Reply-To: <9701061634.AA26637@wasted.zk3.dec.com>; from "bound@zk3.dec.com" at Jan 6, 97 11:34 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim; > >> I agree. I also think 8+8 (or where it will end up) will add additional > >> benefits to the CIDR paradigm and solves the Multihoming problem too for > >> large organizations. The only part I don't like and will battle is that > >> when a packet leaves a host I do not think anyone should step on any > >> parts of the 128bit address space at site border routers or from ISP to > >> ISP. > > >Why? > The other reason is that from a business perspective I don't want to > deal with the security ramifications of a packet being altered from my > site to an ISP and brings up an entire discussion of permitting and > external entity to my site or home changing my packets in transit which > I may not trust. OK. You actually are worrying about the modification of the locator of source address. But, I think it necessary to modify the locator of the destination address. The opinions are compatible. > I also believe if I sent a packet to dcdd::11:edcdba I want to find that > address in by application dns lookup and it will be received only by > dcdd::11:edcdba. It means that you rely routers to dcdd:. So, you can rely routers to dcdd: won't harmfully rewrite destination locator. That is, rewriting of destination locator is harmless. > >With DNS lookup, rewriting won't make weak security weaker. > > Now as you asked me? Please explain in detail what you mean? I don't > know where your coming from on this? Dig ML log last December. > When a site gets a new prefix the goop can be changed quite easily by > advertising the new goop to the site The problem is that it's a lot easier than you think. > and renumbering in the routing > system using ND and autoconfiguration can take place with minimum of > effort as opposed to the effort of securing the environment from > altering the goop on the fly. You are wrong here. We don't need any reconfiguration at all. > >> It has a lot to do with how 8+8 is done for > >> DNS and the root servers. > > >Maybe for DNS but no for the root servers. > > >To make everything too much complex, the root servers should > >have constant locator. > > Please explain why as you asked me? Understand the existing anwer below. > >The root servers DOES worth additional 9 toplevel routing > >table entries. > I can't parse your english statement here at all? Try "nslookup -q=ns ." and count the number of root servers. > I do not believe 0::11:ddcabb (2+6 without the goop --> ESD) will be > gloablly unique Nor do I. But, it's not 8+2+6. It's 6+2+8 now. > >And the uniqueness of the locators of the SECOND level servers > >depends on how many are the second level servers. > > Why? Because I can count the number of routing table entries. > >The idea has been around more than a year. > > Whats this have to do with anything? WHy do you make this statement? Because you are insisting that you need so much time in face-to-face meeting ignoring the mailing list discussion. 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 Tue Jan 7 05:23:50 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08170; Tue, 7 Jan 97 05:23:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08164; Tue, 7 Jan 97 05:23:38 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA18689; Tue, 7 Jan 1997 05:15:15 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA17406 for ; Tue, 7 Jan 1997 05:15:16 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id OAA23875; Tue, 7 Jan 1997 14:15:12 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA06709; Tue, 7 Jan 1997 14:15:07 +0100 Message-Id: <9701071315.AA06709@dxcoms.cern.ch> Subject: (IPng 2724) Re: MOs' 8+8 To: ipng@sunroof.eng.sun.com, bgp@ans.net Date: Tue, 7 Jan 1997 14:15:07 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199701070150.KAA05068@necom830.hpcl.titech.ac.jp> from "Masataka Ohta" at Jan 7, 97 10:50:36 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim and Masataka, > > > > I don't agree. I don't think the Protocol Control Blocks can deal > > globally with just the ESD they are simply not "unique" on the > > "Internet" but can only be 100% guranteed in a site. > > One of the agreement at San Jose meeting was that lower 8 byte > should be globally unique. > "Should be" is not equal to "will be". The real-world issue is whether ESDs would be unique enough to satisfy reasonable requirements, or perhaps: would ESDs be significantly *less* unique than (RG+ESD)s would be? Note on the bizarre concept of "unique enough": what I mean is that in analysing security risks (or the risk of TCP checksum collisions), an ESD is unique enough if the probability of an ESD collision is below some acceptable level. Brian Carpenter P.S. the bgp list is still getting all this. Necessary? ------------------------------------------------------------------------------ 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 Tue Jan 7 05:56:40 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08218; Tue, 7 Jan 97 05:56:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08212; Tue, 7 Jan 97 05:56:24 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA21779; Tue, 7 Jan 1997 05:48:01 -0800 Received: from ns.att.com (ns.research.att.com [192.20.225.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA23737 for ; Tue, 7 Jan 1997 05:48:03 -0800 Received: from research.att.com by ns; Tue Jan 7 08:47:17 EST 1997 Received: from raptor.research.att.com by research; Tue Jan 7 08:46:41 EST 1997 Received: from research.att.com (raptor.research.att.com [135.205.49.32]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id IAA22927; Tue, 7 Jan 1997 08:46:41 -0500 (EST) Message-Id: <199701071346.IAA22927@raptor.research.att.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2725) Re: MOs' 8+8 Date: Tue, 07 Jan 1997 08:46:41 -0500 From: Steven Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim and Masataka, > > > > I don't agree. I don't think the Protocol Control Blocks can deal > > globally with just the ESD they are simply not "unique" on the > > "Internet" but can only be 100% guranteed in a site. > > One of the agreement at San Jose meeting was that lower 8 byte > should be globally unique. > "Should be" is not equal to "will be". The real-world issue is whether ESDs would be unique enough to satisfy reasonable requirements, or perhaps: would ESDs be significantly *less* unique than (RG+ESD)s would be? Note on the bizarre concept of "unique enough": what I mean is that in analysing security risks (or the risk of TCP checksum collisions), an ESD is unique enough if the probability of an ESD collision is below some acceptable level. Against non-malicious attacks, the probability of two 64-bit numbers matching is about 2^-32 -- it's a birthday paradox. This may be sufficient for non-security purposes, such as connection demultiplexing in TCP. For security purposes, where the attacker may try to pierce the veil of randomness, it's not good enough -- but we knew when we headed down this IPng path that address-based authentication would no longer work, for many other reasons. I should note that I'm assuming a true random uniform distribution of these 32-bit ESDs. If the selection is biased -- say, it's a PRNG keyed by boot time or some such -- there will be trouble. On the other hand, even a largely-guessable seed -- say, something derived from the machine's Ethernet address -- is probably sufficient against non-malicious attacks, if fed through a suitable mixer such as MD5. Brian Carpenter P.S. the bgp list is still getting all this. Necessary? I deleted it from this reply... ------------------------------------------------------------------------------ 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 Tue Jan 7 08:18:35 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08384; Tue, 7 Jan 97 08:18:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08378; Tue, 7 Jan 97 08:18:23 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA07487; Tue, 7 Jan 1997 08:10:02 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA04987 for ; Tue, 7 Jan 1997 08:10:02 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id LAA19956 for ipng@sunroof.Eng.Sun.COM; Tue, 7 Jan 1997 11:10:00 -0500 Date: Tue, 7 Jan 1997 11:10:00 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9701071109.ZM19954@seawind.bellcore.com> In-Reply-To: Pedro Roque "(IPng 2698) MOs' 8+8" (Jan 6, 10:40am) References: <9701041605.AA27539@wasted.zk3.dec.com> <199701060140.KAA03048@necom830.hpcl.titech.ac.jp> <199701061040.KAA01617@oberon.di.fc.ul.pt> X-Mailer: Z-Mail (3.2.1 10oct95) To: ipng@sunroof.eng.sun.com Subject: (IPng 2726) MOs' 8+8 is evil, breaks firewalls. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > To explain my point, IPv6 is, until now, based on the same architecture as > IPv4. This was a design goal of the proposal in which IPv6 is based. > I think that both Ohta's and O'Dell's proposals are essentially different > network architectures, although they both apear as "Addressing policies". I studied Mike O'Dell's proposal further at the IETF, and came out with very ambivalent feelings, essentially for the reason that Pedro mentions. At first sight, Mike just propose a simple hack to help renumbering. If we set aside the question of who is allowed to change headers in packets, the most important part of Mike changes is to say the the pseudo-header checksum should be computed only on the last 8 bytes off the source and destination address, so that the top bytes can be modified either "en-route" or by the end users. Mike's proposal is in fact not very ambitious: for TCP connections, it only allows modifications during the initial SYN exchanges, and it assumes that the bottom 8 bytes are sufficiently unique. The restriction to the initial phase blocks changes during the course of the connection, and thus does not solve the mobility problem. The restriction to keep the same bottom 8 bytes constraint calls to stay on one single host, and thus does not solve the "anycasting" problem, in particular for clusters of servers. To be frank, Mike does not claim that his proposal would solve that; in fact, he merely tries to make site renumbering or intermediate provider network rehoming very easy. But that is precisely the problem. Mike's initial argument is that customers don't like to renumber, that market pressures will force providers to bow to customers' desires, and that the net result will be an unbounded increase in the size of routing tables because very soon addresses will not have much relation with network topology. Hence the idea to either make renumbering very easy, or to provide transit providers with tools for forcing renumbering by rewriting addresses themselve. Wait a minute! Why is it that customer don't want renumbering in the first place? We should really not assume they are a bunch of lazy and sloppy guys, unable to properly manage networks. The reason is much simpler. They don't want to renumber because they have been using the addresses for two purposes at the same time, routing and identification. This is a feature of the old architecture, precisely the feature that Mike would like to remove because it is contradictory with the provider backed CIDR architecture. The most common use of addresses as identifiers is probably in access control lists, either in firewalls or in network servers. If I want to let the MIT users access Bellcore, I just have to make an entry for the address prefix 18/8 in my firewall, or in my server. Indeed, this is, in a sense, "weak security", specially when applied to source addresses. However, it is not so weak when considering destination addresses, probably good enough for most routine work. Now, if MIT was to renumber its 12000 machines to some 192.34.128/18 network, I would have to change all this. Experience shows that such changes are really painful, because they occur off site, and are hard to automatize -- there is no DNS entry for "all prefixes used by MIT". Now, suppose that we go along with a variation of Mike's proposal, and make addresses volatile objects that change every minute or so. How exactly do I program my firewall? Do I have to fall back to using IPSEC even for routine work? Do I have to insist that the bottom half of the address, the one that is not rewritten, contains some significative value that let me know that "this is MIT" (and if then, what of automatic address configuration?)? Do we have a DNS entry for network prefixes that I can use for firewalls and other access control lists? And, more important, how do I convince the operators of large networks that we can do all that? Frankly, I would be more confortable with geographic addresses... -- 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 Tue Jan 7 08:55:16 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08436; Tue, 7 Jan 97 08:55:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08430; Tue, 7 Jan 97 08:55:04 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA13399; Tue, 7 Jan 1997 08:46:42 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA17045 for ; Tue, 7 Jan 1997 08:44:22 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id QAA07561; Tue, 7 Jan 1997 16:42:04 GMT Date: Tue, 7 Jan 1997 16:42:04 GMT Message-Id: <199701071642.QAA07561@oberon.di.fc.ul.pt> From: Pedro Roque To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2727) MOs' 8+8 is evil, breaks firewalls. In-Reply-To: <9701071109.ZM19954@seawind.bellcore.com> References: <9701041605.AA27539@wasted.zk3.dec.com> <199701060140.KAA03048@necom830.hpcl.titech.ac.jp> <199701061040.KAA01617@oberon.di.fc.ul.pt> <9701071109.ZM19954@seawind.bellcore.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Christian" == Christian Huitema writes: Christian> I studied Mike O'Dell's proposal further at the IETF, Christian> and came out with very ambivalent feelings, essentially Christian> for the reason that Pedro mentions. At first sight, Christian> Mike just propose a simple hack to help renumbering. Christian> If we set aside the question of who is allowed to Christian> change headers in packets, the most important part of Christian> Mike changes is to say the the pseudo-header checksum Christian> should be computed only on the last 8 bytes off the Christian> source and destination address, so that the top bytes Christian> can be modified either "en-route" or by the end users. Christian> Mike's proposal is in fact not very ambitious: for TCP Christian> connections, it only allows modifications during the Christian> initial SYN exchanges, and it assumes that the bottom 8 Christian> bytes are sufficiently unique. The restriction to the Christian> initial phase blocks changes during the course of the Christian> connection, and thus does not solve the mobility Christian> problem. The restriction to keep the same bottom 8 Christian> bytes constraint calls to stay on one single host, and Christian> thus does not solve the "anycasting" problem, in Christian> particular for clusters of servers. Christian> To be frank, Mike Christian> does not claim that his proposal would solve that; in Christian> fact, he merely tries to make site renumbering or Christian> intermediate provider network rehoming very easy. My understanding is that, as it is curently defined, Mike's proposal gives the same support for site renumbering that we do have today in IPv6. The current IPv6 protocol can do site renumbering quite well... it just doesn't allow for transport communications to live over the renumbering period. Corrections welcomed... ./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 Tue Jan 7 10:02:46 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08601; Tue, 7 Jan 97 10:02:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08197; Tue, 7 Jan 97 05:38:36 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA20154; Tue, 7 Jan 1997 05:30:14 -0800 Received: from syzygy.ieng.com (syzygy.ieng.com [152.160.213.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA20314 for ; Tue, 7 Jan 1997 05:30:15 -0800 Received: from [152.160.213.42] (crackingtoast.ieng.com [152.160.213.194]) by syzygy.ieng.com (8.8.0/8.7.3) with ESMTP id IAA09224; Tue, 7 Jan 1997 08:30:04 -0500 (EST) Message-Id: In-Reply-To: <9701071315.AA06709@dxcoms.cern.ch> References: <199701070150.KAA05068@necom830.hpcl.titech.ac.jp> from "Masataka Ohta" at Jan 7, 97 10:50:36 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 7 Jan 1997 08:31:16 -0500 To: "Brian Carpenter CERN-CN" From: "John G. Scudder" Subject: (IPng 2728) Re: MOs' 8+8 Cc: ipng@sunroof.eng.sun.com, bgp@ans.net Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:15 PM +0100 1/7/97, Brian Carpenter CERN-CN wrote: >P.S. the bgp list is still getting all this. Necessary? No. --John -- John Scudder email: jgs@ieng.com Internet Engineering Group, LLC phone: (313) 669-8800 122 S. Main, Suite 280 fax: (313) 669-8661 Ann Arbor, MI 48104 www: http://www.ieng.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 Tue Jan 7 10:19:09 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08666; Tue, 7 Jan 97 10:19:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08660; Tue, 7 Jan 97 10:18:57 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA28807; Tue, 7 Jan 1997 10:10:33 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA18275 for ; Tue, 7 Jan 1997 10:10:31 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id NAA20000; Tue, 7 Jan 1997 13:09:28 -0500 Date: Tue, 7 Jan 1997 13:09:28 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9701071309.ZM19998@seawind.bellcore.com> In-Reply-To: "Mike O'Dell" "Re: (IPng 2726) MOs' 8+8 is evil, breaks firewalls." (Jan 7, 12:09pm) References: <199701071709.MAA01377@elmo.uu.net> X-Mailer: Z-Mail (3.2.1 10oct95) To: "Mike O'Dell" Subject: (IPng 2729) Re: MOs' 8+8 is evil, breaks firewalls. 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 On Jan 7, 12:09pm, Mike O'Dell wrote: > Subject: Re: (IPng 2726) MOs' 8+8 is evil, breaks firewalls. > > christian, > > never, ever, did I suggest that addresses become "volatile, changing > every minute or so". > > to suggest that is pure fabrication and you are conjuring monsters > where there are none. Mike, You are right. The "minute or so" is indeed an exageration, you were careful to merely speak about relatively rare events, e.g. the rate at which customers change providers today. Please accept my apologies for this. And, by the way, I certainly do not think that you are personnally evil. On the other hand, renumbering is renumbering is renumbering. Forced renumbering by the network will meet the same customer resistance as renumbering to the provider's demand, unless the firewall and other access control list problems are also solved. -- 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 Tue Jan 7 10:21:30 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08678; Tue, 7 Jan 97 10:21:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08448; Tue, 7 Jan 97 09:17:52 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA17166; Tue, 7 Jan 1997 09:09:30 -0800 Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA26000 for ; Tue, 7 Jan 1997 09:09:30 -0800 Received: from elmo.uu.net by relay6.UU.NET with ESMTP (peer crosschecked as: elmo.UU.NET [153.39.245.203]) id QQbxmi29045; Tue, 7 Jan 1997 12:09:28 -0500 (EST) Received: from elmo.uu.net (localhost.UU.NET [127.0.0.1]) by elmo.uu.net (8.7.5/8.7.3) with ESMTP id MAA01377; Tue, 7 Jan 1997 12:09:27 -0500 (EST) Message-Id: <199701071709.MAA01377@elmo.uu.net> To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2730) Re: MOs' 8+8 is evil, breaks firewalls. In-Reply-To: Your message of "Tue, 07 Jan 1997 11:10:00 EST." <9701071109.ZM19954@seawind.bellcore.com> Date: Tue, 07 Jan 1997 12:09:27 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk christian, never, ever, did I suggest that addresses become "volatile, changing every minute or so". to suggest that is pure fabrication and you are conjuring monsters where there are none. -mo ------------------------------------------------------------------------------ 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 Tue Jan 7 10:25:58 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08690; Tue, 7 Jan 97 10:25:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08684; Tue, 7 Jan 97 10:25:46 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA00354; Tue, 7 Jan 1997 10:17:23 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA20869 for ; Tue, 7 Jan 1997 10:17:15 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA13941; Tue, 7 Jan 1997 13:05:52 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA09241; Tue, 7 Jan 1997 13:05:42 -0500 Message-Id: <9701071805.AA09241@wasted.zk3.dec.com> To: Masataka Ohta Cc: bound@zk3.dec.com, brian@dxcoms.cern.ch, ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2731) Re: MOs' 8+8 In-Reply-To: Your message of "Tue, 07 Jan 97 16:33:23 +0200." <199701070733.QAA05489@necom830.hpcl.titech.ac.jp> Date: Tue, 07 Jan 97 13:05:39 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka, >> >One of the agreement at San Jose meeting was that lower 8 byte >> >should be globally unique. >> >> It can't be done and no one has given an algorithm to do it. > >As discussed in San Jose, it can be and is being algorithmically done >with IPv4 through in-addr.arpa. I was there and this discussion did not take place except maybe in your mind as to it being resolved. And we did not agree to anything as consensus. Your wrong. Read the IPng minutes. >> ALso if >> you would read mail more carefully you would note I said based on the >> "premises" for IPv6 in ND and Addrconf the low order 6bytes cannot in >> fact be unique which is why we do Duplicate Address Detection if this >> should happen. >We don't have Duplicate Address Detection to encourage duplication. Is this like the question does a bear shit in the woods? >> Mike in his spec states he does not want to >You apparently missed discussion in San Jose and later. Ah more Masatakagrams... You delete the end to suit your own mind to respond. Re-Read the mail and it meant we are not doing 8+8 to the point where it breaks IPv6 existing specs dramatically. Its a boundary we all want to keep. /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 Tue Jan 7 11:37:35 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08925; Tue, 7 Jan 97 11:37:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08919; Tue, 7 Jan 97 11:37:19 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA18253; Tue, 7 Jan 1997 11:28:55 -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 LAA21854 for ; Tue, 7 Jan 1997 11:28:53 -0800 Received: from gungnir.fnal.gov ("port 36551"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IDXLRR3SBS000PHG@FNAL.FNAL.GOV>; Tue, 07 Jan 1997 13:28:49 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id NAA08587; Tue, 07 Jan 1997 13:28:36 -0600 Date: Tue, 07 Jan 1997 13:28:36 -0600 From: Matt Crawford Subject: (IPng 2732) Re: MOs' 8+8 In-Reply-To: "07 Jan 1997 08:46:41 EST." <"199701071346.IAA22927"@raptor.research.att.com> To: Steven Bellovin Cc: Brian Carpenter CERN-CN , ipng@sunroof.eng.sun.com Message-Id: <199701071928.NAA08587@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{ Note on the bizarre concept of "unique enough": what I mean is > that in analysing security risks (or the risk of TCP checksum > collisions), an ESD is unique enough if the probability of > an ESD collision is below some acceptable level. > > Against non-malicious attacks, the probability of two 64-bit numbers > matching is about 2^-32 -- it's a birthday paradox. Right answer, wrong question. The right phrasing is, "For large N, when M samples are chosen independently with equal probability and with replacement from a set of N objects, the chance of at least one object being chosen twice or more exceeds 1/e when M > sqrt(N)." In simple terms, if you have 2^32 PCBs or more, indexed by the 64 bit ESD, there's a fair chance of at least one collision if the ESDs are random. Can ESDs be better than random, in terms of duplicates? Take IEEE addresses as a test case. Of the possible 2^46 IEEE addresses which can be issued, about 2^34 worth of space has been *allocated*. (There's no telling how many IEEE addresses have been stamped in hardware, but I would guess it's in the range 2^24 - 2^26.) How often have sites with 2^17 interfaces found a duplicate *in the hardware*? Most sites aren't that big, but I have heard claims of duplicates. I chalk that up in part to the slightly hierarchical way IEEE addresses are assigned. The same OUI probably hasn't been assigned twice, but some manufacturers have probably created many duplicates. So the conclusion I reach, and which I didn't expect, is this: perhaps we'd be best off with psuedo-random (but "good" pseudo- random) ESDs. This might *reduce* duplicates, and would certainly avoid a large bureaucratic cost in administering ESD space. Accordingly, I propose that during testing, some fraction f, 1/2 >= f >= 1/16 of the ESD space be reserved for pseudo-randomly generated ESDs. Matt _________________________________________________________ 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 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 Tue Jan 7 12:44:28 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08990; Tue, 7 Jan 97 12:44:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08984; Tue, 7 Jan 97 12:44:16 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA03167; Tue, 7 Jan 1997 12:35:55 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA13642 for ; Tue, 7 Jan 1997 12:35:50 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id PAA25842; Tue, 7 Jan 1997 15:29:58 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA03901; Tue, 7 Jan 1997 15:29:48 -0500 Message-Id: <9701072029.AA03901@wasted.zk3.dec.com> To: Masataka Ohta Cc: bound@zk3.dec.com, photon@nol.net, tli@jnx.com, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2733) Re: MOs' 8+8 In-Reply-To: Your message of "Tue, 07 Jan 97 19:10:13 +0200." <199701071010.TAA06148@necom830.hpcl.titech.ac.jp> Date: Tue, 07 Jan 97 15:29:48 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >OK. You actually are worrying about the modification of the locator >of source address. >But, I think it necessary to modify the locator of the destination >address. I don't think it should be modified in transit. It must be maintained end to end. >> I also believe if I sent a packet to dcdd::11:edcdba I want to find that >> address in by application dns lookup and it will be received only by >> dcdd::11:edcdba. >It means that you rely routers to dcdd:. So, you can rely routers >to dcdd: won't harmfully rewrite destination locator. I do not want the Routing Goop rewritten once it leaves the end node. >That is, rewriting of destination locator is harmless. I consider it dangerous. For reasons stated previously. >> When a site gets a new prefix the goop can be changed quite easily by >> advertising the new goop to the site >The problem is that it's a lot easier than you think. I think its even easier with Bob Hinden's RR proposal. RR + what I can do with Addr conf (stateless and dhcpv6) is very robust. >> and renumbering in the routing >> system using ND and autoconfiguration can take place with minimum of >> effort as opposed to the effort of securing the environment from >> altering the goop on the fly. >You are wrong here. We don't need any reconfiguration at all. Wrong where? If a sites prefix changes then the site must be renumbered. > >> It has a lot to do with how 8+8 is done for > >> DNS and the root servers. > > >Maybe for DNS but no for the root servers. > > >To make everything too much complex, the root servers should > >have constant locator. > > Please explain why as you asked me? Understand the existing anwer below. >Nor do I. But, it's not 8+2+6. It's 6+2+8 now. I hope we get Mike's updated draft soon. >> Whats this have to do with anything? WHy do you make this statement? > >Because you are insisting that you need so much time in face-to-face >meeting ignoring the mailing list discussion. I am not doing that. In fact I sent mail stating we should have much discussion on the mail list before the interim meeting. So I don't know what your talking about. /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 Tue Jan 7 12:53:03 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09013; Tue, 7 Jan 97 12:53:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09007; Tue, 7 Jan 97 12:52:46 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA05258; Tue, 7 Jan 1997 12:44:25 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA07050 for ; Tue, 7 Jan 1997 12:44:24 -0800 Received: from gungnir.fnal.gov ("port 36568"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IDXODUTYYQ000PHG@FNAL.FNAL.GOV>; Tue, 07 Jan 1997 14:43:08 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA08911; Tue, 07 Jan 1997 14:43:07 -0600 Date: Tue, 07 Jan 1997 14:43:07 -0600 From: Matt Crawford Subject: (IPng 2734) Re: MOs' 8+8 is evil, breaks firewalls. In-Reply-To: "07 Jan 1997 11:10:00 EST." <"9701071109.ZM19954"@seawind.bellcore.com> To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com Message-Id: <199701072043.OAA08911@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 most common use of addresses as identifiers is probably in access CH> control lists, either in firewalls or in network servers. If I want to let CH> the MIT users access Bellcore, I just have to make an entry for the CH> address prefix 18/8 in my firewall, or in my server. I claim that you never want to give access to all MIT users access to Bellcore. You actually want to do something more specific, but you either lack the necessary tools or are too lazy. If I am a person you want to block from Bellcore, I do not become the other sort of person simply because I walk onto the MIT campus and log into ATHENA. You may respond that MIT was a poor example because it is such an open environment. Let's take another. If you want Bob at Chrysler to give you some files, would you rather open your firewall to all of Chrysler, or create a private access token of some sort and give it to Bob? CH> How exactly do I program my firewall? Do I have to fall back to CH> using IPSEC even for routine work? Perhaps so. Is that so awful? Wouldn't you feel better knowing you don't have to explain how badguy@goodsite got into Bellcore files? If permitting access to "all MIT users" turns out to be useful, then someone will create a certificate to that effect and configure all MIT machines to be able to use it. _________________________________________________________ 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 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 Tue Jan 7 13:03:10 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09193; Tue, 7 Jan 97 13:03:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09180; Tue, 7 Jan 97 13:02:57 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA07573; Tue, 7 Jan 1997 12:54:35 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA19956 for ; Tue, 7 Jan 1997 12:54:36 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id PAA17809; Tue, 7 Jan 1997 15:36:52 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA03471; Tue, 7 Jan 1997 15:36:51 -0500 Message-Id: <9701072036.AA03471@wasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2735) Re: MOs' 8+8 In-Reply-To: Your message of "Tue, 07 Jan 97 14:15:07 +0100." <9701071315.AA06709@dxcoms.cern.ch> Date: Tue, 07 Jan 97 15:36:51 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, I think the risk is very high if one application breaks. But thats not the main issue. I think many things will break if altering the RG is permitted in transit. Also I think there were other reasons for Mike's proposal in addition to renumbering. The ISPs do not think the Provider Based Addressing will work. They are a customer of IPv6. Mikes LSID + more RG + ESD I think is a more flexible model than the Provider Based addressing. The proposal as I understand it appeases many of the providers and all the ones I have spoken with 1x1. So its a bit more than renumbering. But I believe we will get the benefits of renumbering without the alteration of IPv6 packets in transit from one end node to the other. /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 Tue Jan 7 13:44:58 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09306; Tue, 7 Jan 97 13:44:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09292; Tue, 7 Jan 97 13:44:30 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA16455; Tue, 7 Jan 1997 13:36:08 -0800 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA03080 for ; Tue, 7 Jan 1997 13:36:07 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id NAA29201 Posted-Date: Tue, 7 Jan 1997 13:32:50 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (SMI-8.6/SMI-SVR4) with ESMTP id NAA10968; Tue, 7 Jan 1997 13:34:33 -0800 for Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id QAA23340; Tue, 7 Jan 1997 16:34:34 -0500 for Date: Tue, 7 Jan 1997 16:34:34 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701072134.QAA23340@pobox.engeast.BayNetworks.COM> To: smb@research.att.com, crawdad@FNAL.GOV Subject: (IPng 2736) Re: MOs' 8+8 Cc: brian@dxcoms.cern.ch, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, > > So the conclusion I reach, and which I didn't expect, is this: > perhaps we'd be best off with psuedo-random (but "good" pseudo- > random) ESDs. This might *reduce* duplicates, and would certainly > avoid a large bureaucratic cost in administering ESD space. > My understanding is that an ESD is more or less permanently associated with an interface. So when is this psuedo-random number is generated for an interface? Is it when it is installed on a site, or is it when it comes up? How oftent do you expect ESD of a particular interface to change? 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 Tue Jan 7 14:22:40 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09373; Tue, 7 Jan 97 14:22:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09367; Tue, 7 Jan 97 14:22:22 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA25410; Tue, 7 Jan 1997 14:14:00 -0800 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA15664 for ; Tue, 7 Jan 1997 14:14:00 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id OAA00638 Posted-Date: Tue, 7 Jan 1997 14:05:15 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (SMI-8.6/SMI-SVR4) with ESMTP id OAA24371; Tue, 7 Jan 1997 14:07:04 -0800 for Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id RAA25830; Tue, 7 Jan 1997 17:07:05 -0500 for Date: Tue, 7 Jan 1997 17:07:05 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701072207.RAA25830@pobox.engeast.BayNetworks.COM> To: brian@dxcoms.cern.ch, bound@zk3.dec.com Subject: (IPng 2737) Re: MOs' 8+8 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > But thats not the main issue. I think many things will break if > altering the RG is permitted in transit. > > Also I think there were other reasons for Mike's proposal in addition to > renumbering. The ISPs do not think the Provider Based Addressing will > work. They are a customer of IPv6. Mikes LSID + more RG + ESD I think > is a more flexible model than the Provider Based addressing. > Well.. Mike's addressing smells pretty much as the Provider Based Addressing. How would it be more flexible if we don't allow the RG to change in transit? > The proposal as I understand it appeases many of the providers and all > the ones I have spoken with 1x1. So its a bit more than renumbering. > May be that is exactly due to the promise of easy renumbering? What are other proposal's features that providers like? 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 Tue Jan 7 15:33:07 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09433; Tue, 7 Jan 97 15:33:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09427; Tue, 7 Jan 97 15:32:55 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA11318; Tue, 7 Jan 1997 15:24:31 -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 PAA07655 for ; Tue, 7 Jan 1997 15:24:31 -0800 Received: from metro.isi.edu by metro.isi.edu (5.65c/5.61+local-23) id ; Tue, 7 Jan 1997 18:21:46 -0500 Message-Id: <199701072321.AA21983@metro.isi.edu> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: brian@dxcoms.cern.ch, bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2738) Re: MOs' 8+8 In-Reply-To: Your message of "Tue, 07 Jan 1997 17:07:05 EST." <199701072207.RAA25830@pobox.engeast.BayNetworks.COM> X-Phone: +1 703 812 3704 Date: Tue, 07 Jan 1997 18:21:46 EST From: "John W. Stewart III" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk as a former employee of a large provider, there are a number of things about mike's proposal that seem like they could be promising. however, i don't yet feel like i exactly and completely understand how all of this would work at a "systems" level, so i'm reserving judgement while anxiously waiting for a new version of the document > What are > other proposal's features that providers like? it hasn't been discussed much on the lists, but mike's claim is that 8+8 explicitly supports multi-homing in such a way that multi-homed folks pay for the resources that they consume. that's one of the pieces that i don't completely understand. currently multi-homing is supported in ad-hoc fashion by having many providers carry a prefix, resulting in providers having multiple paths to that prefix, and choosing one based on things like AS path and policy stuff like local-pref (for this reason bgp stuff like AS path manipulation and bgp communities can be involved, and the originator of the prefix has some control over the paths that others take to get to it); sometimes multi-homing can also include the carrying of more granular routing information (though possibly on a controlled scope). an assumption in the current method is that the routing information is carried everywhere .. not just by the two direct providers. so i'd like to understand better how 8+8 ends up resulting in the multi-homed organization paying in proportion to the global resources it consumes all of these questions bring up other questions in my mind about the relationship between the implications of the 8+8 model and the critical inter-domain routing as we understand it in today's internet. the pieces i'm most curious about are the practical organization of the large structures (especially with the potential of "self- organization"), and how the implied meaning of an 8+8 address prefix impacts (if at all) the ability of a routing domain (large structure or otherwise) to control the address prefixes for which it provides transit /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 Tue Jan 7 17:28:58 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09691; Tue, 7 Jan 97 17:28:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09685; Tue, 7 Jan 97 17:28:41 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA05858; Tue, 7 Jan 1997 17:20:17 -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 RAA12385 for ; Tue, 7 Jan 1997 17:20:05 -0800 From: Masataka Ohta Message-Id: <199701080111.KAA07324@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA07324; Wed, 8 Jan 1997 10:11:40 +0900 Subject: (IPng 2739) Re: MOs' 8+8 is evil, breaks firewalls. To: huitema@bellcore.com (Christian Huitema) Date: Wed, 8 Jan 97 10:11:39 JST Cc: mo@elmo.uu.net, ipng@sunroof.eng.sun.com In-Reply-To: <9701071309.ZM19998@seawind.bellcore.com>; from "Christian Huitema" at Jan 7, 97 1:09 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Subject: Re: (IPng 2726) MOs' 8+8 is evil, breaks firewalls. > > > > christian, > > > > never, ever, did I suggest that addresses become "volatile, changing > > every minute or so". > > > > to suggest that is pure fabrication and you are conjuring monsters > > where there are none. > > Mike, > > You are right. The "minute or so" is indeed an exageration, you were > careful to merely speak about relatively rare events, e.g. the rate at > which customers change providers today. That's why we should separate an address into an indentifier, which won't change so often, and a locator, which may change every minute as required by mobility. 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 Tue Jan 7 17:30:57 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09698; Tue, 7 Jan 97 17:30:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09692; Tue, 7 Jan 97 17:30:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA06147; Tue, 7 Jan 1997 17:22:17 -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 RAA12814 for ; Tue, 7 Jan 1997 17:22:15 -0800 From: Masataka Ohta Message-Id: <199701080119.KAA07354@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA07354; Wed, 8 Jan 1997 10:19:29 +0900 Subject: (IPng 2740) Re: MOs' 8+8 To: smb@research.att.com (Steven Bellovin) Date: Wed, 8 Jan 97 10:19:28 JST Cc: brian@dxcoms.cern.ch, ipng@sunroof.eng.sun.com In-Reply-To: <199701071346.IAA22927@raptor.research.att.com>; from "Steven Bellovin" at Jan 7, 97 8:46 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve; > Against non-malicious attacks, the probability of two 64-bit numbers > matching is about 2^-32 -- it's a birthday paradox. This may be > sufficient for non-security purposes, such as connection demultiplexing > in TCP. For security purposes, where the attacker may try to pierce > the veil of randomness, it's not good enough For security purposes? A randomly generated number and stateless autoconfiguration is no good for identification purpose of establishing security relationship. If you want security, it is inevitable to be somewhat stateful. Even with asymmetric cryptography, a host must have a static knowledge on it's private key. 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 Tue Jan 7 17:42:53 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09745; Tue, 7 Jan 97 17:42:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09739; Tue, 7 Jan 97 17:42:36 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA08302; Tue, 7 Jan 1997 17:34:15 -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 RAA15720 for ; Tue, 7 Jan 1997 17:34:12 -0800 From: Masataka Ohta Message-Id: <199701080129.KAA07399@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA07399; Wed, 8 Jan 1997 10:29:07 +0900 Subject: (IPng 2741) Re: MOs' 8+8 To: bound@zk3.dec.com Date: Wed, 8 Jan 97 10:29:06 JST Cc: mohta@necom830.hpcl.titech.ac.jp, photon@nol.net, tli@jnx.com, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, bgp@ans.net In-Reply-To: <9701072029.AA03901@wasted.zk3.dec.com>; from "bound@zk3.dec.com" at Jan 7, 97 3:29 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >But, I think it necessary to modify the locator of the destination > >address. > > I don't think it should be modified in transit. It must be maintained > end to end. As I explained already, maintaining it is simply impossible. Simply repeating unfounded opinion is boring. > >It means that you rely routers to dcdd:. So, you can rely routers > >to dcdd: won't harmfully rewrite destination locator. > > I do not want the Routing Goop rewritten once it leaves the end node. Simply repeating unfounded opinion is boring. > >That is, rewriting of destination locator is harmless. > > I consider it dangerous. For reasons stated previously. Your reason taht "I do not want the Routing Goop rewritten" is too weak. > >> and renumbering in the routing > >> system using ND and autoconfiguration can take place with minimum of > >> effort as opposed to the effort of securing the environment from > >> altering the goop on the fly. > > >You are wrong here. We don't need any reconfiguration at all. > > Wrong where? If a sites prefix changes then the site must be > renumbered. With locator ID separation, site renumbering does not need new autoconfiguration, unless you call locator announcement autoconfiguration. > >Nor do I. But, it's not 8+2+6. It's 6+2+8 now. > > I hope we get Mike's updated draft soon. You don't have to. 6+2+8 is the WG conclusion stated by Steve at San Jose. > >Because you are insisting that you need so much time in face-to-face > >meeting ignoring the mailing list discussion. > > I am not doing that. No. You have even ignored a conclusion of face-to-face meetings. 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 Tue Jan 7 18:01:43 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09793; Tue, 7 Jan 97 18:01:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09787; Tue, 7 Jan 97 18:01:26 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA11603; Tue, 7 Jan 1997 17:53:04 -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 RAA19935 for ; Tue, 7 Jan 1997 17:53:01 -0800 From: Masataka Ohta Message-Id: <199701080150.KAA07464@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA07464; Wed, 8 Jan 1997 10:50:35 +0900 Subject: (IPng 2742) Re: MOs' 8+8 is evil, breaks firewalls. To: huitema@bellcore.com (Christian Huitema) Date: Wed, 8 Jan 97 10:50:34 JST Cc: mo@elmo.uu.net, ipng@sunroof.eng.sun.com In-Reply-To: <9701071309.ZM19998@seawind.bellcore.com>; from "Christian Huitema" at Jan 7, 97 1:09 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian; > On the other hand, renumbering is renumbering is renumbering. Sure. Let's solve the renumbering issue, thoroughly. > Forced > renumbering by the network will meet the same customer resistance as > renumbering to the provider's demand, unless the firewall and other access > control list problems are also solved. What kind of firewalls are you thinking of? If filtering is based on manually configured locator, we can do nothing except to manurally reconfigure it upon renumbering. No addressing architecture can help. But, if the firewall use some cryptographic technology such as shared secrete key (shared by end-to-end and by the firewall itself) or public key (known to the firewall), location independent ID gives the index for the firewall to access the secrete or public key database. Note also that, ID forgery nor accidental ID match is a security problem here, because multiple keys should be checked to find one which matches. Thus, the danger of forgery or possibility of accidental match depends on the strength and length of the keys, not by the strength nor length of the IDs. Well, this may mean somewhat less performance to check a lot of keys. But, no, even a single host may have multiple keys anyway. And, if a host inside the firewall can ask the firewall to create a hole for some external host (based on locator, secret key or anything), we can use any addressing architecture. So, why do you think 8+8 is related to firewalling in a so bad way? 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 Tue Jan 7 19:41:56 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09916; Tue, 7 Jan 97 19:41:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09910; Tue, 7 Jan 97 19:41:44 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA24639; Tue, 7 Jan 1997 19:33:22 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA08792 for ; Tue, 7 Jan 1997 19:33:23 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA20886; Tue, 7 Jan 1997 22:24:20 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31705; Tue, 7 Jan 1997 22:24:19 -0500 Message-Id: <9701080324.AA31705@wasted.zk3.dec.com> To: "John W. Stewart III" Cc: dhaskin@baynetworks.com (Dimitry Haskin), brian@dxcoms.cern.ch, bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2743) Re: MOs' 8+8 In-Reply-To: Your message of "Tue, 07 Jan 97 18:21:46 EST." <199701072321.AA21983@metro.isi.edu> Date: Tue, 07 Jan 97 22:24:18 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, These are questions I am glad you asked as I think they are key to 8+8. One thing Mike did was remove the concept of "monks in robes" handing out addresses too at least for Internet Reigistry (which I don't think even IEPG?? has figured out). If we can understand and define the autonomy of self organizing providers would it not eliminate a lot of overhead? I ask as I don't know? On multihoming. I have two sites at Digital but with different providers. By having packets to me at ff::11:EFCDAB and fe::11:EFCDAB would not that be easier to charge me and even give me a rate as my ESD is the same and I am a frequent user of your service like AT&T or MCI does with the phone? And I could also be tracked as a cell device is in my truck as I get packets or send packets from different locations in my cell area? Is there any benefit from the ESD being constant from a business perspective to the user or the provider? That can't be done today really with an IP address at all. I also don't think it can be done the way the present provider addressing is specified either. I also don't think this gives reason to alter the LSID or the RG in transit. /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 Tue Jan 7 19:56:54 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09949; Tue, 7 Jan 97 19:56:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09943; Tue, 7 Jan 97 19:56:43 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA26089; Tue, 7 Jan 1997 19:48:21 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA11562 for ; Tue, 7 Jan 1997 19:48:21 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA02173; Tue, 7 Jan 1997 22:40:23 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA02943; Tue, 7 Jan 1997 22:40:19 -0500 Message-Id: <9701080340.AA02943@wasted.zk3.dec.com> To: Masataka Ohta Cc: bound@zk3.dec.com, photon@nol.net, tli@jnx.com, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, bgp@ans.net Subject: (IPng 2744) Re: MOs' 8+8 In-Reply-To: Your message of "Wed, 08 Jan 97 10:29:06 +0200." <199701080129.KAA07399@necom830.hpcl.titech.ac.jp> Date: Tue, 07 Jan 97 22:40:19 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve did not conclude anything but suggested where we may be headed. Read the IPng minutes. You simply don't know what your talking about. You are also not defending your claims or giving any technical input or details to discuss. Or even architectural or model premises. Even if you would take your conclusions and then state the premises maybe I could follow you via inductive logic. Get a grip and fix your attitude buddy. I think you need an attitude adjustment. Note you never agree with anyone, you never say when your wrong, and that sounds like you have a serious ego-centric behavior problem. Go fix it and help us work on technology standards, you appear to be a bright person but its all clouded in your attitude with email. This is not how you act in person at the IETF meetings. Is the terminal like a drug to you that causes you to act this way. I am not listening to you anymore or reading your mail for awhile. /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 Tue Jan 7 20:25:19 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09975; Tue, 7 Jan 97 20:25:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09969; Tue, 7 Jan 97 20:25:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA28566; Tue, 7 Jan 1997 20:16:45 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA15424 for ; Tue, 7 Jan 1997 20:16:46 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA30859; Tue, 7 Jan 1997 23:12:36 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA07226; Tue, 7 Jan 1997 23:12:35 -0500 Message-Id: <9701080412.AA07226@wasted.zk3.dec.com> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: brian@dxcoms.cern.ch, bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2745) Re: MOs' 8+8 In-Reply-To: Your message of "Tue, 07 Jan 97 17:07:05 EST." <199701072207.RAA25830@pobox.engeast.BayNetworks.COM> Date: Tue, 07 Jan 97 23:12:35 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry, >> But thats not the main issue. I think many things will break if >> altering the RG is permitted in transit. >> >> Also I think there were other reasons for Mike's proposal in addition to >> renumbering. The ISPs do not think the Provider Based Addressing will >> work. They are a customer of IPv6. Mikes LSID + more RG + ESD I think >> is a more flexible model than the Provider Based addressing. >> >Well.. Mike's addressing smells pretty much as the Provider Based Addressing. >How would it be more flexible if we don't allow the RG to change in transit? I just responded to John Stewart on this. Essentially 8+8 (and thats what I am calling it until Mike himself changes the title of the draft) I think will work. The LSID permits providers to work amongst themselves with out both an Internet Registry and Provider set of bits for one thing. The routing goop can be flat routed between providers too as d iscussed in the draft. The RG + ESD permits a paradigm where the network is cleanly topologically divided to support provider prefix changes without changing the ESD within organizations. This was the jist of my comment earlier today with using the Hinden RR and Autoconfig in IPv6 at each link (stateless or stateful). The IANA is less involved with handing out addresses and is only needed to declare ESD Mode types and possibly assisting with the LSIDs. The rest of the bits are self organizing. This reduces much overhead for the provider. I do not believe I understand all parts about the DNS until I see Mike's next draft and that is really important. I also have just about determined all the implementation ramifications for an IPv6 stack and the APIs and DNS but want to see Mike's next proposal before I do a logic check with the implementors (too much work to do it twice in one month). >> The proposal as I understand it appeases many of the providers and all >> the ones I have spoken with 1x1. So its a bit more than renumbering. >> >May be that is exactly due to the promise of easy renumbering? What are >other proposal's features that providers like? The multihoming as John stated can be of benefit. I think it permits the providers to support Mobility better. A node roaming into a providers domain (like an airplane) can negotiate a provider routing goop across all providers from London to San Francisco before the flight, via using it as a care-of-address multicast prior to leaving on the flight. The bottom line is that my customers want IPv6 right now and to see us in the IETF define how they can get real addresses today. Mike's 8+8 proposal is the first addressing proposal that I hear most people I talk with say that might work and I think I might like it. So for me its pure business and I admit it. Do I like everything about ND or even specs I have worked on for IPv6 after community input, NO. But I move on to get something built and done and delivered. Mike's proposal is very well written, clear, has integrated a lot of bright peoples ideas, and again most people I talk to think it will work. I have my heart burn and that is stepping on packets in transit which Dave Clark proposed some time ago, and I still don't like the idea. Its too risky from an engineering perspective and leaves I think to far the Deering/Hinden essential model of simplicity for IPv6 right now. But Mike's proposal as the rest of IPv6 (as Dan Harrington pointed out) clearly permits us in the future to further experiment with an addressing architecture tomorrow and TCPng and UDPng. I say lets make it work but reduce the risk. Sorry I build products and thats how I think. Thats my input to you and the group for now. I am listening though (except for one person for the time being anyway). I would like providers to comment on the LSID being 8.1K in limit? Do you think 8+8 is a bad idea? Do you want to move forward with the present provider based addressing? Do you have another addressing architecture in mind? /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 Wed Jan 8 05:22:03 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10536; Wed, 8 Jan 97 05:22:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10530; Wed, 8 Jan 97 05:21:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA13750; Wed, 8 Jan 1997 05:13:27 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA04183 for ; Wed, 8 Jan 1997 05:13:28 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id OAA15647 for ; Wed, 8 Jan 1997 14:13:26 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA20277; Wed, 8 Jan 1997 14:13:25 +0100 Message-Id: <9701081313.AA20277@dxcoms.cern.ch> Subject: (IPng 2746) Where lies evilness? [was: Re: MOs' 8+8 is evil, breaks firewalls.] To: ipng@sunroof.eng.sun.com Date: Wed, 8 Jan 1997 14:13:25 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9701071109.ZM19954@seawind.bellcore.com> from "Christian Huitema" at Jan 7, 97 11:10:00 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, Are we so sure where the evilness lies? There are good arguments why firewalls are evil. They break connectivity in an unsystematic way. They also give a false illusion of security (for example, they are not too much use against spoofed source addresses). Their existence opened the door for NAT salespersons. And they make renumbering difficult, although we must sometimes renumber in *any* scenario. ... > Do we have a DNS entry for network prefixes that > I can use for firewalls and other access control lists? This is just the same problem as obtaining authenticated current RG. We have to solve that anyway. > > And, more important, how do I convince the operators of large networks > that we can do all that? Well, you might persuade UUnet, at least :-) > > Frankly, I would be more confortable with geographic addresses... > We're still waiting for a fully worked out proposal for them. I suspect that any geographic proposal with fully worked out routing mechanisms will look amazingly similar to 6+2+8. Brian Carpenter ------------------------------------------------------------------------------ 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 Wed Jan 8 05:33:10 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10548; Wed, 8 Jan 97 05:33:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10542; Wed, 8 Jan 97 05:32:58 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA14913; Wed, 8 Jan 1997 05:24:34 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA05868 for ; Wed, 8 Jan 1997 05:24:36 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id IAA20360; Wed, 8 Jan 1997 08:21:51 -0500 Date: Wed, 8 Jan 1997 08:21:51 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9701080821.ZM20358@seawind.bellcore.com> In-Reply-To: Masataka Ohta "Re: (IPng 2729) Re: MOs' 8+8 is evil, breaks firewalls." (Jan 8, 10:50am) References: <199701080150.KAA07464@necom830.hpcl.titech.ac.jp> X-Mailer: Z-Mail (3.2.1 10oct95) To: Masataka Ohta , huitema@bellcore.com (Christian Huitema) Subject: (IPng 2747) Re: MOs' 8+8 is evil, breaks firewalls. Cc: mo@elmo.uu.net, 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 > So, why do you think 8+8 is related to firewalling in a so bad way? > Masataka, Today's Internet addresses are essentially identifiers. The "location" part is in fact computed in real time by the network, using BGP, OSPF, etc. The move towards CIDR was an attempt to make that computation simpler, by tying addresses to locations in the network. I think that everybody agrees that we should continue moving somewhat in that direction, because there are indeed limits to the computing complexity that the network can sustain. Because today's addresses are identifiers, I have a relatively good knowledge of the address to user mapping -- or, at the very least, of the mapping between an address and the owner of a host. You may object that source addresses are very easy to forge, and you will indeed be right. But destination addresses on the other hand are relatively safe. You can trust them about as much as you trust your network provider, which is not enough for critical tasks but quite sufficient for routine work. Breaking the information into a location part and an identification part completely removes that level of certification. You would need cryptographic verification for all transactions, even for something as simple as discriminating local users from remote calls. I do not believe that we can sell that to the user community. In fact, it would break one of the strong design hypothesis of IPv6, i.e. that it operates exactly the same way as IPv4 and only requires minimal retraining of network managers. Excuse me, but explaining everyone that they have to understand how to manage cryptographic keys before they can have even a minimal amount of confidence in the network is a major disruption of the "installed base." -- 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 Wed Jan 8 08:13:54 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10708; Wed, 8 Jan 97 08:13:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10702; Wed, 8 Jan 97 08:13:42 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA03521; Wed, 8 Jan 1997 08:05:19 -0800 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA19194 for ; Wed, 8 Jan 1997 08:05:05 -0800 Received: from nestvx.kar.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA18800; Wed, 8 Jan 1997 07:55:10 -0800 Received: from sand2.kar.dec.com by nestvx.kar.dec.com; (5.65/1.1.8.2/10Jul96-9.1MPM) id AA27153; Wed, 8 Jan 1997 16:54:41 +0100 Received: from localhost by sand2.kar.dec.com; (5.65v3.2/1.1.8.2/17Sep96-1133AM) id AA15314; Wed, 8 Jan 1997 16:54:39 +0100 Message-Id: <9701081554.AA15314@sand2.kar.dec.com> X-Mailer: exmh version 1.6.9 8/22/96 To: ipng@sunroof.eng.sun.com Cc: jork@kar.dec.com Subject: (IPng 2748) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: Your message of "Thu, 02 Jan 97 15:05:12 MST." <199701022205.PAA07273@kohala.kohala.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Jan 97 16:54:39 +0100 From: "Markus Jork" X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk just a short addition to the "received hop limit" discussion: >> First, Neither the basic or advanced API spec seems to provide a way >> to obtain the Hop Limit on a *received* datagram. [...] > Obviously we could provide a way to return the received hop limit, if > people think it's needed. I've never needed it, and traceroute is the > only application that I am familiar with that uses it. RSVP needs to know about it (to detect the existance of RSVP-unaware previous hops). So I also vote for putting it in the spec. Markus ------------------------------------------------------------------------------ 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 Wed Jan 8 10:06:49 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10958; Wed, 8 Jan 97 10:06:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10952; Wed, 8 Jan 97 10:06:31 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA25550; Wed, 8 Jan 1997 09:58:06 -0800 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA00793 for ; Wed, 8 Jan 1997 09:58:06 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id JAA03826 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id JAA15426 Posted-Date: Wed, 8 Jan 1997 09:27:04 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id MAA05844; Wed, 8 Jan 1997 12:27:05 -0500 for Date: Wed, 8 Jan 1997 12:27:05 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701081727.MAA05844@pobox.engeast.BayNetworks.COM> To: tbates@cisco.com Subject: (IPng 2749) Re: a different proposal for ipv6 in bgp Cc: dkatz@cisco.com, jstewart@metro.isi.edu, 6bone@isi.edu, bgp@ans.net, jstewart@isi.edu, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, > > Dimitry Haskin writes: > * At 04:53 PM 1/6/97 -0800, Dave Katz wrote: > * >It remains unclear to me why it is desirable to couple multiprotocol > * >support and the AS number space increase. The two functions are > * >completely orthogonal and as far as I can tell there is no benefit for > * >*mandating* that the two changes be made at the same time. > * > > * >Clearly the multiprotocol stuff could be deployed and become useful > * >more quickly than the AS number extension, due to the fact that it > * >can be done in a backward compatible, pairwise fashion. > * > > * I don't believe that this assessment is accurate. The BGP5 proposal > * is as backward compatible (if not more) with BGP4 as the proposed multiprot > * ocol > * extension to BGP4. I.e., v4 routing information exchanged between BGP5 > * peers can be fully re-advertised via BGP4 and vise versa. As you might not > * ice > * we even didn't require to immediately extend AS number space for v4 > * to keep the v4 related changes to a bare minimum. To support v6, bgp data > * structures need to change any way and v6 has no backward compatibility > * issue at this point. Thus it only makes sense to get a larger AS space for > * v6 now > * to avoid another transition later. > * > > Let's perhaps look at this a little differently. Since widespread > deployment of BGP4 and the hassle of transition from BGP3 (for those > of us who went through this, it was certainly not something to do more > than say a couple of times in your lifetime and in that case we were > driven by an immediate need) we have actually been able to add several > new attributes (communities, reflection, etc) to keep enhancing > inter-domain routing capabilities (all in use today) with very little > pain. We definitely not proposing a transition of the grand-scale of moving from the classfull to classless routing paradigm. I can assure you that what we're proposing is of a much smaller scale, practically no scale at all. And our intention was to make it even more extensible than BGP4. >The reason we've been able to do this is becuase we essentially > haven't messed with the underpinnings of the protocol itself. Neither did we. > The operational factors in doing this are much greater than perhaps many > folks realize (ISPs tell me different if you think I'm > overstating). In your proposal, before I can get benefit of the pain I > need to move I have the entrie Internet moved over to BGP5. This is definitely an overstatement. > I understand I can use it for multiprotocol on a pairwise basis > providing I dont touch the AS space but this doesn't seem like too > much of a win when I can add attributes to the exisiting BGP4 protocol > and start using BGP for multi-protocol interdomain support in an > understood and well-practiced operational way. This is a win because we don't have to drag 2-byte ASN into IPv6. There is enough discomfort with the 2-byte ASN to make me belive that dragging 2-byte ASN into v6 as a bad idea. And the most important it is _not_ necessary. Is it v6 that all this multiprotocol support is really about? And, if you want, you can use the option of gradually extending ASN for v4 too. For some, probably long, period simple mapping of zero-extended 4-byte ASN into 2-byte ASN used by BGP4 will ensure backward compatibility with BGP4. > > * >The deployment considerations for multiprotocol support are far less > * >onerous than the AS number stuff. > * > > * Care elaborate (in light of the BGP5 proposal)? > * > See above. See above. > > If you buy into my ease of deployment point above [and of course you > might not] let's look at where we are in terms of AS space as this is > other factor driving the current discussuion. Since I've started the > CIDR report I produce I've also been tracking the activity of ASes in the > global routing system as seen in BGP by a well connected router. The > interesting trend you see is the growth of ASes in the global routing > system is essentially linear. Whilst my data source is quite small (see > http://www.remplyees.org/~tbates/cidr.as.plot.html) this seems to be > growing at an average rate of 3 ASes per day. The linear growth if > further backed in "An analysis of Internet Inter-Domain Topology and > Route Stability" by Ramesh Govindan and Anoop Reddy from USC/ISI. > > If we use this growth rate and look at a couple of scenarios: > > Best Case > --------- > Assuming we have 65000 (not including Private ASes) ASes and > accounting for the 1937 ASes already in the system (this also assumes > we could re-use ones pre-allocated and not currently being used which > is probably over optimistic) we have 63063 ASes to play with resulting > in : > > 63063/3 = 21021 Days > 21021/365 = 57 Years before we run out. > > Worst Case > ---------- > > If we assume 15535 ASes will in fact be wasted (private space, > early/bad allocations before RFC1930, some ISPs getting as AS > for the wrong reason) we still end up with. > > (50000-1937)/3/365 = 43.8 years > > Now you could argue that this doesn't take into account the increasing > trend towards mutlihoming (not currently shown in the AS growth either > but anyway ;-)). However, there are a number of things to help with > this approach. > > 1. Improving use of private AS space. ISP router should be able to > override customer's AS with a preconfigured number. ISP router > shouldn't propagate a route to a customer router if the route includes > AS of the customer (this AS is preconfigured on the ISP router). > > 2. Use RIPv2 (instead of BGP) - doesn't require AS number at all. > > 3. Use single globally unique AS number (draft-stewart-bgp-without-as-00.txt) > None of that will be necessary for v6 if we use a larger ASN space there. > So with this in mind do we really want to tackle the AS number issue > right now at the risk of the operational impact ? You still didn't convince me that there is a significant operational impact with the BGP5 proposal. If you afraid to extend ASN for v4, we don't force you to do so. But we want a larger ASN space for v6. Would you agree that there is a zero operational impact for v6 at this point? If it not for v6 we, most probable, would be looking in extending BGP-4, don't we? > If the answer is yes > (which I must abmit seems hard to see from my viewpoint) then we > better make sure we look at all aspects before spinning the protocol > again wouldn't you agree ? > Sure. > --Tony 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 Wed Jan 8 10:07:50 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10965; Wed, 8 Jan 97 10:07:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10515; Wed, 8 Jan 97 04:11:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA07459; Wed, 8 Jan 1997 04:02:43 -0800 Received: from ns2.eds.com (ns2.eds.com [199.228.142.78]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id EAA22674 for ; Wed, 8 Jan 1997 04:02:44 -0800 Received: from nnsp.eds.com (nnsp.eds.com [130.174.32.78]) by ns2.eds.com (8.8.4/8.8.4) with ESMTP id HAA27249; Wed, 8 Jan 1997 07:02:42 -0500 (EST) Received: from [130.175.183.223] (netmac.iscg.eds.com [130.175.183.223]) by nnsp.eds.com (8.7.6/8.7.3) with ESMTP id HAA24708; Wed, 8 Jan 1997 07:02:11 -0500 (EST) X-Sender: jcutle01@info1.iscg.eds.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jan 1997 06:54:23 -0500 To: bound@zk3.dec.com From: "James R. Cutler" Subject: (IPng 2750) Re: MOs' 8+8 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: bound@zk3.dec.com > >The bottom line is that my customers want IPv6 right now and to see us >in the IETF define how they can get real addresses today. >/jim > As Corporate Registration Authority for EDS, I need to know "yesterday" how to define IPv6 addressing for EDS and EDS customers so that I can put address assignment and registration tools and procedures into place. Until I am able to assign IPv6 addresses, no router engineer or systems configurator can deploy IPv6 in any meaningful way. This is what we often call a "show stopper". JimC - James R. Cutler EDS Mail Stop 4165 800 Tower Drive, Troy, MI 48007-7012 Phone: 810-265-7514 FAX: 810-265-7514 EDS Internal Web: World Wide Web: ------------------------------------------------------------------------------ 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 Wed Jan 8 11:34:45 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11217; Wed, 8 Jan 97 11:34:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11211; Wed, 8 Jan 97 11:34:27 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA16369; Wed, 8 Jan 1997 11:26:05 -0800 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA08682 for ; Wed, 8 Jan 1997 11:26:04 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id LAA08086 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id LAA14934 Posted-Date: Wed, 8 Jan 1997 11:19:09 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id OAA12593; Wed, 8 Jan 1997 14:19:11 -0500 for Date: Wed, 8 Jan 1997 14:19:11 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701081919.OAA12593@pobox.engeast.BayNetworks.COM> To: bound@zk3.dec.com Subject: (IPng 2751) Re: MOs' 8+8 Cc: brian@dxcoms.cern.ch, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >... > > Do you think 8+8 is a bad idea? > I haven't form an opinion on 8+8 as I don't really understand all ramifications of the proposal. At this point I just asking questions in hope to get to understand it better. > Do you want to move forward with the present provider based addressing? > This is definitely sensible to do independently of the 8+8 efforts. 8+8 is not enough understood and is too experimental at this point to stall any provider based deployment. > Do you have another addressing architecture in mind? > Noop. > /jim > 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 Wed Jan 8 12:54:54 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11347; Wed, 8 Jan 97 12:54:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11341; Wed, 8 Jan 97 12:54:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA03509; Wed, 8 Jan 1997 12:46:12 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA06599 for ; Wed, 8 Jan 1997 12:46:12 -0800 Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.4/8.6.12) with SMTP id PAA26461; Wed, 8 Jan 1997 15:43:33 -0500 (EST) Message-Id: <199701082043.PAA26461@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: "James R. Cutler" Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2752) Re: MOs' 8+8 In-Reply-To: Your message of "Wed, 08 Jan 1997 06:54:23 EST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 08 Jan 1997 15:43:32 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "James R. Cutler" writes: > As Corporate Registration Authority for EDS, I need to know "yesterday" > how to define IPv6 addressing for EDS and EDS customers so that I can > put address assignment and registration tools and procedures into place. > > Until I am able to assign IPv6 addresses, no router engineer or systems > configurator can deploy IPv6 in any meaningful way. This is what we > often call a "show stopper". Would the lack of commercial router products sort of get in the way, too? Perry ------------------------------------------------------------------------------ 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 Wed Jan 8 13:09:31 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11503; Wed, 8 Jan 97 13:09:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11497; Wed, 8 Jan 97 13:09:18 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA06121; Wed, 8 Jan 1997 13:00:55 -0800 Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA11199 for ; Wed, 8 Jan 1997 13:00:50 -0800 Message-Id: <199701082100.NAA11199@mercury.Sun.COM> Received: from RALVM6 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2527; Wed, 08 Jan 97 16:00:33 EST Date: Wed, 8 Jan 97 15:59:46 EST From: "Karen Tracey" To: ipng@sunroof.eng.sun.com Subject: (IPng 2753) Thoughts on alternative addressing proposals Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've been watching the discussion of the alternative addressing architecture proposals hoping to gain a better understanding of them and their implications for IPv6. To some extent I have, but I still feel like I'm looking at a very fuzzy picture. So I decided to try to write up some of my thoughts, issues, etc. That helped too, but the picture's not in focus yet. Maybe some feedback would help. I apologize for the length of this.... First, I think Christian and Pedro have made some very good points. We need to acknowledge that these alternative "addressing architectures" really represent a fundamental architectural change, and look at them from that perspective. We need to determine what the goals of the group are, see how these proposals meet/conflict with the goals, determine the implications of the proposals (that is, figure out what breaks), decide if what gets broken can be fixed and how. I think it is dangerous to view the proposals as relatively small changes. It is dangerous because we might miss a subtle thing that breaks and turns out to be a show-stopper to fix. It may also have the unfortunate side-effect of blinding us to potentially better solutions because we are trying to change as little as possible. That said, I realize that the issue of address as identifier, locator, or both was discussed much earlier on in the development of IPng, so maybe there is some reluctance to re-hash old discussions and arguments. But I think we have to if we are to give proper consideration to these proposals, because these proposals DO reverse the earlier decision. One thing (address) made up of two pieces (identifier and locater) and packaged together in one 16 byte field is really 2 things, and essentially not a combined locator/identifier as in IPv4. (Since I've only been following this group for about 7 months, it would help me to read any old documents generated by the previous discussion. Does anyone have any pointers?) One question I have then, is why are we re-opening a previously closed discussion? What is the new information we have learned that makes this necessary? This ties in with Pedro's questions on what are the group's goals. Have the goals changed? Brian Carpenter responded with a pointer to draft-iab-ip-ad-today-01.txt. This draft has a short section on IPv6 stating essentially that the IAB feels that it is unfortunate that IPv6 retained IPv4's combined identifier/locator. The draft status of this document suggests that it may be the result of some "new information" about exactly what IPv6 needs to "fix" in IPv4, so therefore something of a change in goals. At another level, it is not so much a change of goals, as it is a recognition that one goal (don't drastically change anything unless it is a recognized inhibitor to future Internet growth) no longer applies to this aspect of IPv4. The next step then is to ask, what is wrong with combined identifier/locator addresses? What problems do they cause that we need to fix in IPv6? From O'Dell's draft, the problem is Route Scaling. This problem is better understood now than when current IPv6 addressing architecture was designed, and as a result, "the current IPv6 addressing proposal fails to provide an operationally-scalable scheme for aggressive topological aggregation and the continued scaling of the routing architecture." There seem to be two specific problems then identified in the O'Dell draft: - Renumbering is required to meet the above goal, but renumbering is still too hard. - Multihoming, given the CIDR approach to meeting the above goal, (which is all we have with the current IPv6 proposal), hurts the ability to scale. This is an additional problem that the IPv6 proposal now needs to fix. The belief is that you can solve these problems by eliminating the combined identifier/locator, and the proposal then goes on to split the 16-byte IPv6 address into 2 8-byte quantities. And here is where I got somewhat uncomfortable, because the change in some ways seemed small but in other ways fundamental. And I wasn't quite sure I could properly assess the implications of the fundamental change, because it was somewhat masked by the seemingly minor nature of the changes proposed. I found it helped me to compare/contrast this proposal with an abstract network protocol that had no concept of a combined identifier/locator. Identifiers are used by applications to name partners, and the network protocol is responsible for figuring out how to locate the partner. Applications are not aware of, and can in no way see, the locator used by the protocol. That is when I began to realize one of the reasons I was uncomfortable with 8+8. In 8+8, locators are still visible to applications. The proposal, in attempting to change as little as possible, hasn't really gotten rid of the combined identifier/locator. It's something of a hybrid scheme. And being a hybrid, I'm not sure it has all the benefits of protocols that don't have a combined identifier/locator. Specifically, I'm not sure it has the benefit of "easy renumbering", because locators are visible to applications. If applications can see the locators, then to ensure "easy renumbering" you have to make sure that applications can handle locators changing. In general you cannot do that, because you have no control what an application does with a piece of data it can happen to see. You can say applications shouldn't care, and shouldn't depend on locators at all, etc., but all you are doing then is describing the guidelines that should be followed for an application to allow "transparent renumbering". And if you have to have such guidelines, I'm not sure you have made renumbering "easy enough". Thinking about this abstract protocol also helped me to identify potential problem areas to examine when considering the proposal. For example, with no combined identifier/locator, the network protocol has to somehow map identifier to locator. Some discussion here has been focused on using DNS for this. DNS already maps names to combined identifier/locator, it seems not too difficult to extend it to map names to split identifiers and locators. But what about the reverse mapping? Does that involve a combined locator/identifier, or just the identifier? It seems like the answer should be just the identifier, because in doing this reverse mapping I think you are trying to determine more "what this identifies" rather than "how do I get to this". But, if it is just the identifier, and all topological information has been confined to the locator, how do we do this reverse mapping? Today, doesn't reverse DNS lookup make use of the topological information in the IPv4 address? I'd like to see more discussion of how 8+8 impacts reverse DNS lookup. Continuing to think of this fictitious protocol, I came roundabout to a problem that has been discussed extensively on this list: the security implications of these proposals. But coming to it this way made it appear somehow clearer, involving basic concepts instead of more specific technical problems such as "how do you deal with changes in routing goop" or "is it OK for routers to rewrite headers". I thought: If the network protocol somehow knows how to map identifier to locator, then there is no need to put a source locator in a packet. You can just put the source identifier. If a reply is needed, the network protocol on the other end can map the identifier to a locator however it does that. Note you have no assurance a packet came from the claimed source identifier. But you do have some assurance that a reply will go to the claimed source, because you trust the network's identifier to locator mapping process. How does that compare to a combined identifier/locator protocol? Pretty much the same. You may receive a packet appearing to come from a source that really did not send it, but a reply will be routed to the claimed source, not the actual source, if you trust the network's routing system. How does it compare to the hybrid 8+8 proposal? Here there is a major change. You may receive a packet appearing to come from a source that really did not send it, AND a reply will be routed to the actual source, not the claimed source. Any "security" relying on identifiers is therefore completely false. Then I realized a lot of the discussion on dealing with changes in the routing goop is really a discussion of two problems: 1 - How does the network correctly adapt to changes in topology? 2 - How are endpoints assured that a claimed source identifier is true? I don't see how 8+8 ever accomplishes the 2nd item, unless there is somehow security above the base protocol. This seems like a major change compared to the current situation in IPv4, and a potentially large problem? Recent mail from Christian sounds like he thinks this is a big problem too. He mentions needing cryptographic verification to fix, and fears that that will never sell. Could it be dealt with in a simpler fashion, by adding some source RG validity checking on packet receipt? How 1 is accomplished is tied somewhat to how the identifier->locator mapping is done. The 8+8 scheme seems rather asymmetric here. Destination locators are determined by DNS lookup. Source locators are inserted by site boundary routers. Changing the topology therefore requires DNS and router reconfiguration. You might also want to have some router-router RG propagation protocol. I think that ties in with where 8+8 talks about RG "flowing", but that's all kind of fuzzy to me. What about TCP connections established before a topology change? Well, when the routers are reconfigured, they will start inserting updated source RG on all packets, and TCP connections will be fine if the destination switches to the updated RG on receipt. How do you know the new RG is "good"? Well, how did you know the original RG was "good"? There are bunches of other issues, but this is way too long already. My impression right now is that the alternative addressing proposals go too far without going far enough. They change enough to break some things (that may be fixable), and make transition harder. But I'm not convinced they change enough to really solve the problems they address. Karen Tracey ------------------------------------------------------------------------------ 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 Wed Jan 8 13:22:58 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11560; Wed, 8 Jan 97 13:22:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11554; Wed, 8 Jan 97 13:21:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA08348; Wed, 8 Jan 1997 13:13:19 -0800 Received: from ftp.com (ftp.com [128.127.2.122]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA15008 for ; Wed, 8 Jan 1997 13:13:18 -0800 Received: from ftp.com by ftp.com ; Wed, 8 Jan 1997 16:13:06 -0500 Received: from mailserv-2high.ftp.com by ftp.com ; Wed, 8 Jan 1997 16:13:06 -0500 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id QAA27999; Wed, 8 Jan 1997 16:13:08 -0500 Message-Id: <199701082113.QAA27999@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: perry@piermont.com Cc: ipng@sunroof.eng.sun.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 2754) Re: MOs' 8+8 Date: Wed, 08 Jan 1997 16:09:02 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Reply to your message of 1/8/97 3:48 PM > >Would the lack of commercial router products sort of get in the way, >too? 6-bone. -- Frank ------------------------------------------------------------------------------ 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 Wed Jan 8 14:03:29 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11629; Wed, 8 Jan 97 14:03:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11599; Wed, 8 Jan 97 13:56:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA15201; Wed, 8 Jan 1997 13:47:39 -0800 Received: from ns2.eds.com (ns2.eds.com [199.228.142.78]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA27179 for ; Wed, 8 Jan 1997 13:47:36 -0800 Received: from nnsp.eds.com (nnsp.eds.com [130.174.32.78]) by ns2.eds.com (8.8.4/8.8.4) with ESMTP id QAA22941; Wed, 8 Jan 1997 16:47:04 -0500 (EST) Received: from [130.175.183.223] (netmac.iscg.eds.com [130.175.183.223]) by nnsp.eds.com (8.7.6/8.7.3) with ESMTP id QAA02229; Wed, 8 Jan 1997 16:46:19 -0500 (EST) X-Sender: jcutle01@info1.iscg.eds.com Message-Id: In-Reply-To: <199701082043.PAA26461@jekyll.piermont.com> References: Your message of "Wed, 08 Jan 1997 06:54:23 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jan 1997 16:27:32 -0500 To: perry@piermont.com From: "James R. Cutler" Subject: (IPng 2755) Re: MOs' 8+8 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >"James R. Cutler" writes: >> As Corporate Registration Authority for EDS, I need to know "yesterday" >> how to define IPv6 addressing for EDS and EDS customers so that I can >> put address assignment and registration tools and procedures into place. >> >> Until I am able to assign IPv6 addresses, no router engineer or systems >> configurator can deploy IPv6 in any meaningful way. This is what we >> often call a "show stopper". > >Would the lack of commercial router products sort of get in the way, >too? > >Perry Not particularly. We need to spend much more planning time on the network addressing plan before any large deployment. By that time the lack of an IPv6 stack on Microsoft desktops and servers will be the show stopper. The router vendors seem to be on track for delivery "real soon now". JimC - James R. Cutler EDS Mail Stop 4165 800 Tower Drive, Troy, MI 48007-7012 Phone: 810-265-7514 FAX: 810-265-7514 EDS Internal Web: World Wide Web: ------------------------------------------------------------------------------ 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 Wed Jan 8 14:30:13 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11663; Wed, 8 Jan 97 14:30:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11657; Wed, 8 Jan 97 14:30:01 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA22734; Wed, 8 Jan 1997 14:21:37 -0800 Received: from ftp.com (ftp.com [128.127.2.122]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA09288 for ; Wed, 8 Jan 1997 14:21:30 -0800 Received: from ftp.com by ftp.com ; Wed, 8 Jan 1997 17:21:16 -0500 Received: from mailserv-2high.ftp.com by ftp.com ; Wed, 8 Jan 1997 17:21:16 -0500 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id RAA04148; Wed, 8 Jan 1997 17:21:18 -0500 Message-Id: <199701082221.RAA04148@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: jcutle01@iscg.eds.com Cc: ipng@sunroof.eng.sun.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 2756) Re: MOs' 8+8 Date: Wed, 08 Jan 1997 17:17:12 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >.. By that time >the lack of an IPv6 stack on Microsoft desktops and servers will be >the show stopper. #include FTP Software has some support for it. Send mail to JD Stanley (jstanley@ftp.com) for more info.. -- Frank ------------------------------------------------------------------------------ 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 Wed Jan 8 15:52:43 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11882; Wed, 8 Jan 97 15:52:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11876; Wed, 8 Jan 97 15:52:32 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA10603; Wed, 8 Jan 1997 15:44:05 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA05655 for ; Wed, 8 Jan 1997 15:44:05 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id SAA19985; Wed, 8 Jan 1997 18:38:37 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23123; Wed, 8 Jan 1997 18:38:36 -0500 Message-Id: <9701082338.AA23123@wasted.zk3.dec.com> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: bound@zk3.dec.com, brian@dxcoms.cern.ch, ipng@sunroof.eng.sun.com Subject: (IPng 2757) Re: MOs' 8+8 In-Reply-To: Your message of "Wed, 08 Jan 97 14:19:11 EST." <199701081919.OAA12593@pobox.engeast.BayNetworks.COM> Date: Wed, 08 Jan 97 18:38:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thanks Dimitry... I respect what you think a lot.. I think 8+8 can move fast to be mature... Now I need to put some effort into convincing others why... I am moving on that now. /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 Wed Jan 8 15:55:37 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11900; Wed, 8 Jan 97 15:55:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11894; Wed, 8 Jan 97 15:55:19 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA11239; Wed, 8 Jan 1997 15:46:55 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA06463 for ; Wed, 8 Jan 1997 15:46:53 -0800 Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.4/8.6.12) with SMTP id SAA26724; Wed, 8 Jan 1997 18:46:46 -0500 (EST) Message-Id: <199701082346.SAA26724@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: "James R. Cutler" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2758) Re: MOs' 8+8 In-Reply-To: Your message of "Wed, 08 Jan 1997 16:27:32 EST." Reply-To: perry@piermont.com Date: Wed, 08 Jan 1997 18:46:45 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "James R. Cutler" writes: > >Would the lack of commercial router products sort of get in the way, > >too? > > Not particularly. We need to spend much more planning time on the > network addressing plan before any large deployment. Isn't the v6 model that we are supposed to be ready to renumber in a flash? Perry ------------------------------------------------------------------------------ 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 Wed Jan 8 16:05:13 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12086; Wed, 8 Jan 97 16:05:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12080; Wed, 8 Jan 97 16:05:02 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA13571; Wed, 8 Jan 1997 15:56:37 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA09581 for ; Wed, 8 Jan 1997 15:56:35 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id SAA03712; Wed, 8 Jan 1997 18:54:04 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA10633; Wed, 8 Jan 1997 18:54:03 -0500 Message-Id: <9701082354.AA10633@wasted.zk3.dec.com> To: perry@piermont.com Cc: "James R. Cutler" , bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2759) Re: MOs' 8+8 In-Reply-To: Your message of "Wed, 08 Jan 97 15:43:32 EST." <199701082043.PAA26461@jekyll.piermont.com> Date: Wed, 08 Jan 97 18:54:03 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Commercial Routers... Just to note we now have the following Routers participating on the 6bone and at the UNH Interoperability Events (that means your testing more than just tunnels and base stack to do a tunnel). Bay Networks Cisco Digital Telebit (Formal Product) RIPv6ng working, MOSPF in progress (I hope to see by June is my hope) and awaiting on BGP vs IDRP discussions in process now. Anyone else working on a router or router/switch implementation and just has not made the 6bone or UNH lately? So early adopters would be able to deploy with AD kits I think right now if they had a real address or use RFC 1897 for testing. Also I know Sun and Digital support RIPng on their Host systems when acting as a router on an interface. Sun and Digital provide binary kits (host and routers) now. For PCs FTP Software ships a product right now. I think this can get one started for sure. /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 Wed Jan 8 17:09:23 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12161; Wed, 8 Jan 97 17:09:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12155; Wed, 8 Jan 97 17:09:11 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA27002; Wed, 8 Jan 1997 17:00:48 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA29487 for ; Wed, 8 Jan 1997 17:00:48 -0800 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 RAA09305; Wed, 8 Jan 1997 17:00:38 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199701082346.SAA26724@jekyll.piermont.com> References: Your message of "Wed, 08 Jan 1997 16:27:32 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jan 1997 17:00:39 -0800 To: perry@piermont.com From: Steve Deering Subject: (IPng 2760) Re: MOs' 8+8 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Perry, > Isn't the v6 model that we are supposed to be ready to renumber in a > flash? That's one of those slightly misleading statements, like "isn't the RSVP model that we are supposed to always get perfect quality of service?" It's considered very desirable to make renumbering as painless as possible, and the IPng WG has done a lot of work, and continues to work, on those parts of the renumbering problem that fall within its scope. But since no one has actually demonstrated that painless flash renumbering of user sites can be done in a way that would be acceptable to those users, it is premature to say it is "the v6 model". In other words, we're trying hard to support painless automatic renumbering, but if it turns out to be too difficult/expensive to implement or too unpalatable to the users, that would not necessarily invalidate IPv6; it would just mean the new IP wouldn't be quite as wonderful as one would wish. (For example, some folks seem to be willing to have TCP connections break across renumbering events, even though that may cause pain for some users, presumably because those folks have convinced themselves it is too hard or too expensive to do otherwise.) 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 Wed Jan 8 18:14:52 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12237; Wed, 8 Jan 97 18:14:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12231; Wed, 8 Jan 97 18:14:40 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA07791; Wed, 8 Jan 1997 18:06:17 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA16608 for ; Wed, 8 Jan 1997 18:06:16 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQbxrk11275; Wed, 8 Jan 1997 21:06:07 -0500 (EST) Message-Id: To: "Karen Tracey" Cc: ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 2761) Re: Thoughts on alternative addressing proposals In-Reply-To: Your message of "Wed, 08 Jan 1997 15:59:46 EST." <199701082100.NAA11199@mercury.Sun.COM> Date: Wed, 08 Jan 1997 21:06:06 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The fundamental point is: the current addressing models for IPv6 are not viable because the routing computations will not scale Therefore, why should anyone go to the trouble to deploy a new infrastructure with the knowledge that it does not address the most fundamental problem we face trying to grow the Global Internet? The large network operators are not simpletons, and it seems pretty clear that the current IPv6 addressing models simply give us a way to hit the wall going a lot faster. Doing a lot of extra work so we can hit the abutment at 200mph rather than dying from a mere 70mph impact doesn't seem like a particularly good use of resources. The routing computations do not scale for several reasons: (1) the current CIDR-style addressing models for "IPv6 classic" do not provide for sufficiently-aggressive address aggregation (2) multihoming dramatically reduces the effectiveness of (1) (3) multihoming as currently done is a "tragedy of the commons" where a facility used by only a few inflicts significant work upon the entire Global Internet without compensation (4) worse, the "few" doing multihoming is growing rapidly and will only accellerate (5) renumbering of interior topology for provider changes will become completely unacceptable in the markeplace. The number of customers who will refuse to do it and manage to enforce their will can only grow, and it doesn't take many to produce a "zipper" which will unravel the whole thing. Imagine what happens if, say, the government *mandates* "portable addresses". (5) the current proposals have extremely limited flexibility to explore other possible alternative solutions without producing serious deployment dislocations, assuming IPv6-classic were to actually get deployed in large infrastructures disconnecting the routing information from the identity is the only way to address these issues in the short term while also providing the extension mechanism which can allow for evolving the semantics and processing of Routing Goop. Why reopen this decision?? Because it's never to late to not make a mistake. -mo ------------------------------------------------------------------------------ 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 Wed Jan 8 18:39:20 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12278; Wed, 8 Jan 97 18:39:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12271; Wed, 8 Jan 97 18:39:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA11044; Wed, 8 Jan 1997 18:30:45 -0800 Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA21980 for ; Wed, 8 Jan 1997 18:30:44 -0800 Received: from big-dogs.cisco.com ([171.68.53.75]) by diablo.cisco.com (8.8.4/CISCO.SERVER.1.2) with SMTP id SAA21749; Wed, 8 Jan 1997 18:30:34 -0800 (PST) Message-Id: <3.0.32.19970108213032.006b0430@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 08 Jan 1997 21:30:36 -0500 To: "Mike O'Dell" From: Paul Ferguson Subject: (IPng 2762) Re: Thoughts on alternative addressing proposals Cc: "Karen Tracey" , ipng@sunroof.eng.sun.com, mo@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:06 PM 1/8/97 -0500, Mike O'Dell wrote: > Imagine what happens if, say, the government *mandates* > "portable addresses". > Hey, that's a good one. ;-) - paul ------------------------------------------------------------------------------ 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 Thu Jan 9 00:46:09 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12490; Thu, 9 Jan 97 00:46:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12484; Thu, 9 Jan 97 00:45:57 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA08011; Thu, 9 Jan 1997 00:37:33 -0800 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id AAA17257 for ; Thu, 9 Jan 1997 00:37:33 -0800 Received: from rama.imag.fr (rama.imag.fr [129.88.26.9]) by imag.imag.fr (8.8.1/8.6.9) with ESMTP id JAA21492 for ; Thu, 9 Jan 1997 09:37:31 +0100 (MET) Received: (from durand@localhost) by rama.imag.fr (8.8.0/8.8.Beta.3) id KAA03398 for ipng@sunroof.Eng.Sun.COM; Thu, 9 Jan 1997 10:38:22 +0100 (MET) From: "Alain Durand" Message-Id: <970109103821.ZM3309@rama.imag.fr> Date: Thu, 9 Jan 1997 10:38:21 +0100 X-Mailer: Z-Mail (4.0b.514 14may96) To: ipng@sunroof.eng.sun.com Subject: (IPng 2763) 8+8: user point of view Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have been seeing implementor, vendor, ISP & protocol designer points of view on 8+8, I'd like to give some thoughts with a user's prespective. There is one point I that is not very clear to me which is how to do routing inside a user domain with the 8+8 model. As destination addresses are left unchanged, they include the routing goop. The 2 bytes in the 8+8 models (6+2+8 or 8+2+6), as they are not unique, do not carry enough informations to make routing decisions _inside_ a site. So, from what I understand, either I need to configure all the routers of my site with my routing goop & private topology informations or I need to use LAN-switching technology to have only one flat network, which is, again from what I understand, the draft hinted solution. The first alternative will not solve the renumbering problem for a complex site topology as if the routing goop should change, I will have to reconfigure all the site routers. If to do that we need some extra protocols as the one presented by Bob Hinden at last IETF, why do we still need 8+8? The second one might be simply not acceptable for many large sites. Many sites I know have complex, segmented, topologies for many different reasons and requiring them to change that for a flat topology to have IPv6 will never work. Is there something I missed on this subject that will solve this issue? There is another point I'd like to outline. I have been reading many concerns about security and some people suggested that to have a minimum or resonable level of security, we need to _may_ need to use systematic authentication. I'm very concern about the performance impact of _mandating_ the use of AH. - Alain Durand. ------------------------------------------------------------------------------ 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 Thu Jan 9 01:46:00 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12535; Thu, 9 Jan 97 01:46:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12529; Thu, 9 Jan 97 01:45:44 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA11291; Thu, 9 Jan 1997 01:37:20 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA25854 for ; Thu, 9 Jan 1997 01:37:20 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id KAA16406 for ; Thu, 9 Jan 1997 10:37:19 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA28145; Thu, 9 Jan 1997 10:37:19 +0100 Message-Id: <9701090937.AA28145@dxcoms.cern.ch> Subject: (IPng 2764) Re: 8+8: user point of view To: ipng@sunroof.eng.sun.com Date: Thu, 9 Jan 1997 10:37:18 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <970109103821.ZM3309@rama.imag.fr> from "Alain Durand" at Jan 9, 97 10:38:21 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain, > The 2 bytes in the 8+8 models (6+2+8 or 8+2+6), as they are not unique, > do not carry enough informations to make routing decisions _inside_ a site. They are administered within the site, and as big as a class B. I don't see your issue at all. You could choose to use them as end-system addresses with a subnet model and OSPF-like routing, or to use them as subnet addresses, using ES-IS-like routing to reach the end-systems. Brian Carpenter ------------------------------------------------------------------------------ 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 Thu Jan 9 01:52:41 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12547; Thu, 9 Jan 97 01:52:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12541; Thu, 9 Jan 97 01:52:29 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA11686; Thu, 9 Jan 1997 01:44:05 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA26856 for ; Thu, 9 Jan 1997 01:44:06 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id KAA17214 for ; Thu, 9 Jan 1997 10:44:04 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA22964; Thu, 9 Jan 1997 10:44:04 +0100 Message-Id: <9701090944.AA22964@dxcoms.cern.ch> Subject: (IPng 2765) Re: MOs' 8+8 To: ipng@sunroof.eng.sun.com Date: Thu, 9 Jan 1997 10:44:04 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199701081919.OAA12593@pobox.engeast.BayNetworks.COM> from "Dimitry Haskin" at Jan 8, 97 02:19:11 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry, Jim, > > > Do you want to move forward with the present provider based addressing? > > > This is definitely sensible to do independently of the 8+8 efforts. > 8+8 is not enough understood and is too experimental at this point > to stall any provider based deployment. > That has the implication that provider-based and 8+8 need to be run-time compatible, unless you plan an upgrade from IPv6.1 to IPv6.2. That has some implications for implementors. Brian p.s. to be more precise: everything has to work when one end of a conversation has a provider-based address and the other end has an 8+8 address, and this is not known in advance of the DNS lookup. ------------------------------------------------------------------------------ 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 Thu Jan 9 04:24:19 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12641; Thu, 9 Jan 97 04:24:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12635; Thu, 9 Jan 97 04:24:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA19730; Thu, 9 Jan 1997 04:15:40 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA19587 for ; Thu, 9 Jan 1997 04:15:25 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id MAA15514; Thu, 9 Jan 1997 12:06:30 GMT Date: Thu, 9 Jan 1997 12:06:30 GMT Message-Id: <199701091206.MAA15514@oberon.di.fc.ul.pt> From: Pedro Roque To: "Mike O'Dell" Cc: "Karen Tracey" , ipng@sunroof.eng.sun.com Subject: (IPng 2766) Re: Thoughts on alternative addressing proposals In-Reply-To: References: <199701082100.NAA11199@mercury.Sun.COM> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Mike" == Mike O'Dell writes: Mike, Mike> The routing computations do not scale for several reasons: Mike> (1) the current CIDR-style addressing models for "IPv6 Mike> classic" do not provide for sufficiently-aggressive address Mike> aggregation Mike> (2) multihoming dramatically reduces the effectiveness Mike> of (1) Mike> (3) multihoming as currently done is a "tragedy of the Mike> commons" where a facility used by only a few inflicts Mike> significant work upon the entire Global Internet without Mike> compensation Mike> (4) worse, the "few" doing multihoming is growing Mike> rapidly and will only accellerate While the problem list seams consensual, the solution is not... Your proposal can be said to have two major points: 1) A different network architecture. 2) Periodic renumbering of the Internet. I've some points against it: a) Your architecture does not provide more support for 2) than the current IPv6 architecture, it only places a fixed boundary on the address. As you say, one can expect "some" resistance to such periodic renumbering. At least i don't see how it does... b) With your proposal there cannot be support for multihomed domains without all the traffic being authenticated. By moving the decision of source prefix to routers and hiding it from hosts, hosts have no way to detect whenever they need to generate special control traffic to change the address bindings. So, the only chance left open is to have "normal" traffic change the remote binding. This traffic must be authenticated. The same reasoning can be applied to mobility support. c) The constant ESD is useless, as defined. Without a current RG, and unless you have a directory service that allows lookups on those flat maybe-unique identifiers, you can't to mapping from ESD to host name or host credentials. For an host, changing the current RG on all comunication peers is a problem of the same level of change an whole 128 bit address. Mike> (5) renumbering of interior topology for provider Mike> changes will become completely unacceptable in the Mike> markeplace. With the current IPv6 you don't need to change the interior topology of a leaf site when you renumber. Of you are a traffic provider, you still need to renumber your clients with 8+8. Mike> The number of customers who will refuse to do Mike> it and manage to enforce their will can only grow, and it Mike> doesn't take many to produce a "zipper" which will unravel Mike> the whole thing. Imagine what happens if, say, the Mike> government *mandates* "portable addresses". Ho, we do have "portable addresses" already, DNS host names. They are the visible token to users... So if your government whishes to have the same "portability" than 800 numbers have in the US. You have already met that goal. Mike> (5) the current proposals have extremely limited Mike> flexibility to explore other possible alternative solutions Mike> without producing serious deployment dislocations, assuming Mike> IPv6-classic were to actually get deployed in large Mike> infrastructures I would say your architecture is even more limitative as it places part of the necessary information to keep comunications flowing in the routers and part in the hosts. Mike> disconnecting the routing information from the identity is Mike> the only way to address these issues The problem is that "identity" as a binary stream of bits is useless. An usefull identity is something like a credential or a FQDN. As you have to be able to map changing locators to identities it is not perfectly clear to me that introducing an indirection layer in the middle is really helpful. Mike> Because it's never to late to not make a mistake. I do feel confortable with an architecture in which the main limitations are already well understood, and several proposals do exist that try to solve the multihomed domain problems within this architecture. A new architecture represent a jump in the dark... 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 Thu Jan 9 05:17:19 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12690; Thu, 9 Jan 97 05:17:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12684; Thu, 9 Jan 97 05:17:07 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA23409; Thu, 9 Jan 1997 05:08:42 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA27466 for ; Thu, 9 Jan 1997 05:08:43 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQbxtc13653; Thu, 9 Jan 1997 08:08:32 -0500 (EST) Message-Id: To: "Alain Durand" Cc: ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 2767) Re: 8+8: user point of view In-Reply-To: Your message of "Thu, 09 Jan 1997 10:38:21 +0100." <970109103821.ZM3309@rama.imag.fr> Date: Thu, 09 Jan 1997 08:08:32 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk within a Site, you route on the Private Topology Partition. RG is not required to navigate within the bounds of a Site. whether or not you need to renumber inside a site depends upon how you structure your site and use the PTP to divide it up. note that I didn't ever say there won't be renumbering - what 8+8 does is remove the requirement for forced-renumber of entire sites when the external connection to the rest of the Global Internet changes. however, as for renumbering inside the site, that becomes a matter of local choice and local control. you could use VLAN technology, put everything in one PTP, and never renumber anything, ever. You could use the PTP to identify a large set of virtual lans, route between them, and still never "renumber" except in the case of a given machine being moved between VLAN segments (and then the IPv6 auto-assignment magic would do the job just fine for that machine). If you want, you can use the PTP to label physical LAN segments like we do with subnets today, route between them, and then when you move a machine, the IPv6 auto-assignment stuff would work again. if you restructure the interior topology, depending on what LAN technology is under it, the IPv6 auto-assignment/renumbering stuff will either solve it, or it won't matter. But if you want to change your connectivity to the Global Internet (eg, change or add service providers), you do NOT have to completely renumber the interior of your Site!! -mo ------------------------------------------------------------------------------ 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 Thu Jan 9 05:22:18 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12706; Thu, 9 Jan 97 05:22:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12700; Thu, 9 Jan 97 05:22:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA23715; Thu, 9 Jan 1997 05:13:41 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA28591 for ; Thu, 9 Jan 1997 05:13:43 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQbxtc14137; Thu, 9 Jan 1997 08:13:40 -0500 (EST) Message-Id: To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 2768) Re: 8+8: user point of view In-Reply-To: Your message of "Thu, 09 Jan 1997 10:37:18 +0100." <9701090937.AA28145@dxcoms.cern.ch> Date: Thu, 09 Jan 1997 08:13:40 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, the PTP is MUCH bigger than a class B. in a class B, you have to have room for the hosts, too. the PTP allows 32K LAN SEGMENTS, any one of which could (architecturally) exhaust the entire IEEE MAC address space. (of course, you wouldn't have anything to put on the other segments, but that's beside the point). actually, with a 15-bit PTP, a Site can have a routing complexity on par with the current Global Internet. (32K segments - 40K routes in the Global Internete). -mo ------------------------------------------------------------------------------ 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 Thu Jan 9 05:23:28 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12730; Thu, 9 Jan 97 05:23:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12724; Thu, 9 Jan 97 05:23:11 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA23789; Thu, 9 Jan 1997 05:14:45 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA28970 for ; Thu, 9 Jan 1997 05:14:47 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQbxtc14271; Thu, 9 Jan 1997 08:14:45 -0500 (EST) Message-Id: To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 2769) Re: MOs' 8+8 In-Reply-To: Your message of "Thu, 09 Jan 1997 10:44:04 +0100." <9701090944.AA22964@dxcoms.cern.ch> Date: Thu, 09 Jan 1997 08:14:44 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i have not addressed interoperability between "provider-based" addresses and 8+8 because the issue is pointless. -mo ------------------------------------------------------------------------------ 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 Thu Jan 9 05:49:20 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12800; Thu, 9 Jan 97 05:49:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12790; Thu, 9 Jan 97 05:49:07 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA25641; Thu, 9 Jan 1997 05:40:41 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA04507 for ; Thu, 9 Jan 1997 05:40:42 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id OAA20972 for ; Thu, 9 Jan 1997 14:40:36 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA12440; Thu, 9 Jan 1997 14:40:32 +0100 Message-Id: <9701091340.AA12440@dxcoms.cern.ch> Subject: (IPng 2770) Re: MOs' 8+8 To: ipng@sunroof.eng.sun.com Date: Thu, 9 Jan 1997 14:40:32 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: from "Mike O'Dell" at Jan 9, 97 08:14:44 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, > > i have not addressed interoperability between "provider-based" > addresses and 8+8 because the issue is pointless. > That depends on what scenarios you think are likely. If 8+8 is just an extra format prefix, you can't dismiss interoperability out of hand. (It may be a Bad Thing but it needs to be looked at.) If 8+8 is the only format, then it's a non-issue. Brian ------------------------------------------------------------------------------ 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 Thu Jan 9 06:28:35 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12863; Thu, 9 Jan 97 06:28:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12857; Thu, 9 Jan 97 06:28:23 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA29022; Thu, 9 Jan 1997 06:19:59 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA14087 for ; Thu, 9 Jan 1997 06:20:00 -0800 Received: by rodan.UU.NET id QQbxth26703; Thu, 9 Jan 1997 09:19:59 -0500 (EST) Date: Thu, 9 Jan 1997 09:19:59 -0500 (EST) From: mo@UU.NET (Mike O'Dell) Message-Id: To: ipng@sunroof.eng.sun.com Subject: (IPng 2771) 8+8 and other formats.... Cc: mo@UU.NET Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk so the transport protocols will decide how to do the pseudo header based on the address format????? that's pretty bizarre i don't see any particular interoperability issues with other IPv6 formats, other than the one above. Assuming all the routers understand all the formats and can figure out when to look at how much of the address to use for forwarding, then i don't see any particular problem, other than the basic problems already outlined with PBA (provider-based addressing). although convincing the router folks that is a good idea is going to be a *real* stretch and while we're on PBA, in reviewing the proposal, either nobody imagines there's very much multi-level wholesale business out there (which there is and will grow very considerably), or they expect only two tiers, thereby dramatically compouding the difficulty of effective aggregation. -mo ------------------------------------------------------------------------------ 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 Thu Jan 9 09:52:32 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13026; Thu, 9 Jan 97 09:52:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13020; Thu, 9 Jan 97 09:52:16 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA28326; Thu, 9 Jan 1997 09:43:50 -0800 Received: from cornpuffs.cisco.com (cornpuffs.cisco.com [171.69.1.219]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA22615 for ; Thu, 9 Jan 1997 09:43:37 -0800 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id JAA27382; Thu, 9 Jan 1997 09:43:25 -0800 Date: Thu, 9 Jan 1997 09:43:25 -0800 From: Ran Atkinson Message-Id: <199701091743.JAA27382@cornpuffs.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2772) Re: Thoughts on alternative addressing proposals In-Reply-To: <199701091206.MAA15514@oberon.di.fc.ul.pt> References: Organization: cisco Systems Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <199701091206.MAA15514@oberon.di.fc.ul.pt> Pedro wrote: >While the problem list seams consensual, the solution is not... >Your proposal can be said to have two major points: >1) A different network architecture. >2) Periodic renumbering of the Internet. > >I've some points against it: >a) Your architecture does not provide more support for 2) than the >current IPv6 architecture, it only places a fixed boundary on the address. >As you say, one can expect "some" resistance to such periodic renumbering. >At least i don't see how it does... I disagree with the above. The fixed boundary means that the edge router can modify the high-order portion in the Source Address of the Routing Goop to be appropriate for provider/home "B" if the original Source Address assumed the packet would go out via provider/home "A". This feature means the multi-homed/multi-provider connections work now and won't cause undue bloat in routing table size. This feature is critical to solving the multi-homed/multi-provider operational issue in a way acceptable to users. >b) With your proposal there cannot be support for multihomed domains >without all the traffic being authenticated. False. Authentication is not more necessary for 6+2+8 than it is in the current system. Nothing that Mike is changing fundamentally alters the security requirements of the system, AFAIK. >By moving the decision of source prefix to routers and hiding it from hosts, >hosts have no way to detect whenever they need to generate special control >traffic to change the address bindings. So, the only chance left open is to >have "normal" traffic change the remote binding. This traffic must be >authenticated. This reasoning is faulty. I'd urge a re-reading of Mike's draft. >The same reasoning can be applied to mobility support. and is equally faulty there. Ran rja@cisco.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 Thu Jan 9 10:14:29 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13062; Thu, 9 Jan 97 10:14:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13007; Thu, 9 Jan 97 09:43:15 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA26580; Thu, 9 Jan 1997 09:34:49 -0800 Received: from cornpuffs.cisco.com (cornpuffs.cisco.com [171.69.1.219]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA18284 for ; Thu, 9 Jan 1997 09:33:54 -0800 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id JAA27199; Thu, 9 Jan 1997 09:33:07 -0800 Date: Thu, 9 Jan 1997 09:33:07 -0800 Message-Id: <199701091733.JAA27199@cornpuffs.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2773) Re: MOs' 8+8 is evil, breaks firewalls. In-Reply-To: <9701080821.ZM20358@seawind.bellcore.com> References: From: Ran Atkinson Organization: The Internet Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have to disagree with those who consider the binding between the node identification and the node location desirable. The current reliance of such bindings is the cause of many security problems in operational networks. Many in the security community consider it strongly desirable to decouple node location information from node identification. One reason that I find 6+2+8 strongly desirable is the potential ability to bind IPsec SAs to the node identifier 64-bits _without_ binding it also to the subnet location 64-bits. A number of us in the IPsec community consider the identification 64-bit chunk of the 6+2+8 proposal to be sufficiently unique for IPsec SA purposes. That said, it isn't rocket science to create a new DNS record for naming (routing prefix + netmask) objects. If folks consider this an operational need, then those folks should write up an I-D and submit it to the community for consideration. Ran rja@inet.org ------------------------------------------------------------------------------ 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 Thu Jan 9 10:39:31 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13140; Thu, 9 Jan 97 10:39:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13134; Thu, 9 Jan 97 10:39:19 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA08555; Thu, 9 Jan 1997 10:30:53 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA11315 for ; Thu, 9 Jan 1997 10:30:51 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id TAA18718 for ; Thu, 9 Jan 1997 19:30:48 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA29590; Thu, 9 Jan 1997 19:30:43 +0100 Message-Id: <9701091830.AA29590@dxcoms.cern.ch> Subject: (IPng 2774) Re: MOs' 8+8 To: ipng@sunroof.eng.sun.com Date: Thu, 9 Jan 1997 19:30:43 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199701091745.JAA27441@cornpuffs.cisco.com> from "Ran Atkinson" at Jan 9, 97 09:45:47 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, > > If 6+2+8 is not the only format, then we've lost big time because many of the > features that make 6+2+8 work to solve major issues (e.g. multi-homing without > bloating routing tables) only work well if 6+2+8 is always in use. I concede that this is true. But that means we lose the flexibility offered by the format prefix in the existing address architecture (because even if we leave the format prefix in place, we can never actually use it.) Brian ------------------------------------------------------------------------------ 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 Thu Jan 9 10:57:01 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13164; Thu, 9 Jan 97 10:57:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13158; Thu, 9 Jan 97 10:56:49 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA12619; Thu, 9 Jan 1997 10:48:22 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA22113 for ; Thu, 9 Jan 1997 10:48:13 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id SAA16780; Thu, 9 Jan 1997 18:41:04 GMT Date: Thu, 9 Jan 1997 18:41:04 GMT Message-Id: <199701091841.SAA16780@oberon.di.fc.ul.pt> From: Pedro Roque To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2775) Re: Thoughts on alternative addressing proposals In-Reply-To: <199701091743.JAA27382@cornpuffs.cisco.com> References: <199701091206.MAA15514@oberon.di.fc.ul.pt> <199701091743.JAA27382@cornpuffs.cisco.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Ran" == Ran Atkinson writes: Ran> In article <199701091206.MAA15514@oberon.di.fc.ul.pt> Pedro Ran> wrote: >> While the problem list seams consensual, the solution is not... >> Your proposal can be said to have two major points: 1) A >> different network architecture. 2) Periodic renumbering of the >> Internet. >> >> I've some points against it: a) Your architecture does not >> provide more support for 2) than the current IPv6 architecture, >> it only places a fixed boundary on the address. As you say, >> one can expect "some" resistance to such periodic renumbering. >> At least i don't see how it does... Ran> I disagree with the above. The fixed boundary means that the Ran> edge router can modify the high-order portion in the Source Ran> Address of the Routing Goop to be appropriate for Ran> provider/home "B" if the original Source Address assumed the Ran> packet would go out via provider/home "A". Ran, The multi-homed domain case has at least two major problems (and we are discussing different ones, i think). a) reliability, being able to fall back the trafic to another provider when one fails. b) choosing the "best" source address. On reliability, users want their traffic to remain undisturbed on failure. To allow that, the communications that where using an address on the failing prefix(home) must change to use an address on a working prefix. This is the reasoning for the two points i make bellow, and that you quoted from my mail. If TCP/UDP resistance to failure is not a goal (and it is not in the current 8+8 draft), then, you can have the same support by announcing, inside your AS that a prefix as becomed deprecated when you detect a failure. b) can be achieved in other ways, for instance, allowing the hosts to query the routers for the "best" address for a destination and leting them store cache entries on the form "destination/prefix source_prefix_to_use". Ran> This feature means the multi-homed/multi-provider connections Ran> work now and won't cause undue bloat in routing table size. With the present 8+8 draft this is only true for people that don't care that their traffic stops because they happened to be using the addresses of a path that failed. Also, with the two suggestions i made above you get the same functionality the present draft gives you within the current architecture. >> b) With your proposal there cannot be support for multihomed >> domains without all the traffic being authenticated. Ran> False. Authentication is not more necessary for 6+2+8 than Ran> it is in the current system. If you mean that the current system needs authentication anyway then i cannot rebate you statement ;-) The rational for the my statement is the following: If you want to support reliability for multi-homed domains you have to mandate that a peer of a multi-homed system changes the address it uses for sending packets according to the source address it receives on packets. This does weaken the security of the system, IMHO. >> By moving the decision of source prefix to routers and hiding >> it from hosts, hosts have no way to detect whenever they need >> to generate special control traffic to change the address >> bindings. So, the only chance left open is to have "normal" >> traffic change the remote binding. This traffic must be >> authenticated. Ran> This reasoning is faulty. I'd urge a re-reading of Mike's Ran> draft. The point is that an host will never know what the router does to it's packets in terms of source address rewriting. 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 Thu Jan 9 12:16:50 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13279; Thu, 9 Jan 97 12:16:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13273; Thu, 9 Jan 97 12:16:38 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA00290; Thu, 9 Jan 1997 12:08:14 -0800 Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA21794 for ; Thu, 9 Jan 1997 12:08:13 -0800 Message-Id: <199701092008.MAA21794@mercury.Sun.COM> Received: from RALVM6 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2346; Thu, 09 Jan 97 15:07:56 EST Date: Thu, 9 Jan 97 15:07:48 EST From: "Karen Tracey" To: mo@UU.NET Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2776) Thoughts on alternative addressing proposals Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ref: Your note of Wed, 08 Jan 1997 21:06:06 -0500 > Why reopen this decision?? > > Because it's never to late to not make a mistake. OK, then, let us reopen discussion of this. What are the pros/cons of combined locator/identifier compared to non-combined locator/identifier? As I said, I wasn't here for the original discussion, but from what I can see... A pro of non-combined is the ability to change topology more easily than combined. (That seems pretty straightforward, although topology changes probably still require some work somewhere, depending on the exact scheme, and then the question arises: How "easy" do such changes have to be for IPv6 to be a reasonable "upgrade" from IPv4? That is, configuration changes must be limited to what scope, exactly?) A con of non-combined is that it is rather unfamiliar to anyone with mostly IPv4 experience. Are we sure that this benefit of easy topological change doesn't come with a price tag of some other breakage that we don't know how to fix? Some other way of hitting the wall at >70 mph? The unknown tends to be somewhat scary. (I think this con also applies to the current 8+8 proposal, which I consider a hybrid.) To me, the benefit of easy topological change sounds compelling, since I have heard many cite Route Scaling as the major inhibitor to continued Internet growth, without hearing anyone deny this, and the arguments make sense to me. If IPv6 is to succeed IPv4, then, it must solve this problem. And current proposals do not do so. But, overcoming the con is going to take significant work. And, given where the IPv6 specs are currently at, it has the potential for adding a significant delay to the prospect of any "real" IPv6 deployment, since such a fundamental change may require re-development of some component protocols. Not surprisingly, there is considerable resistance to that idea. IPv6 is close to the point where "real" deployment could begin. A fundamental change in addressing architecture would be a big setback. And so the current proposal attempts to allow this group to start walking two parallel paths. Those who believe in provider-based addressing can continue essentially unchanged. A couple of tweaks to how checksums are done for certain addresses, and that's it. (We think. I'm not sure all the various IPv6-related protocols have been given careful examination in light of 8+8 yet.) Meanwhile those who don't believe in provider-based addresses can start exploring this new option. I see the value of this approach. It gives us the option to explore the possibility of developing the protocols that will allow IPv6 to solve the major scaling problem faced by the Internet today, without derailing the years of work already invested in IPv6. But it also has a cost, in that it limits the options of 8+8 to only those things that do not break the existing provider-based scheme. In considering the proposal we must make sure that this cost doesn't prevent the scheme from really achieving its intent. I look forward to an updated draft, and more discussion. Karen Tracey ------------------------------------------------------------------------------ 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 Thu Jan 9 15:14:31 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13644; Thu, 9 Jan 97 15:14:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13638; Thu, 9 Jan 97 15:14:19 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA06273; Thu, 9 Jan 1997 15:05:53 -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 PAA20291 for ; Thu, 9 Jan 1997 15:05:55 -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 PAA26460; Thu, 9 Jan 1997 15:03:21 -0800 Message-Id: <3.0.32.19970109150253.0071d45c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 09 Jan 1997 15:03:01 -0800 To: bound@zk3.dec.com From: Bob Hinden Subject: (IPng 2777) Re: Interim IPng Working Group Meeting Cc: Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com, deering@parc.xerox.com, bound@zk3.dec.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >I would suggest that the entire two days be used for 8+8 and not even >attempt any other agenda items. This is just too critical to IPv6. That is our plan. >I also have a request of both you and Steve OK. At San Jose both of you >presented new ideas or adjustments to working ideas (like source address >selection) we are all working on and need to define in some cases. I >know both of you are really busy and Steve switched companies. I would >request that you both please select X amount of time as WG Chairs to be > .... While I for one don't want to have any strict rules which limit the presentation of new ideas, I agree that it is preferable to send them to the list prior to meetings. I am trying to spend more regular time on the working group. My personal situation should make this a bit easier this year. Regards, 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 Thu Jan 9 18:02:09 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13935; Thu, 9 Jan 97 18:02:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13929; Thu, 9 Jan 97 18:01:57 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA08586; Thu, 9 Jan 1997 17:53:32 -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 RAA08532 for ; Thu, 9 Jan 1997 17:53:20 -0800 Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA59144; Thu, 9 Jan 1997 20:53:08 -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 UAA33188; Thu, 9 Jan 1997 20:53:05 -0500 Received: from lig32-224-57-131.us.lig-dial.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA14866; Thu, 9 Jan 1997 20:53:25 -0500 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 UAA02137; Thu, 9 Jan 1997 20:48:11 -0500 Message-Id: <199701100148.UAA02137@hygro.raleigh.ibm.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2778) Re: MOs' 8+8 is evil, breaks firewalls. In-Reply-To: Your message of "Thu, 09 Jan 1997 09:33:07 PST." <199701091733.JAA27199@cornpuffs.cisco.com> Date: Thu, 09 Jan 1997 20:48:11 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, > I have to disagree with those who consider the binding between the node >identification and the node location desirable. I don't think that it a question of desirable or undesirable. There are a set of tradeoffs with either approach. The fact is that today, we have a pretty good understanding of the pros and cons of combining both functions into the address (and there are definitely drawbacks). I think we have a much sketchier understanding of the other approach. What existing systems have used this approach? How well do they scale? TANSTAAFL. Removing the locating function from an address doesn't magically solve any problem. It just shuffles problems around, so that they pop up again in a different form somewhere else. Sometimes the transformed problem is easier to solve in a different context, sometimes not. >The current reliance of such >bindings is the cause of many security problems in operational networks. I think you are being overly simplistic in assigning blame here. It seems to me that the security problems are actually caused by a node relying on something easily forgeable (e.g., source addresses) rather than shared keys. Decoupling the binding between node identification and location would not automatically change that, especially if it becomes *easier* to forge identities. In the present CIDR-ized system, it is (relatively) hard to forge an identity because return packets get routed (in most cases) to the actual node that owns that identity (which will often cause some action to take place, like having TCP send a RST). If one removes the locating function from an address leaving only the identity, it could well become *easier* to misroute a packet intended for "foo" back to an intruder. There would seem to be a great potential here for lessoning security. For example, assuming the 8+8 approach, suppose you receive a TCP SYN packet. How can you verify that the Routing Goop that comes with the source address of the packet will really route return packets back to the correct endpoint associated with the ESD portion of the address? Just believing that the supplied RG is correct is almost certainly a security hole (do you trust someone else's ISP or router to only put in the correct stuff?). As currently defined, there is no way (e.g., via the DNS) to map a flat ESD back into a meaningful quantity (e.g., DNS name, security info, certificate, etc.). Making such a mapping possible requires adding heirarchy bits to the ESD. How many? I'd guess 4 bytes worth. But now 16 bytes is probably not enough anymore for RG+heirarchy+ESD. And such addresses would contain heirarchy in two places, since the RG portion will almost certainly have heirarchy. The point I'm making is that removing location information from addresses doesn't automatically improve security. > Many in the security community consider it strongly desirable to decouple >node location information from node identification. One reason that I find >6+2+8 strongly desirable is the potential ability to bind IPsec SAs to the >node identifier 64-bits _without_ binding it also to the subnet location >64-bits. A number of us in the IPsec community consider the identification >64-bit chunk of the 6+2+8 proposal to be sufficiently unique for IPsec SA >purposes. And why can't that be done right now with IPSec? IPSec uses the [destination address, SPI] to identify SAs. Since SPIs are allocated by the _receiver_, a receiver could choose to insure that all SPIs are unique (at any one time) independent of which of the addresses a packet is actually sent to (i.e., for any of the machine's interface addresses). It is also the case that the receiver could choose to ignore looking at the source/destination address of the packet, doing its authentication/decryption based solely on keys. Ultimately, it is the strength of the shared keys that is significant, not the addresses in the packet that delivered the payload. 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 Thu Jan 9 20:32:46 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14048; Thu, 9 Jan 97 20:32:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14042; Thu, 9 Jan 97 20:32:34 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA24850; Thu, 9 Jan 1997 20:24:08 -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 UAA06252 for ; Thu, 9 Jan 1997 20:24:09 -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 UAA10146; Thu, 9 Jan 1997 20:23:34 -0800 Message-Id: <3.0.32.19970109201602.00728c64@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 09 Jan 1997 20:23:16 -0800 To: "Mike O'Dell" From: Bob Hinden Subject: (IPng 2779) Re: 8+8: user point of view Cc: "Alain Durand" , ipng@sunroof.eng.sun.com, mo@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, >within a Site, you route on the Private Topology Partition. >RG is not required to navigate within the bounds of a Site. > >whether or not you need to renumber inside a site depends upon >how you structure your site and use the PTP to divide it up. I think the issue Alain pointed out is that current routers (in sites and backbones) do longest match route lookups. They do not know how to not look at the RG (e.g., only look at the Private topology partition). So the only way to make this work is to populate the routing tables with all of the prefixes that are in use. This would make the 8+8 proposal a lot less attractive. Maybe the way around this is to have the border routers to the site always replace the routable RG with the default RG for the site for packets entering the site. The trick is to make sure that there are never any packets with destination addresses that do not have either a default RG or RG outside of the site. 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 Thu Jan 9 20:51:27 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14065; Thu, 9 Jan 97 20:51:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14059; Thu, 9 Jan 97 20:51:15 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA26416; Thu, 9 Jan 1997 20:42:49 -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 UAA09057 for ; Thu, 9 Jan 1997 20:42: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 UAA10826; Thu, 9 Jan 1997 20:42:48 -0800 Message-Id: <3.0.32.19970109203419.00712a50@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 09 Jan 1997 20:42:29 -0800 To: "Brian Carpenter CERN-CN" From: Bob Hinden Subject: (IPng 2780) Re: MOs' 8+8 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 Brain, >I concede that this is true. But that means we lose the >flexibility offered by the format prefix in the existing >address architecture (because even if we leave the format >prefix in place, we can never actually use it.) I may be missing something, but it would seem to me that there would not be any issue with multiple FP which all had the 8+8 properties. Further, if you assume that we start with the current provider based prefixes for the initial RG, I am not sure there would be a problem interoperating with 8+8 prefixes and non-8+8 prefixes. Sites which used 8+8 would get the benefits of 8+8 and sites which used static provider prefixes (non-8+8) would not (e.g., need to renumber to switch providers, no multihoming to multiple providers, etc.). 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 Fri Jan 10 00:37:26 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14372; Fri, 10 Jan 97 00:37:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14366; Fri, 10 Jan 97 00:37:12 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA14713; Fri, 10 Jan 1997 00:28:47 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA11860 for ; Fri, 10 Jan 1997 00:28:47 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id JAA07523 for ; Fri, 10 Jan 1997 09:28:46 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA27868; Fri, 10 Jan 1997 09:28:45 +0100 Message-Id: <9701100828.AA27868@dxcoms.cern.ch> Subject: (IPng 2781) Re: Thoughts on alternative addressing proposals To: ipng@sunroof.eng.sun.com Date: Fri, 10 Jan 1997 09:28:45 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199701091841.SAA16780@oberon.di.fc.ul.pt> from "Pedro Roque" at Jan 9, 97 06:41:04 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, > > The point is that an host will never know what the router does to it's packets > in terms of source address rewriting. > This is a feature, not a bug. You can argue that 8+8 with the RG being re-written is a working version of NAT. Brian ------------------------------------------------------------------------------ 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 Fri Jan 10 04:45:09 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14513; Fri, 10 Jan 97 04:45:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14507; Fri, 10 Jan 97 04:44:56 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA28502; Fri, 10 Jan 1997 04:36:30 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA18152 for ; Fri, 10 Jan 1997 04:36:31 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQbxws07639; Fri, 10 Jan 1997 07:36:03 -0500 (EST) Message-Id: To: Bob Hinden Cc: "Mike O'Dell" , "Alain Durand" , ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 2782) Re: 8+8: user point of view In-Reply-To: Your message of "Thu, 09 Jan 1997 20:23:16 PST." <3.0.32.19970109201602.00728c64@mailhost.ipsilon.com> Date: Fri, 10 Jan 1997 07:36:03 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ah, i understand the question now. sorry to be thick. the set of valid RG for a site has the same ordinality as the number of connections the Site has to the Global Internet, so that number isn't very large. populating the routers shouldn't actually be a problem, but it is not the preferred solution. the solution i had developed before (but left out of the draft, which will be fixed, thanks!), is alter the defintion of the "subnet mask" to require it to be one contiguous span of bits, but lift the requirement it is left-anchored. this would all the site routers to just look at the PTP ignoring the RG that got them inside the Site. this is simple to do and essentially accomplishes your suggested "cannonification of the RG" without modifying the packet. I really only want to rewrite on outgoing. the approach is that once you get inside the Site, PTP is all you need examine to navigate. -mo ------------------------------------------------------------------------------ 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 Fri Jan 10 06:58:56 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14566; Fri, 10 Jan 97 06:58:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14560; Fri, 10 Jan 97 06:58:44 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA08078; Fri, 10 Jan 1997 06:50:19 -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 GAA14604 for ; Fri, 10 Jan 1997 06:50:16 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA37248; Fri, 10 Jan 1997 09:48:51 -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 JAA31624 for ; Fri, 10 Jan 1997 09:48:49 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16052; Fri, 10 Jan 1997 09:49:10 -0500 Message-Id: <9701101449.AA16052@ludwigia.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2783) Re: W.G. Last Call on "Header Compression for IPv6" In-Reply-To: Your message of "Tue, 10 Dec 1996 22:17:56 PST." <3.0.32.19961210180037.006cc4ec@mailhost.ipsilon.com> Date: Fri, 10 Jan 1997 09:49:10 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've got few questions/comments on this draft. First though, I must say that I like it. There is some pretty nifty stuff here! > Title : Header Compression for IPv6 Is it the intention that the draft only apply to IPv6? I thought the intention was to support both v4 and v6 (wasn't this stated in San Jose?). If so, the title should be changed. Also, there are numerous places in the draft where IPv6 is mentioned explicitely, while IPv4 is not mentioned at all. That is, it definitely reads like it is oriented towards v6. > Full header (header refresh) > > An uncompressed header that updates or refreshes the > compression state for a packet stream. It carries a CID that > will be used to identify the compression state. Any chance on changing the name "full header" to something else? The term doesn't (to me) clearly distinguish that this is a special packet (i.e., contains compression information) as opposed to a normal (non-compressed) packet that is unmodified (i.e., that contains "full headers"). How about something like "Sync Header" (since the packet contains info that synchronizes the receiver's state with that of the sender). Or perhaps SCS Header (for sync compression state)? Or ....??? > TCP's repair mechanisms will eventually retransmit the discarded > segment and the compressor peeks into the TCP headers to detect when > TCP retransmits. When this happens, the compressor sends a full > header on the assumption that the retransmission was due to > mismatching compression state at the decompressor. [RFC-1144] has a > good explanation of this mechanism. I got the impression elsewhere that whenever a full header is sent, "slow start" is also initiated. How about adding a sentence above making that clear. > 3.3. Lost packets in UDP and other non-TCP packet streams > > Incorrectly decompressed headers of UDP packets and other non-TCP > packets are not so well-protected by checksums as TCP packets because > differential coding is not used and there are no sequence numbers. > The UDP checksum only covers payload, UDP header, and pseudo header. > The pseudo header includes the source and destination addresses, the > transport protocol type and the length of the transport packet. > Except for those fields, large parts of the IPv6 header are not > covered by the UDP checksum. Moreover, other non-TCP headers lack > checksums altogether, for example fragments. I had trouble understanding the above at first, especially the first sentence. I take it that what you mean to say is that if the decompressor computes the checksum (to try to verify that the packet decompressed correctly), UDP isn't as well protected. That is, this is not an end-to-end issue, but an issue for the decompressor. Right? How about clarifying that a bit. Also, I'm not 100% clear on what the benefits of the generation number are. It seems to me, it is really just a way extending the CID value. That is, compression state is located via [CID, generation ID]. Whenever the compression state changes, a new generation number is sent. Why not just make the CID space larger, and do away with the generation ID? What would this change? It is the case that compression slow-start is invoked whenever either the CID or generation number change. Correct? > Defining fields > > All fields in subheaders that are marked with DEF in section 7 You have a forward reference to DEF. How about adding a sentence (or a parenthetical remark) stating the DEF fields are those that are used to classify packets into an their appropriate CID. > should be present and identical in all packets belonging to the > same packet stream. The DEF marked fields include the flow ^^^^^^^^^^ > label, source and destination addresses of IP headers, final > destination address in routing headers, the next header field > preceding a UDP or TCP header, port numbers, and the SPI in > authentication and encryption headers. How about changing the above to "Examples of fields that would typically be marked DEF include ..." > No field after a Fragment Header or an IPv4 header for a > fragment should be used for grouping purposes. The above implies this can't be used to compress IPv4/TCP headers, since one can't look at the TCP header of an IPv4 packet... > Priority field > > It is concievable that the Priority field of the IPv6 header > can change between packets with identical DEF fields when the > Flow Label is zero. A sophisticated implementation can watch ^^^^ > out for this and be prepared to use the Priority field as a DEF > field. The above implies that one wouldn't want to look at the Priority Field if the Flow Label is non-zero. Why is that? > The configurable parameter MAX_HEADER (see section 14) represents the > maximum size of the compression state, expressed as the maximum sized > header that can be stored as compression state. When an IPv6 header > is larger than MAX_HEADER, only part of it is stored as compression > state. An implementation must not compress more than the initial > MAX_HEADER octets of a header. An implementation must not partially > compress a subheader. Thus, the part of the header that is stored as > compression state and is compressed is the longest initial sequence > of entire subheaders that is not larger than MAX_HEADER octets. One thing that seems to be missing is a way for the compressor and decompressor to negotiate with each other about configurable parameters. I realize that this can't be done on one-way links, but those links are the exception. I think it would be a mistake to require manual configuration of both ends of a link to insure that they agree on the various configuration parameters. I fear that it will lead to interoperability problems in practice. How about defining a way to negotiate parameters at startup, with the caveat that it only works on duplex links. > The generation requires one octet and the CID may require up to 2 > octets. Length fields of 2 octets occur in the IPv6 Base Header, the > IPv4 header, and the UDP header. How about changing "occur in the IPv6 Base Header..." to "are carried in the IPv6 Base Header ..., since the length fields can be computed from implied information." (or something like that). > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Second length field | MSB of pkt nr | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > See section 11 for a description of how the pkt nr field is used. I assume the "pkt nr" is the sequence number described in 11.2? The term "pkt nr" is not used there at all. It would be helpful if the same terms were used in Section 11 as are used here. > The first bit inthe first length field indicates the length of the ^^^^^ > 6. Compressed Header Formats This may seem like an obvious question, but what is the wire format of compressed packets that have multiple headers? The document only talks about how to compress the individual headers. An example showing multiple headers would be helpful I think. Are they simply concatenated? 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 Fri Jan 10 07:48:05 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14593; Fri, 10 Jan 97 07:48:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14587; Fri, 10 Jan 97 07:47:53 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA15283; Fri, 10 Jan 1997 07:39:28 -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 HAA00976 for ; Fri, 10 Jan 1997 07:39:27 -0800 Received: from metro.isi.edu by metro.isi.edu (5.65c/5.61+local-23) id ; Fri, 10 Jan 1997 10:39:02 -0500 Message-Id: <199701101539.AA07043@metro.isi.edu> To: "Mike O'Dell" Cc: Bob Hinden , "Alain Durand" , ipng@sunroof.eng.sun.com Subject: (IPng 2784) Re: 8+8: user point of view In-Reply-To: Your message of "Fri, 10 Jan 1997 07:36:03 EST." X-Phone: +1 703 812 3704 Date: Fri, 10 Jan 1997 10:39:02 EST From: "John W. Stewart III" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk mike, in san jose you mentioned the ability to generalize a transit network to a Site (an idea which wasn't in your draft at the time). does this generalization have any implications on this specific issue (routing packets within a domain, some of which originated in that domain [and therefore have a RG of ?all zeros?] and others which originated outside that domain [and therefore have a "valid" RG])? or does it have any implication on the general issue of having Site border routers rewrite the RG of source addresses when leaving the Site? any estimate on when a new draft will be available? thanks, /jws > > ah, i understand the question now. sorry to be thick. > > the set of valid RG for a site has the same ordinality as the > number of connections the Site has to the Global Internet, > so that number isn't very large. populating the routers shouldn't > actually be a problem, but it is not the preferred solution. > > > the solution i had developed before (but left out of the draft, > which will be fixed, thanks!), is alter the defintion of the > "subnet mask" to require it to be one contiguous span of bits, > but lift the requirement it is left-anchored. this would all > the site routers to just look at the PTP ignoring the RG that > got them inside the Site. this is simple to do and essentially > accomplishes your suggested "cannonification of the RG" without > modifying the packet. I really only want to rewrite on outgoing. > the approach is that once you get inside the Site, PTP is all you > need examine to navigate. > > -mo > ---------------------------------------------------------------------------- -- > 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 ------------------------------------------------------------------------------ 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 Fri Jan 10 07:58:55 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14612; Fri, 10 Jan 97 07:58:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14606; Fri, 10 Jan 97 07:58:44 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA16903; Fri, 10 Jan 1997 07:50:19 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA04590 for ; Fri, 10 Jan 1997 07:50:18 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA11966; Fri, 10 Jan 1997 10:38:57 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA25977; Fri, 10 Jan 1997 10:38:57 -0500 Message-Id: <9701101538.AA25977@wasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Silubject: Re: (IPng 2765) Re: MOs' 8+8 In-Reply-To: Your message of "Thu, 09 Jan 97 10:44:04 +0100." <9701090944.AA22964@dxcoms.cern.ch> Date: Fri, 10 Jan 97 10:38:57 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> >> > Do you want to move forward with the present provider based addressing? >> > >> This is definitely sensible to do independently of the 8+8 efforts. >> 8+8 is not enough understood and is too experimental at this point >> to stall any provider based deployment. >> >That has the implication that provider-based and 8+8 need to >be run-time compatible, unless you plan an upgrade from >IPv6.1 to IPv6.2. That has some implications for implementors. >p.s. to be more precise: everything has to work when one end >of a conversation has a provider-based address and the other end >has an 8+8 address, and this is not known in advance of the >DNS lookup. I am about to send out in the next few days for discussions and corrections each one will be its own mail thread: 1. Why do we care about this is the model changing? 2. Why ESDS are not Globally Unique. 3. What can break on the network because of the transit model of the Routing Goop. 4. What can break in the existing specs with this model. 5. What are the implementation ramifications. 6. 8+8 and Provider Based Integration will it work. 7. IPv6 Renumbering Myth and Reality. I think we need some order to this discussion or we are just going to ramble on as we did for too long with ND and router redirects 2 years ago. /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 Fri Jan 10 09:23:49 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14783; Fri, 10 Jan 97 09:23:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14777; Fri, 10 Jan 97 09:23:36 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA02936; Fri, 10 Jan 1997 09:15:06 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA06725 for ; Fri, 10 Jan 1997 09:15:06 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA19654; Fri, 10 Jan 1997 12:08:02 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14949; Fri, 10 Jan 1997 12:08:00 -0500 Message-Id: <9701101708.AA14949@wasted.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2785) Re: Interim IPng Working Group Meeting In-Reply-To: Your message of "Thu, 09 Jan 97 15:03:01 PST." <3.0.32.19970109150253.0071d45c@mailhost.ipsilon.com> Date: Fri, 10 Jan 97 12:07:59 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, Thanks... Any idea on location yet? Bay area is broad? I am thinking about getting in hotel near Connectathon but that is San Francisco proper? Not could if we are in Mountainview as one example? 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 Fri Jan 10 09:49:21 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14823; Fri, 10 Jan 97 09:49:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13959; Thu, 9 Jan 97 18:41:47 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA13120; Thu, 9 Jan 1997 18:33:21 -0800 Received: from ha1.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA17178 for ; Thu, 9 Jan 1997 18:33:22 -0800 Received: from c8-a.snvl1.sfba.home.com ([24.1.16.12]) by ha1.rdc1.sfba.home.com (Netscape Mail Server v2.0) with SMTP id AAA28471; Thu, 9 Jan 1997 18:33:22 -0700 Date: Fri, 10 Jan 97 02:22:27 GMT Standard Time From: Ran Atkinson Subject: (IPng 2786) Re: MOs' 8+8 is evil, breaks firewalls. To: ipng@sunroof.eng.sun.com, Thomas Narten X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199701100148.UAA02137@hygro.raleigh.ibm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Many in the security community consider it strongly desirable to decouple >node location information from node identification. One reason that I find >6+2+8 strongly desirable is the potential ability to bind IPsec SAs to the >node identifier 64-bits _without_ binding it also to the subnet location >64-bits. A number of us in the IPsec community consider the identification >64-bit chunk of the 6+2+8 proposal to be sufficiently unique for IPsec SA >purposes. --- On Thu, 09 Jan 1997 20:48:11 -0500 Thomas Narten wrote: And why can't that be done right now with IPSec? IPSec uses the [destination address, SPI] to identify SAs. Since SPIs are allocated by the _receiver_, a receiver could choose to insure that all SPIs are unique (at any one time) independent of which of the addresses a packet is actually sent to (i.e., for any of the machine's interface addresses). It is also the case that the receiver could choose to ignore looking at the source/destination address of the packet, doing its authentication/decryption based solely on keys. Ultimately, it is the strength of the shared keys that is significant, not the addresses in the packet that delivered the payload. ---------------End of Original Message----------------- Tom, I don't think you fully understand how IPsec, in particular the integral component of key management, works. An IPsec SA contains two endpoint _identities_, among other things. At present, the ISAKMP/Oakley specs and PF_KEYv2 support identities of the following flavours: Fully Qualified Domain Name User + FQDN IP Address IP Address +ULP + Port Each end of an IPsec session has its own identity. It would be strongly desirable to replace IP address (which is explicitly part of 2 identity types and implicitly part of the other two identity types) with an identifier that did not relate to addresses or routing for the purposes of IPsec identities. I'm not the only person who has noted this. Its been noted several times (before my note) by others on this list and its also been noted repeatedly on the IPsec list. SPIs are _irrelevant_ to this dicussion because they are just a demux byte, nothing more than that. Naming (in the security context) is a MUCH harder problem that most folks on the IPng list seem to understand. I have a good handle on how hard it is and the issues surrounding it, but I don't claim to have a magic bullet. However, its clear that decoupling identity information from location information makes the security naming problem substantially more tractable. Your claim that such a decoupling has adverse side effects would be stronger and clearer if you enumerated the adverse side effects that you perceive. Ran rja@inet.org ------------------------------------------------------------------------------ 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 Fri Jan 10 10:18:26 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14938; Fri, 10 Jan 97 10:18:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14932; Fri, 10 Jan 97 10:18:10 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA15903; Fri, 10 Jan 1997 10:09:42 -0800 Received: from cornpuffs.cisco.com (cornpuffs.cisco.com [171.69.1.219]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA27377 for ; Fri, 10 Jan 1997 10:09:42 -0800 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id KAA27718; Fri, 10 Jan 1997 10:09:37 -0800 Date: Fri, 10 Jan 1997 10:09:37 -0800 From: Ran Atkinson Message-Id: <199701101809.KAA27718@cornpuffs.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2787) Re: MOs' 8+8 In-Reply-To: <3.0.32.19970109203419.00712a50@mailhost.ipsilon.com> Organization: cisco Systems Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As a reminder and for the benefit of those not present at the San Jose meeting... There are very significant real-world performance advantages to using an address architecture where only the high-order 64 bits need to be examined by routers. If one were to define _all_ IPv6 addresses such that the high-order 64 bits uniquely identified a subnet, there are a number of advantages. If only some IPv6 addresses had that property, most of the potential gain vanishes. For example, IPv6 routing tables could be very substantially smaller (which is particularly important given that routing table size explosion is a more immediately pressing problem than total address space; this also makes ISPs more likely to enable IPv6 natively in their backbones. Also, inexpensive off-the-shelf 64-bit CPUs (Alpha, UltraSPARC, MIPS) could manipulate the routing portion of an IPv6 address using register operations (as different from the current case where the need to process more than 64 bits causes a significant increase in the machine instructions in the forwarding path). Note that no off-the-shelf CPU vendor has announced plans to build anything bigger than a 64-bit CPU anytime soon and that custom hardware (e.g. SSE) is substantially more expensive than off-the-shelf CPUs (both to the router vendor and ultimately to the customer). Note that these performance advantages also are available to host vendors with 64-bit CPUs. Mike's original proposal could have been characterised as 8+2+6 (exterior routing/interior routing/interface ID). My proposal at San Jose was to guarantee that the interface ID is always 8 bytes (for the reasons above). My slight revision of Mike's proposal is 6+2+8 (exterior/interior/interface ID), though the part that is important to me personally is that the low order 64 bits are Interface ID and are not used in routing. Regards, Ran rja@cisco.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 Fri Jan 10 10:34:51 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14967; Fri, 10 Jan 97 10:34:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14961; Fri, 10 Jan 97 10:34:40 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA20168; Fri, 10 Jan 1997 10:26:11 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA03689 for ; Fri, 10 Jan 1997 10:26:11 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA17860; Fri, 10 Jan 1997 13:17:12 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28169; Fri, 10 Jan 1997 13:17:12 -0500 Message-Id: <9701101817.AA28169@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2788) 8+8 Why do we care? Date: Fri, 10 Jan 97 13:17:11 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Why do we want to even think about putting time into 8+8? I pose no answers in this message just questions for discussion. 1. Mike O'dell put out a draft and we are reviewing it as all work in the IETF? 2. The draft assists with Dynamic Renumbering of a site: a) by supporting a site not using the RG which means packets may be altered in transit? b) simply because the addressing structure is more organized even if the packets are not altered in transit? 3. Because the separation of locator and identifier assists with renumbering, security identifiers, and Provider Based Addressing does not? 4. 8+8 solves the Multihoming problem, Provider Based Addressing does not? 5. 8+8 permits self-organizing address space except for FP and ESD modes? LSID: Who assigns it? How do you get one? How do we make sure they are not duplicated? 6. Provider Based Addressing RFC 2073: Why not just use this? Whats wrong with it? [Note I consider saying it will just make us hit the wall faster with IPv6 "hand-waving" what are the "technical" and "adminitrative failures in RFC 2073]????? Who assigns the Internet Registry? How are provider n-bits defined and why who? Does 8+8 alleviate this? 7. Is 8+8 useful if we do not permit packets to be altered in transit? 8. Do we have any implementation experience with in transit packets being altered as it severly breaks the IPv4 model? 9. We have momentum now with IPv6 and the market wants it and needs IPv6 deployed to what extent should 8+8 be permitted to hold up deployement of 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 Fri Jan 10 10:50:49 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14996; Fri, 10 Jan 97 10:50:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14990; Fri, 10 Jan 97 10:50:38 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA24240; Fri, 10 Jan 1997 10:42:11 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA14351 for ; Fri, 10 Jan 1997 10:42:00 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA23776; Fri, 10 Jan 1997 13:34:01 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28183; Fri, 10 Jan 1997 13:33:56 -0500 Message-Id: <9701101833.AA28183@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2789) 8+8 Why ESDS are not globally Unique Date: Fri, 10 Jan 97 13:33:56 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We cannot gurantee 100% that ESDS low order 6bytes are globally unique and this has several ramifications. 1. Based on IPng WG past discussions: None of the 802.2 stds (e.g. Ethernet, Token Ring, FDDI....) can be assured that they are globally unique on a link and we require duplicate address detection on the link for all addresses presently. Even in DHCPv6 we don't even trust they are globally unique in a site without some other parameter in the server database. So why do we think they can be globally unique with the worldwide Internet? This greatly affects having RG not attached to Apps or Kernel PCBs as two examples. Do we want to change our view of 802.2 or invent an algorithm to make the 6bytes unique which no one has been able to do. I think to say they are mostly unique is completely bogus to trust on the Internet. 2. The PT of the EDS 8bytes can only be guranteed to be unique at the site level. It does not help at all with the ESD being globally unique. 3. If they are not completely unique then: a) A DNS look up on AAAA or PTR record cannot be known who it really is and even with a meta query for RG I would not know who was what RG? b) An implementations Internet PCBs if only looking at ESDS would not be able to differentiate incoming connections that were site based or from the INternet. In addition I would not be able to differentiate one connection from another. 4. It affects what an application uses to fill in the API structures to send a message when its a reverse lookup (e.g. gethostbyaddr). I could get back multiple names for the same ESD and not be able to tell which are in my site and which are not. I could parse the FQDN but I think that is bogus and extra work existing applications will not want to change when converting to just use 128bit addresses. 0::abcdef node1@mysite.nbr.org or 0::abcdef node2@outofmysite.nbr.org This really alters the present paradigm of today as a note. Others ..... comments....etc... /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 Fri Jan 10 11:10:02 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15031; Fri, 10 Jan 97 11:10:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15025; Fri, 10 Jan 97 11:09:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA29143; Fri, 10 Jan 1997 11:01:24 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA22303 for ; Fri, 10 Jan 1997 11:01:23 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA20363; Fri, 10 Jan 1997 13:50:55 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28997; Fri, 10 Jan 1997 13:50:55 -0500 Message-Id: <9701101850.AA28997@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2790) 8+8 What it breaks for IPv6 now Date: Fri, 10 Jan 97 13:50:55 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Why is this important? 1. Lots of thought went into IPv6 not just to make sure that it solves the criteria in RFC 1752 but that it was as close to IPv4 as possible to ease the transition to the next IPng. 2. We have a time-to-market pressure on the Internet. Many feel IPv4 address space has hit the wall on their Intranets and for start up ISPs on the Internet. If 8+8 holds up IPv6 from being deployed by even 1 year we need to ask why and if it can be made to be done faster than RFC 2073 took to get done. 8+8 with packets being altered in transit: All of these affect whether EDS is globally unique on another mail thread. 1. It affects the API for IPv6 and IPv4 for transition because only 64bits are considered for the application. The globally unique ESD question must be answered. But if it is the paradigm changes. The present IPv6 paradigm works well with the transition mechanisms defined and critical to the deployment of IPv6. Much of that is our use of the API. 2. We need to ask what this does to the Flow Label which many of us want for end-to-end flows. Can I be assured the flow label and a source address that I only have 8bytes listed can provide me an end-to-end flow label. 3. All implementations on hosts would need to consider only the low order 8bytes for NUD, Routing Table Look ups, Security Identfiers. What prefixes are used and how from ND RA, NA, and NS messages. 4. What prevents impersonation to a host from outside the site if an ESD is learned? 5. What happens in the routing path if the routing goop is lost for some reason? How is a message returned to the originating host? 6. How is DNS structured? 8+8 with packets NOT being altered in transit: 1. It can be used without alterations to specs or implementations other than to treat the RG as dynamic within the site for renumbering. 2. Justfication for us to use it is based on if it is a better addressing model than Provider based addressing. 3. We stay in the scope of the present architecture and we have some implementation experience. 4. I can't see it interfering with deployment if we do it fast. 5. We don't have to assume EDSs are globally unique. comments, additions for discusions....etc.... /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 Fri Jan 10 11:12:33 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15043; Fri, 10 Jan 97 11:12:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15037; Fri, 10 Jan 97 11:12:21 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA29738; Fri, 10 Jan 1997 11:03:53 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA23239 for ; Fri, 10 Jan 1997 11:03:51 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA30998; Fri, 10 Jan 1997 13:59:29 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA25510; Fri, 10 Jan 1997 13:59:32 -0500 Message-Id: <9701101859.AA25510@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2791) 8+8 What specs need looking into and technology Date: Fri, 10 Jan 97 13:59:31 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Probably need folks to sign up for each spec and report back to the group? I will take on the API and Addr Conf Specs and devote some time? If others will commit I will make a list? Should look at it two ways: with alterations during transit and without (tracy's hybrid scenario). Base spec and entire addressing model. Fragmentation and Reassembly Path MTU Discovery Security APIs Addr Conf (stateless and dhcpv6) ND and NUD Conceptual Model Flow Labels (probably see what it does to RSVP too) Transition ICMPv6 Routing Protocols (RIPng, OSPFv3, and BGP/IDRP???) Transition Mechanisms Affect to Multicast DNS Record Types and RG+ESD query type (some API part) IPv6 Tunnel Spec Anycast Addresses Mobility others..... /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 Fri Jan 10 11:20:30 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15065; Fri, 10 Jan 97 11:20:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15059; Fri, 10 Jan 97 11:20:14 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA01717; Fri, 10 Jan 1997 11:11:48 -0800 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA26408 for ; Fri, 10 Jan 1997 11:11:46 -0800 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id OAA15852 for ; Fri, 10 Jan 1997 14:11:43 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma015667; Fri Jan 10 14:11:09 1997 Received: from mako.us.newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id OAA01850 for ; Fri, 10 Jan 1997 14:11:04 -0500 Received: from lobster.nni by mako.us.newbridge.com (4.1/SMI-4.1) id AA14066; Fri, 10 Jan 97 14:08:52 EST Received: by lobster.nni (5.0/SMI-SVR4) id AA00370; Fri, 10 Jan 1997 14:08:46 +0500 Date: Fri, 10 Jan 1997 14:08:46 +0500 From: jhalpern@us.newbridge.com (Joel Halpern) Message-Id: <9701101908.AA00370@lobster.nni> To: ipng@sunroof.eng.sun.com Subject: (IPng 2792) Re: 8+8 Why ESDS are not globally Unique X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like to try to separate two aspects of the effect of non-unique ESDs. In doing so, I will take as a working assumption that the individual collision probability is very low, but not zero. On the one hand there is the reverse lookup issue. If ESDs are not globally unique, then you can not get a unique reverse lookup. Most of the time, you will get only one answer. Sometimes you won't. So, why are you doing the lookup? If for logging, just log all the possibilites. If for very crude source checking, just figure out which one has a listed Routing Goop (in the DNS, going forward) which matches what you found. In general, I would like to know more about what people want from this capability before rejecting the use of lower 8 "uniqueness". The second issue is that of ongoing communication. If you are communicating with a party, and someone else with the same ESD tries to talk to you, there is a problem. There are several relevant observations: 1) Not only must there be a collision, but you as a third party must be communicating with both colliding entities at the same time. Given that your simultaneous communication set is probably smaller than 2^16, the probability of trouble goes down significantly. 2) The most likely result is that you will simply reject the new packet as being out of proper state (syn while in established, wrong sequence, ...). If so, even if you are learning routing goop from all packets (a suspect operation) you can easily ignore this routing goop, and therefore have no problem. Thus, it seems to me that it in the normal, non-authenticated, cases the mild non-uniqueness of the ESD would not cause any difficulty. There is an additional issue: Authentication. Let us assume that authentication and security associations are tied to ESDs. Then the non-uniqueness of the ESD could cause a problem. This is potentially more serious. However, if the security/key management system can detect the collision if it falls into an overlapping domain of use, then it will be possible to deal with it. Otherwise there is a problem that we will have to deal with. I would like to sweep this all under the rug by claiming that the 8 byte ESD will be globally unique, but as observed several times during the IPv6 debates, that is not a reasonable conclusion. The question then is whether the IDs are sufficiently unique so as to be useable. I think so. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jan 10 11:21:16 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15072; Fri, 10 Jan 97 11:21:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15066; Fri, 10 Jan 97 11:20:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA01840; Fri, 10 Jan 1997 11:12:24 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA26639 for ; Fri, 10 Jan 1997 11:12:19 -0800 Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.4/8.6.12) with SMTP id OAA03790; Fri, 10 Jan 1997 14:11:56 -0500 (EST) Message-Id: <199701101911.OAA03790@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2793) Re: MOs' 8+8 In-Reply-To: Your message of "Fri, 10 Jan 1997 10:09:37 PST." <199701101809.KAA27718@cornpuffs.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 10 Jan 1997 14:11:55 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran Atkinson writes: > There are very significant real-world performance advantages to using > an address architecture where only the high-order 64 bits need to be examined > by routers. [...] > Mike's original proposal could have been characterised as 8+2+6 > (exterior routing/interior routing/interface ID). My proposal at San > Jose was to guarantee that the interface ID is always 8 bytes (for the > reasons above). My slight revision of Mike's proposal is 6+2+8 > (exterior/interior/interface ID), though the part that is important to > me personally is that the low order 64 bits are Interface ID and are > not used in routing. I'll point out, Ran, that most of the crunchiest routers on earth could make their decisions based on the first 64 bits even in 8+2+6, since they could readily ascertain that no more bits need be examined. Perry ------------------------------------------------------------------------------ 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 Fri Jan 10 11:31:24 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15095; Fri, 10 Jan 97 11:31:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15089; Fri, 10 Jan 97 11:31:09 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA04192; Fri, 10 Jan 1997 11:22:43 -0800 Received: from cornpuffs.cisco.com (cornpuffs.cisco.com [171.69.1.219]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA00492 for ; Fri, 10 Jan 1997 11:22:43 -0800 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id LAA29831; Fri, 10 Jan 1997 11:22:39 -0800 Message-Id: <199701101922.LAA29831@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Fri, 10 Jan 1997 11:22:38 PST In-Reply-To: "Perry E. Metzger" "Re: (IPng 2787) Re: MOs' 8+8" (Jan 10, 2:11pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: perry@piermont.com, Ran Atkinson Subject: (IPng 2794) Re: MOs' 8+8 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Jan 10, 2:11pm, "Perry E. Metzger" wrote: } Subject: Re: (IPng 2787) Re: MOs' 8+8 % I'll point out, Ran, that most of the crunchiest routers on earth % could make their decisions based on the first 64 bits even in 8+2+6, % since they could readily ascertain that no more bits need be examined. 8+2+6 doesn't help nearly as much with the routing table size issue. Your assertion that the router "could readily ascertain that no more bits need be examined" is inconsistent with local instruction count estimates for 6+2+8 vs. 8+2+6 vs. 16 on our existing 64-bit CPUs. The decision making process also increases instruction count somewhat. Clearly any router vendor will optimise the heck out of their forwarding path. There are some clear advantages to never having to look at more than 64-bits. Ran rja@cisco.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 Fri Jan 10 11:50:40 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15219; Fri, 10 Jan 97 11:50:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15186; Fri, 10 Jan 97 11:50:22 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA08812; Fri, 10 Jan 1997 11:41:57 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA07321 for ; Fri, 10 Jan 1997 11:41:56 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA31911; Fri, 10 Jan 1997 14:30:30 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA06532; Fri, 10 Jan 1997 14:30:28 -0500 Message-Id: <9701101930.AA06532@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2795) 8+8 Dynamic Renumbering Myth and Reality Date: Fri, 10 Jan 97 14:30:28 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk First lets separate two scenarios: Case A Dynamic Renumbering when it is OK for connections to break when the valid lifetime has not expired. I think this is OK with 99% of the market? Case B Dynamic Renumbering when its not OK to break the connection when the valid lifetime has not expired. I think this is a requirement for only specialized applications and a very small market requirement? Comments.... How for Case A: The fact is that if sites organize their domains to use prefixes that are dynamic from the RG then its simply just a matter of setting up those prefixes with a proper valid and preferred lifetime. If by chance an emergency renumber change happens like the company decides at 12:00 a.m. to renumber by 12:00 p.m. then the Hinden RR from San Jose can be used to cancel existing prefixes and then ND can cascade or DHCPv6 that all prefixes can be reconfigured. I am viewing this as the hybrid approach to using 8+8 which I don't believe is supported as well with RFC 2073 because of the PT bits in 8+8 being clearly demarcated for the ESD. But given that a site has a 30 day grace period to renumber then its just a matter of setting the lifetimes correctly at the site to gradually renumber and make sure the preferred timers are enforced. I think we need to fast track Bob Hindens RR proposal expediently. How for Case B: For specialized applications we need to work on the spec to dynamcially change addresses on the fly. But I think this is not a huge priority in the market at all, but is needed for specialized applications. Myth vs Reality: The vendors that build IPv6 need to build the parts in their implementations that we don't standardize in the industry to not take inherent knowledge of addresses, masks, etc or it simply does not matter what addressing architecture we select renumbering will be a pain otherwise. The vendors must see a market reason and profit to do this addtiional work for IPv6 and there is no way to mandate it. ALso see the new Routing Renumber Reqs just out too. I think the idea of an ESD being globally unique is a complete myth and is not reality. Also the effort to change the software engineering paradigm to only look at ESDs on hosts in the kernel and applications is a myth too. I consider the entire notion of EIDs a myth and not reality. The best we can do is have actions defined with mechanisms to deal with the locator and identifier but they must be used together any attempt to do otherwise will be an exhaustive exercise in futility if attempted as reality. The cost and time-to-market issues must also be understood or we will invent something no one builds or uses. The default is RFC 2073 will be used and this will be nothing more than an academic discussion. A hybrid of the ideas in 8+8 is all I think possible at this point but certainly listening and thinking if I can alter this view. If Mike keeps as manadatory that packets MUST be altered in transit anywhere and not an option then I think just using RFC 2073 is the prudent thing to do and start deploying on the 6bone now thru IANA at least as an implementor for customers who don't have 2 years for us to define how this will work. We will have to deploy and then adjust for a new Format Prefix later, as this will now I think become a major battle in the IETF and the split will take some time for all of us to resolve. But, if we move towards a hybrid solution then I think we can come to some resolution quickly. Renumbering without any system administration directives and configuration rule sets is a complete myth not founded in reality. /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 Fri Jan 10 12:03:47 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15857; Fri, 10 Jan 97 12:03:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15149; Fri, 10 Jan 97 11:45:25 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA07691; Fri, 10 Jan 1997 11:37:00 -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 LAA05548 for ; Fri, 10 Jan 1997 11:36:57 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA131224; Fri, 10 Jan 1997 14:36:19 -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 OAA38648; Fri, 10 Jan 1997 14:36:18 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA12766; Fri, 10 Jan 1997 14:36:41 -0500 Message-Id: <9701101936.AA12766@ludwigia.raleigh.ibm.com> To: rja@cisco.com (Ran Atkinson) Cc: perry@piermont.com, ipng@sunroof.eng.sun.com Subject: (IPng 2796) Re: MOs' 8+8 In-Reply-To: Your message of "Fri, 10 Jan 1997 11:22:38 PST." <199701101922.LAA29831@cornpuffs.cisco.com> Date: Fri, 10 Jan 1997 14:36:40 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk rja@cisco.com (Ran Atkinson) writes: >8+2+6 doesn't help nearly as much with the routing table size issue. I thought that the size of the routing _table_ is NOT the real issue. Rather, it is the number of distinct routing prefixes contained in updates multiplied by the number of peers a router shares/synchronizes its database with. That is, scalability of the computation that builds the routing table is the issue, not the raw size of the routing table itself. That's not so say that halving the size of addresses isn't beneficial. But it is not the fundamental problem. 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 Fri Jan 10 12:10:53 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15888; Fri, 10 Jan 97 12:10:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15882; Fri, 10 Jan 97 12:10:41 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA14009; Fri, 10 Jan 1997 12:02:16 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA14211 for ; Fri, 10 Jan 1997 12:02:16 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA12843; Fri, 10 Jan 1997 14:59:29 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA08919; Fri, 10 Jan 1997 14:59:29 -0500 Message-Id: <9701101959.AA08919@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2797) Re: 8+8 What it breaks for IPv6 now In-Reply-To: Your message of "Fri, 10 Jan 97 13:50:55 EST." <9701101850.AA28997@wasted.zk3.dec.com> Date: Fri, 10 Jan 97 14:59:29 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk WHoops ERROR ERROR... >All of these affect whether EDS is globally unique on another mail >thread. Should say above ESDS not EDS.. p.s. boy this is a lot of new work for us I hope we get somewhere it spilt my plate over the edge with tasks.... apologies, /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 Fri Jan 10 12:12:12 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15901; Fri, 10 Jan 97 12:12:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15892; Fri, 10 Jan 97 12:11:47 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA14196; Fri, 10 Jan 1997 12:03:22 -0800 Received: from cornpuffs.cisco.com (cornpuffs.cisco.com [171.69.1.219]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA14511 for ; Fri, 10 Jan 1997 12:03:22 -0800 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id MAA01079; Fri, 10 Jan 1997 12:02:54 -0800 Message-Id: <199701102002.MAA01079@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Fri, 10 Jan 1997 12:02:54 PST In-Reply-To: Thomas Narten "Re: (IPng 2794) Re: MOs' 8+8" (Jan 10, 2:36pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Thomas Narten , rja@cisco.com (Ran Atkinson) Subject: (IPng 2798) Re: MOs' 8+8 Cc: perry@piermont.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tom, If you ask the ISPs, you'll find that memory consumption in backbone (i.e. defaultless) routers is the more pressing problem. Hence my use of the term "routing table size". This is not to suggest that the number of routes is ignorable or irrelevant. Ran rja@cisco.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 Fri Jan 10 12:24:23 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15956; Fri, 10 Jan 97 12:24:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15944; Fri, 10 Jan 97 12:24:02 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA16950; Fri, 10 Jan 1997 12:15:37 -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 MAA18510 for ; Fri, 10 Jan 1997 12:15:36 -0800 Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA39548; Fri, 10 Jan 1997 15:10:29 -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 PAA36812; Fri, 10 Jan 1997 15:10:26 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15000; Fri, 10 Jan 1997 15:10:51 -0500 Message-Id: <9701102010.AA15000@ludwigia.raleigh.ibm.com> To: rja@cisco.com (Ran Atkinson) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2799) Re: MOs' 8+8 In-Reply-To: Your message of "Fri, 10 Jan 1997 12:02:54 PST." <199701102002.MAA01079@cornpuffs.cisco.com> Date: Fri, 10 Jan 1997 15:10:51 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If you ask the ISPs, you'll find that memory consumption in >backbone (i.e. defaultless) routers is the more pressing problem. My understanding (which may be incorrect) is that the main source of the memory consumption is a router's need to maintain a copy of each of its BGP peers' databases in memory. I.e., typical routers easily have 10 BGP peers, and an order of magnitude more memory is needed for the BGP info compared to the routing table itself. 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 Fri Jan 10 12:26:32 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15972; Fri, 10 Jan 97 12:26:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15966; Fri, 10 Jan 97 12:26:16 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA17536; Fri, 10 Jan 1997 12:17:50 -0800 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA19290 for ; Fri, 10 Jan 1997 12:17:47 -0800 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id PAA09302 for ; Fri, 10 Jan 1997 15:17:43 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma009198; Fri Jan 10 15:17:28 1997 Received: from mako.us.newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id PAA07702 for ; Fri, 10 Jan 1997 15:17:21 -0500 Received: from lobster.nni by mako.us.newbridge.com (4.1/SMI-4.1) id AA14872; Fri, 10 Jan 97 15:13:38 EST Received: by lobster.nni (5.0/SMI-SVR4) id AA00386; Fri, 10 Jan 1997 15:13:33 +0500 Date: Fri, 10 Jan 1997 15:13:33 +0500 From: jhalpern@us.newbridge.com (Joel Halpern) Message-Id: <9701102013.AA00386@lobster.nni> To: ipng@sunroof.eng.sun.com Subject: (IPng 2800) Some of the important boundaries in 8+8 X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk During the discussion in San Jose, it was brought out that there are two relevant boundaries in 8+8, and that they each exist for a reason. Boundary 1: at 8, the ESD. This serves several functions: 1) It cleanly allows for the separation of identity and location. This has been observed several times to be a powerful capability. 2) It places all the routing related information in the first 8 bytes, which is a big advantage for the routers. Note that this is really just shifting by two bytes a boundary that was already in the IPv6 work. Then having done so, we want to work on getting some of the other (security, manageability, etc) related advantages of ESDs. Boundary 2: at 6, within the Routing Goop The reason this is being called 6+2+8 is that there is a second boundary, six bytes into the routing goop. This is the boundary between the provider address space and the customer address space. In conjunction with some of the other behaviors (to provide clean multi-connected or multi-homed behavior) this gives 1) The providers NEVER have to carry customer addresses. This means that aggregation works MUCH better. 2) If a customer changes provider, he gets the same length prefix. This means that he does not need to refigure his addressing plan when he changes providers. There is a related issue here for mid-stream ISPs. An ISPs internal network can behave as a site. Therefore, if a mid-level ISP changes upstream ISPs, he does not have to worry about changing his internal addressing plan. However, when a mid-level ISP changes upstream providers, the space that he has for identifying points where his customers connect to him may change size. He may therefore need to go through an unfortunate process of re-assign customer identification points. Fortunately, this does not ripple down to cause serious disruption to the end customer, since they just see a prefix change. (And presumably an orderly prefix change at that.) The other observation here is that a mid-level provider connected to two upstream providers presumably gets two routing goop prefixes which may be of different lengths. Short of going to fully variable length addresses, the mid-level ISPs will have to deal with these length issues. It should be understood that although there are some prefix length issues for 6+2+8, all such issues exist in much larger form for the current 16 byte IPv6 addressing plan, even with the help of "provider based addressing" Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jan 10 12:37:34 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15995; Fri, 10 Jan 97 12:37:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15989; Fri, 10 Jan 97 12:37:23 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA19671; Fri, 10 Jan 1997 12:28:58 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA22935 for ; Fri, 10 Jan 1997 12:28:58 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id PAA04074; Fri, 10 Jan 1997 15:15:04 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA12937; Fri, 10 Jan 1997 15:14:57 -0500 Message-Id: <9701102014.AA12937@wasted.zk3.dec.com> To: jhalpern@us.newbridge.com (Joel Halpern) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2801) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Fri, 10 Jan 97 14:08:46 +0500." <9701101908.AA00370@lobster.nni> Date: Fri, 10 Jan 97 15:14:56 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joel, We also must consider engineering cost for where the case is not unique and all the additional software developed to handle those cases on a host. Why not push the cost and resolution in the routers there are certainly less of them than hosts on the Internet and Intranets? By using a hybrid approach. I would also add that the idea of end-to-end application flows is affected and talking to ISVs and customers with apps that want the benefit of end-to-end flows from IPv6 (its in the socket structure/API, in the IPv6 header, and I would think part of the routing table lookup on hosts too). It could be the ESD concept is good for state but not good for global uniqueness so we need a hybrid solution to this problem. But can we consciously develop a protocol in the IETF that has the inherent possibility of creating a major problem for an application because of the reliance on non-globally unique identifiers. Suppose the problem shows up on a 10 million dollar wire transfer of funds. Are we leaving a gaping hole in our design that could be very costly. I think so. if we proceed down the path of permitting packets to not be defined completely when leaving an arriving on end nodes. ALso how does an end node determine a set of addresses for a source route. The example from the IPng Directorate days is as follows: Military commander using an Internet for communications to front line field operations. The commander gets updates that he MUST have knowledge of for each encrypted message path to the front line. The application layer builds the source route and sends the message and it is sent with all bits being set to strict. The RG must be known a priori in this scenario to give the field coordinates for targets. This is mission critical I realize but its worth asking for the host application initiated source route. /jim /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 Fri Jan 10 12:48:39 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16041; Fri, 10 Jan 97 12:48:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16035; Fri, 10 Jan 97 12:48:22 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA21889; Fri, 10 Jan 1997 12:39:56 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA27002 for ; Fri, 10 Jan 1997 12:39:53 -0800 Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.4/8.6.12) with SMTP id PAA04372; Fri, 10 Jan 1997 15:39:45 -0500 (EST) Message-Id: <199701102039.PAA04372@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: rja@cisco.com (Ran Atkinson) Cc: Thomas Narten , perry@piermont.com, ipng@sunroof.eng.sun.com Subject: (IPng 2802) Re: MOs' 8+8 In-Reply-To: Your message of "Fri, 10 Jan 1997 12:02:54 PST." <199701102002.MAA01079@cornpuffs.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 10 Jan 1997 15:39:44 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran Atkinson writes: > Tom, > > If you ask the ISPs, you'll find that memory consumption in > backbone (i.e. defaultless) routers is the more pressing problem. Not to be cruel, but the memory itself is cheap -- the problem is that a certain large router manufacturer's older popular devices don't include many SIMM slots so they can't upgrade even though they want to. IPv6 itself will break those routers, though, so provided the large router manufacturer always makes sure there are plenty of SIMM slots going forward this may not be such an issue. > Hence my use of the term "routing table size". > > This is not to suggest that the number of routes is ignorable > or irrelevant. Nor am I trying to suggest that routing table size is irrelevant -- just that Tom did have a point. Of course, twice the size means lots of uglies like half the cache hits... Perry ------------------------------------------------------------------------------ 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 Fri Jan 10 12:56:27 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16086; Fri, 10 Jan 97 12:56:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16076; Fri, 10 Jan 97 12:56:10 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA23238; Fri, 10 Jan 1997 12:47:45 -0800 Received: from cornpuffs.cisco.com (cornpuffs.cisco.com [171.69.1.219]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA29801 for ; Fri, 10 Jan 1997 12:47:43 -0800 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id MAA02036; Fri, 10 Jan 1997 12:47:39 -0800 Date: Fri, 10 Jan 1997 12:47:39 -0800 From: Ran Atkinson Message-Id: <199701102047.MAA02036@cornpuffs.cisco.com> To: jhalpern@us.newbridge.com Subject: (IPng 2803) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: <9701101908.AA00370@lobster.nni> Organization: cisco Systems Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9701101908.AA00370@lobster.nni> Joel Halpern wrote: >I would like to try to separate two aspects of the effect of non-unique ESDs. >In doing so, I will take as a working assumption that the individual >collision probability is very low, but not zero. ... >There is an additional issue: Authentication. Let us assume that >authentication and security associations are tied to ESDs. Then the >non-uniqueness of the ESD could cause a problem. This is potentially >more serious. However, if the security/key management system can detect >the collision if it falls into an overlapping domain of use, then it will >be possible to deal with it. Otherwise there is a problem that we will >have to deal with. For new SAs or changes to SAs, Key Management system can detect this using existing mechanisms for authentication (e.g. the signed public keys used in the ISAKMP/Oakley Phase 1 exchange) For existing IPsec/RIP/OSPF SAs, the cryptographic computation will fail unless the same session key is used. Since the session key is only supposed to be known by the legitimate parties and had better not be guessable, then detection is not a problem for these cases either. >The question then is whether the IDs are sufficiently unique so as to be >useable. I think so. I concur with this restatement of the issue and this conclusion. Joel explained it much more clearly than I could have. Ran rja@cisco.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 Fri Jan 10 13:21:26 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16387; Fri, 10 Jan 97 13:21:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16354; Fri, 10 Jan 97 13:21:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA27613; Fri, 10 Jan 1997 13:12:40 -0800 Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA08313 for ; Fri, 10 Jan 1997 13:12:40 -0800 Received: from big-dogs.cisco.com ([171.68.53.75]) by diablo.cisco.com (8.8.4/CISCO.SERVER.1.2) with SMTP id NAA25134; Fri, 10 Jan 1997 13:11:03 -0800 (PST) Message-Id: <3.0.32.19970110161056.006a4c64@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 10 Jan 1997 16:11:03 -0500 To: Thomas Narten From: Paul Ferguson Subject: (IPng 2804) Re: MOs' 8+8 Cc: rja@cisco.com (Ran Atkinson), 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 At 03:10 PM 1/10/97 -0400, Thomas Narten wrote: >> If you ask the ISPs, you'll find that memory consumption in >>backbone (i.e. defaultless) routers is the more pressing problem. > >My understanding (which may be incorrect) is that the main source of >the memory consumption is a router's need to maintain a copy of each >of its BGP peers' databases in memory. I.e., typical routers easily >have 10 BGP peers, and an order of magnitude more memory is needed for >the BGP info compared to the routing table itself. > Actually, both of you are right, but the other 'half' of the equation is the effect that this has on performance during bouts of instability. - paul ------------------------------------------------------------------------------ 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 Fri Jan 10 13:43:40 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16936; Fri, 10 Jan 97 13:43:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16691; Fri, 10 Jan 97 13:34:59 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA00389; Fri, 10 Jan 1997 13:26:32 -0800 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA12418 for ; Fri, 10 Jan 1997 13:26:30 -0800 Received: from elmo.uu.net by relay5.UU.NET with ESMTP (peer crosschecked as: elmo.UU.NET [153.39.245.203]) id QQbxyb29309; Fri, 10 Jan 1997 16:26:25 -0500 (EST) Received: from elmo.uu.net (localhost.UU.NET [127.0.0.1]) by elmo.uu.net (8.7.5/8.7.3) with ESMTP id QAA03177; Fri, 10 Jan 1997 16:26:21 -0500 (EST) Message-Id: <199701102126.QAA03177@elmo.uu.net> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2805) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Fri, 10 Jan 1997 13:33:56 EST." <9701101833.AA28183@wasted.zk3.dec.com> Date: Fri, 10 Jan 1997 16:26:21 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sigh - here we go again IPv4 addresses are not globally unique. there are MANY more errors assigning those than are ever made with IEEE MAC addresses By your argument, why should we believe the current Global Internet works?? -mo ------------------------------------------------------------------------------ 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 Fri Jan 10 13:50:38 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17619; Fri, 10 Jan 97 13:50:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16767; Fri, 10 Jan 97 13:42:34 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA02066; Fri, 10 Jan 1997 13:34:09 -0800 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA14781 for ; Fri, 10 Jan 1997 13:34:08 -0800 Received: from elmo.uu.net by relay2.UU.NET with ESMTP (peer crosschecked as: elmo.UU.NET [153.39.245.203]) id QQbxyc17248; Fri, 10 Jan 1997 16:34:02 -0500 (EST) Received: from elmo.uu.net (localhost.UU.NET [127.0.0.1]) by elmo.uu.net (8.7.5/8.7.3) with ESMTP id QAA03230; Fri, 10 Jan 1997 16:33:57 -0500 (EST) Message-Id: <199701102133.QAA03230@elmo.uu.net> To: Thomas Narten Cc: rja@cisco.com (Ran Atkinson), perry@piermont.com, ipng@sunroof.eng.sun.com Subject: (IPng 2806) Re: MOs' 8+8 In-Reply-To: Your message of "Fri, 10 Jan 1997 14:36:40 -0400." <9701101936.AA12766@ludwigia.raleigh.ibm.com> Date: Fri, 10 Jan 1997 16:33:57 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk you are right, of course, that the complexity of the computation is the issue.... however N**M or (N/2)**M one of those actually gets smaller faster! -mo ------------------------------------------------------------------------------ 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 Fri Jan 10 13:53:38 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17925; Fri, 10 Jan 97 13:53:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17519; Fri, 10 Jan 97 13:49:47 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA03450; Fri, 10 Jan 1997 13:41:21 -0800 Received: from mailhost3.BayNetworks.COM (shrimp.corpeast.baynetworks.com [192.32.253.7]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA17091 for ; Fri, 10 Jan 1997 13:41:20 -0800 Received: from ns1.BayNetworks.COM (ns1.baynetworks.com [134.177.1.107]) by mailhost3.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id QAA04989 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id NAA28009 Posted-Date: Fri, 10 Jan 1997 13:38:32 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id PAA14810; Fri, 10 Jan 1997 15:59:20 -0500 for Date: Fri, 10 Jan 1997 15:59:20 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701102059.PAA14810@pobox.engeast.BayNetworks.COM> To: rja@cisco.com, narten@raleigh.ibm.com Subject: (IPng 2807) Re: MOs' 8+8 Cc: perry@piermont.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >8+2+6 doesn't help nearly as much with the routing table size issue. > > I thought that the size of the routing _table_ is NOT the real > issue. Rather, it is the number of distinct routing prefixes contained > in updates multiplied by the number of peers a router > shares/synchronizes its database with. That is, scalability of the > computation that builds the routing table is the issue, not the raw > size of the routing table itself. > > That's not so say that halving the size of addresses isn't > beneficial. But it is not the fundamental problem. > > Thomas I agree with this observation. Routers are more cpu bound than memory bound. The CPU consumption comes from the rate of routing changes that need to be processed. This in turn correlates with the number of prefixes in a routing domain not the mere size of the routing table. Forwarding on 8 byte prefix will improve forwarding performance somewhat. 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 Fri Jan 10 14:06:08 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19210; Fri, 10 Jan 97 14:06:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19149; Fri, 10 Jan 97 14:05:37 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA06787; Fri, 10 Jan 1997 13:57:10 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA22220 for ; Fri, 10 Jan 1997 13:57:08 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA14059; Fri, 10 Jan 1997 16:48:19 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31224; Fri, 10 Jan 1997 16:48:17 -0500 Message-Id: <9701102148.AA31224@wasted.zk3.dec.com> To: "Mike O'Dell" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2808) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Fri, 10 Jan 97 16:26:21 EST." <199701102126.QAA03177@elmo.uu.net> Date: Fri, 10 Jan 97 16:48:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, >sigh - here we go again We have to go over alot, you have proposed something radical Mike. We need to understand it you have been thinking about this problem I am sure for a long time before you sent out the draft. >IPv4 addresses are not globally unique. Yes they are by virtue of my address using Class A net 16 and Digital is net 16. You don't get the same benefit from 0::abcdef. >there are MANY more errors assigning those than are ever >made with IEEE MAC addresses Whats is your point here? >By your argument, >why should we believe the current Global Internet works?? It does because no one else is using Net 16 in my case. Its assigned. But 8+8 changes the paradigm not just for nslookup (to use a simple case) but in all the implementations even the way we locate an existing connection for tcp. If you don't see the problems being stated when the ESD is not unique I am real nervous now? We need to get past hand waving here and nice little chic one liners and delve into what it really means to do 8+8 and I think now if we use the hybrid as opposed to what you initially have proposed. At least I think people want to discuss it and have concerns not raised in San Jose. /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 Fri Jan 10 14:06:33 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19248; Fri, 10 Jan 97 14:06:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19166; Fri, 10 Jan 97 14:05:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA06820; Fri, 10 Jan 1997 13:57:19 -0800 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA22277 for ; Fri, 10 Jan 1997 13:57:17 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id NAA23134 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id NAA17085 Posted-Date: Fri, 10 Jan 1997 13:50:17 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id QAA18657; Fri, 10 Jan 1997 16:50:18 -0500 for Date: Fri, 10 Jan 1997 16:50:18 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701102150.QAA18657@pobox.engeast.BayNetworks.COM> To: bound@zk3.dec.com Subject: (IPng 2809) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, It may be just me, but I still fail to understand how your "hybrid" approach is different from the current provider based approach. As far as I can see (and I don't claim that I clearly understand all aspect of the 8+8 proposal), if 8+8 is modified so that it 1) does not rely on sufficient ESD uniqueness and 2) no change to packet addresses in transit is allowed, we are strait back to a provider based scheme with only somewhat different from rfc2073 address format. Dimitry P.S. I like your attempt to separate 8+8 discussions in more manageable threads. ------------------------------------------------------------------------------ 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 Fri Jan 10 17:08:56 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00493; Fri, 10 Jan 97 17:08:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00467; Fri, 10 Jan 97 17:02:44 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA21724; Fri, 10 Jan 1997 15:14:52 -0800 From: jam@iol.unh.edu Received: from ragnar.iol.unh.edu (ragnar.iol.unh.edu [132.177.118.29]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA14932 for ; Fri, 10 Jan 1997 15:14:52 -0800 Received: by ragnar.iol.unh.edu (5.65v3.2/1.1.10.5/01Nov96-0252PM) id AA24595; Fri, 10 Jan 1997 18:12:13 -0500 Date: Fri, 10 Jan 1997 18:12:13 -0500 Message-Id: <9701102312.AA24595@ragnar.iol.unh.edu> To: bound@zk3.dec.com Cc: "Mike O'Dell" , ipng@sunroof.eng.sun.com Subject: (IPng 2810) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: <9701102148.AA31224@wasted.zk3.dec.com> References: <199701102126.QAA03177@elmo.uu.net> <9701102148.AA31224@wasted.zk3.dec.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Implied in this discussion has been the ability to do reverse-lookup based upon the ESD alone. I fail to see how this is possible with no hierarchy in the ESD. Jeremy ------------------------------------------------------------------------------ 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 Fri Jan 10 20:19:58 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00659; Fri, 10 Jan 97 20:19:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00653; Fri, 10 Jan 97 20:19:46 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA02266; Fri, 10 Jan 1997 20:11:20 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA14522 for ; Fri, 10 Jan 1997 20:11:20 -0800 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 UAA14286; Fri, 10 Jan 1997 20:11:18 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: References: Your message of "Wed, 08 Jan 1997 15:59:46 EST." <199701082100.NAA11199@mercury.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Jan 1997 20:11:18 -0800 To: "Mike O'Dell" From: Steve Deering Subject: (IPng 2811) Re: Thoughts on alternative addressing proposals Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike O'Dell wrote: > The fundamental point is: > > the current addressing models for IPv6 are not viable > because the routing computations will not scale > > Therefore, why should anyone go to the trouble to deploy a new > infrastructure with the knowledge that it does not address > the most fundamental problem we face trying to grow the Global > Internet? > > The large network operators are not simpletons, and it seems pretty > clear that the current IPv6 addressing models simply give us a > way to hit the wall going a lot faster. Doing a lot of extra work > so we can hit the abutment at 200mph rather than dying from a mere 70mph > impact doesn't seem like a particularly good use of resources. With respect, Mike, I think the line of reasoning is a bit muddled here. Let me try a slightly different "crash" analogy: Suppose you were thrown out of airplane, with a parachute and a hand-grenade strapped to you, and the grenade is set to explode before you hit the ground. By your reasoning above, you would apparently say "Why should I go to the trouble of deploying my parachute when it does not address the fundamental problem that this grenade is going to kill me first? This parachute won't do a thing prevent the grenade from exploding!" Well, the point is, you have to do *two* things to survive: (a) you have to defuse or somehow get rid of the grenade, and (b) you have to deploy your parachute. That is, we are hurtling towards two address-related crashes in the Internet. The problems caused by insufficient address aggregation (the grenade), if not solved, are likely to kill us before we run out of address space (hit the ground). But after we've solved the routing problems, if we have put off deploying IPv6 (the parachute), we may be too late to avoid going splat! I agree with you that straight provider-based addressing is not an adequate long-term solution, for all the reasons you gave. But I don't see how postponing IPv6 deployment helps to solve it. If anything, moving to IPv6 as soon as possible might give us better tools for dealing with the routing problems than the ones we have in IPv4, such as the IPv6 renumbering mechanisms already designed and implemented, and the flexibility offered by the bigger addresses to do things precisely like your 8+8 proposal. I disagree with your claim that v6 deployment would significantly exacerbate the routing table growth. The IPv4 routing table is full of legacy unaggregated routes which are *not* being carried forward to IPv6; IPv6 is doing only strongly-aggregated addressing and routing right from the beginning. Yes, if we do nothing beyond provider-based addressing, that aggregation will also succumb to entropy over time, thanks to multi-homing, sites claiming the right to be "providers", etc., so continued work on addressing and routing is absolutely essential. But that's always been the case in the Internet, and there's no reason to believe that it won't continue to be the case indefinitely. Over the years, the community developed subnetting, variable-length subnetting, CIDR, provider-based CIDR; they continue to come up with ideas for new ways of structuring the addresses, the routing, and the topology, in order to deal with the growth and structural evolution of the Internet. Some of those changes required or will require modification of hosts and/or router implementations and some didn't or won't. But that's all orthogonal to the issue of changing the header format to carry a larger address. Does anyone think that a solution that would work for IPv4 *won't* work in IPv6? To summarize: o IPv6 does not (or, at least, need not) add significantly to the size or volatility of the Isotopic routing tables. o IPv6 *may* offer some better tools than IPv4 to deal with the routing problems. o IPv6 relieves the address space shortage, which is an important and largely orthogonal problem to the routing problems. o The longer we delay deployment of IPv6, the (exponentially) more machines we will have to upgrade. o The longer we delay deployment of IPv6, the more band-aids and hacks we have to deploy to cope with the address shortages. Maybe you think NAT's just fine, but wait till you have to start doing NAT at points within the backbone, as well as in and out of sites, when there are no longer enough global IPv4 addresses to give even one to each site; the architectural, performance, robustness, and manageability consequences of *that* will be much more profound (and negative, in my opinion) than the 8+8 uncertainties under discussion here. Steve p.s. I don't subscribe to the NANOG list, but I have been told that the opinion you expressed -- that IPv6 has no value if it doesn't fix the routing problems and in fact will make the routing problems horribly worse -- has been expressed on that list. If so, and if no countering opinions have been posted there, perhaps you would consider forwarding this message there, in the (admittedly scant) hope of shedding a bit of a different light on the issues. ------------------------------------------------------------------------------ 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 Fri Jan 10 20:28:25 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00671; Fri, 10 Jan 97 20:28:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00665; Fri, 10 Jan 97 20:28:13 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA02641; Fri, 10 Jan 1997 20:19:47 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA15596 for ; Fri, 10 Jan 1997 20:19:48 -0800 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 UAA14515; Fri, 10 Jan 1997 20:19:46 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: References: Your message of "Wed, 08 Jan 1997 15:59:46 EST." <199701082100.NAA11199@mercury.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Jan 1997 20:19:46 -0800 To: "Mike O'Dell" From: Steve Deering Subject: (IPng 2812) Re: Thoughts on alternative addressing proposals Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering wrote: > o IPv6 does not (or, at least, need not) add significantly to the > size or volatility of the Isotopic routing tables. ^^^^^^^^ A spell-checker gem! What I *actually* wrote was: o IPv6 does not (or, at least, need not) add significantly to the size or volatility of the ISPs' routing tables. 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 Sat Jan 11 04:22:49 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00903; Sat, 11 Jan 97 04:22:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00897; Sat, 11 Jan 97 04:22:36 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA23220; Sat, 11 Jan 1997 04:14:08 -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 EAA19547 for ; Sat, 11 Jan 1997 04:14:09 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id MA23536; Sat, 11 Jan 1997 23:14:01 +1100 (from kre@munnari.OZ.AU) To: "Mike O'Dell" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2813) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Fri, 10 Jan 1997 16:26:21 CDT." <199701102126.QAA03177@elmo.uu.net> Date: Sat, 11 Jan 1997 23:13:56 +1100 Message-Id: <11683.852984836@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 10 Jan 1997 16:26:21 -0500 From: "Mike O'Dell" Message-ID: <199701102126.QAA03177@elmo.uu.net> sigh - here we go again Exactly, Mike you should know better than this. IPv4 addresses are not globally unique. The ones that work on the global internet are. there are MANY more errors assigning those than are ever made with IEEE MAC addresses Absolutely. But the difference isn't in how common it is for mistakes to be made, but how common for mistakes to be made and remain uncorrected in production. Mistakes that are corrected (in either scheme) don't matter. It is impossible to use a duplicate IPv4 address, even locally, it either doesn't work at all (if an address on another subnet gets duplicated) or causes all kinds of bizarre problems if on the same subnet. Because of this, the large numbers of mistakes that are made in their allocation tend to get fixed quite quickly. Once fixed, they're irrelevant. With duplicate MAC addresses, currently, duplicates are only noticed (if they escape where the assignments are done) if the devices happen to be connected to the same level 2 "cable". Anywhere else the duplicate will never be noticed, and never cause any problems (now). Note that the difference here is the assignment technique. IPv4 addresses are assigned hierarchically, with similar addresses being local, which all makes more assignment work for the masses, and hence more errors, but which also makes the errors easier to locate and correct. MAC addresses are essentially assigned centrally, with no reference at all to where they will be used. This makes them easy to assign, means less work for the end users and hence fewer mistakes - but any mistakes that are made are essentially impossible to locate and correct. None of this says that MAC addresses are not "unique enough" for use as ESDs, but comparing apples and oranges as some kind of proof that they must be is ludicrous. 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 Sat Jan 11 06:44:20 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00925; Sat, 11 Jan 97 06:44:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00919; Sat, 11 Jan 97 06:44:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA29616; Sat, 11 Jan 1997 06:35:42 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA26196 for ; Sat, 11 Jan 1997 06:35:42 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQbyas18655; Sat, 11 Jan 1997 09:34:20 -0500 (EST) Message-Id: To: Robert Elz Cc: "Mike O'Dell" , ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 2814) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Sat, 11 Jan 1997 23:13:56 +1100." <11683.852984836@munnari.OZ.AU> Date: Sat, 11 Jan 1997 09:34:20 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, the world-wide success of IPX and the relative ease of ownership is proof that MAC conflicts are not that big a deal. -mo ------------------------------------------------------------------------------ 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 Sat Jan 11 08:54:47 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01045; Sat, 11 Jan 97 08:54:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01039; Sat, 11 Jan 97 08:54:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA05445; Sat, 11 Jan 1997 08:46:08 -0800 Received: from ns.mvp.com (ns.mvp.com [206.129.167.225]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA06739 for ; Sat, 11 Jan 1997 08:46:09 -0800 Received: from northstation.mvp.com (northstation.mvp.com [206.129.167.252]) by ns.mvp.com (8.8.3/8.6.6) with ESMTP id IAA01342; Sat, 11 Jan 1997 08:46:02 -0800 (PST) Received: (from george@localhost) by northstation.mvp.com (8.7.5/8.6.9) id IAA00225; Sat, 11 Jan 1997 08:45:57 -0800 (PST) Date: Sat, 11 Jan 1997 08:45:57 -0800 (PST) From: George Mitchell Message-Id: <199701111645.IAA00225@northstation.mvp.com> To: deering@cisco.com, mo@UU.NET Subject: (IPng 2815) Re: Thoughts on alternative addressing proposals Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If IPv6 is not deployed soon, Microsoft will do it for us. -- George Mitchell (george@mvp.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 Sun Jan 12 07:17:52 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01913; Sun, 12 Jan 97 07:17:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01907; Sun, 12 Jan 97 07:17:38 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA22216; Sun, 12 Jan 1997 07:09:10 -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 HAA10003 for ; Sun, 12 Jan 1997 07:09:10 -0800 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA75212; Sun, 12 Jan 1997 10:09:06 -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 KAA35620; Sun, 12 Jan 1997 10:08:50 -0500 Received: from lig32-224-57-139.us.lig-dial.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15864; Sun, 12 Jan 1997 10:09:07 -0500 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 JAA03707; Sun, 12 Jan 1997 09:51:39 -0500 Message-Id: <199701121451.JAA03707@hygro.raleigh.ibm.com> To: "Mike O'Dell" Cc: Robert Elz , ipng@sunroof.eng.sun.com Subject: (IPng 2816) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Sat, 11 Jan 1997 09:34:20 EST." Date: Sun, 12 Jan 1997 09:51:39 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, >the world-wide success of IPX and the relative ease of ownership >is proof that MAC conflicts are not that big a deal. It shows only that MAC conflicts aren't a problem in IPX. Saying that because MAC address conflicts aren't a problem today (e.g., in IPv4 or IPX) they won't be a problem in 8+8 is false reasoning. For all we know, there could be zillions of duplicate MAC addresses in existance. But because they are on different links, they aren't a problem to IP (which uses globally unique IP addresses not related to the MAC address). My (admittedly limited) understanding of IPX addressing is that IPX addresses consist of a network number and a local part. Only the local part is derived from an interface's MAC address. Thus, duplicate MAC addresses do not imply duplicate IPX addresses at a global level. That is, IPX addresses are a lot more like IPv6 stateless addrconf addresses than like globally unique, flat ESDs as used in 8+8. If we require globally unique ESDs for end-to-end communication, and those ESDs are defined to be the MAC address, I'd venture that duplicates may well start appearing in places where they currently pose no problem. Still, I think most folks would agree that non-uniqueness will be an infrequent occurence in practice. The "are unique" vs. "are not" debate misses the point. ESDs can be "unique enough" only if the cost of collisions is acceptable in the overall scheme of things. Just what happens if two nodes choose the same ESD? If two interfaces on the same link have the same MAC address (i.e., IPv4), the sys admin can simply take one back to the manufacturer. No big deal. On the other hand, If Grandma's new PC can't talk to web site for the Global Shopping Network, how is that dealt with? If she exchanges her PC for another one, maybe it won't talk to the dorm's mail server where her grandson lives. Now what? In an earlier posting, Ran points out that if the ESD is mapped into the wrong identity/cryptographic certificate, authentication will fail. While that can be used to _detect_ problems, it doesn't solve grandma's problem. What happens next? Does communication simply fail? There has to be a fall back. At this point, I think we still need a better understanding of exactly how ESDs are used and what happens if collisions take place before we can state definitively whether they are unique enough, and if not, whether collisions can be dealt with in an acceptable manner. 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 Mon Jan 13 00:18:39 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02687; Mon, 13 Jan 97 00:18:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02681; Mon, 13 Jan 97 00:18:27 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA10218; Mon, 13 Jan 1997 00:09:57 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA25596 for ; Mon, 13 Jan 1997 00:09:58 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id JAA02836 for ; Mon, 13 Jan 1997 09:09:56 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA03643; Mon, 13 Jan 1997 09:09:56 +0100 Message-Id: <9701130809.AA03643@dxcoms.cern.ch> Subject: (IPng 2817) Re: 8+8 Why ESDS are not globally Unique To: ipng@sunroof.eng.sun.com Date: Mon, 13 Jan 1997 09:09:55 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9701101833.AA28183@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Jan 10, 97 01:33:56 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IMHO the answer to this is documented in RFC 1526. The worst case is that today's IP address registries will have to add a new but simpler function of ESD registry. Brian ------------------------------------------------------------------------------ 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 Mon Jan 13 00:45:23 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02710; Mon, 13 Jan 97 00:45:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02704; Mon, 13 Jan 97 00:45:11 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA11668; Mon, 13 Jan 1997 00:36:41 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA28965 for ; Mon, 13 Jan 1997 00:36:41 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id JAA05625 for ; Mon, 13 Jan 1997 09:36:40 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA04993; Mon, 13 Jan 1997 09:36:40 +0100 Message-Id: <9701130836.AA04993@dxcoms.cern.ch> Subject: (IPng 2818) Re: 8+8 Why do we care? To: ipng@sunroof.eng.sun.com Date: Mon, 13 Jan 1997 09:36:40 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9701101817.AA28169@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Jan 10, 97 01:17:11 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > 2. The draft assists with Dynamic Renumbering of a site: > a) by supporting a site not using the RG which means > packets may be altered in transit? > b) simply because the addressing structure is more > organized even if the packets are not altered in transit? > > 3. Because the separation of locator and identifier assists > with renumbering, security identifiers, and Provider Based > Addressing does not? 2.+3. together: 8+8 allows renumbering without breaking TCP sessions and SAs, if that is important to you. > > 4. 8+8 solves the Multihoming problem, Provider Based Addressing > does not? 8+8 scales better in a multihomed Internet. Provider-based scales like Class C's under multihoming. > > 5. 8+8 permits self-organizing address space except for FP and > ESD modes? > LSID: Who assigns it? > How do you get one? > How do we make sure they are not duplicated? Registries > > 6. Provider Based Addressing RFC 2073: > Why not just use this? Whats wrong with it? It doesn't enforce higher-level aggregation, above ISPs, which sets a scaling limit - well above the scaling limit for the pre-CIDR Internet, but well below the LSID scaling limit. (the small number of bits in the LSID is a key feature) > [Note I consider saying it will just make us hit the wall > faster with IPv6 "hand-waving" what are the "technical" > and "adminitrative failures in RFC 2073]????? > Who assigns the Internet Registry? > How are provider n-bits defined and why who? > Does 8+8 alleviate this? You still need registries and you still need IANA > > 7. Is 8+8 useful if we do not permit packets to be altered in > transit? It is not useful to deploy it unless we architect it to permit rewriting > > 8. Do we have any implementation experience with in transit > packets being altered as it severly breaks the IPv4 model? > That's why we wrote draft-iab-ip-ad-today-01.txt NAT was never architected properly - we have a chance to do so with 8+8 > 9. We have momentum now with IPv6 and the market wants it > and needs IPv6 deployed to what extent should 8+8 be > permitted to hold up deployement of IPv6? > It is claimed that the absence of 8+8 will hold up deployment, because the ISPs are reluctant to deploy provider-based. We need to evaluate this claim. Brian ------------------------------------------------------------------------------ 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 Mon Jan 13 01:11:07 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02731; Mon, 13 Jan 97 01:11:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02725; Mon, 13 Jan 97 01:10:55 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA12769; Mon, 13 Jan 1997 01:02:25 -0800 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 BAA02574 for ; Mon, 13 Jan 1997 01:02:25 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 13 Jan 1997 09:02:17 +0000 To: Brian Carpenter CERN-CN Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2819) Re: 8+8 Why do we care? In-Reply-To: Your message of "Mon, 13 Jan 1997 09:36:40 +0100." <9701130836.AA04993@dxcoms.cern.ch> Date: Mon, 13 Jan 1997 09:02:10 +0000 Message-Id: <742.853146130@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >NAT was never architected properly - we have a chance to do >so with 8+8 >> 9. We have momentum now with IPv6 and the market wants it >> and needs IPv6 deployed to what extent should 8+8 be >> permitted to hold up deployement of IPv6? >It is claimed that the absence of 8+8 will hold up >deployment, because the ISPs are reluctant to deploy >provider-based. We need to evaluate this claim. Brian right.....we might get some very nice deployment momentum from these two pieces of the equation..... eight+eight by '98? jon ------------------------------------------------------------------------------ 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 Mon Jan 13 05:23:02 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02947; Mon, 13 Jan 97 05:23:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02941; Mon, 13 Jan 97 05:22:47 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA24404; Mon, 13 Jan 1997 05:14:16 -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 FAA08547 for ; Mon, 13 Jan 1997 05:14:17 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA15334; Mon, 13 Jan 1997 08:13: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 IAA70790; Mon, 13 Jan 1997 08:13:43 -0500 Received: from lig32-225-17-86.us.lig-dial.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15856; Mon, 13 Jan 1997 08:14:19 -0500 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 IAA10268; Mon, 13 Jan 1997 08:08:39 -0500 Message-Id: <199701131308.IAA10268@hygro.raleigh.ibm.com> To: jhalpern@us.newbridge.com (Joel Halpern) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2820) Re: Some of the important boundaries in 8+8 In-Reply-To: Your message of "Fri, 10 Jan 1997 15:13:33 +0500." <9701102013.AA00386@lobster.nni> Date: Mon, 13 Jan 1997 08:08:39 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jhalpern@us.newbridge.com (Joel Halpern) writes: >Boundary 2: at 6, within the Routing Goop > The reason this is being called 6+2+8 is that there is a second boundary, > six bytes into the routing goop. This is the boundary between the > provider address space and the customer address space. > In conjunction with some of the other behaviors (to provide clean > multi-connected or multi-homed behavior) this gives > 1) The providers NEVER have to carry customer addresses. This means that > aggregation works MUCH better. Are you proposing two kinds of routers? One used by ISPs (that looks only at the first 6 or 8 bytes of an address) whereas another type would be used for intra-site routing (where more of the prefix bits need to be examined)? If by "customer address" you include the prefix bits that are used for internal routing within a site (i.e., routers only look at the first 6 bytes), this would not allow providers to carry longer "exceptions" for a customer that wants to advertise a sub-prefix of its internal topology. It would seem to me that we would want routers everywhere to always be able to look at all of the prefix bits used for routing whether they are internal to a site or not. That way it would be policy as to whether a router actually looked at a site's internal bits. Thus, the relevent boundary from a router's perspective should be the one between the routing prefix vs. the interface identifier (i.e., interface token). Perhaps we should just decree that X bytes of an address are always reserved for an interface identifier and are never used for routing at the IP level. Can we do that? I suspect that folks with PPP servers and the like won't like this much at all! It would likely force things that are treated as separate interfaces (e.g., pt-to-pt links) to be lumped into one interface having multiple links that are not directly visible to IP (in order to preserve subnet numbers). Hmm. 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 Mon Jan 13 05:58:40 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02985; Mon, 13 Jan 97 05:58:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02979; Mon, 13 Jan 97 05:58:29 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA28069; Mon, 13 Jan 1997 05:49:58 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA15867 for ; Mon, 13 Jan 1997 05:49:59 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA32596; Mon, 13 Jan 1997 08:41:58 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31329; Mon, 13 Jan 1997 08:41:56 -0500 Message-Id: <9701131341.AA31329@wasted.zk3.dec.com> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2821) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Fri, 10 Jan 97 16:50:18 EST." <199701102150.QAA18657@pobox.engeast.BayNetworks.COM> Date: Mon, 13 Jan 97 08:41:56 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry, >As far as I can see (and I don't claim that I clearly understand all >aspect of the 8+8 proposal), if 8+8 is modified so that it >1) does not rely on sufficient ESD uniqueness and 2) no change to packet >addresses in transit is allowed, we are strait back to a provider >based scheme with only somewhat different from rfc2073 address format. All we can do now then is determine if 8+8 is valuable as a hybrid and I think also a list of exactly what is wrong with 2073. I have tried to ask those questions but have seen no answers other than the one I gave you below previosly. > FROM: Subject: Re: (IPng 2735) Re: MOs' 8+8 >I just responded to John Stewart on this. Essentially 8+8 (and >thats what I am calling it until Mike himself changes the title of the >draft) I think will work. The LSID permits providers to work amongst >themselves with out both an Internet Registry and Provider set of bits for >one thing. The routing goop can be flat routed between providers too as d >iscussed in the draft. The RG + ESD permits a paradigm where the network >is cleanly topologically divided to support provider prefix changes without >changing the ESD within organizations. This was the jist of my comment >earlier today with using the Hinden RR and Autoconfig in IPv6 at each >link (stateless or stateful). The IANA is less involved with handing >out addresses and is only needed to declare ESD Mode types and possibly >assisting with the LSIDs. The rest of the bits are self organizing. >This reduces much overhead for the provider. I do not believe I >understand all parts about the DNS until I see Mike's next draft and >that is really important. /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 Mon Jan 13 07:38:10 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03096; Mon, 13 Jan 97 07:38:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03090; Mon, 13 Jan 97 07:37:59 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA08423; Mon, 13 Jan 1997 07:29:28 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA15149 for ; Mon, 13 Jan 1997 07:29:29 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA06410; Mon, 13 Jan 1997 10:16:21 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14971; Mon, 13 Jan 1997 10:16:18 -0500 Message-Id: <9701131516.AA14971@wasted.zk3.dec.com> To: "Mike O'Dell" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2822) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Sat, 11 Jan 97 09:34:20 EST." Date: Mon, 13 Jan 97 10:16:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, >Robert, > >the world-wide success of IPX and the relative ease of ownership >is proof that MAC conflicts are not that big a deal. I think this is really not a good argument or proof point. I could claim the same about DECnet too and to some degree SNA. But IPX, DECnet, or SNA are not used on the Global Internet Backbone. They are used mostly as Intranet protocols and do not have the scope of IPv4 let alone the use that will be done via IPv6 in the world. The bottom line is we have put mechanisms in IPv6 because we believe that the MAC address are not unique. I would like to see all of us agree we were WRONG, or stick to what consensus has built about IPv6. The other the bottom line is that what you propose is pretty major to not just existing IPv6 implementation but also to many of the features we want from IPv6. Such as end-to-end flows and transition. Another issue is if we require the transit model of edge and other routers to alter the source address, this has significant ramifications to host transport layer code. This can not be considered lightly and without caution. ALso I assume you do not want to alter the destination address in the packet? Is that correct? /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 Mon Jan 13 07:53:59 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03116; Mon, 13 Jan 97 07:53:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03110; Mon, 13 Jan 97 07:53:48 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA10464; Mon, 13 Jan 1997 07:45:18 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA20463 for ; Mon, 13 Jan 1997 07:45:18 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA25337; Mon, 13 Jan 1997 10:33:47 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19019; Mon, 13 Jan 1997 10:32:36 -0500 Message-Id: <9701131532.AA19019@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2823) Re: Thoughts on alternative addressing proposals In-Reply-To: Your message of "Fri, 10 Jan 97 20:11:18 PST." Date: Mon, 13 Jan 97 10:32:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >I agree with you that straight provider-based addressing is not an adequate >long-term solution, for all the reasons you gave. But I don't see how >postponing IPv6 deployment helps to solve it. If anything, moving to IPv6 >as soon as possible might give us better tools for dealing with the routing >problems than the ones we have in IPv4, such as the IPv6 renumbering >mechanisms already designed and implemented, and the flexibility offered by >the bigger addresses to do things precisely like your 8+8 proposal. Agree with you 100%. In fact it might be that Release 2 of IPv6 takes on the transport changes and other changes it appears "some" want with new ideas like 8+8, but gets those customers that want the bigger address space and the technology advantages of IPv6 in 1997 on their Intranets. Providers that can make profit or gain market leadership or mind share by being an early adopter may actually run the risk and even some of the large NAPs like AT&T, British Telecom, etc.. That would make the ISPs certainly think about it differently for sure. >To summarize: o IPv6 does not (or, at least, need not) add significantly to the size or volatility of the Isotopic routing tables. o IPv6 *may* offer some better tools than IPv4 to deal with the routing problems. o IPv6 relieves the address space shortage, which is an important and largely orthogonal problem to the routing problems. o The longer we delay deployment of IPv6, the (exponentially) more machines we will have to upgrade. o The longer we delay deployment of IPv6, the more band-aids and hacks we have to deploy to cope with the address shortages. Maybe you think NAT's just fine, but wait till you have to start doing NAT at points within the backbone, as well as in and out of sites, when there are no longer enough global IPv4 addresses to give even one to each site; the architectural, performance, robustness, and manageability consequences of *that* will be much more profound (and negative, in my opinion) than the 8+8 uncertainties under discussion here. WIth RFC 2073 becoming PS deployment is certainly possible right now once the BGP/IDRP discussions are decided IMO. /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 Mon Jan 13 10:47:04 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03647; Mon, 13 Jan 97 10:47:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03077; Mon, 13 Jan 97 07:27:02 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA07131; Mon, 13 Jan 1997 07:18:31 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA11814 for ; Mon, 13 Jan 1997 07:18:31 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA10354; Mon, 13 Jan 1997 10:05:26 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA15695; Mon, 13 Jan 1997 10:05:20 -0500 Message-Id: <9701131505.AA15695@wasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2824) Re: 8+8 Why do we care? In-Reply-To: Your message of "Mon, 13 Jan 97 09:36:40 +0100." <9701130836.AA04993@dxcoms.cern.ch> Date: Mon, 13 Jan 97 10:05:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, I think you give good reasons why 8+8 is better (Dimitry does this mail from Brian help with your question of use of 8+8 without packets being altered in transit), though you say below its of no use without rewriting, which confuses me as I ask below. >2.+3. together: 8+8 allows renumbering without breaking TCP sessions >and SAs, if that is important to you. Do you believe the destination address leaving from the application should have RG + ESD in its address, and not altered by the transit of the packet? If yes then it does not automatically handle existing connections being renumberd unless you believe the pcb look up will work with just the ESD? I am not convinced that is true yet for the ESDs. If no then the security problems occur that I have to differentiate in some way at the pcb look up to verify its the same person I am talking too. Also most of us care about UDP too and that has other ramifications. UNless your in the camp that believes you don't care about UDP? Also the work Pedro, Charlie, and I are working on will renumber connections without the risk of 8+8. So if all we want is renumbering that can be done with much less pain than 8+8. >> >> 7. Is 8+8 useful if we do not permit packets to be altered in >> transit? >It is not useful to deploy it unless we architect it to permit rewriting So all the benefits you just listed do not exist without rewriting? Why is that? It feels like a contradiction? >> >> 8. Do we have any implementation experience with in transit >> packets being altered as it severly breaks the IPv4 model? >> >That's why we wrote draft-iab-ip-ad-today-01.txt > >NAT was never architected properly - we have a chance to do >so with 8+8 To some degree because the RG can be rewritten. It still don't help with transition? Or have you changed your view on this because of 8+8? RFC 1671???? >> 9. We have momentum now with IPv6 and the market wants it >> and needs IPv6 deployed to what extent should 8+8 be >> permitted to hold up deployement of IPv6? >> >It is claimed that the absence of 8+8 will hold up >deployment, because the ISPs are reluctant to deploy >provider-based. We need to evaluate this claim. I have had some private mail that goes like this: If 6bone keeps evolving. If routers keep building IPv6. If UNIX and PC desktop vendors keep building IPv6. If customers on the Intranet start deployment. The ISPs will deploy once they see they can make a profit on IPv6, as opposed to saving person-kind from the evils of provider basesd addressing. I must say I take that input to heart. /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 Mon Jan 13 11:26:21 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03689; Mon, 13 Jan 97 11:26:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03683; Mon, 13 Jan 97 11:26:10 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA22913; Mon, 13 Jan 1997 11:17:39 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA17044 for ; Mon, 13 Jan 1997 11:17:29 -0800 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 LAA15658; Mon, 13 Jan 1997 11:13:47 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <9701131516.AA14971@wasted.zk3.dec.com> References: Your message of "Sat, 11 Jan 97 09:34:20 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Jan 1997 11:13:46 -0800 To: bound@zk3.dec.com From: Steve Deering Subject: (IPng 2825) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The bottom line is we have put mechanisms in IPv6 because we believe > that the MAC address are not unique. I would like to see all of us agree > we were WRONG, or stick to what consensus has built about IPv6. Jim, If you are referring to Duplicate Address Detection, I believe the reason we included that function was because of the duplication risks that arise when addresses are generated using something *other* than MAC addresses, e.g., when using manual configuration or using address-assignment servers like DHCPv6 that might have failure modes that result in duplicates. If we always generated IPv6 addresses from MAC addresses, I don't think that DAD would be worth the extra code and spec complexity (at least not for those media that use factory-provided MAC addresses). 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 Mon Jan 13 12:13:20 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03780; Mon, 13 Jan 97 12:13:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03774; Mon, 13 Jan 97 12:13:10 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA03204; Mon, 13 Jan 1997 12:04:39 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA05764 for ; Mon, 13 Jan 1997 12:04:09 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA00949; Mon, 13 Jan 1997 14:50:54 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA09318; Mon, 13 Jan 1997 14:50:53 -0500 Message-Id: <9701131950.AA09318@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2826) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Mon, 13 Jan 97 11:13:46 PST." Date: Mon, 13 Jan 97 14:50:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >If you are referring to Duplicate Address Detection, I believe the reason >we included that function was because of the duplication risks that arise >when addresses are generated using something *other* than MAC addresses, >e.g., when using manual configuration or using address-assignment servers >like DHCPv6 that might have failure modes that result in duplicates. If we >always generated IPv6 addresses from MAC addresses, I don't think that DAD >would be worth the extra code and spec complexity (at least not for those >media that use factory-provided MAC addresses). I actually agree with you. But it was my recollection that most of the addr conf WG from the beginning were driven by some evil that we could run into from 802.X. I believe 802.X is unique enough and always have but thought I was wrong from our IPng process. If we believe factory addresses are unique then that makes 8+8 much more doable and moves the discussion to other areas???? For me anyway. But would like to see that folks don't violently object to your mail or my response..... I can still question DAD, but will just leave it be as we implemented it and it seems to not eat up anything to much or precious. 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 Mon Jan 13 12:58:37 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03850; Mon, 13 Jan 97 12:58:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03844; Mon, 13 Jan 97 12:58:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA11883; Mon, 13 Jan 1997 12:49:49 -0800 Received: from mailhost3.BayNetworks.COM (shrimp.corpeast.baynetworks.com [192.32.253.7]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA22944 for ; Mon, 13 Jan 1997 12:49:35 -0800 Received: from ns1.BayNetworks.COM (ns1.baynetworks.com [134.177.1.107]) by mailhost3.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id PAA13509 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id MAA06914 Posted-Date: Mon, 13 Jan 1997 12:45:55 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id PAA00793; Mon, 13 Jan 1997 15:45:56 -0500 for Date: Mon, 13 Jan 1997 15:45:56 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701132045.PAA00793@pobox.engeast.BayNetworks.COM> To: brian@dxcoms.cern.ch Subject: (IPng 2827) Re: 8+8 Why do we care? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > > > > 6. Provider Based Addressing RFC 2073: > > Why not just use this? Whats wrong with it? > > It doesn't enforce higher-level aggregation, above ISPs, > which sets a scaling limit - well above the scaling limit > for the pre-CIDR Internet, but well below the LSID scaling limit. > (the small number of bits in the LSID is a key feature) > If you set the ProviderID portion of the RFC-2073 address to 8 bits, wouldn't you get the same aggregation level as with LSID? If registries allocate fewer than 8 bits to ProviderID, even a higher level of aggregation can be achieved with RFC 2073. Are you arguing that as far as the level of aggregation is concerned, it would be better to fix the highest level provider portion of the address to some small number of bits (to "enforce higher-level aggregationrather") rather that leave it up to the registries as is suggested in RFC 2073? 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 Mon Jan 13 15:15:59 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04265; Mon, 13 Jan 97 15:15:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04259; Mon, 13 Jan 97 15:15:47 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA11391; Mon, 13 Jan 1997 15:07:15 -0800 Received: from ftp.com (ftp.com [128.127.2.122]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA15225 for ; Mon, 13 Jan 1997 15:06:51 -0800 Received: from ftp.com by ftp.com ; Mon, 13 Jan 1997 18:06:33 -0500 Received: from mailserv-2high.ftp.com by ftp.com ; Mon, 13 Jan 1997 18:06:33 -0500 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id SAA15968; Mon, 13 Jan 1997 18:06:34 -0500 Message-Id: <199701132306.SAA15968@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: bound@zk3.dec.com, deering@cisco.com Cc: ipng@sunroof.eng.sun.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 2828) Re: 8+8 Why ESDS are not globally Unique Date: Mon, 13 Jan 1997 18:02:19 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >... If we believe factory addresses are unique then .. There's been a few cases where bugs in someone's manufacturing process resulted in the factory addresses being non-unique. It was, of course, discovered The Hard Way. -- Frank ------------------------------------------------------------------------------ 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 Mon Jan 13 15:21:10 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04280; Mon, 13 Jan 97 15:21:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04274; Mon, 13 Jan 97 15:20:54 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA12569; Mon, 13 Jan 1997 15:12:23 -0800 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA17117 for ; Mon, 13 Jan 1997 15:11:58 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id PAA00335 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id PAA18778 Posted-Date: Mon, 13 Jan 1997 15:11:17 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id SAA10962; Mon, 13 Jan 1997 18:11:18 -0500 for Date: Mon, 13 Jan 1997 18:11:18 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701132311.SAA10962@pobox.engeast.BayNetworks.COM> To: mo@UU.NET, narten@raleigh.ibm.com Subject: (IPng 2829) Re: 8+8 Why ESDS are not globally Unique Cc: kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >the world-wide success of IPX and the relative ease of ownership > >is proof that MAC conflicts are not that big a deal. > > It shows only that MAC conflicts aren't a problem in IPX. Saying that > because MAC address conflicts aren't a problem today (e.g., in IPv4 or > IPX) they won't be a problem in 8+8 is false reasoning. For all we > know, there could be zillions of duplicate MAC addresses in > existance. But because they are on different links, they aren't a > problem to IP (which uses globally unique IP addresses not related to > the MAC address). > Interestingly, the fact that it has been possible to administer globally unique IP addresses which are successfully used as end-system identifiers is an indication that the same is quite possible with ESD. The probably simplest approach would be to administer ESDs the same way IP addresses are administered (pretending that IP address is 64-bit long). An added advantage of that would be that it probably solves the reverse DNS lookup problem by reverting the problem to the already solved one. 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 Mon Jan 13 15:48:51 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04349; Mon, 13 Jan 97 15:48:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04343; Mon, 13 Jan 97 15:48:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA17834; Mon, 13 Jan 1997 15:40:05 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA27229 for ; Mon, 13 Jan 1997 15:40:05 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id SAA22940; Mon, 13 Jan 1997 18:39:58 -0500 Date: Mon, 13 Jan 1997 18:39:58 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9701131839.ZM22938@seawind.bellcore.com> In-Reply-To: dhaskin@BayNetworks.COM (Dimitry Haskin) "(IPng 2829) Re: 8+8 Why ESDS are not globally Unique" (Jan 13, 6:11pm) References: <199701132311.SAA10962@pobox.engeast.BayNetworks.COM> X-Mailer: Z-Mail (3.2.1 10oct95) To: dhaskin@BayNetworks.COM (Dimitry Haskin) Subject: (IPng 2830) Re: 8+8 Why ESDS are not globally Unique 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 > the probably > simplest approach would be to administer ESDs the same way IP > addresses are administered (pretending that IP address is 64-bit long). > An added advantage of that would be that it probably solves the > reverse DNS lookup problem by reverting the problem to the already solved > one. ... which means that automatic address configuration works just the same way as it does for IPv4, right ? -- 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 Mon Jan 13 17:24:35 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04649; Mon, 13 Jan 97 17:24:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04630; Mon, 13 Jan 97 17:08:26 PST Received: from sunmail1.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA02523; Mon, 13 Jan 1997 16:59:56 -0800 Received: from sun.Eng.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id QAA05048; Mon, 13 Jan 1997 16:59:55 -0800 Received: from guitarman.nd.net.fujitsu.co.jp by sun.Eng.Sun.COM (4.1/SMI-4.1) id AA10376; Mon, 13 Jan 97 16:59:53 PST Received: from fdmmail.fujitsu.co.jp ([133.161.11.2]) by fujitsuI.fujitsu.com (8.7.5/8.7.3) with SMTP id QAA02282 for ; Mon, 13 Jan 1997 16:46:55 -0800 (PST) Received: from guitarman.nd.net.fujitsu.co.jp by fdmmail.fujitsu.co.jp (8.6.12+2.5Wb4/3.3W9-MX970108-Fujitsu Domain Mail Master) id JAA23750; Tue, 14 Jan 1997 09:46:51 +0900 Received: from guitarman (localhost [127.0.0.1]) by guitarman.nd.net.fujitsu.co.jp (8.7.4/8.6.9) with ESMTP id JAA19477; Tue, 14 Jan 1997 09:51:42 +0900 (JST) Resent-Message-Id: <199701140051.JAA19477@guitarman.nd.net.fujitsu.co.jp> Message-Id: <199701140051.JAA19477@guitarman.nd.net.fujitsu.co.jp> To: ipng@Eng Subject: (IPng 2831) How to set source routing 1st hop LOOSE/STRICT in Advanced API ? From: Yoshinobu Inoue X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 13 Jan 1997 22:29:30 +0900 Resent-To: sunroof.eng.sun.com!ipng@Eng Resent-Cc: shin@guitarman.nd.net.fujitsu.co.jp Resent-Date: Tue, 14 Jan 1997 09:51:41 +0900 Resent-From: Yoshinobu Inoue Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am Yoshinobu Inoue, engineer at Fujitsu Limited in Japan. I have been trying to implement IPv6 source routing for ping using Advanced API these days, and found that there seems to be no way to specify source routing 1st hop's LOOSE/STRICT, at least as current draft description. inet6_srcrt_add() can specify LOOSE/STRICT for 2nd to 24th source routing hops which included in routing header, but seems not to specify it for 1st hop which placed at IPv6 header's dst addr field at first. I think adding some exeptional case to the description of inet6_srcrt_add() will solve the problem, that is, for example, -Advanced API Spec, at the top of Page 26, int inet6_srcrt_add(struct cmsghdr *cmsg, const struct in6_addr *addr, unsigned int flags); This function adds the address pointed to by addr to the end of the routing header being constructed and sets the type of this hop to the value of flags. For an IPv6 type 0 routing header, flags must be either IPV6_SRCRT_LOOSE or IPV6_SRCRT_STRICT. -- addition begin -- When this function called first, if successful, specified addr is inserted into sending packet's IPv6 header's destination address field, return value of the function is 0, and cmsg_len member of the cmsghdr structure is not changed. And after the second call, if successful, the cmsg_len member of the cmsghdr structure is updated to account for the newly inserted address into the routing header and the return value of the function is 0. -- addition end -- -- deletion start -- If successful, the cmsg_len member of the cmsghdr structure is updated to account for the new address in the routing header and the return value of the function is 0. -- deletion end -- Sorry if this is already discussed. And also sorry in advance for any incomplete wording result from my language skill. I wish to here any other better solution. (I surely believe there is.) Regards, -- Yoshinobu Inoue shin@nd.net.fujitsu.co.jp 2nd Development Department Network Division Fujitsu Limited ------------------------------------------------------------------------------ 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 Mon Jan 13 17:32:08 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04665; Mon, 13 Jan 97 17:32:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04659; Mon, 13 Jan 97 17:31:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA06378; Mon, 13 Jan 1997 17:23:19 -0800 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id RAA29427 for ; Mon, 13 Jan 1997 17:23:19 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id RAA04221 Received: from pobox.corpwest.BayNetworks.COM (mailhost.corpwest.baynetworks.com [134.177.1.95]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id RAA21763 Posted-Date: Mon, 13 Jan 1997 17:22:38 -0800 (PST) Received: from dhaskin.baynetworks.com ([192.32.171.165]) by pobox.corpwest.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id RAA28481; Mon, 13 Jan 1997 17:22:38 -0800 for Message-Id: <2.2c.32.19970114011731.00aaca54@pobox.corpeast.baynetworks.com> X-Sender: dhaskin@pobox.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 2.2c (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Jan 1997 20:17:31 -0500 To: huitema@bellcore.com (Christian Huitema) From: Dimitry Haskin Subject: (IPng 2832) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 06:39 PM 1/13/97 -0500, Christian Huitema wrote: >> the probably >> simplest approach would be to administer ESDs the same way IP >> addresses are administered (pretending that IP address is 64-bit long). >> An added advantage of that would be that it probably solves the >> reverse DNS lookup problem by reverting the problem to the already >solved >> one. > >... which means that automatic address configuration works just the same >way as it does for IPv4, right ? > May be yes, may be not.. It depends if enough lower order bits can be spared in the extended IP address to generate a link-unique token and still to leave enough bits for the hierarchical part. 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 Mon Jan 13 18:20:39 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04785; Mon, 13 Jan 97 18:20:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04779; Mon, 13 Jan 97 18:20:27 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA13163; Mon, 13 Jan 1997 18:11:54 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA13131 for ; Mon, 13 Jan 1997 18:11:51 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQbyjw02222; Mon, 13 Jan 1997 21:09:13 -0500 (EST) Message-Id: To: Frank T Solensky Cc: bound@zk3.dec.com, deering@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 2833) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Mon, 13 Jan 1997 18:02:19 EST." <199701132306.SAA15968@MAILSERV-2HIGH.FTP.COM> Date: Mon, 13 Jan 1997 21:09:13 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk of course, nobody has *ever* made a similar mistake configuring a few hundred workstations by hand... oh no.... (grin) -mo ------------------------------------------------------------------------------ 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 Mon Jan 13 18:34:20 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04807; Mon, 13 Jan 97 18:34:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04801; Mon, 13 Jan 97 18:34:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA14714; Mon, 13 Jan 1997 18:25:37 -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 SAA16075 for ; Mon, 13 Jan 1997 18:25:33 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA29570; Mon, 13 Jan 1997 21:25: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 VAA73066; Mon, 13 Jan 1997 21:25:13 -0500 Received: from lig32-225-17-6.us.lig-dial.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA19514; Mon, 13 Jan 1997 21:25:45 -0500 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 VAA14054; Mon, 13 Jan 1997 21:19:55 -0500 Message-Id: <199701140219.VAA14054@hygro.raleigh.ibm.com> To: Dimitry Haskin Cc: huitema@bellcore.com (Christian Huitema), ipng@sunroof.eng.sun.com Subject: (IPng 2834) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Mon, 13 Jan 1997 20:17:31 EST." <2.2c.32.19970114011731.00aaca54@pobox.corpeast.baynetworks.com> Date: Mon, 13 Jan 1997 21:19:55 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >May be yes, may be not.. It depends if enough lower order bits can be spared >in the extended IP address to generate a link-unique token and still to leave >enough bits for the hierarchical part. I'd say we would need a minimum of 3 bytes for heirarchy (which is effectively what we have in IPv4 today), and 4 would probably be a lot smarter. 2 bytes would only allow 65K separately administered sites, which is clearly not enough (each "end site" would probably need its own number). Further, it is almost certainly a requirement that the space be truly heirarchical (for administrative and scalability reasons), with higher levels delegating numbering space to lower levels. That implies the space will be used relatively inefficiently. How that can be combined with a 6 byte token to produce an 8 byte ESD is an interesting problem. I'm assuming that 8 bytes in the upper half of an address is needed for routing and that we'll not be able to steal any additional bits from there, though I suppose we could revisit that one too. If we assume that 8+8 allows frequent renumbering of the backbone, one can then also make the argument that the backbone shouldn't need as many bits for routing -- the numbering space will be used efficiently. 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 Mon Jan 13 18:43:28 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04834; Mon, 13 Jan 97 18:43:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04828; Mon, 13 Jan 97 18:43:16 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA15685; Mon, 13 Jan 1997 18:34:45 -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 SAA17797 for ; Mon, 13 Jan 1997 18:34:34 -0800 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA84750; Mon, 13 Jan 1997 21:33:45 -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 VAA38920; Mon, 13 Jan 1997 21:33:39 -0500 Received: from lig32-225-17-6.us.lig-dial.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA19916; Mon, 13 Jan 1997 21:34:21 -0500 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 VAA14099; Mon, 13 Jan 1997 21:28:32 -0500 Message-Id: <199701140228.VAA14099@hygro.raleigh.ibm.com> To: Frank T Solensky Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2835) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Mon, 13 Jan 1997 18:02:19 EST." <199701132306.SAA15968@MAILSERV-2HIGH.FTP.COM> Date: Mon, 13 Jan 1997 21:28:32 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Frank, >>... If we believe factory addresses are unique then .. >There's been a few cases where bugs in someone's manufacturing process >resulted in the factory addresses being non-unique. It was, of course, >discovered The Hard Way. I've heard this statement made made several times, but the information is always second hand. Do you (or anyone) have references to specific examples of this? That is, how many duplicate addresses actually got shipped, who were the manufacturers, were they all recalled, etc.? I don't doubt that it _could_ happen, but I can't help but wonder if there is also a bit of urban legend here as well. 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 Mon Jan 13 19:15:57 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04905; Mon, 13 Jan 97 19:15:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04899; Mon, 13 Jan 97 19:15:40 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA18982; Mon, 13 Jan 1997 19:07:09 -0800 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id TAA23762 for ; Mon, 13 Jan 1997 19:07:10 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id TAA06864 Received: from pobox.corpwest.BayNetworks.COM (mailhost.corpwest.baynetworks.com [134.177.1.95]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id TAA18385 Posted-Date: Mon, 13 Jan 1997 19:06:30 -0800 (PST) Received: from dhaskin.baynetworks.com ([192.32.171.165]) by pobox.corpwest.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id TAA02154; Mon, 13 Jan 1997 19:06:28 -0800 for Message-Id: <2.2c.32.19970114030122.00ab3660@pobox.corpeast.baynetworks.com> X-Sender: dhaskin@pobox.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 2.2c (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Jan 1997 22:01:22 -0500 To: Thomas Narten From: Dimitry Haskin Subject: (IPng 2836) Re: 8+8 Why ESDS are not globally Unique Cc: huitema@bellcore.com (Christian Huitema), ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:19 PM 1/13/97 -0500, Thomas Narten wrote: >>May be yes, may be not.. It depends if enough lower order bits can be spared >>in the extended IP address to generate a link-unique token and still to leave >>enough bits for the hierarchical part. > >I'd say we would need a minimum of 3 bytes for heirarchy (which is >effectively what we have in IPv4 today), and 4 would probably be a lot >smarter. 2 bytes would only allow 65K separately administered sites, >which is clearly not enough (each "end site" would probably need its >own number). Further, it is almost certainly a requirement that the >space be truly heirarchical (for administrative and scalability >reasons), with higher levels delegating numbering space to lower >levels. That implies the space will be used relatively inefficiently. > Agreed -- 4 bytes seems the right size for the ESD hierarchy. >How that can be combined with a 6 byte token to produce an 8 byte ESD >is an interesting problem. I'm assuming that 8 bytes in the upper half >of an address is needed for routing and that we'll not be able to >steal any additional bits from there, though I suppose we could >revisit that one too. If we assume that 8+8 allows frequent >renumbering of the backbone, one can then also make the argument that >the backbone shouldn't need as many bits for routing -- the numbering >space will be used efficiently. > Yes, if a 4 byte token is declared to be too small to produce a sufficiently unique value for autoconfiguration purposes, it may be very well that we'll be able to extend ESD to 10 bytes (6+10 :). Didn't I hear an argument for fewer routing bits to enforce a higher level of aggregation? >Thomas > 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 Mon Jan 13 19:17:07 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04912; Mon, 13 Jan 97 19:17:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04906; Mon, 13 Jan 97 19:16:44 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA19050; Mon, 13 Jan 1997 19:08:13 -0800 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA09996 for ; Mon, 13 Jan 1997 19:08:11 -0800 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id WAA26074; Mon, 13 Jan 1997 22:03:10 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma026046; Mon Jan 13 22:02:52 1997 Received: from mako.us.newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id WAA02711; Mon, 13 Jan 1997 22:02:51 -0500 Received: from lobster.nni by mako.us.newbridge.com (4.1/SMI-4.1) id AA23339; Mon, 13 Jan 97 22:00:35 EST Received: by lobster.nni (5.0/SMI-SVR4) id AA01025; Mon, 13 Jan 1997 22:00:33 +0500 From: jhalpern@us.newbridge.com (Joel Halpern) Message-Id: <9701140300.AA01025@lobster.nni> Subject: (IPng 2837) Re: Some of the important boundaries in 8+8 To: narten@raleigh.ibm.com (Thomas Narten) Date: Mon, 13 Jan 1997 22:00:33 -0500 (EST) Cc: jhalpern@us.newbridge.com, ipng@sunroof.eng.sun.com In-Reply-To: <199701131308.IAA10268@hygro.raleigh.ibm.com> from "Thomas Narten" at Jan 13, 97 08:08:39 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am not suggesting that there would be two kinds of routers. All routers would be prepare to look at all eight bytes. (As Thomas rightly implies, anything else would be silly.) However, I am suggesting that something else he suggests would not be allowed. If the first six bytes of an address always relate to the point of connectivity of a site to a provider, then there is never any need to carry in the provider space any prefixes which stretch into the two bytes of customer space. In fact, the proposal is that providers will never advertise such address, ine the only reason to do so is when they are non-aggregateable, and we are tryig to beat entropy here. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 14 01:10:01 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05270; Tue, 14 Jan 97 01:10:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05264; Tue, 14 Jan 97 01:09:49 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA13756; Tue, 14 Jan 1997 01:01:18 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA18121 for ; Tue, 14 Jan 1997 01:01:17 -0800 Received: from shut.ticl.co.uk (shut.ticl.co.uk [193.32.1.3]) by gate.ticl.co.uk (8.7.4/8.7.3) with ESMTP id IAA06943; Tue, 14 Jan 1997 08:48:36 GMT Message-Id: <199701140848.IAA06943@gate.ticl.co.uk> From: "Peter Curran" To: "Frank T Solensky" , "Thomas Narten" Cc: Subject: (IPng 2838) Re: 8+8 Why ESDS are not globally Unique Date: Tue, 14 Jan 1997 08:57:36 -0000 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1160 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 > >>... If we believe factory addresses are unique then .. > > >There's been a few cases where bugs in someone's manufacturing process > >resulted in the factory addresses being non-unique. It was, of course, > >discovered The Hard Way. > > I've heard this statement made made several times, but the information > is always second hand. Do you (or anyone) have references to specific > examples of this? That is, how many duplicate addresses actually got > shipped, who were the manufacturers, were they all recalled, etc.? I > don't doubt that it _could_ happen, but I can't help but wonder if > there is also a bit of urban legend here as well. > Why don't we simply ask a couple of the major vendors - SMC, 3Com, etc. what the incidence of duplicate MAC address assignment is? Is there anybody from a NIC vendor listening in on this list? /peter ------------------------------------------------------------------------------ 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 Tue Jan 14 01:41:29 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05298; Tue, 14 Jan 97 01:41:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05292; Tue, 14 Jan 97 01:41:16 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA15554; Tue, 14 Jan 1997 01:32:45 -0800 Received: from relay-7.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA24291 for ; Tue, 14 Jan 1997 01:32:45 -0800 Received: from max073.frontier-networks.co.uk ([195.200.12.73]) by relay-6.mail.demon.net id aa602329; 14 Jan 97 9:11 GMT Message-Id: Date: Tue, 14 Jan 1997 08:30:32 +0000 To: ipng@sunroof.eng.sun.com From: Thomas Lee Subject: (IPng 2839) Re: larger AS/RD space for v6? In-Reply-To: <199701070932.SAA05919@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 X-Mailer: Turnpike Version 3.02 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk x-no-archive: yes In article <199701070932.SAA05919@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes >Let's face the issue and make renumbering easy. I've been listening to this, rapidly becoming bad-tempered, exchange for some days now. Just what is the issue that you wish to face? Is there a documment clearly stating the problem you're trying to solve? I must have missed it. Sorry for the intrusion on anotherwise interesting argument. Thomas -- Thomas Lee (email: tfl@psp.co.uk, web: http://www.psp.demon.co.uk/tfl/tfl.htm) Microsoft Certified Systems Engineer and Certified Trainer PS Partnership - A Microsoft Solution Provider Ph: +44 1628 850 077 Fax: +44 1628 850 143 ------------------------------------------------------------------------------ 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 Tue Jan 14 04:43:16 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05425; Tue, 14 Jan 97 04:43:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05419; Tue, 14 Jan 97 04:43:04 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA25168; Tue, 14 Jan 1997 04:34:32 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA27226 for ; Tue, 14 Jan 1997 04:34:33 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id FAA02270; Tue, 14 Jan 1997 05:33:51 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id FAA29746; Tue, 14 Jan 1997 05:33:51 -0700 (MST) Message-Id: <199701141233.FAA29746@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 14 Jan 1997 05:33:50 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 2840) Re: How to set source routing 1st hop LOOSE/STRICT in Advanced API ? Cc: Yoshinobu Inoue Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Jan 13, 10:29pm you write:] > > I have been trying to implement IPv6 source routing for ping using > Advanced API these days, and found that there seems to be no way to > specify source routing 1st hop's LOOSE/STRICT, at least as current > draft description. inet6_srcrt_add() can specify LOOSE/STRICT for 2nd > to 24th source routing hops which included in routing header, but > seems not to specify it for 1st hop which placed at IPv6 header's dst > addr field at first. There is an error in the advanced API draft (top of p. 25) where it says that "the destination address ... is the first hop". That should be "When a routing header is specified the destination address specified for connect(), sendto(), or sendmsg() is the final destination of the packet. The routing header contains only the intermediate hops." I believe that solves your problem. We are currently working on a new version of the draft that corrects this, and takes into account all the comments we've received over the past months. It should be ready within the next week or two. Rich Stevens ------------------------------------------------------------------------------ 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 Tue Jan 14 09:54:21 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05623; Tue, 14 Jan 97 09:54:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05542; Tue, 14 Jan 97 08:25:19 PST Received: from sunmail1.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA15002; Tue, 14 Jan 1997 08:16:46 -0800 Received: from sun.Eng.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id IAA18151; Tue, 14 Jan 1997 08:16:46 -0800 Received: from guitarman.nd.net.fujitsu.co.jp by sun.Eng.Sun.COM (4.1/SMI-4.1) id AA12636; Tue, 14 Jan 97 08:16:46 PST Received: from fdmmail.fujitsu.co.jp ([133.161.11.2]) by fujitsuI.fujitsu.com (8.7.5/8.7.3) with SMTP id IAA18963 for ; Tue, 14 Jan 1997 08:13:00 -0800 (PST) Received: from guitarman.nd.net.fujitsu.co.jp by fdmmail.fujitsu.co.jp (8.6.12+2.5Wb4/3.3W9-MX970108-Fujitsu Domain Mail Master) id BAA10221; Wed, 15 Jan 1997 01:12:57 +0900 Received: from guitarman (localhost [127.0.0.1]) by guitarman.nd.net.fujitsu.co.jp (8.7.4/8.6.9) with ESMTP id BAA20957; Wed, 15 Jan 1997 01:17:47 +0900 (JST) Message-Id: <199701141617.BAA20957@guitarman.nd.net.fujitsu.co.jp> To: rstevens@kohala.com Cc: sunroof.Eng.Sun.COM!ipng@Eng Subject: (IPng 2841) Re: How to set source routing 1st hop LOOSE/STRICT in Advanced API ? From: Yoshinobu Inoue In-Reply-To: Your message of "Tue, 14 Jan 1997 05:33:50 -0700" References: <199701141233.FAA29746@kohala.kohala.com> X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 15 Jan 1997 01:17:46 +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: rstevens@kohala.com (W. Richard Stevens) Subject: Re: (IPng 2831) How to set source routing 1st hop LOOSE/STRICT in Advanced API ? Date: Tue, 14 Jan 1997 05:33:50 -0700 > [In your message of Jan 13, 10:29pm you write:] > > > > I have been trying to implement IPv6 source routing for ping using > > Advanced API these days, and found that there seems to be no way to > > specify source routing 1st hop's LOOSE/STRICT, at least as current > > draft description. inet6_srcrt_add() can specify LOOSE/STRICT for 2nd > > to 24th source routing hops which included in routing header, but > > seems not to specify it for 1st hop which placed at IPv6 header's dst > > addr field at first. > > There is an error in the advanced API draft (top of p. 25) where it says > that "the destination address ... is the first hop". That should be > "When a routing header is specified the destination address specified > for connect(), sendto(), or sendmsg() is the final destination of the > packet. The routing header contains only the intermediate hops." > > I believe that solves your problem. Thank you for your reply. Then, may be my concern about 1st hop was very implementation specific thing. But now I have new concern about how to specify LOOSE/STRICT for last hop of source routing when it is specified by connect(), sendto(), or sendmsg(). My assumption is that if SO_DONTROUTE is specified with routing header, then last hop is STRICT, else last hop is LOOSE, and the flag(SO_DONTROUTE) is not for the 1st hop at that time. Is this right assumption?, or should new other flag is specified? Regards, -- Yoshinobu Inoue shin@nd.net.fujitsu.co.jp 2nd Development Department Network Division Fujitsu Limited ------------------------------------------------------------------------------ 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 Tue Jan 14 10:07:13 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05755; Tue, 14 Jan 97 10:07:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05749; Tue, 14 Jan 97 10:07:00 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA05262; Tue, 14 Jan 1997 09:58:23 -0800 Received: from ftp.com (ftp.com [128.127.2.122]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA18179 for ; Tue, 14 Jan 1997 09:58:25 -0800 Received: from ftp.com by ftp.com ; Tue, 14 Jan 1997 12:58:15 -0500 Received: from mailserv-2high.ftp.com by ftp.com ; Tue, 14 Jan 1997 12:58:15 -0500 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id MAA09666; Tue, 14 Jan 1997 12:58:18 -0500 Message-Id: <199701141758.MAA09666@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: narten@raleigh.ibm.com Cc: ipng@sunroof.eng.sun.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 2842) Re: 8+8 Why ESDS are not globally Unique Date: Tue, 14 Jan 1997 12:54:00 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Reply to your message of 1/13/97 9:37 PM > >>There's been a few cases where bugs in someone's manufacturing process >>resulted in the factory addresses being non-unique. It was, of course, >>discovered The Hard Way. > >I've heard this statement made made several times, but the information >is always second hand. Do you (or anyone) have references to specific >examples of this? That is, how many duplicate addresses actually got >shipped, who were the manufacturers, were they all recalled, etc.? Mine's first hand. At least one manufacturing run of a pretty large vendor at the time had transposed digits in their manufacturer code and collided with those of a very large vendor. The error affected "thousands" of cards says a co-worker; I'm pretty sure they weren't recalled but were replaced on request. This is back in the days when 40MB was a large hard disk: I'd be surprised if many of the cards, much less the PCs they were installed into, are still in use. Nevertheless, it happened. Since DAD allows one to recover from this, it's still needed for other media and has a relatively low overhead, leave it in. -- Frank ------------------------------------------------------------------------------ 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 Tue Jan 14 10:38:15 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05801; Tue, 14 Jan 97 10:38:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05795; Tue, 14 Jan 97 10:38:04 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA12120; Tue, 14 Jan 1997 10:29:30 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA02663 for ; Tue, 14 Jan 1997 10:29:19 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id LAA00388; Tue, 14 Jan 1997 11:29:02 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id LAA00270; Tue, 14 Jan 1997 11:29:01 -0700 (MST) Message-Id: <199701141829.LAA00270@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 14 Jan 1997 11:29:01 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Yoshinobu Inoue Subject: (IPng 2843) Re: How to set source routing 1st hop LOOSE/STRICT in Advanced API ? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Jan 15, 1:17am you write:] > To: rstevens@kohala.com > From: Yoshinobu Inoue > > > There is an error in the advanced API draft (top of p. 25) where it says > > that "the destination address ... is the first hop". That should be > > "When a routing header is specified the destination address specified > > for connect(), sendto(), or sendmsg() is the final destination of the > > packet. The routing header contains only the intermediate hops." > > > > I believe that solves your problem. > > But now I have new concern about how to specify LOOSE/STRICT for last > hop of source routing when it is specified by connect(), sendto(), or > sendmsg(). My assumption is that if SO_DONTROUTE is specified with > routing header, then last hop is STRICT, else last hop is LOOSE, and > the flag(SO_DONTROUTE) is not for the 1st hop at that time. > Is this right assumption?, or should new other flag is specified? Yoshinobu, First, I've not seen either of your messages on the IPng mailing list, so perhaps the UUCP-style address that's in your header is not working. You are right that there is still a problem. Rereading RFC 1883 Matt and I now see that in the worst case scenario src -> R1 -> R2 -> R3 -> ... -> R22 -> R23 -> dst there are 23 intermediate routers but 24 hops that require the loose/strict flag. But in the API there would be only 23 calls to inet6_srcrt_add(), for R1 through R23. The dst is still specified by the call to sendto(). We plan to add wording to the I-D that the call inet6_srcrt_add(ptr, Rn, flag) specifies the loose/strict flag for the hop leading *to* Rn. We will also add a new function inet6_srcrt_lasthop(ptr, flag) to let the user specify the loose/strict flag for the final hop. OK? We briefly thought of having inet6_srcrt_add(ptr, Rn, flag) specify the loose/strict flag for the hop leading *from* Rn and then specifying the loose/strict flag for the first hop by MSG_DONTROUTE, but this is counter- intuitive (to us, at least) in that we normally think of the loose/strict flag as pertaining *to* the hop, not from the hop. Also, this won't work (easily) with TCP where you cannot specify MSG_DONTROUTE with connect(), after specifying the source route. So we think the new inet6_srcrt_lasthop() function is better. Many thanks for the implementation feedback, Rich Stevens ------------------------------------------------------------------------------ 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 Tue Jan 14 13:51:44 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06237; Tue, 14 Jan 97 13:51:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06231; Tue, 14 Jan 97 13:51:28 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA21470; Tue, 14 Jan 1997 13:42:54 -0800 Received: from ncc.ripe.net (ncc.ripe.net [193.0.0.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA21307 for ; Tue, 14 Jan 1997 13:42:15 -0800 Received: from office.ripe.net by ncc.ripe.net with SMTP id AA08058 (5.65a/NCC-2.40); Tue, 14 Jan 1997 22:41:43 +0100 Message-Id: <9701142141.AA08058@ncc.ripe.net> To: Frank T Solensky Cc: ipng@sunroof.eng.sun.com From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: (IPng 2844) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Tue, 14 Jan 1997 12:54:00 EST." <199701141758.MAA09666@MAILSERV-2HIGH.FTP.COM> Date: Tue, 14 Jan 1997 22:41:42 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 14 Jan 1997 12:54:00 -0500 Frank T Solensky wrote: > Mine's first hand. At least one manufacturing run of a pretty large > vendor at the time had transposed digits in their manufacturer code > and collided with those of a very large vendor. The error affected > "thousands" of cards says a co-worker; I'm pretty sure they weren't > recalled but were replaced on request. An X terminal I worked with allowed one to set the ethernet address, on the same menu as IP address, subnet mask, and default. I leave it to your imagination what can go wrong. Many of the current PC ethernet cards I know of allow one to change the ethernet address, even if that isn't advertized (it is usually stored in a 93C46 EEPROM or somesorts, next to the I/O address, IRQ and media selection; these EEPROMs sometimes get zapped or changed) Should I show how to change the ethernet address in a SUN4c machine? It's only 5 minutes work. Phil Karn reported that in the past, he had bought a clone ethernet card where the manufacturer hadn't bothered to apply for an official MAC prefix but had picked one himself. This was actually worse because the LSB of the first byte was 1, i.e. the ethernetcards shipped with 'multicast' ethernet addresses (there is still some code in the CRYNWR packet driver set to resolve this). > Since DAD allows > one to recover from this, it's still needed for other media and has > a relatively low overhead, leave it in. Yes! Geert Jan ------------------------------------------------------------------------------ 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 Tue Jan 14 16:02:38 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09025; Tue, 14 Jan 97 16:02:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08994; Tue, 14 Jan 97 16:02:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA16948; Tue, 14 Jan 1997 15:53:45 -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 PAA06717 for ; Tue, 14 Jan 1997 15:53:44 -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 PAA12289; Tue, 14 Jan 1997 15:53:40 -0800 Message-Id: <3.0.32.19970114155255.00752048@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 14 Jan 1997 15:52:57 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 2845) Location for the Interim IPng Working Group Meeting Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sun Microsystems will be hosting the IPng interim meeting on Feb 27 and 28th. The meeting will be at their Palo Alto site (which is just north of Mountain View). Directions and hotel information will be sent out tomorrow. Bob >Date: Fri, 20 Dec 1996 15:26:56 -0800 >To: ipng@sunroof.Eng.Sun.COM >From: Bob Hinden >Subject: (IPng 2637) Interim IPng Working Group Meeting >Cc: hinden@Ipsilon.COM, deering@cisco.com, deering@parc.xerox.com >Sender: owner-ipng@sunroof.Eng.Sun.COM > >The IPng working group will hold an interim working group meeting on > > Feb 27 and 28, 1997 > >in the San Francisco bay area. This is the Thursday and Friday prior to the >IPv6 testing at Connectethon. The meeting location and hotel information >will be sent out in early January. > >The main agenda topic will be a detailed discussion on Mike O'Dells 8+8 >proposal. This is described in which can be found >in the internet draft directories. > >Please RSVP so we can make sure the meeting facility is adequate. We hope >to also have the meeting broadcast on the MBONE. > >Bob Hinden / Steve Deering >IPng Working Group Co-Chairs > ------------------------------------------------------------------------------ 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 Tue Jan 14 21:17:18 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21106; Tue, 14 Jan 97 21:17:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21100; Tue, 14 Jan 97 21:17:05 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA23519; Tue, 14 Jan 1997 21:08:31 -0800 Received: from infobro.com (ns.infobro.com [204.255.254.70]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA22643 for ; Tue, 14 Jan 1997 21:08:33 -0800 Received: from red (153.34.50.101) by infobro.com (EMWAC SMTPRS 0.81) with SMTP id ; Wed, 15 Jan 1997 00:08:30 -0500 Message-Id: From: "Eric D. Williams" To: "Frank T Solensky" , "Geert Jan de Groot" Cc: Subject: (IPng 2846) Re: 8+8 Why ESDS are not globally Unique Date: Wed, 15 Jan 1997 00:06:04 -0500 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 I remember this same issue early on during the addressing architecture debates TUBA, SIP, P ... Frank you brought it up then and are still right on the money. Until we find a way to stop ole' Murphy's postulates from coming to pass we should keep DAD as a recovery mechanism. ---------- > On Tue, 14 Jan 1997 12:54:00 -0500 Frank T Solensky wrote: > > Mine's first hand. At least one manufacturing run of a pretty large > > vendor at the time had transposed digits in their manufacturer code > > and collided with those of a very large vendor. The error affected > > "thousands" of cards says a co-worker; I'm pretty sure they weren't > > recalled but were replaced on request. > > An X terminal I worked with allowed one to set the ethernet address, > on the same menu as IP address, subnet mask, and default. > I leave it to your imagination what can go wrong. > > Many of the current PC ethernet cards I know of allow one to change > the ethernet address, even if that isn't advertized (it is usually > stored in a 93C46 EEPROM or somesorts, next to the I/O address, > IRQ and media selection; these EEPROMs sometimes get zapped or > changed) > Should I show how to change the ethernet address in a SUN4c machine? > It's only 5 minutes work. Oh so true. And this little bugger can also hose an Ethernet switch in half the time, allowing MAC spoofing of almost any (scratch most firewalls) directly connected system. > Phil Karn reported that in the past, he had bought a clone ethernet card > where the manufacturer hadn't bothered to apply for an official MAC > prefix but had picked one himself. This was actually worse because > the LSB of the first byte was 1, i.e. the ethernetcards shipped with > 'multicast' ethernet addresses (there is still some code in the > CRYNWR packet driver set to resolve this). > > > Since DAD allows > > one to recover from this, it's still needed for other media and has > > a relatively low overhead, leave it in. > YES YES YES Eric Williams, Pres. http://infobro.com/Black/InfoBro1.htm Information Brokers, Inc. Phone: +1 202.678.5377 http://www.infobro.com/ Fax: +1 301.441.1116 mailto:eric@infobro.com Info: info@infobro.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 Wed Jan 15 06:36:07 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21467; Wed, 15 Jan 97 06:36:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21461; Wed, 15 Jan 97 06:35:56 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA27349; Wed, 15 Jan 1997 06:27:23 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA14102 for ; Wed, 15 Jan 1997 06:27:23 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA29871; Wed, 15 Jan 1997 09:06:39 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23662; Wed, 15 Jan 1997 09:06:34 -0500 Message-Id: <9701151406.AA23662@wasted.zk3.dec.com> To: Frank T Solensky Cc: narten@raleigh.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 2847) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Tue, 14 Jan 97 12:54:00 EST." <199701141758.MAA09666@MAILSERV-2HIGH.FTP.COM> Date: Wed, 15 Jan 97 09:06:33 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Frank/Tom, I also got the attached privately too. I asked if there is violent objection...I think its not just a pipe dream or urban legend. /jim ------------------------------------- To: bound@zk3.dec.com Date: Mon, 13 Jan 1997 13:06:22 -0800 (PST) In-Reply-To: <9701131950.AA09318@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Jan 13, 97 02:50:52 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit bound@zk3.dec.com says: > >If you are referring to Duplicate Address Detection, I believe the reason > >we included that function was because of the duplication risks that arise > >when addresses are generated using something *other* than MAC addresses, > >e.g., when using manual configuration or using address-assignment servers > >like DHCPv6 that might have failure modes that result in duplicates. If we > >always generated IPv6 addresses from MAC addresses, I don't think that DAD > >would be worth the extra code and spec complexity (at least not for those > >media that use factory-provided MAC addresses). > > I actually agree with you. But it was my recollection that most of the > addr conf WG from the beginning were driven by some evil that we could > run into from 802.X. I believe 802.X is unique enough and always have > but thought I was wrong from our IPng process. If we believe factory > addresses are unique then that makes 8+8 much more doable and moves the > discussion to other areas???? For me anyway. But would like to see > that folks don't violently object to your mail or my response..... > I can still question DAD, but will just leave it be as we implemented it > and it seems to not eat up anything to much or precious. There is a Taiwanese company that creates Ethernet cards, by the name of "Enet-16", which have to be set up with a MAC address by the user. I wish I could say they are few and far between, but I've been running into them often enough in my consulting endeavours that they're hard to ignore. Thus, it's not even safe to assume that Ethernet MACs are all that unique. The most common addresses I've run into have been a linear increasing monotonic sequence that starts at "0:0:0:0:0:1" ... :-) -scottm ----------------------------------------------------- ------------------------------------------------------------------------------ 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 Wed Jan 15 07:50:54 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21510; Wed, 15 Jan 97 07:50:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21504; Wed, 15 Jan 97 07:50:42 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA06437; Wed, 15 Jan 1997 07:42:09 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA08938 for ; Wed, 15 Jan 1997 07:42:08 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA31022; Wed, 15 Jan 1997 10:18:16 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA07380; Wed, 15 Jan 1997 10:18:12 -0500 Message-Id: <9701151518.AA07380@wasted.zk3.dec.com> To: deering@cisco.com Cc: "Frank T Solensky" , "Geert Jan de Groot" , , "Eric D. Williams" Subject: (IPng 2848) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Wed, 15 Jan 97 00:06:04 EST." Date: Wed, 15 Jan 97 10:18:12 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, It seems to me that when we did addrconf I was right in my initial assumption that people don't trust factory or 802.2 addresses and this mail is again convincing me I was WRONG to ever believe they were globally unique. Has it affect you at this point????? There is no question we need DAD simply because of this mail in addition to the other cases of getting addresses (e.g. Manual, DHCPv6). If these are not globally unqiue then I think it affects greatly how we approach 8+8 and view it. /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 Wed Jan 15 08:09:44 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21638; Wed, 15 Jan 97 08:09:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21632; Wed, 15 Jan 97 08:09:30 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA08795; Wed, 15 Jan 1997 08:00:57 -0800 Received: from lynx.europe.shiva.com (lynx.spider.co.uk [134.191.64.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA15365 for ; Wed, 15 Jan 1997 08:00:55 -0800 Received: from chryses.europe.shiva.com (chryses.europe.shiva.com [89.0.0.223]) by lynx.europe.shiva.com (8.8.4/8.8.3) with ESMTP id QAA21854 for ; Wed, 15 Jan 1997 16:00:52 GMT Received: from black.europe.shiva.com (black.europe.shiva.com [134.191.8.140]) by chryses.europe.shiva.com (8.8.4/8.8.3) with SMTP id QAA29763 for ; Wed, 15 Jan 1997 16:00:52 GMT Received: from localhost by black.europe.shiva.com (SMI-8.6/SMI-SVR4) id QAA29446; Wed, 15 Jan 1997 16:00:51 GMT Date: Wed, 15 Jan 1997 16:00:51 +0000 (GMT) From: Malcolm Campbell To: ipng@sunroof.eng.sun.com Subject: (IPng 2849) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: <9701151518.AA07380@wasted.zk3.dec.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 15 Jan 1997 bound@zk3.dec.com wrote: > It seems to me that when we did addrconf I was right in my initial > assumption that people don't trust factory or 802.2 addresses and this > mail is again convincing me I was WRONG to ever believe they were > globally unique. Another point of experience - I once got a 10-pack of ethernet cards from a vendor who shall remain nameless, and they all had the same MAC address. But apart from that one experience, Ive no other personal experience of duplicates. But Ive heard a lot of anecdotes.. ------------------------------------------------------------------------------ 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 Wed Jan 15 10:43:00 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21896; Wed, 15 Jan 97 10:43:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21890; Wed, 15 Jan 97 10:42:48 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA07289; Wed, 15 Jan 1997 10:34:14 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA07908 for ; Wed, 15 Jan 1997 10:34:15 -0800 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 KAA02162; Wed, 15 Jan 1997 10:30:28 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <9701151518.AA07380@wasted.zk3.dec.com> References: Your message of "Wed, 15 Jan 97 00:06:04 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jan 1997 10:30:26 -0800 To: bound@zk3.dec.com From: Steve Deering Subject: (IPng 2850) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bound@zk3.dec.com wrote: > It seems to me that when we did addrconf I was right in my initial > assumption that people don't trust factory or 802.2 addresses and this > mail is again convincing me I was WRONG to ever believe they were > globally unique. > > Has it affect you at this point????? Yes, this has been a useful elicitation of information (thanks, Thomas!). It is now clearer that DAD is a useful safety mechanism to detect collisons of factory assigned 802 adresses, as well as the other ways that duplicate addresses can be created by mistake (such as manual configuration of IPv6 addresses or MAC addresses, or DHCP inconsistencies). The question now is what are the consequences, vis a vis 8+8. Clearly, duplicates appearing on the same link can be detected by DAD and eliminated. But what about duplicates appearing on different links? How likely is it that a single node will engage in conversations with two other non-neighbor nodes with the same MAC address? If that occurs, will it be diagnosable and possible to remedy? Is this believed to be an issue whose relevance is rapidly declining, or is it likely to grow (i.e., are the shady Ethernet vendors going out of business, or are they multiplying?)? I'd really hate to give up stateless autoconfig for the sake of ESD uniqueness assurance, and I'm queasy about trying to fit both a routing hierarchy and an ESD-assignment hierarchy into 16 minus 6 bytes. 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 Wed Jan 15 11:05:24 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21978; Wed, 15 Jan 97 11:05:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21972; Wed, 15 Jan 97 11:05:10 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA12458; Wed, 15 Jan 1997 10:56:36 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA14317 for ; Wed, 15 Jan 1997 10:56:35 -0800 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 KAA03975; Wed, 15 Jan 1997 10:55:48 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <2.2c.32.19970114030122.00ab3660@pobox.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jan 1997 10:55:47 -0800 To: Dimitry Haskin From: Steve Deering Subject: (IPng 2851) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry Haskin wrote: > Agreed -- 4 bytes seems the right size for the ESD hierarchy. I don't think so! When evaluating whether or not a 64-bit address would have been big enough for IPng (as part of the SIP work), several analyses came to the conclusion that we might need closer to 48 bits (6 bytes) of hierarchically-structured prefix to identify all the possible sites in the world 30-40 years from now (e.g., assuming every home and workplace became an Intenet site, which is a plausible assumption); the 64-bit SIP address would then have allowed each site to have the equivalent of a Class B's worth of address space (with really large sites getting multiple site prefixes to increase that space). This was taking into account the inefficiencies of hierarchical encoding with manual delegation, which I believe is what you are advocating for ESD prefixes. 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 Wed Jan 15 11:42:43 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22095; Wed, 15 Jan 97 11:42:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22089; Wed, 15 Jan 97 11:42:32 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA20794; Wed, 15 Jan 1997 11:33:55 -0800 Received: from digi-data.com ([196.32.33.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA00526 for ; Wed, 15 Jan 1997 11:33:44 -0800 Received: by odin.digi-data.com id <19600>; Wed, 15 Jan 1997 15:32:12 -0400 Date: Wed, 15 Jan 1997 19:34:22 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi Data Systems, Limited X-Mailer: Mozilla 3.0Gold (WinNT; I) Mime-Version: 1.0 To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2852) Re: 8+8 Why ESDS are not globally Unique References: Your message of "Wed, 15 Jan 97 00:06:04 EST." Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <97Jan15.153212gmt-0400.19600@odin.digi-data.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Steve, I am new on this mailing list and have just been lurking for a couple of months now listening in on the very enlightening exchanges but I want to deal with one aspect of your message: > The question now is what are the consequences, vis a vis 8+8. Clearly, >duplicates appearing on the same link can be detected by DAD and >eliminated. But what about duplicates appearing on different links? If there should be duplicates on different links then it would seem that the two different nodes would have the same ESD value and yet have different RG values. That may not be very easy to detect because the two nodes would have to have transmitted a packet within a short time of each other and both to the same destination address or to each other, an event with a very low probability. The problem that would arise here concerns the routing infrastructure. Consider this: Two very active nodes (nodes 1 and node 2) with identical ESDs happen to be configured in two topological regions of the network for which the RGs are not identical. Let the RG of node 1 be RG1 and let the RG of node 2 be RG2. We then have the situation where a node whose address would be RG1:ESD and another node whose address would be RG2:ESD. Now consider a node (node 3) that knows or has a need to reach nodes of either or both regions and it is preparing a packet to send to node 1. If my understanding of 8+8 is correct then node 3 might not know the value of RG1 (as it can be changed in flight anyway). My questions in this instance are: once the packet leaves node 3's local link, how do we know which way to forward it? Can we send the packet both ways, or should an error message be returned. Can we rely on some additional information like the hostname or other DNS information to determine the correct path to get the packet to node 1 from node 3? Are there any special security implications/issues in doing so? >How likely is it that a single node will engage in conversations with >two other non-neighbor nodes with the same MAC address? If that occurs, >will it be diagnosable and possible to remedy? It may not be diagnosable because ICMP error messages will go to the sender node if we have a situation as above involving nodes 1, 2 and 3. -- Just my $0.02 worth, Robert Honore robert@digi-data.com Phone: 623 6658 Fax: 623 0978 Snail Mail: Digi Data systems limited, 96 Wrightson Road, Trinidad, W. I. > Take care of what IS. The APPEARANCES will take care of themselves. ------------------------------------------------------------------------------ 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 Wed Jan 15 11:57:43 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22155; Wed, 15 Jan 97 11:57:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22149; Wed, 15 Jan 97 11:57:31 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA23915; Wed, 15 Jan 1997 11:48:59 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA07094 for ; Wed, 15 Jan 1997 11:48:53 -0800 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 LAA07292; Wed, 15 Jan 1997 11:48:09 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: References: Your message of "Thu, 09 Jan 1997 10:44:04 +0100." <9701090944.AA22964@dxcoms.cern.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jan 1997 11:48:07 -0800 To: "Mike O'Dell" From: Steve Deering Subject: (IPng 2853) 8+8 terminology Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, I hope this message doesn't trigger a long, distracting thread on terminology, but I wonder if you could clear up a few things for me? I know you decided to coin new terms in order to avoid the baggage associated with existing terms, but I am puzzled by a couple of your choices: (1) "End System Designator" (ESD) seems wrong in at least two ways: (a) They are not used solely for End Systems (hosts), but are also used to identify Intermediate Systems (routers). (This is an example of ISO terminology baggage). (b) According to your document and your professed preference, they identify interfaces, not systems. Shouldn't they be called Interface Designators? (Yeah, you wouldn't want to abbreviate that to "IDs", but how about "IFDs"?) (2) Why Routing Goop, rather than Locator Goop or Locating Goop? The goop specifies *where* something is in the topology (its location), not *how to get there* (a route). 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 Wed Jan 15 12:45:16 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22444; Wed, 15 Jan 97 12:45:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22438; Wed, 15 Jan 97 12:44:59 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA03239; Wed, 15 Jan 1997 12:36:26 -0800 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA27070 for ; Wed, 15 Jan 1997 12:36:23 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id MAA08282 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id MAA22024 Posted-Date: Wed, 15 Jan 1997 12:35:46 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id PAA28870; Wed, 15 Jan 1997 15:35:46 -0500 for Date: Wed, 15 Jan 1997 15:35:46 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701152035.PAA28870@pobox.engeast.BayNetworks.COM> To: deering@cisco.com Subject: (IPng 2854) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > > Dimitry Haskin wrote: > > > Agreed -- 4 bytes seems the right size for the ESD hierarchy. > > I don't think so! When evaluating whether or not a 64-bit address would > have been big enough for IPng (as part of the SIP work), several analyses > came to the conclusion that we might need closer to 48 bits (6 bytes) of > hierarchically-structured prefix to identify all the possible sites in the > world 30-40 years from now (e.g., assuming every home and workplace became > an Intenet site, which is a plausible assumption); the 64-bit SIP address > would then have allowed each site to have the equivalent of a Class B's > worth of address space (with really large sites getting multiple site > prefixes to increase that space). This was taking into account the > inefficiencies of hierarchical encoding with manual delegation, which > I believe is what you are advocating for ESD prefixes. > To be precise I wasn't advocating but merely suggesting it ;) I'm wondering if that analyses assumed that ESD prefixes would be also used for hierarchical routing in addition to their identification purpose. I suspect that if we remove routing considerations from the equation, the ESD space can be used much more efficiently. It will not be necessary to allocate a single large contiguous block of prefixes to each site. In any event, I believe that ensuring global uniqueness of ESD is critical for the 8+8 proposal to survive and MAC-based allocation is not that going to provide that. > Steve 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 Wed Jan 15 12:49:00 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22457; Wed, 15 Jan 97 12:49:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22450; Wed, 15 Jan 97 12:48:46 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA03965; Wed, 15 Jan 1997 12:40:13 -0800 Received: from snoopy.agile.com ([198.3.105.68]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA28703; Wed, 15 Jan 1997 12:40:10 -0800 Received: by snoopy.agile.com with Microsoft Exchange (IMC 4.0.837.3) id <01BC02F7.B770EC60@snoopy.agile.com>; Wed, 15 Jan 1997 15:21:01 -0500 Message-Id: From: "Conta, Alex" To: "'Mike O'Dell'" , "'owner-ipng@sunroof.Eng.Sun.COM'" Cc: "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 2855) RE: 8+8 terminology Date: Wed, 15 Jan 1997 15:21:00 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mike, > > I hope this message doesn't trigger a long, distracting thread on > terminology, but I wonder if you could clear up a few things for me? I know > you decided to coin new terms in order to avoid the baggage associated with > existing terms, but I am puzzled by a couple of your choices: > .... > Steve > > Mike, Since I had this on my mind for quite a while... and I would have sent this out regardless of Steve's message... Jim Bound spent the time to send out a list of IPv6 documents that may be affected by adopting the 8+8 proposal - thanks Jim. Long, scary list..., and it is getting longer... To minimize the impact on all the documents, I would feel much more comfortable if the next version of the 8+8 draft would use existent IPv6 terminology - several IPv6 documents already on standards track have long lists with "terms" definitions. I know it may be fun inventing new or "cute" names, but it will make your draft more consistent with the rest of the IPv6 documents, and terms, and also the process of assimilating or reviewing it easier. Thanks, Alex ------------------------------------------------------------------------------ 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 Wed Jan 15 12:56:21 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22473; Wed, 15 Jan 97 12:56:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22467; Wed, 15 Jan 97 12:56:09 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA05306; Wed, 15 Jan 1997 12:47:36 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA01749 for ; Wed, 15 Jan 1997 12:47:31 -0800 Received: from shut.ticl.co.uk (shut.ticl.co.uk [193.32.1.3]) by gate.ticl.co.uk (8.7.4/8.7.3) with ESMTP id UAA09714; Wed, 15 Jan 1997 20:33:26 GMT Message-Id: <199701152033.UAA09714@gate.ticl.co.uk> From: "Peter Curran" To: , "Steve Deering" Cc: Subject: (IPng 2856) Re: 8+8 Why ESDS are not globally Unique Date: Wed, 15 Jan 1997 20:42:30 -0000 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1160 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 > > Yes, this has been a useful elicitation of information (thanks, Thomas!). > It is now clearer that DAD is a useful safety mechanism to detect collisons > of factory assigned 802 adresses, as well as the other ways that duplicate > addresses can be created by mistake (such as manual configuration of IPv6 > addresses or MAC addresses, or DHCP inconsistencies). The question now > is what are the consequences, vis a vis 8+8. Clearly, duplicates appearing > on the same link can be detected by DAD and eliminated. But what about > duplicates appearing on different links? How likely is it that a single > node will engage in conversations with two other non-neighbor nodes with the > same MAC address? If that occurs, will it be diagnosable and possible to > remedy? Is this believed to be an issue whose relevance is rapidly > declining, or is it likely to grow (i.e., are the shady Ethernet vendors > going out of business, or are they multiplying?)? > This may be a major misconception on my part, but I don't understand how this scheme will work in the context of reverse DNS. May be I need to look at the 8+8 proposal documentation again, but I sort of assumed that we would do a reverse DNS query on the basis of the ESD alone. In that case, how do we get around global address collisions? Also, whilst DAD will find a duplicate on the local link, I am not clear what we do when that happens. Do we just grab a random number? > I'd really hate to give up stateless autoconfig for the sake of ESD > uniqueness assurance, and I'm queasy about trying to fit both a routing > hierarchy and an ESD-assignment hierarchy into 16 minus 6 bytes. > I think the above is a given/essential. One of the main selling points of IPv6 from the intranet perspective is autoconfiguration. If we get this right then the takeup of v6 could be very rapid (speaking from the perspective of somebody who brushes up against the manual configuration problems of large networks frequently). ------------------------------------------------------------------------------ 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 Wed Jan 15 13:36:35 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00199; Wed, 15 Jan 97 13:36:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00155; Wed, 15 Jan 97 13:36:15 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA12888; Wed, 15 Jan 1997 13:27:41 -0800 From: bound@ZK3.DEC.COM Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA17651 for ; Wed, 15 Jan 1997 13:27:35 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA26801; Wed, 15 Jan 1997 16:12:48 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA04056; Wed, 15 Jan 1997 16:12:42 -0500 Message-Id: <9701152112.AA04056@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2857) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Wed, 15 Jan 97 10:30:26 PST." Date: Wed, 15 Jan 97 16:12:41 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >I'd really hate to give up stateless autoconfig for the sake of ESD >uniqueness assurance, and I'm queasy about trying to fit both a routing >hierarchy and an ESD-assignment hierarchy into 16 minus 6 bytes. What do you mean on "giving up on stateless addrconf" above? 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 Wed Jan 15 13:51:05 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00220; Wed, 15 Jan 97 13:51:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00214; Wed, 15 Jan 97 13:50:54 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA15589; Wed, 15 Jan 1997 13:42:20 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA23232 for ; Wed, 15 Jan 1997 13:42:12 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA26782; Wed, 15 Jan 1997 16:20:48 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16957; Wed, 15 Jan 1997 16:20:42 -0500 Message-Id: <9701152120.AA16957@wasted.zk3.dec.com> To: robert@digi-data.com Cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: (IPng 2858) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Wed, 15 Jan 97 19:34:22 -0400." <97Jan15.153212gmt-0400.19600@odin.digi-data.com> Date: Wed, 15 Jan 97 16:20:42 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Two very active nodes (nodes 1 and node 2) with identical ESDs happen >to be configured in two topological regions of the network for which the >RGs are not identical. Let the RG of node 1 be RG1 and let the RG of >node 2 be RG2. We then have the situation where a node whose address >would be RG1:ESD and another node whose address would be RG2:ESD. Now >consider a node (node 3) that knows or has a need to reach nodes of >either or both regions and it is preparing a packet to send to node 1. >If my understanding of 8+8 is correct then node 3 might not know the >value of RG1 (as it can be changed in flight anyway). My questions in >this instance are: once the packet leaves node 3's local link, how do we >know which way to forward it? Can we send the packet both ways, or >should an error message be returned. Can we rely on some additional >information like the hostname or other DNS information to determine the >correct path to get the packet to node 1 from node 3? Are there any >special security implications/issues in doing so? This is why I keep asking Mike O'dell if the application when obtaining the address from gethostbyname2() will get a complete address (location and identifcation) from DNS in his vision. There by making it unecessary to alter the dst address from a site. This means the RG is known when it leaves the host. It also means we are only talking about source addresses using the transit packet changes. I hope Mike responds to this question soon. Its key to our discussion of his proposal. It also implies other things but would like to get an answer to this one. Mike ??????????????? /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 Wed Jan 15 14:06:14 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00262; Wed, 15 Jan 97 14:06:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00256; Wed, 15 Jan 97 14:06:03 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA19139; Wed, 15 Jan 1997 13:57:29 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA29314 for ; Wed, 15 Jan 1997 13:57:27 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA29306; Wed, 15 Jan 1997 16:40:14 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19994; Wed, 15 Jan 1997 16:40:11 -0500 Message-Id: <9701152140.AA19994@wasted.zk3.dec.com> To: "Peter Curran" Cc: , "Steve Deering" , Subject: (IPng 2859) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Wed, 15 Jan 97 20:42:30 GMT." <199701152033.UAA09714@gate.ticl.co.uk> Date: Wed, 15 Jan 97 16:40:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, >This may be a major misconception on my part, but I don't understand how >this scheme will work in the context of reverse DNS. May be I need to look >at the 8+8 proposal documentation again, but I sort of assumed that we >would do a reverse DNS query on the basis of the ESD alone. In that case, >how do we get around global address collisions? Exactly. I think if a node has multiple RGs then it will have to have multiple PTR records. This can present a problem but I think its doable. I am diligently looking at the BIND code now and trying to understand ramifications for the Interim meeting and the autoconfig stuff we have already built and the APIs. All of this IMHO MUST continue to work and cannot be broken, without more data on 8+8 like Mike's next draft. Lots of questions needing answers. One way to look for an ESD too is to attach RG meta records to it via pointers. This would cause reverse look ups to be created on the fly which is not good, but would be useful for a lookup on a host name to get a complete address RG + ESD. So the PTR records could be built on the fly in a similar manner. But this is not even close to life today. DNS is a major issue to resolve for 8+8. >Also, whilst DAD will find a duplicate on the local link, I am not clear >what we do when that happens. Do we just grab a random number? Report a system error on your console. UNH: We should force this error somehow at Connectathon to see what implementations do..... >> I'd really hate to give up stateless autoconfig for the sake of ESD >> uniqueness assurance, and I'm queasy about trying to fit both a routing >> hierarchy and an ESD-assignment hierarchy into 16 minus 6 bytes. >I think the above is a given/essential. One of the main selling points of >IPv6 from the intranet perspective is autoconfiguration. If we get this >right then the takeup of v6 could be very rapid (speaking from the >perspective of somebody who brushes up against the manual configuration >problems of large networks frequently). I just asked Steve what he mean't by that and I hope that its something else than you suggest --->... Your 1000% correct and we CANNOT give up stateless addrconf. And I have found first hand customers who are seriously thinking about going to IPv6 on their Intranet now because of autoconfig both stateless and stateful in IPv6. But I don't see how Mike's ESD would obviate stateless addrconf. You still need the PT bits and also whether to use stateless or stateful. Plus if 8+8 gets past discussion stage and to serious implementation stage if its wrong we want to not loose RFC 1971. /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 Wed Jan 15 14:21:24 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00334; Wed, 15 Jan 97 14:21:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00328; Wed, 15 Jan 97 14:21:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA22212; Wed, 15 Jan 1997 14:12:33 -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 OAA04963 for ; Wed, 15 Jan 1997 14:12:00 -0800 Received: from gungnir.fnal.gov ("port 38391"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IE8XRC2DLS000VRY@FNAL.FNAL.GOV> for ipng@sunroof.Eng.Sun.COM; Wed, 15 Jan 1997 16:10:48 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA18734; Wed, 15 Jan 1997 16:10:47 -0600 Date: Wed, 15 Jan 1997 16:10:47 -0600 From: Matt Crawford Subject: (IPng 2860) Why ESDs *need* not be globally unique To: ipng@sunroof.eng.sun.com Message-Id: <199701152210.QAA18734@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 (4.1/SMI-4.1) id AA00446; Wed, 15 Jan 97 14:57:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00436; Wed, 15 Jan 97 14:57:17 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA29234; Wed, 15 Jan 1997 14:48:42 -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 OAA19239 for ; Wed, 15 Jan 1997 14:48:40 -0800 Received: from gungnir.fnal.gov ("port 38405"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IE8Z3327W6000VRY@FNAL.FNAL.GOV>; Wed, 15 Jan 1997 16:48:31 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA20214; Wed, 15 Jan 1997 16:48:29 -0600 Date: Wed, 15 Jan 1997 16:48:29 -0600 From: Matt Crawford Subject: (IPng 2861) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: "15 Jan 1997 16:20:42 EST." <"9701152120.AA16957"@wasted.zk3.dec.com> To: bound@zk3.dec.com Cc: robert@digi-data.com, ipng@sunroof.eng.sun.com Message-Id: <199701152248.QAA20214@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{ This is why I keep asking Mike O'dell if the application when obtaining > the address from gethostbyname2() will get a complete address (location > and identifcation) from DNS in his vision. There by making it > unecessary to alter the dst address from a site. This means the RG is > known when it leaves the host. I don't mean to be a smart-aleck, but I thought that, if there were any "obvious" points about the draft, this was one of them. Of course you get the full destination address from DNS, and insert it in your outgoing packet. Any other scheme is unworkable. (And my idea of "workable" tends to be on the liberal side.) _________________________________________________________ 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 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 Wed Jan 15 16:22:07 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00732; Wed, 15 Jan 97 16:22:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00716; Wed, 15 Jan 97 16:08:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA12016; Wed, 15 Jan 1997 16:00:06 -0800 From: jam@iol.unh.edu Received: from ragnar.iol.unh.edu (ragnar.iol.unh.edu [132.177.118.29]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA16228 for ; Wed, 15 Jan 1997 15:59:50 -0800 Received: by ragnar.iol.unh.edu (5.65v3.2/1.1.10.5/01Nov96-0252PM) id AA31643; Wed, 15 Jan 1997 18:57:17 -0500 Date: Wed, 15 Jan 1997 18:57:17 -0500 Message-Id: <9701152357.AA31643@ragnar.iol.unh.edu> To: bound@zk3.dec.com Cc: Subject: (IPng 2862) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: <9701152140.AA19994@wasted.zk3.dec.com> References: <199701152033.UAA09714@gate.ticl.co.uk> <9701152140.AA19994@wasted.zk3.dec.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bound@zk3.dec.com writes: > > UNH: We should force this error somehow at Connectathon to see what > implementations do..... Jim, When we held our first testing event, those implementations which supported DAD simply disabled the corresponding interface once a duplicate was detected. Jeremy -- | Jeremy McCooey | jam@iol.unh.edu | | UNH InterOperability Laboratory | 603-862-0090 | ------------------------------------------------------------------------------ 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 Wed Jan 15 17:18:05 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00978; Wed, 15 Jan 97 17:18:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00972; Wed, 15 Jan 97 17:17:53 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA27337; Wed, 15 Jan 1997 17:09:20 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA12826 for ; Wed, 15 Jan 1997 17:09:18 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id KAA03447 for ; Thu, 16 Jan 1997 10:09:07 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id AAA03574; Thu, 16 Jan 1997 00:58:55 GMT To: ipng@sunroof.eng.sun.com Subject: (IPng 2863) Forward: hlim and IF on API X-Mailer: Mew version 1.54 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Jan_16_09:58:50_1997)--" Content-Transfer-Encoding: 7bit Date: Thu, 16 Jan 1997 09:58:55 +0900 Message-Id: <3571.853376335@mine.aist-nara.ac.jp> From: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----Next_Part(Thu_Jan_16_09:58:50_1997)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I posted the following message in the end of last year. Probably many people missed it due to Christmas vacation. I would like to hear your comments. In addition to the suggestions below, I have one more suggestion to the basic API. It defines inet_pton() and inet_ntop() and they supports AF_INET and INET6 only. With my implemenation experience of "netstat", "route", etc, I think these functions should be more generic. For example, define "pton()" and "ntop()" and support AF_NS, AF_ISO, etc as well. I believe such functions make some commands more simple. --Kazu ----Next_Part(Thu_Jan_16_09:58:50_1997)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with SMTP id KAA07194 for ; Tue, 24 Dec 1996 10:30:10 +0900 Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA29548; Mon, 23 Dec 1996 17:28:22 -0800 Received: from sunroof.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA08544; Mon, 23 Dec 1996 17:28:15 -0800 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27969; Mon, 23 Dec 96 17:33:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27963; Mon, 23 Dec 96 17:32:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA19175; Mon, 23 Dec 1996 17:24:52 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA10497 for ; Mon, 23 Dec 1996 17:24:50 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id KAA06686 for ; Tue, 24 Dec 1996 10:24:47 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id KAA02522; Mon, 23 Dec 1996 10:19:59 GMT To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 2647) hlim and IF on API Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mew version 1.54 on Emacs 19.28.2, Mule 2.3 Date: Mon, 23 Dec 1996 19:19:59 +0900 Message-Id: <2519.851336399@mine.aist-nara.ac.jp> From: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, I have several questions and suggestions concerned with hop-limit and IF selection. (1) Hop Limit IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS are defined on the basic API draft. Are there any strong reasons to separate them? NDP and RIPng requires to set hop-limit 255. But I believe that it is very good idea to set hop-limit 255 for all on-link communication. Are there any problem if the basic IPv6 spec requires it? (2) IF The basic API draft defines IPV6_MULTICAST_IF whereas the advanced API makes it possible to select an IF with sendmsg(). If they conflicts(e.g. select IF_1 with setsockopt() then sendmsg() to IF_2), how should it work? Moreover, if the SO_DONTROUTE option is specified, what will happen? sendmsg() successes only when the destination is link-local-used address or multicast. That is, sendmsg() fails if the destination is off-link since a gateway can't be resolved. This explanation should be contained in the advanced API spec. (1) Hop Limit Delete IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS. Then define IPV6_HOPS which can be used for both unicast and multicast. Require 255 hop-limit if the destination starts with 0xfe80 and 0xff02. (2) IF Delete IPV6_MULTICAST_IF and SO_DONTROUTE. For interface selection, use sendmsg(). If the destination is not link-local-use address nor multicast, sendmsg() returns an error. Comments? --Kazu ------------------------------------------------------------------------------ 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 ----Next_Part(Thu_Jan_16_09:58:50_1997)---- ------------------------------------------------------------------------------ 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 Wed Jan 15 17:28:01 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01022; Wed, 15 Jan 97 17:28:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01016; Wed, 15 Jan 97 17:27:49 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA29088; Wed, 15 Jan 1997 17:19:15 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA15813 for ; Wed, 15 Jan 1997 17:19:04 -0800 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 RAA26103; Wed, 15 Jan 1997 17:16:32 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <9701152112.AA04056@wasted.zk3.dec.com> References: Your message of "Wed, 15 Jan 97 10:30:26 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jan 1997 17:16:31 -0800 To: bound@ZK3.DEC.COM From: Steve Deering Subject: (IPng 2864) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bound@ZK3.DEC.COM wrote: > >I'd really hate to give up stateless autoconfig for the sake of ESD > >uniqueness assurance, and I'm queasy about trying to fit both a routing > >hierarchy and an ESD-assignment hierarchy into 16 minus 6 bytes. > > What do you mean on "giving up on stateless addrconf" above? It seemed that where the discussion was leading was possibly having two hierarchically-structured parts embedded in the 16-byte IPv6 address: the routing goop and the ESD. The ESD would be hierarchically-structured to ensure its uniqueness via delegated assignment, rather than depending on the uniqueness of 802 addresses alone. I assume we'd want at *least* 6 bytes for the routing goop to locate a subnet/link (the O'Dell and Ohta proposals suggested 10 bytes and 8 bytes, respectively -- it might be a hard sell to scrunch that down to 6). And I think a manually-delegated ESD would require at least 6 bytes to identify a site. That leaves at best 4 bytes for the node-within-site part of the ESD, probably less if we want to leave more of a cushion in the RG or high-order parts of the ESD. That isn't enough room to fit an 802 address (though maybe some low-order part of the 802 address would still be sufficiently random not too collide within a site). So I was anticipating that line of reasoning coming to the conclusion that we'd have to use only stateful auto-config, as in IPv4. (Matt Crawford's random allocation ideas also seem to lead possibly to doing stateful auto-config only (i.e., DHCPv6), since having a memoryless machine generate a new random ESD every time it boots and then having to update the DNS to know about that new ESD seems unlikely to fly, to me.) 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 Wed Jan 15 17:39:47 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01046; Wed, 15 Jan 97 17:39:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01040; Wed, 15 Jan 97 17:39:36 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA01328; Wed, 15 Jan 1997 17:31:03 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA18952 for ; Wed, 15 Jan 1997 17:31:03 -0800 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 RAA26758; Wed, 15 Jan 1997 17:30:29 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199701152035.PAA28870@pobox.engeast.BayNetworks.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jan 1997 17:30:28 -0800 To: dhaskin@BayNetworks.COM (Dimitry Haskin) From: Steve Deering Subject: (IPng 2865) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry Haskin wrote: > To be precise I wasn't advocating but merely suggesting it ;) Thanks for that correction. > I'm wondering if that analyses assumed that ESD prefixes would be also > used for hierarchical routing in addition to their identification purpose. > I suspect that if we remove routing considerations from the equation, > the ESD space can be used much more efficiently. It will not be necessary > to allocate a single large contiguous block of prefixes to each site. Yes, the analyses assumed a single prefix for both identifying and locating. But it is not obvious to me the removing the locating function reduces the needed number of bits -- to the contrary, the *locating* prefix might be made smaller, since separating it from the identification function means it can be frequently renumbered/balanced to make dense use of its available space, whereas the *identification* will not be amenable to frequent renumbering (at least I *hope* it won't, or we'll end up recursing again and inventing yet another numbering space). On the other hand, you may be right, and we could do ESD-prefix assignment in a relatively flat, densely- packed manner -- that probably depends on such issues as whether or not you need a distributed reverse-lookup directory for ESD prefixes. I must also must admit to *real* trepidation at the thought of establishing yet another number assignment bureaucracy. Ready for another replay of the DNS TLD and IPv4 address-prefix money-and-powerpower struggles? 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 Wed Jan 15 17:44:50 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01085; Wed, 15 Jan 97 17:44:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01079; Wed, 15 Jan 97 17:44:37 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA02249; Wed, 15 Jan 1997 17:36:05 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA20338 for ; Wed, 15 Jan 1997 17:36:04 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id BAA01997; Thu, 16 Jan 1997 01:35:33 GMT Message-Id: <199701160135.BAA01997@inner.net> To: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2866) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Thu, 16 Jan 1997 09:58:55 +0900." <3571.853376335@mine.aist-nara.ac.jp> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Wed, 15 Jan 1997 20:35:31 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3571.853376335@mine.aist-nara.ac.jp>, you write: >In addition to the suggestions below, I have one more suggestion to >the basic API. It defines inet_pton() and inet_ntop() and they >supports AF_INET and INET6 only. With my implemenation experience of >"netstat", "route", etc, I think these functions should be more >generic. For example, define "pton()" and "ntop()" and support AF_NS, >AF_ISO, etc as well. I believe such functions make some commands more >simple. Use getaddrinfo() and getnameinfo(). (Am I the only person who uses these functions?) >(1) Hop Limit > >IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS are defined on the basic API >draft. Are there any strong reasons to separate them? Yes, it makes it easier to write apps that spray out both multicast and unicast packets, since you'll almost always want different hop limits on them. >NDP and RIPng requires to set hop-limit 255. But I believe that it is >very good idea to set hop-limit 255 for all on-link communication. Are >there any problem if the basic IPv6 spec requires it? It seems to me that the use of link-local addresses already solves the problem. I don't think this requirement is necessary, but I don't think it hurts anything either. >The basic API draft defines IPV6_MULTICAST_IF whereas the advanced API >makes it possible to select an IF with sendmsg(). If they >conflicts(e.g. select IF_1 with setsockopt() then sendmsg() to IF_2), >how should it work? Moreover, if the SO_DONTROUTE option is specified, >what will happen? > >sendmsg() successes only when the destination is link-local-used >address or multicast. That is, sendmsg() fails if the destination is >off-link since a gateway can't be resolved. This explanation should be >contained in the advanced API spec. I disagree. The IPV6_MULTICAST_IF setsockopt() sets the default. If you explicitly override that for a single packet via sendmsg() control data, that data is used instead of the default. It's not clear to me that the SO_DONTROUTE option figured into the discussion of IPV6_MULTICAST_IF and sendmsg() with IPV6_PKTINFO. -Craig ------------------------------------------------------------------------------ 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 Wed Jan 15 17:49:07 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01101; Wed, 15 Jan 97 17:49:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01095; Wed, 15 Jan 97 17:48:55 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA02907; Wed, 15 Jan 1997 17:40:22 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA21410 for ; Wed, 15 Jan 1997 17:40:22 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA04362; Wed, 15 Jan 97 17:38:31 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id RAA12915; Wed, 15 Jan 1997 17:40:00 -0800 Date: Wed, 15 Jan 1997 17:40:00 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199701160140.RAA12915@feller.mentat.com> To: ipng@sunroof.eng.sun.com, kazu@is.aist-nara.ac.jp Subject: (IPng 2867) Re: Forward: hlim and IF on API Content-Type: X-sun-attachment Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 42 Kazu, > > (1) Hop Limit > > Delete IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS. Then define > IPV6_HOPS which can be used for both unicast and multicast. > > Require 255 hop-limit if the destination starts with 0xfe80 and > 0xff02. > I believe that IPV6_MULTICAST_HOPS may have utility when used with site-local multicast addresses. I am not sure about this, but I would be hesitant to remove the functionality until we know more about how scoped multicast addresses are going to be used. > > (2) IF > > Delete IPV6_MULTICAST_IF and SO_DONTROUTE. For interface selection, > use sendmsg(). If the destination is not link-local-use address nor > multicast, sendmsg() returns an error. > The problem with this suggestion is that there are a whole class of existing multicast applications which set the prefered multicast interface when the socket is opened and then use sendto's, sends or even writes possibly. They never change what interface they are using. What you are suggesting is that every IPv6 multicast application will need to pay the performance penalty of using sendmsg with ancillary data even though their prefered interface never changes. I don't think this is a good idea and I am opposed to making this change Tim Hartrick ---------- X-Sun-Data-Type: mail-message X-Sun-Charset: us-ascii X-Sun-Content-Lines: 78 Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with SMTP id KAA07194 for ; Tue, 24 Dec 1996 10:30:10 +0900 Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA29548; Mon, 23 Dec 1996 17:28:22 -0800 Received: from sunroof.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA08544; Mon, 23 Dec 1996 17:28:15 -0800 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27969; Mon, 23 Dec 96 17:33:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27963; Mon, 23 Dec 96 17:32:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA19175; Mon, 23 Dec 1996 17:24:52 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA10497 for ; Mon, 23 Dec 1996 17:24:50 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id KAA06686 for ; Tue, 24 Dec 1996 10:24:47 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id KAA02522; Mon, 23 Dec 1996 10:19:59 GMT To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 2647) hlim and IF on API Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mew version 1.54 on Emacs 19.28.2, Mule 2.3 Date: Mon, 23 Dec 1996 19:19:59 +0900 Message-Id: <2519.851336399@mine.aist-nara.ac.jp> From: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, I have several questions and suggestions concerned with hop-limit and IF selection. (1) Hop Limit IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS are defined on the basic API draft. Are there any strong reasons to separate them? NDP and RIPng requires to set hop-limit 255. But I believe that it is very good idea to set hop-limit 255 for all on-link communication. Are there any problem if the basic IPv6 spec requires it? (2) IF The basic API draft defines IPV6_MULTICAST_IF whereas the advanced API makes it possible to select an IF with sendmsg(). If they conflicts(e.g. select IF_1 with setsockopt() then sendmsg() to IF_2), how should it work? Moreover, if the SO_DONTROUTE option is specified, what will happen? sendmsg() successes only when the destination is link-local-used address or multicast. That is, sendmsg() fails if the destination is off-link since a gateway can't be resolved. This explanation should be contained in the advanced API spec. (1) Hop Limit Delete IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS. Then define IPV6_HOPS which can be used for both unicast and multicast. Require 255 hop-limit if the destination starts with 0xfe80 and 0xff02. (2) IF Delete IPV6_MULTICAST_IF and SO_DONTROUTE. For interface selection, use sendmsg(). If the destination is not link-local-use address nor multicast, sendmsg() returns an error. Comments? --Kazu ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 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 Wed Jan 15 18:42:48 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01295; Wed, 15 Jan 97 18:42:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01289; Wed, 15 Jan 97 18:42:31 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA11530; Wed, 15 Jan 1997 18:33:58 -0800 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id SAA05158 for ; Wed, 15 Jan 1997 18:33:57 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id SAA23478 Received: from pobox.corpwest.BayNetworks.COM (mailhost.corpwest.baynetworks.com [134.177.1.95]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id SAA18098 Posted-Date: Wed, 15 Jan 1997 18:26:34 -0800 (PST) Received: from dhaskin.baynetworks.com ([192.32.171.174]) by pobox.corpwest.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id SAA03595; Wed, 15 Jan 1997 18:26:32 -0800 for Message-Id: <2.2c.32.19970116022117.00ab446c@pobox.corpeast.baynetworks.com> X-Sender: dhaskin@pobox.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 2.2c (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jan 1997 21:21:17 -0500 To: Steve Deering , bound@ZK3.DEC.COM From: Dimitry Haskin Subject: (IPng 2868) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 05:16 PM 1/15/97 -0800, Steve Deering wrote: >It seemed that where the discussion was leading was possibly having two >hierarchically-structured parts embedded in the 16-byte IPv6 address: >the routing goop and the ESD. The ESD would be hierarchically-structured >to ensure its uniqueness via delegated assignment, rather than depending >on the uniqueness of 802 addresses alone. I assume we'd want at *least* >6 bytes for the routing goop to locate a subnet/link (the O'Dell and Ohta >proposals suggested 10 bytes and 8 bytes, respectively -- it might be >a hard sell to scrunch that down to 6). Actually I hoped that the hierarchical ESD would be useful enough to route within sites so that the RG is only used to locate a site. That is, sites get some reasonable size contiguous address blocks but nothing like "class B space for each site". 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 Wed Jan 15 19:58:48 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01346; Wed, 15 Jan 97 19:58:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01340; Wed, 15 Jan 97 19:58:36 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA19620; Wed, 15 Jan 1997 19:50:02 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA21116 for ; Wed, 15 Jan 1997 19:50:03 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA16382; Wed, 15 Jan 1997 22:42:38 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA05976; Wed, 15 Jan 1997 22:42:33 -0500 Message-Id: <9701160342.AA05976@wasted.zk3.dec.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2869) Re: Why ESDs *need* not be globally unique In-Reply-To: Your message of "Wed, 15 Jan 97 16:10:47 CST." <199701152210.QAA18734@gungnir.fnal.gov> Date: Wed, 15 Jan 97 22:42:33 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, Very interesting. I believe to do all you ask requires much conditional code in an implementation that does not exist today, changes the IPv4 model futher, eliminates the use of DNS reverse lookups (recall we tried to eliminate inaddrr.arpa in DNSIND and the community raged). But lets assume all this can be done. We can bag 8+8, develop an extension to change addresses on the fly, use the Hinden RR idea, autoconfig (stateless or stateful), and we have renumbering IMHO. This can all be done with provider based addressing as it is. But some ISPs have voiced a complaint on the architecture and that in itself it does not solve renumbering. Well we can solve renumbering as I stated. But before I write one line of code to do any of this other than Provider Based addressing I would like to see and hear from folks whats wrong with the present addressing model in technical detail. So this proposal (8+8) being ram-rodded because of renumbering cannot be the only reason. So I am now heading where Pedro went at San Jose. But I do believe a hybrid of 8+8 has benefit. Note I am changing my statement at San Jose that I would build a test implementation of 8+8 now because of two reasons: 1) As I keep saying for this to work and be supported by implementors it must be done quick. And IMHO we should have seen a draft already to update 8+8. If you want to lay this on this very serious and willing to do real work and implement IETF working group you need to be serious about updating your drafts and put a lot of time to work on this. 2) I simply do not believe right now without more analysis that altering packets in transit is a good technical or business idea. Had I seen more support for the hybrid approach publicly from the draft author and the community I would have pushed harder. But I don't see support for this except from a few without much further analysis in any form. I need to check your math for myself, but its late, and first reading seems right, and good job. /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 Wed Jan 15 20:10:31 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01367; Wed, 15 Jan 97 20:10:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01361; Wed, 15 Jan 97 20:10:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA20679; Wed, 15 Jan 1997 20:01:42 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA23712 for ; Wed, 15 Jan 1997 20:01:43 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA05014; Wed, 15 Jan 1997 22:58:41 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA06988; Wed, 15 Jan 1997 22:58:40 -0500 Message-Id: <9701160358.AA06988@wasted.zk3.dec.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2870) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Wed, 15 Jan 97 16:48:29 CST." <199701152248.QAA20214@gungnir.fnal.gov> Date: Wed, 15 Jan 97 22:58:40 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I don't mean to be a smart-aleck, but I thought that, if there were >any "obvious" points about the draft, this was one of them. Of >course you get the full destination address from DNS, and insert it >in your outgoing packet. Any other scheme is unworkable. (And my >idea of "workable" tends to be on the liberal side.) I thought so too at first. But once we started the discussion that packets can be altered in transit I wanted to make sure that did not include the dst address. I wanted to verify the premises being put forth, which I felt were not clear in 8+8 section 9.2 after the ensuing discussion altering the packet in transition. I figured we should check with Mike. Other schemes are: 1) the site border or 8+8 designated router does the RG lookup for the ESD AAAA record returned and adds it. Reasons could be only these routers can really tell which locator is appropriate. 2) In transit the ISP can realize a better RG for this ESD. There are others I could dream up, but I hate them all. I just want confirmation to a very direct question and I don't want to have to read between the lines in the draft which I have to get what you got out of it presently. I have serious Internet architecture reasons for hating this, but see no point going into them if its not an issue. So I still await an answer. /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 Wed Jan 15 20:19:31 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01387; Wed, 15 Jan 97 20:19:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01381; Wed, 15 Jan 97 20:19:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA21553; Wed, 15 Jan 1997 20:10:46 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA26481 for ; Wed, 15 Jan 1997 20:10:46 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA21065; Wed, 15 Jan 1997 23:04:43 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA12258; Wed, 15 Jan 1997 23:04:42 -0500 Message-Id: <9701160404.AA12258@wasted.zk3.dec.com> To: jam@iol.unh.edu Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2871) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Wed, 15 Jan 97 18:57:17 EST." <9701152357.AA31643@ragnar.iol.unh.edu> Date: Wed, 15 Jan 97 23:04:41 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Oh yeah...thanks Jeremy...I was thinking should we build some "known" hardware addresses into the ND packets that are duplicated. But if we already know we catch it why bother. /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 Wed Jan 15 20:50:24 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01409; Wed, 15 Jan 97 20:50:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01403; Wed, 15 Jan 97 20:50:13 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA23960; Wed, 15 Jan 1997 20:41:39 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA02932 for ; Wed, 15 Jan 1997 20:41:40 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA12128; Wed, 15 Jan 1997 23:36:23 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16812; Wed, 15 Jan 1997 23:36:23 -0500 Message-Id: <9701160436.AA16812@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2872) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Wed, 15 Jan 97 17:16:31 PST." Date: Wed, 15 Jan 97 23:36:22 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Oh.... I have only really considered Mode 0 of 8+8 for the identity token, which will still support an 802.2 address or other factory hardware address. The top 2 bytes are the Private Topology Partition (PTP). So what I thought was that we could always treat the low order 6bytes as the token for ND and used by stateless or DHCPv6. In addition you can assign FE80 to the token to still get a link-local address. The RA prefix assignments would be 0::xx:000000 where xx is the PTP for that link in that site (upto 2**15 which I hope is big enough for a celluar telephone area or site). So I envisioned that even with Modes 1&2 that the identity token would still be 6bytes with 2 bytes set to zero. So now checking from your mail (which made me reread it again) we can still use addrconf stateless for Mode 0 of the ESD and for any ESD when the PTP is 2bytes and will work too for the ND RAs. 8+8 declares the PTP is always present too. But for Modes 1&2 I think DHCPv6 is a better tool, but it could be done done with stateless, but not without assistance from using Mode 0. I think 8+8 now must state that Mode 0 must be used to generate your link-local address (or we do it in ND) so you have an address from 802.2 or factory installed hardware address so in fact ND and addrconf can work. So this is some input to 8+8 that I just assumed was obvious. A big win for IPv6 is that after my machine boots I have a real address to use to start communicating on the link. We should not let any addressing architecture take this ability away from IPv6. I consider it mandatory for efficient IPv6 let alone ND and Addrconf. I want to state to the way we identify a client to a remote DHCPv6 Server is by a 2-tuple consisting of the Link-Local Address and the Interface address which must have at least site-scope, that relayed the packet to the server. So I am comfortable that 8+8 did not break that either. So the above is equally important to DHCPv6. Mike did build 8+8 to not wreck the machinery we built as he stated up front in his draft. I think the issue of 8+8 is the idea of the locator being assigned on the fly for the source address and its ramifications. I will assume this is not the case for dst address for now. Matt's idea could be Mode 3...but we can only have 8 modes with 8+8 so we need to use them sparingly. So I think we are OK Steve at least with Mode 0 identity token. PTP = 2 bytes Identity Token = 6 bytes /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 Wed Jan 15 21:07:45 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01525; Wed, 15 Jan 97 21:07:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01519; Wed, 15 Jan 97 21:07:34 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA25233; Wed, 15 Jan 1997 20:59:00 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA07229 for ; Wed, 15 Jan 1997 20:59:01 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA22834; Wed, 15 Jan 1997 23:54:04 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19307; Wed, 15 Jan 1997 23:54:03 -0500 Message-Id: <9701160454.AA19307@wasted.zk3.dec.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2873) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Wed, 15 Jan 97 16:48:29 CST." <199701152248.QAA20214@gungnir.fnal.gov> Date: Wed, 15 Jan 97 23:54:02 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, I just got word from Mike.... Yes on the dst addr using 16bytes. /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 Wed Jan 15 21:13:29 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01541; Wed, 15 Jan 97 21:13:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01535; Wed, 15 Jan 97 21:13:18 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA26088; Wed, 15 Jan 1997 21:04:44 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA08982 for ; Wed, 15 Jan 1997 21:04:45 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA30573; Wed, 15 Jan 1997 23:57:08 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA15042; Wed, 15 Jan 1997 23:57:07 -0500 Message-Id: <9701160457.AA15042@wasted.zk3.dec.com> To: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2874) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Wed, 15 Jan 97 21:21:17 EST." <2.2c.32.19970116022117.00ab446c@pobox.corpeast.baynetworks.com> Date: Wed, 15 Jan 97 23:57:07 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry, >Actually I hoped that the hierarchical ESD would be useful enough to route >within sites so that the RG is only used to locate a site. That is, >sites get some reasonable size contiguous address blocks but nothing like >"class B space for each site". It is in a site now in the current draft if you believe 2**15 is enough. The PTP maps where the Identity Token is within the site. The RG is the locator out of the site. Are you thinking we need more than that? 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 Thu Jan 16 00:41:34 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01698; Thu, 16 Jan 97 00:41:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01692; Thu, 16 Jan 97 00:41:19 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA10354; Thu, 16 Jan 1997 00:32:46 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA18527 for ; Thu, 16 Jan 1997 00:32:40 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id RAA16616 for ; Thu, 16 Jan 1997 17:32:24 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id IAA04125; Thu, 16 Jan 1997 08:22:12 GMT To: ipng@sunroof.eng.sun.com Subject: (IPng 2875) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Wed, 15 Jan 1997 20:35:31 -0500" References: <199701160135.BAA01997@inner.net> X-Mailer: Mew version 1.54 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 16 Jan 1997 17:22:12 +0900 Message-Id: <4122.853402932@mine.aist-nara.ac.jp> From: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you, Craig and Tim, From: Craig Metz Subject: Re: (IPng 2863) Forward: hlim and IF on API Date: Wed, 15 Jan 1997 20:35:31 -0500 > Use getaddrinfo() and getnameinfo(). (Am I the only person who uses > these functions?) You are completely right. But this is not a reason to oppose to make inet_{pton,ntop}() functions more generic. > Yes, it makes it easier to write apps that spray out both multicast and > unicast packets, since you'll almost always want different hop > limits on them. OK, then, I'd suggest that we make unicast stuff and multicast stuff as symmetric as possible. For instance, define IPV6_UNICAST_IF against IPV6_MULTICAST_IF. > It seems to me that the use of link-local addresses already solves the > problem. I don't think this requirement is necessary, but I don't think it > hurts anything either. Link-local addresses are not enough to prevent "off-link attack". If we require 255 hop-limit for all link-local addresses, off-link attack can be prevented. In this situation, RIPng daemon, for example, need not to care hop-limit. > The IPV6_MULTICAST_IF setsockopt() sets the default. If you explicitly > override that for a single packet via sendmsg() control data, that data is > used instead of the default. > > It's not clear to me that the SO_DONTROUTE option figured into the > discussion of IPV6_MULTICAST_IF and sendmsg() with IPV6_PKTINFO. Current my position: (1) Define pton() and ntop() instead of inet_pton() and inet_ntop(), respectively. But encourage to use getaddrinfo() and getnameinfo(). (2) Hop Limit Require 255 hop-limit if the destination starts with 0xfe80 and 0xff02. (3) IF Insert an explanation that SO_DONTROUTE must not use for IPv6. Define IPV6_UNICAST_IF in the basic API. Clarify preferences between IPV6_{UNICAST,MULTICAST}_IF and sendmsg(). --Kazu ------------------------------------------------------------------------------ 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 Thu Jan 16 03:42:22 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01784; Thu, 16 Jan 97 03:42:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01778; Thu, 16 Jan 97 03:42:10 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA20750; Thu, 16 Jan 1997 03:33:35 -0800 Received: from scol.sco.com (scol.london.sco.COM [150.126.1.48]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA14071 for ; Thu, 16 Jan 1997 03:33:35 -0800 Received: from nowhere.london.sco.com by scol.sco.COM id aa24540; 16 Jan 97 11:07 GMT X-Uri: X-Face: "Ht#9&2KEo;v0Jn!m[7V}D}F5>{KUiNw Cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: (IPng 2876) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: Your message of "Thu, 02 Jan 1997 15:05:12 MST." <199701022205.PAA07273@kohala.kohala.com> Date: Thu, 16 Jan 1997 11:07:39 +0000 Message-Id: <1593.853412859@sco.COM> From: Harvey Thompson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have some questions and comment which I don't think have been covered in the group yet; > From: "W. Richard Stevens" > To: Thomas Narten , ipng@sunroof.eng.sun.com > Subject: (IPng 2674) Re: W.G. Last Call on "Basic Socket Interface Extensions > for IPv6" > Date: Thu, 2 Jan 1997 15:05:12 -0700 > > > > - gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6 > > > addresses with the h_length member of the hostent structure set > > > to 16. > > > > Does it continue to also supply regular (non IPv4-mapped) AAAA > > addresses as well? (I suspect that it does, but it might help to add > a sentence to that effect.) > > Yes, but only if the 2nd argument is AF_INET6. When the 2nd argument is > AF_INET it does just what it says above. My question here is why? gethostbyname2() is asking for AF_INET but gets back AF_INET6? The only reason I can see for this is to make implementing gethostbyname() in terms of gethostbyname2() easier. Are we asking for trouble, perhaps naive programmers will call gethostbyname2(host, AF_INET) and then assume they get h_length of 4. Perhaps I'm being paranoid, they're are of course no naive programmers out there. > > > The return value from the function is 0 upon success or a nonzero > > > error code. The following names are the nonzero error codes from > > > getaddrinfo(): > > > > And how do programmers know what (integer) codes map to which (string) > > errors? strerror()? > > Unfortunately all Posix specifies is the names. I do have a functions > similar to strerror() for these codes, and it's just a bunch of if's > comparing against the names (i.e., not a simple index into an array). Will this become part of the draft/rfc? Could you give us a sneak preview of the function? > > > structures. To return this information to the system the function > > > freeaddrinfo() is called: > > > > In light of the discussion about using free() to return storage > > obtained indirectly via another call (to the library), I'm surprised > > that we have a freeaddrinfo() but no freenameindex(). > > I plan to add a freenameindex() function, after the discussions on this > list a few weeks back. Again, will this become part of the draft/rfc? Another sneak preview? > > > Note that [getnameinfo()] function does not know the protocol of > > > the socket > > > address structure. Normally this is not a problem because the same > > > port is assigned to a given service for both TCP and UDP. But there > > > exist historical artifacts that violate this rule (e.g., ports 512, > > > > As others have noted, this is not true. The TCP and UDP port numbering > > spaces are independent. > > Yes, and currently I plan to add a 7th argument, as Craig Metz has done. I guess this is going into the standard as well? Another sneak preview? Another related question; Many implementations of inet_aton() parse certain "compact" style addresses (such as a.b, a.b.c, and also allowing octal and hexadecimal numbers). However inet_pton() cannot (and does not in BIND 4.9.4) support them, and since the standard says that it "returns 0 if the input is not a valid IPv4 dotted-decimal string", one could argue that it is not allowed to. Therefore I've been changing code like this; struct in_addr in; inet_aton(cp, &in); to something like this; struct in_addr in; struct in6_addr in6; void * addr; addr = ((af == AF_INET) ? &in : &in6); inet_pton(af, cp, addr); However it's not backwards compatible (groan), so I've had to recode it to; struct in_addr in; struct in6_addr in6; void * addr; if (af == AF_INET) { addr = ∈ inet_aton(cp, &in); } else { addr = &in6; inet_pton(af, cp, addr); } Eurk. Slightly cheesey. Is there a reason why support for these old style addresses dropped? In draft 5 the above wording is not present, and so one could (by the fact that it didn't explicitly disallow any other formats) parse these "compact" (and some might say crufty) IPv4 address styles with inet_pton(). Would it be a bad idea to allow (not force) these old styles to be parsed? Is there anyone who wants inet_pton() to be a completely compatible replacement? --HarveyT ------------------------------------------------------------------------------ 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 Thu Jan 16 05:02:02 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01927; Thu, 16 Jan 97 05:02:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01921; Thu, 16 Jan 97 05:01:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA25027; Thu, 16 Jan 1997 04:53:14 -0800 Received: from mailhub.axion.bt.co.uk (bt-sys.bt.co.uk [132.146.5.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA26671 for ; Thu, 16 Jan 1997 04:53:14 -0800 Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by mailhub.axion.bt.co.uk with SMTP (PP); Thu, 16 Jan 1997 11:47:31 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA02468; Thu, 16 Jan 1997 11:43:25 GMT Date: Thu, 16 Jan 1997 11:43:25 +0000 (GMT) From: George Tsirtsis To: ipng@sunroof.eng.sun.com Subject: (IPng 2877) multihoming alternative Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >---------- >From: Alan ONeill >Sent: 16 January 1997 03:02 >To: George Tsirtsis >Subject: Please submit > The following are some thoughts on IPv6 addressing and multi-homing which I hope will be useful. We are also preparing a description of the use of the existing IPv4 prefix as the provider id which should be complimentary to the thoughts expressed below. This should be submitted next week. Multihoming and Renumbering To support multi-homing without renumbering, in a provider based addressing scheme it is necessary to satisfy two conflicting requirements. Firstly, to ensure that every address is unique to a provider, whilst enabling a host to use the same address for connecting to more than one provider, or to change provider. This difficulty exists because the provider_id (pid) needs to achieve two independent functions. The first is to enable provider basedallocation of addresses so that routing efficiency is maintained whilst ensuring global uniqueness. The second is to identify the chosen forwarding network for a packet. Note that renumbering is a consequence of this problem because as I change provider, whether simply for multi-homing, I must change address or suffer routing inefficiencies. The 8+8 scheme attempts to provide an alternative solution whereby only the last 8 bytes are used to uniquely identify the host, and the upper 8 bytes used to provide the aggregation and routing efficiency. The result for multihoming is that the host still has a single, smaller address, and the routing goop represents the provider specifc routing element. It is important to realise though that the 8+8 scheme drastically reduces the number of IPv6 addresses, moves from an interface address to an ESD, and effectively focusses the addressing scheme around a single customer requirement and the need to avoid renumbering which may not in the future be particularly onerous. A compromise between these two approaches should be possible and is the focus of this idea. The Multi-Homing Identifier (mhid) Assume that the host address is composed of a host part (subid + host_id etc) plus two additional leading fields (ignoring the registry_id for now). The most significant field is the existing pid which identifies the forwarder or routing domain for this packet. For routing efficiency, the rest of the address must be part of that providers address space so that all routes can be advertised within a single prefix. The second field, which is between the pid and the host part, is the mhid. This is intended to ensure that the combination of the mhid and the host part is unique in the Internet. Therefore, if a customer specific host part must be multi-homed to both Provider 1 and Provider 2, then it is necessary to provide a means to distiguish, within the domain of Provider 1, between the host part belonging to Provider 1 and that multi-homed from Provider 2. This is the purpose of the mhid which can be considered to indicate whether the host part belongs to this providers network or another provider, and must therefore either directly orindirectly identify that other provider. This other provider is the primary provider/owner/allocator of that address (mhid + hostpart) and when outside of this provider domain the address can be considered to be roaming or loaned without loss of capacity to the primary provider as they themselves can also accept roaming addresses In summary; The pid indicates the routing domain The pid changes as I move provider. Hosts use n x pids for n x multi-homing. The mhid + X is the globally unique address. The mhid may or may not change as I change provider or multi-home depending of the form of the mhid as discussed below. Scheme A One way to algorithmically determine the mhid for any host is to make the mhid field the same size as the pid field and insert into this field the pid of the provider who allocated the address to the host. This is shown below where it can be seen that host Ha who is normally within the domain of Provider 1, is multihomed to Provider y. The pid is set to indicate which provider will forward the packet. The mhid field is independent of which provider will forward the packet but instead indicates who allocated the host part X to host Ha. It is clear that the combination of the mhid and the hostpart is unique within any providers network, and hence within the internet. It is also clear that when traffic arrives at Provider M based on the pid, the mhid is used as a routing identifier to distinguish between any multi-homed hosts who are connected to provider M, such as Hb and Hc, which also use the host part X. -------------- -------------- -------------- | Provider 1 | |Provider y | | Provider M | -------------- -------------- -------------- | | | ^ pid=1 ^ pid=y | pid=M | | V |------->---------^ | | mhid=1 ------------<-------------| | | mhid= y V mhid=M -------------- -------------- -------------- | Ha = X | | Hb = X | | Hc = X | -------------- -------------- -------------- Advantages Clear roles for pid and mhid. Traffic forwarded by host part allocator has pid=mhid = primary traffic. No renumbering required as a host changes provider, because they still use the address space of the allocating provider, but use the pid (network) of any other provider. Disadvantages Loss of address space = 2 power of pid field size. Inefficient field use because this system enables a host to multi-home to all other possible providers in the Internet at the same time or one provider to be able to support all hosts with address X in the Internet at the same time - both of which are improbably. Scheme B Scheme A does not exploit the fact that a site would probably only multi-home to a few providers at the same time. Therefore, it should be possible to use a short mhid to distinguish between the n different hosts using the same host part in any provider's network. Each mhid must be unique in each providers domain for every supported host with host part = X. Therefore, when a host decides to move provider or multi-home to another provider, it may be necessary to change mhid as well as the pid field. It would also be advantageous for the number of mhids / provider to be limited and consecutive to enable internal routing aggregation. Hence, to change provider, this would require a search through the mhids of those hosts using host part = X in the new provider, for a free mhid code. To multi-home would require a search through two sets of mhids belonging to the two providers for a unique code (mhid=1 below). -------------- -------------- -------------- | Provider 1 | | Provider y | | Provider M | -------------- -------------- -------------- | | | ^ pid=1 ^ pid=y | pid=M | | | |------->--------------- V ^ | | mhid=1 --------<---------------| | | mhid= 2 V mhid=1 -------------- -------------- -------------- | Ha = X | | Hb = X | | Hc = X | -------------- -------------- -------------- Advantages Efficiency in the size of the mhid. Disadvantages mhid renumbering required when moving between single & multi-homing and possibly required when moving between, or adding and deleting, alternative providers. Discussions necessary between n providers to allocate a unique mhid for a host multi-homing to n providers. Mhid Aggregation To provide efficient routing and aggregation within a large providers domain, I think it be essential for the pid field to include not only the provider id but also sufficient routing information to route the packets close to the customer site. This is because we would like the mhid to be well aggregated within the provider domain rather than having routes for all mhids (providers) to which our customers (globally?) are multi-homed. This could be achieved by realising that in a geographical area, a set of customers would have a number of local routers, in different providers networks, on which to multi-home. There should therefore be a good correlation between the different mhids being injected into a providers network in a local geographical area, reflecting the provider part of the pids of the adjacent providers. In particular, two powerful providers with local presense in a single area could expect to attract all the local business traffic which would be multi-homed between them and be fully and completely aggregated under the two mhids appearing in each provider domain. Other issues It is worth pointing out that the registry actually provides the mhid+X address and it would therefore might be sensible to have the registry handle mhid uniqueness. The mhid might also therefore be combined with the registry id field in some way, with multiple mhids per registry, and the providers and registries could cooperate to get efficient allocation of mhids in scheme B. This note uses PBA terminology and hence the pid is the first routing field and indicates the allocator. It may be more logical to call the first field the mhid and the second field the pid (followed by the host part=X) such that the pid refers to the "provider" of the address and the mhid the router/forwarder of the address. Alan O'Neill, BT Labs, aoneill@bt-sys.bt.co.uk. _____________________________________________________________________ This contribution has been prepared to assist the IETF as a basis for discussion. It is not a binding proposal on British Telecommunications plc; specifically, British Telecommunications plc reserves the right tomodify, delete or amend any statements contained herein. _____________________________________________________________________ ------------------------------------------------------------------------------ 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 Thu Jan 16 06:18:47 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01965; Thu, 16 Jan 97 06:18:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01959; Thu, 16 Jan 97 06:18:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA01158; Thu, 16 Jan 1997 06:10:02 -0800 Received: from relay-7.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA13115 for ; Thu, 16 Jan 1997 06:10:01 -0800 Received: from max107.frontier-networks.co.uk ([195.200.12.107]) by relay-5.mail.demon.net id aa527319; 16 Jan 97 13:00 GMT Message-Id: Date: Thu, 16 Jan 1997 12:56:46 +0000 To: ipng@sunroof.eng.sun.com From: Thomas Lee Subject: (IPng 2878) Re: MOs' 8+8 In-Reply-To: Mime-Version: 1.0 X-Mailer: Turnpike Version 3.02 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk x-no-archive: yes In article , Mike O'Dell writes >i have not addressed interoperability between "provider-based" >addresses and 8+8 because the issue is pointless. But to end users and end user organisations, isn't this interoperability both important (ie NOT pointless) and very, very desirable? Seems to me we need at least some degree of interoperability - or am I missing something (again). Thomas -- Thomas Lee (email: tfl@psp.co.uk, web: http://www.psp.demon.co.uk/tfl/tfl.htm) Microsoft Certified Systems Engineer and Certified Trainer PS Partnership - A Microsoft Solution Provider Ph: +44 1628 850 077 Fax: +44 1628 850 143 ------------------------------------------------------------------------------ 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 Thu Jan 16 08:03:37 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02188; Thu, 16 Jan 97 08:03:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02182; Thu, 16 Jan 97 08:03:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA13423; Thu, 16 Jan 1997 07:54:46 -0800 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA20085 for ; Thu, 16 Jan 1997 07:54:31 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id HAA09331 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id HAA23644 Posted-Date: Thu, 16 Jan 1997 07:47:22 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id KAA09935; Thu, 16 Jan 1997 10:47:22 -0500 for Date: Thu, 16 Jan 1997 10:47:22 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701161547.KAA09935@pobox.engeast.BayNetworks.COM> To: bound@zk3.dec.com Subject: (IPng 2879) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > >Actually I hoped that the hierarchical ESD would be useful enough to route > >within sites so that the RG is only used to locate a site. That is, > >sites get some reasonable size contiguous address blocks but nothing like > >"class B space for each site". > > It is in a site now in the current draft if you believe 2**15 is enough. > The PTP maps where the Identity Token is within the site. The RG is the > locator out of the site. Are you thinking we need more than that? > The above comment was in the context of the discussion on the suggested administered ESD allocation scheme which is not presented in the current draft. 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 Thu Jan 16 08:44:15 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02206; Thu, 16 Jan 97 08:44:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02200; Thu, 16 Jan 97 08:44:03 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA19085; Thu, 16 Jan 1997 08:35:28 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA07374 for ; Thu, 16 Jan 1997 08:35:17 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id JAA03406; Thu, 16 Jan 1997 09:35:11 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id JAA04155; Thu, 16 Jan 1997 09:35:05 -0700 (MST) Message-Id: <199701161635.JAA04155@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 16 Jan 1997 09:35:04 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Harvey Thompson Subject: (IPng 2880) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Jan 16, 11:07am you write:] > > My question here is why? gethostbyname2() is asking for AF_INET but gets > back AF_INET6? Because someone set the RES_USE_INET6 option, saying the application wants back 16-byte IPv6 addresses. But they also said they wanted to search only for A records. A couple of points. First, applications should not (IMHO) be calling gethostbyname2(). If they do, then they should set or clear the RES_USE_INET6 option directly (preventing any inheritance of this option from the environment) and specify the 2nd argument to this function as desired. Applications should be calling gethostbyname(). Second, the description of these functions is as they are implemented in BIND 4.9.4 and 4.9.5. While they may not be perfect, I think Paul Vixie designed them well, considering both backwards compatibility and new IPv6 applications. I think it's too early to start second guessing their design. Perhaps when we all get more experience designing IPv6 applications, and porting IPv4 apps to IPv6 we will want to make some changes, but I think it's premature. > > > > The return value from the function is 0 upon success or a nonzero > > > > error code. The following names are the nonzero error codes from > > > > getaddrinfo(): > > > > > > And how do programmers know what (integer) codes map to which (string) > > > errors? strerror()? > > > > Unfortunately all Posix specifies is the names. I do have a functions > > similar to strerror() for these codes, and it's just a bunch of if's > > comparing against the names (i.e., not a simple index into an array). > > Will this become part of the draft/rfc? Could you give us a sneak preview > of the function? We had not planned to add this function to the draft, but always could. It's the trivial mapping of the EAI_xxx codes to its corresponding string (e.g., EAI_MEMORY maps to something like "memory allocation failure"). > > I plan to add a freenameindex() function, after the discussions on this > > list a few weeks back. > > Again, will this become part of the draft/rfc? Another sneak preview? Yes, it will be in the draft, and I should have another version out within days. > > > > Note that [getnameinfo()] function does not know the protocol of > > > > the socket > > > > address structure. Normally this is not a problem because the same > > > > port is assigned to a given service for both TCP and UDP. But there > > > > exist historical artifacts that violate this rule (e.g., ports 512, > > > > > > As others have noted, this is not true. The TCP and UDP port numbering > > > spaces are independent. > > > > Yes, and currently I plan to add a 7th argument, as Craig Metz has done. > > I guess this is going into the standard as well? Another sneak preview? Yes, it will be there. Give me a few days to get the draft updated. > Many implementations of inet_aton() parse certain "compact" style addresses > (such as a.b, a.b.c, and also allowing octal and hexadecimal numbers). > However inet_pton() cannot (and does not in BIND 4.9.4) support them, and > since the standard says that it "returns 0 if the input is not a valid IPv4 > dotted-decimal string", one could argue that it is not allowed to. > ... > Would it be a bad idea to allow (not force) these old styles to > be parsed? Is there anyone who wants inet_pton() to be a completely > compatible replacement? This was hashed over on this mailing list starting with Paul Vixie's comments on May 19, 1996. Paul detailed some of this bizarre (and often undocumented) behavior, asked for comments, and said he did not plan to implement these older IPv4 representations in BIND unless there was a strong call to support it (which there wasn't). I plan to add wording to the draft that these older formats, acceptable to inet_aton(), are not supported with inet_pton(). If you need this old behavior, just call inet_aton() directly for IPv4 strings. Rich Stevens ------------------------------------------------------------------------------ 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 Thu Jan 16 09:02:51 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02223; Thu, 16 Jan 97 09:02:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02217; Thu, 16 Jan 97 09:02:40 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA22072; Thu, 16 Jan 1997 08:54:05 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA15238 for ; Thu, 16 Jan 1997 08:53:56 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id JAA03421; Thu, 16 Jan 1997 09:53:50 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id JAA04217; Thu, 16 Jan 1997 09:53:49 -0700 (MST) Message-Id: <199701161653.JAA04217@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 16 Jan 1997 09:53:49 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Kazu Yamamoto , ipng@sunroof.eng.sun.com Subject: (IPng 2881) Re: Forward: hlim and IF on API Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Jan 16, 9:58am you write:] > > (2) IF > > The basic API draft defines IPV6_MULTICAST_IF whereas the advanced API > makes it possible to select an IF with sendmsg(). If they > conflicts(e.g. select IF_1 with setsockopt() then sendmsg() to IF_2), > how should it work? The next version of the advanced API spec (due out within a week) will explicitly state that the sendmsg() specification will override for just that operation. > Moreover, if the SO_DONTROUTE option is specified, what will happen? As I understand this socket option it says "don't look up the destination in the routing table, assume it's on-link, and if not, error". The kernel then looks up the destination in its interface tables, not the routing table. I would say if the interface located this way is not the same as one specified to sendmsg(), then error. > sendmsg() successes only when the destination is link-local-used > address or multicast. That is, sendmsg() fails if the destination is > off-link since a gateway can't be resolved. This explanation should be > contained in the advanced API spec. The next version of the draft will also specify that the local interface is now specified with its index number, not an IPv6 address. This is a basic change that started with the multicast interface specification in the basic API spec before the San Jose IETF. Rich Stevens ------------------------------------------------------------------------------ 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 Thu Jan 16 09:16:15 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02239; Thu, 16 Jan 97 09:16:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02233; Thu, 16 Jan 97 09:16:03 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA25661; Thu, 16 Jan 1997 09:07:28 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA20772 for ; Thu, 16 Jan 1997 09:05:59 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id KAA03431; Thu, 16 Jan 1997 10:05:42 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id KAA04248; Thu, 16 Jan 1997 10:05:42 -0700 (MST) Message-Id: <199701161705.KAA04248@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 16 Jan 1997 10:05:41 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Kazu Yamamoto , ipng@sunroof.eng.sun.com Subject: (IPng 2882) Re: Forward: hlim and IF on API Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Current my position: > > (1) Define pton() and ntop() instead of inet_pton() and inet_ntop(), > respectively. These names were hashed over on this mailing list in April 1996. As they stand they *do* begin with "inet_" but there is *nothing* at all that prevents them from being implemented for other protocol families. inet_pton() takes an address family argument, a pointer to a C string containing the presentation format, and stores through a void* the binary address. That should work for any family. > (2) Hop Limit > > Require 255 hop-limit if the destination starts with 0xfe80 and > 0xff02. This doesn't belong in the API spec. If you really want something like this, it belongs elsewhere (i.e., so that the kernel implements this requirement). For example some IPv4 kernels do special things with the TTL of link-layer broadcasts (e.g., Solaris). > (3) IF > > Insert an explanation that SO_DONTROUTE must not use for IPv6. I'm not sure you cannot use it, you just need to note that if a conflict exists, an error is returned. How many applications even use SO_DONTROUTE (I recall looking a few months ago and routed was the only one). > Define IPV6_UNICAST_IF in the basic API. I don't know what you mean by this. The ability to specify the outgoing interface for unicast packets is in the advanced API and it's there because it's done using ancillary data with sendmsg(). We decided a while ago that this belongs in the advanced API, not the basic API. > Clarify preferences between IPV6_{UNICAST,MULTICAST}_IF and sendmsg(). This will be done in the advanced API. Rich Stevens ------------------------------------------------------------------------------ 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 Thu Jan 16 11:11:23 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02387; Thu, 16 Jan 97 11:11:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02381; Thu, 16 Jan 97 11:11:12 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA19499; Thu, 16 Jan 1997 11:02:37 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA16694 for ; Thu, 16 Jan 1997 11:02:37 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA26119; Thu, 16 Jan 1997 13:54:35 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23180; Thu, 16 Jan 1997 13:54:32 -0500 Message-Id: <9701161854.AA23180@wasted.zk3.dec.com> To: dhaskin@BayNetworks.COM (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2883) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Thu, 16 Jan 97 10:47:22 EST." <199701161547.KAA09935@pobox.engeast.BayNetworks.COM> Date: Thu, 16 Jan 97 13:54:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well I think no scheme should destroy addrconf, ND, the idea of a Link-Local address at boot time, etc.. Mike did not do this and if someone has a plan to do this write it up and submit a draft I guess. /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 Thu Jan 16 11:44:48 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02422; Thu, 16 Jan 97 11:44:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02411; Thu, 16 Jan 97 11:44:29 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA26074; Thu, 16 Jan 1997 11:35:55 -0800 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA01411 for ; Thu, 16 Jan 1997 11:35:49 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id LAA04839 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id LAA15703 Posted-Date: Thu, 16 Jan 1997 11:28:55 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id OAA24881; Thu, 16 Jan 1997 14:28:56 -0500 for Date: Thu, 16 Jan 1997 14:28:56 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701161928.OAA24881@pobox.engeast.BayNetworks.COM> To: bound@zk3.dec.com Subject: (IPng 2884) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > Well I think no scheme should destroy addrconf, ND, the idea of a > Link-Local address at boot time, etc.. Mike did not do this and if > someone has a plan to do this write it up and submit a draft I guess. > > /jim > Save me.. I don't have any plans to destroy neither addrconf nor any other IPv6 goodies. The ESD allocation scheme that I've suggested (please re-read my mail) supposed to keep all that. In addition it allegedly guaranty global ESD uniqueness, allow (maybe) reverse DNS lookup, and permit to use firewalls the way they currently used in IP. The problem is that we may not have enough bits in the IPv6 address to support the proposed scheme. 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 Thu Jan 16 13:21:35 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02700; Thu, 16 Jan 97 13:21:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02694; Thu, 16 Jan 97 13:21:22 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA12272; Thu, 16 Jan 1997 13:12:48 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA08639 for ; Thu, 16 Jan 1997 13:12:47 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id VAA02669; Thu, 16 Jan 1997 21:12:30 GMT Message-Id: <199701162112.VAA02669@inner.net> To: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2885) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Thu, 16 Jan 1997 17:22:12 +0900." <4122.853402932@mine.aist-nara.ac.jp> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 16 Jan 1997 16:12:29 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4122.853402932@mine.aist-nara.ac.jp>, you write: >> Use getaddrinfo() and getnameinfo(). (Am I the only person who uses >> these functions?) > >You are completely right. But this is not a reason to oppose to make >inet_{pton,ntop}() functions more generic. Actually, it is IMO. The next step towards making them more generic is to make them take a struct sockaddr. After that, make them also support names. And multiple addresses then follow. With every step towards making them more generic, at least in my mind, you end up moving closer to getaddrinfo and (with the addition of a flags field) getnameinfo. So why not just use those functions instead? There are some cases where inet_pton and inet_ntop make sense to use. But they are the exceptional cases. I think I've used them maybe once or twice, while I've used getaddrinfo/getnameinfo *a lot*. >OK, then, I'd suggest that we make unicast stuff and multicast stuff >as symmetric as possible. For instance, define IPV6_UNICAST_IF against >IPV6_MULTICAST_IF. There is no need for IPV6_UNICAST_IF; it doesn't solve any problem. Your routing table takes the destination address and knows (maybe not correctly, but precisely) which interface a packet must go out. But a multicast destination address is potentially valid on all interfaces, so the routing table doesn't tell you what interface a packet must go out. This is the problem the IPV6_MULTICAST_IF setsockopt solves. In either multicast or unicast case, if you need exact control over the interface, you can always use the advanced API. >Link-local addresses are not enough to prevent "off-link attack". If >we require 255 hop-limit for all link-local addresses, off-link attack >can be prevented. In this situation, RIPng daemon, for example, need >not to care hop-limit. Actually, thinking about this more, a hop limit of 255 appears to me to be an exceedingly bad idea. There are two possible cases here. The first is that your link-local addresses are correctly handled, in which case your packet never gets forwarded regardless of hop limit, and all is well. The second is that your link-local addresses are NOT correctly handled, in which case the hop limit of 255 lets the martian packet live a lot longer than it should. Also, the local daemon still does not automagically get protected against martian packets - it MUST use the advanced API and receive the IPV6_HOPLIMIT control data to check the hop limit. If you wanted to force a hop limit, I'd suggest forcing it to either zero (depends on how everyone interprets zero; the spec seems a bit vague to me in this case because there's no forwarding going on) or one. For now, however, I stand by my original statement that link-local addresses should be enough. If link-locals are not properly handled by IPv6 systems, lots of things are going to break badly. -Craig ------------------------------------------------------------------------------ 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 Thu Jan 16 13:24:28 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02712; Thu, 16 Jan 97 13:24:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02706; Thu, 16 Jan 97 13:24:16 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA12769; Thu, 16 Jan 1997 13:15:41 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA09990 for ; Thu, 16 Jan 1997 13:15:34 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id VAA02673; Thu, 16 Jan 1997 21:15:12 GMT Message-Id: <199701162115.VAA02673@inner.net> To: Harvey Thompson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2886) Re: W.G. Last Call on "Basic Socket Interface Extensions for IPv6" In-Reply-To: Your message of "Thu, 16 Jan 1997 11:07:39 GMT." <1593.853412859@sco.COM> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 16 Jan 1997 16:15:11 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <1593.853412859@sco.COM>, you write: >Eurk. Slightly cheesey. Is there a reason why support for these old style >addresses dropped? In draft 5 the above wording is not present, and so >one could (by the fact that it didn't explicitly disallow any other formats) >parse these "compact" (and some might say crufty) IPv4 address styles with >inet_pton(). > >Would it be a bad idea to allow (not force) these old styles to >be parsed? Is there anyone who wants inet_pton() to be a completely >compatible replacement? The "compact" form is an old hack (old BSD hack?) that is rarely used and whose behavior isn't consistent on all systems (especially older ones) and is not standardized. I don't believe it would be a real loss if it wasn't supported. -Craig ------------------------------------------------------------------------------ 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 Thu Jan 16 15:01:03 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02870; Thu, 16 Jan 97 15:01:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02864; Thu, 16 Jan 97 15:00:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA02457; Thu, 16 Jan 1997 14:52:17 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA16951 for ; Thu, 16 Jan 1997 14:52:15 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id RAA24290; Thu, 16 Jan 1997 17:52:06 -0500 Date: Thu, 16 Jan 1997 17:52:06 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9701161752.ZM24288@seawind.bellcore.com> In-Reply-To: dhaskin@BayNetworks.COM (Dimitry Haskin) "(IPng 2884) Re: 8+8 Why ESDS are not globally Unique" (Jan 16, 2:28pm) References: <199701161928.OAA24881@pobox.engeast.BayNetworks.COM> X-Mailer: Z-Mail (3.2.1 10oct95) To: dhaskin@BayNetworks.COM (Dimitry Haskin) Subject: (IPng 2887) Re: 8+8 Why ESDS are not globally Unique 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 On Jan 16, 2:28pm, Dimitry Haskin wrote: > Save me.. I don't have any plans to destroy neither addrconf nor any other > IPv6 goodies. The ESD allocation scheme that I've suggested (please re-read > my mail) supposed to keep all that. In addition it allegedly guaranty > global ESD uniqueness, allow (maybe) reverse DNS lookup, and permit to > use firewalls the way they currently used in IP. The problem is that > we may not have enough bits in the IPv6 address to support the proposed > scheme. In fact, the whole thing could be made to work if: 1) there is a link between an RG and a domain, or in fact between a set of "equivalent" RG and a domain, 2) ESD are guaranteed unique within the domain, 3) the domain administrator knows what RGs have been allocated in his or her domain. In that case: 1) we can pick any RG as an autoconfiguration prefix. 2) we can use DAD to check unicity. 3) we can build up reverse look-up names in the DNS of the form .e.a.c.h.n.i.b.b.l.e.o.f.R.G.ipv6.int or, if we accept a two pass look-up, we can have e.a.c.h.n.i.b.b.l.e.o.f.R.G.ipv6.int point to the domain.name, then .domain.name point to the actual interface. 4) we can use good old data base techniques to store the ESD information only once in the DNS, and have several RG point ot it. This is trivial if we adopt the two pass technique. 5) ditto, we can use good old data base techniques to store the ESD only once under the name of teh interface, associate it with the set of RG of the day, and construct up to date AAAA records on the fly. Or, if we accept to work with two records, we can have an ESD record per interface that gives the value of the ESD and points to the name of the domain, then a set of RG records per domain. 6) If we use the "two pass" strategy, administrators can trivially use DNS security to sign the RG and ESD records, thus providing a safe way to receive modified RG during the course of a TCP connection, check that they are valid, and accept to pursue the connection with the new RG. The impact of the proposal would be essentially on the DNS access procedures. Address configuration would remained, by and large, unchanged. TCP would also remain unchanged, except if a new capability is added to accept modified RG during the course of a connection. The condition there is to step down one notch from Mike O'Dell's initial objective, and leave domain administrators with some controls on the RG that can be used on their behalf. basically, if they cannot sign the RG in teh DNS, then partners have no insurance that the packet does originate from their domain. -- 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 Thu Jan 16 18:54:09 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03322; Thu, 16 Jan 97 18:54:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03316; Thu, 16 Jan 97 18:53:56 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA14997; Thu, 16 Jan 1997 18:45:22 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA29415 for ; Thu, 16 Jan 1997 18:45:19 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id LAA07133 for ; Fri, 17 Jan 1997 11:44:58 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id CAA04786; Fri, 17 Jan 1997 02:34:46 GMT To: ipng@sunroof.eng.sun.com Subject: (IPng 2888) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Thu, 16 Jan 1997 16:12:29 -0500" References: <199701162112.VAA02669@inner.net> X-Mailer: Mew version 1.54 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 17 Jan 1997 11:34:46 +0900 Message-Id: <4783.853468486@mine.aist-nara.ac.jp> From: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, From: Craig Metz Subject: Re: (IPng 2875) Re: Forward: hlim and IF on API Date: Thu, 16 Jan 1997 16:12:29 -0500 > The next step towards making them more generic is to make them > take a struct sockaddr. After that, make them also support > names. And multiple addresses then follow. With every step towards > making them more generic, at least in my mind, you end up moving > closer to getaddrinfo and (with the addition of a flags field) > getnameinfo. So why not just use those functions instead? I'm now satisfied with Rich's statement that inet_{pton,ntop}() can take families other than AF_INET{,6}. And I believe you are right. We should use get{addr,name}info() for portability. > There is no need for IPV6_UNICAST_IF; it doesn't solve any > problem. Your routing table takes the destination address and knows > (maybe not correctly, but precisely) which interface a packet must > go out. But a multicast destination address is potentially valid on > all interfaces, so the routing table doesn't tell you what interface > a packet must go out. This is the problem the IPV6_MULTICAST_IF > setsockopt solves. No. You probably didn't cover link-local unicast addresses. A link-local unicast destination address is potentially valid on all interfaces as same as a multicast destination. The advanced API can can choose an interface for a link-local address but this argument is exactly same as the multicast case. Multicast has IPV6_MULTICAST_IF and sendmsg(), so link-local unicast addresses should have IPV6_UNICAST_IF and sendmsg(). > The second is that your link-local addresses are NOT correctly > handled, in which case the hop limit of 255 lets the martian packet > live a lot longer than it should. Also, the local daemon still does > not automagically get protected against martian packets - it MUST > use the advanced API and receive the IPV6_HOPLIMIT control data to > check the hop limit. My assessment is as following: (1) If the hop limit of 255 is a bad idea, we went a wrong way on NDP. (2) In my scheme, if link-local scope IPv6 packets don't have 255 hop-limit, the kernel must discard it. So, local daemons need not to check hop-limit. (3) RFC1884 clearly says that link-local unicast addresses must not be forwarded. (But I now an accident happens.) --Kazu ------------------------------------------------------------------------------ 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 Thu Jan 16 19:15:59 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03407; Thu, 16 Jan 97 19:15:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03401; Thu, 16 Jan 97 19:15:48 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA17495; Thu, 16 Jan 1997 19:07:13 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA03874 for ; Thu, 16 Jan 1997 19:07:13 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id VAA24567; Thu, 16 Jan 1997 22:00:00 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA12412; Thu, 16 Jan 1997 21:59:58 -0500 Message-Id: <9701170259.AA12412@wasted.zk3.dec.com> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2889) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Thu, 16 Jan 97 14:28:56 EST." <199701161928.OAA24881@pobox.engeast.BayNetworks.COM> Date: Thu, 16 Jan 97 21:59:58 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry, Did not intend my response to "you". It was generic. Sorry you took it that way. I just started looking at Alan O'Neill's new draft and its interesting too while we are looking at addressing architectures. That may make the entire idea of renumbering null and void. /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 Thu Jan 16 19:20:25 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03422; Thu, 16 Jan 97 19:20:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03416; Thu, 16 Jan 97 19:20:12 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA17916; Thu, 16 Jan 1997 19:11:38 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA04665 for ; Thu, 16 Jan 1997 19:11:37 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id WAA00396; Thu, 16 Jan 1997 22:26:14 GMT Message-Id: <199701162226.WAA00396@inner.net> To: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2890) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Fri, 17 Jan 1997 11:34:46 +0900." <4783.853468486@mine.aist-nara.ac.jp> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 16 Jan 1997 22:11:23 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4783.853468486@mine.aist-nara.ac.jp>, you write: >No. You probably didn't cover link-local unicast addresses. A >link-local unicast destination address is potentially valid on all >interfaces as same as a multicast destination. The advanced API can >can choose an interface for a link-local address but this argument is >exactly same as the multicast case. Multicast has IPV6_MULTICAST_IF >and sendmsg(), so link-local unicast addresses should have >IPV6_UNICAST_IF and sendmsg(). After ND is done, you almost always will have exactly one interface that the unicast link-local packet goes out. There exists two interesting cases. The first: |--A--| | | |--B--| Where A and B come from a vendor who assigns the same MAC address to every interface on the system. In this case, it really shouldn't matter which interface it goes out. If it really does, use the advanced API. The second: A---B---C Where A and C somehow have the same MAC address. In this case, you scream really loudly (probably at some vendor). This case could cause lots of things to break. >(1) If the hop limit of 255 is a bad idea, we went a wrong way on NDP. >(2) In my scheme, if link-local scope IPv6 packets don't have 255 >hop-limit, the kernel must discard it. So, local daemons need not to >check hop-limit. >(3) RFC1884 clearly says that link-local unicast addresses must not be >forwarded. (But I now an accident happens.) If packets are filtered properly (IMO, source and dest should be checked for link-locals and the packet never forwarded if either are) then hop limit tricks shouldn't be needed. I guess it just doesn't seem like enough of a problem to me to warrant the behavior you describe. -Craig ------------------------------------------------------------------------------ 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 Thu Jan 16 19:32:35 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03453; Thu, 16 Jan 97 19:32:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03447; Thu, 16 Jan 97 19:32:24 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA19228; Thu, 16 Jan 1997 19:23:49 -0800 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA07082 for ; Thu, 16 Jan 1997 19:23:50 -0800 Received: from big-dogs.cisco.com ([171.68.53.75]) by lint.cisco.com (8.8.4/CISCO.SERVER.1.2) with SMTP id TAA11462; Thu, 16 Jan 1997 19:23:45 -0800 (PST) Message-Id: <3.0.32.19970116222343.0069f764@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 16 Jan 1997 22:23:46 -0500 To: bound@zk3.dec.com From: Paul Ferguson Subject: (IPng 2891) Re: 8+8 Why ESDS are not globally Unique 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 At 09:59 PM 1/16/97 -0500, bound@zk3.dec.com wrote: > >I just started looking at Alan O'Neill's new draft and its interesting >too while we are looking at addressing architectures. That may make the >entire idea of renumbering null and void. > This I gotta see. Pointer, please. - paul ------------------------------------------------------------------------------ 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 Thu Jan 16 19:51:02 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03474; Thu, 16 Jan 97 19:51:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03468; Thu, 16 Jan 97 19:50:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA20843; Thu, 16 Jan 1997 19:42:15 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA10305 for ; Thu, 16 Jan 1997 19:42:08 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id MAA12721 for ; Fri, 17 Jan 1997 12:42:06 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id DAA04846; Fri, 17 Jan 1997 03:31:55 GMT To: ipng@sunroof.eng.sun.com Subject: (IPng 2892) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Thu, 16 Jan 1997 22:11:23 -0500" References: <199701162226.WAA00396@inner.net> X-Mailer: Mew version 1.54 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 17 Jan 1997 12:31:55 +0900 Message-Id: <4843.853471915@mine.aist-nara.ac.jp> From: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Craig Metz Subject: Re: (IPng 2888) Re: Forward: hlim and IF on API Date: Thu, 16 Jan 1997 22:11:23 -0500 > After ND is done, you almost always will have exactly one interface > that the unicast link-local packet goes out. There exists two interesting > cases. On the interface selection topic, I'm talking the stage BEFORE ND is done. > The second: > > A---B---C > > Where A and C somehow have the same MAC address. In this case, you > scream really loudly (probably at some vendor). This case could cause lots of > things to break. Sorry, I can't understand what you are talking about to oppose my suggestion. > If packets are filtered properly (IMO, source and dest should be > checked for link-locals and the packet never forwarded if either are) then > hop limit tricks shouldn't be needed. > > I guess it just doesn't seem like enough of a problem to me to warrant > the behavior you describe. Let me clarify. (1) Almost all packets which have link-local addresses would be filtered out by routers thanks to RFC1884. (2) But accidents happen. This packets are discarded by a received kernel because they don't have 255 hop-limit. (3) So, a routing daemon (and other applications) need not to handle such illegal packets. This improves performance of the routing daemon and makes its code simpler. --Kazu ------------------------------------------------------------------------------ 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 Thu Jan 16 20:11:24 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03521; Thu, 16 Jan 97 20:11:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03515; Thu, 16 Jan 97 20:11:12 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA22793; Thu, 16 Jan 1997 20:02:37 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA13962 for ; Thu, 16 Jan 1997 20:02:37 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA07834; Thu, 16 Jan 1997 22:56:04 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA17699; Thu, 16 Jan 1997 22:56:03 -0500 Message-Id: <9701170356.AA17699@wasted.zk3.dec.com> To: Paul Ferguson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2893) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Thu, 16 Jan 97 22:23:46 EST." <3.0.32.19970116222343.0069f764@lint.cisco.com> Date: Thu, 16 Jan 97 22:56:03 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul, This came to us today>..... /jim Return-Path: owner-ipng@sunroof.eng.sun.com Received: from flambe.zk3.dec.com by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18672; Thu, 16 Jan 1997 08:12:28 -0500 Received: from mail12.digital.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA15779; Thu, 16 Jan 1997 08:12:27 -0500 Received: from venus.Sun.COM by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA23841; Thu, 16 Jan 1997 08:07:10 -0500 (EST) Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA15562; Thu, 16 Jan 1997 04:55:39 -0800 Received: from sunroof.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA22697; Thu, 16 Jan 1997 04:55:32 -0800 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01927; Thu, 16 Jan 97 05:02:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01921; Thu, 16 Jan 97 05:01:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA25027; Thu, 16 Jan 1997 04:53:14 -0800 Received: from mailhub.axion.bt.co.uk (bt-sys.bt.co.uk [132.146.5.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA26671 for ; Thu, 16 Jan 1997 04:53:14 -0800 Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by mailhub.axion.bt.co.uk with SMTP (PP); Thu, 16 Jan 1997 11:47:31 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA02468; Thu, 16 Jan 1997 11:43:25 GMT Date: Thu, 16 Jan 1997 11:43:25 +0000 (GMT) From: George Tsirtsis To: ipng@sunroof.eng.sun.com Subject: (IPng 2877) multihoming alternative Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >---------- >From: Alan ONeill >Sent: 16 January 1997 03:02 >To: George Tsirtsis >Subject: Please submit > The following are some thoughts on IPv6 addressing and multi-homing which I hope will be useful. We are also preparing a description of the use of the existing IPv4 prefix as the provider id which should be complimentary to the thoughts expressed below. This should be submitted next week. Multihoming and Renumbering To support multi-homing without renumbering, in a provider based addressing scheme it is necessary to satisfy two conflicting requirements. Firstly, to ensure that every address is unique to a provider, whilst enabling a host to use the same address for connecting to more than one provider, or to change provider. This difficulty exists because the provider_id (pid) needs to achieve two independent functions. The first is to enable provider basedallocation of addresses so that routing efficiency is maintained whilst ensuring global uniqueness. The second is to identify the chosen forwarding network for a packet. Note that renumbering is a consequence of this problem because as I change provider, whether simply for multi-homing, I must change address or suffer routing inefficiencies. The 8+8 scheme attempts to provide an alternative solution whereby only the last 8 bytes are used to uniquely identify the host, and the upper 8 bytes used to provide the aggregation and routing efficiency. The result for multihoming is that the host still has a single, smaller address, and the routing goop represents the provider specifc routing element. It is important to realise though that the 8+8 scheme drastically reduces the number of IPv6 addresses, moves from an interface address to an ESD, and effectively focusses the addressing scheme around a single customer requirement and the need to avoid renumbering which may not in the future be particularly onerous. A compromise between these two approaches should be possible and is the focus of this idea. The Multi-Homing Identifier (mhid) Assume that the host address is composed of a host part (subid + host_id etc) plus two additional leading fields (ignoring the registry_id for now). The most significant field is the existing pid which identifies the forwarder or routing domain for this packet. For routing efficiency, the rest of the address must be part of that providers address space so that all routes can be advertised within a single prefix. The second field, which is between the pid and the host part, is the mhid. This is intended to ensure that the combination of the mhid and the host part is unique in the Internet. Therefore, if a customer specific host part must be multi-homed to both Provider 1 and Provider 2, then it is necessary to provide a means to distiguish, within the domain of Provider 1, between the host part belonging to Provider 1 and that multi-homed from Provider 2. This is the purpose of the mhid which can be considered to indicate whether the host part belongs to this providers network or another provider, and must therefore either directly orindirectly identify that other provider. This other provider is the primary provider/owner/allocator of that address (mhid + hostpart) and when outside of this provider domain the address can be considered to be roaming or loaned without loss of capacity to the primary provider as they themselves can also accept roaming addresses In summary; The pid indicates the routing domain The pid changes as I move provider. Hosts use n x pids for n x multi-homing. The mhid + X is the globally unique address. The mhid may or may not change as I change provider or multi-home depending of the form of the mhid as discussed below. Scheme A One way to algorithmically determine the mhid for any host is to make the mhid field the same size as the pid field and insert into this field the pid of the provider who allocated the address to the host. This is shown below where it can be seen that host Ha who is normally within the domain of Provider 1, is multihomed to Provider y. The pid is set to indicate which provider will forward the packet. The mhid field is independent of which provider will forward the packet but instead indicates who allocated the host part X to host Ha. It is clear that the combination of the mhid and the hostpart is unique within any providers network, and hence within the internet. It is also clear that when traffic arrives at Provider M based on the pid, the mhid is used as a routing identifier to distinguish between any multi-homed hosts who are connected to provider M, such as Hb and Hc, which also use the host part X. -------------- -------------- -------------- | Provider 1 | |Provider y | | Provider M | -------------- -------------- -------------- | | | ^ pid=1 ^ pid=y | pid=M | | V |------->---------^ | | mhid=1 ------------<-------------| | | mhid= y V mhid=M -------------- -------------- -------------- | Ha = X | | Hb = X | | Hc = X | -------------- -------------- -------------- Advantages Clear roles for pid and mhid. Traffic forwarded by host part allocator has pid=mhid = primary traffic. No renumbering required as a host changes provider, because they still use the address space of the allocating provider, but use the pid (network) of any other provider. Disadvantages Loss of address space = 2 power of pid field size. Inefficient field use because this system enables a host to multi-home to all other possible providers in the Internet at the same time or one provider to be able to support all hosts with address X in the Internet at the same time - both of which are improbably. Scheme B Scheme A does not exploit the fact that a site would probably only multi-home to a few providers at the same time. Therefore, it should be possible to use a short mhid to distinguish between the n different hosts using the same host part in any provider's network. Each mhid must be unique in each providers domain for every supported host with host part = X. Therefore, when a host decides to move provider or multi-home to another provider, it may be necessary to change mhid as well as the pid field. It would also be advantageous for the number of mhids / provider to be limited and consecutive to enable internal routing aggregation. Hence, to change provider, this would require a search through the mhids of those hosts using host part = X in the new provider, for a free mhid code. To multi-home would require a search through two sets of mhids belonging to the two providers for a unique code (mhid=1 below). -------------- -------------- -------------- | Provider 1 | | Provider y | | Provider M | -------------- -------------- -------------- | | | ^ pid=1 ^ pid=y | pid=M | | | |------->--------------- V ^ | | mhid=1 --------<---------------| | | mhid= 2 V mhid=1 -------------- -------------- -------------- | Ha = X | | Hb = X | | Hc = X | -------------- -------------- -------------- Advantages Efficiency in the size of the mhid. Disadvantages mhid renumbering required when moving between single & multi-homing and possibly required when moving between, or adding and deleting, alternative providers. Discussions necessary between n providers to allocate a unique mhid for a host multi-homing to n providers. Mhid Aggregation To provide efficient routing and aggregation within a large providers domain, I think it be essential for the pid field to include not only the provider id but also sufficient routing information to route the packets close to the customer site. This is because we would like the mhid to be well aggregated within the provider domain rather than having routes for all mhids (providers) to which our customers (globally?) are multi-homed. This could be achieved by realising that in a geographical area, a set of customers would have a number of local routers, in different providers networks, on which to multi-home. There should therefore be a good correlation between the different mhids being injected into a providers network in a local geographical area, reflecting the provider part of the pids of the adjacent providers. In particular, two powerful providers with local presense in a single area could expect to attract all the local business traffic which would be multi-homed between them and be fully and completely aggregated under the two mhids appearing in each provider domain. Other issues It is worth pointing out that the registry actually provides the mhid+X address and it would therefore might be sensible to have the registry handle mhid uniqueness. The mhid might also therefore be combined with the registry id field in some way, with multiple mhids per registry, and the providers and registries could cooperate to get efficient allocation of mhids in scheme B. This note uses PBA terminology and hence the pid is the first routing field and indicates the allocator. It may be more logical to call the first field the mhid and the second field the pid (followed by the host part=X) such that the pid refers to the "provider" of the address and the mhid the router/forwarder of the address. Alan O'Neill, BT Labs, aoneill@bt-sys.bt.co.uk. _____________________________________________________________________ This contribution has been prepared to assist the IETF as a basis for discussion. It is not a binding proposal on British Telecommunications plc; specifically, British Telecommunications plc reserves the right tomodify, delete or amend any statements contained herein. _____________________________________________________________________ ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 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 Thu Jan 16 20:17:42 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03537; Thu, 16 Jan 97 20:17:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03531; Thu, 16 Jan 97 20:17:30 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA23317; Thu, 16 Jan 1997 20:08:55 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA15016 for ; Thu, 16 Jan 1997 20:08:55 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id XAA00807; Thu, 16 Jan 1997 23:23:20 GMT Message-Id: <199701162323.XAA00807@inner.net> To: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2894) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Fri, 17 Jan 1997 12:31:55 +0900." <4843.853471915@mine.aist-nara.ac.jp> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 16 Jan 1997 23:08:30 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4843.853471915@mine.aist-nara.ac.jp>, you write: >(1) Almost all packets which have link-local addresses would be filtered out by routers thanks to RFC1884. > >(2) But accidents happen. This packets are discarded by a received >kernel because they don't have 255 hop-limit. > >(3) So, a routing daemon (and other applications) need not to handle >such illegal packets. This improves performance of the routing daemon >and makes its code simpler. If it's never supposed to happen, it seems very unlikely to me that it will happen often enough to load receivers (e.g., routing daemons) down. At the point where enough packets are slipping through to create an appreciable load on the receiver, you have a BIG network problem anyway (that's no accident, that's something being seriously broken). It is therefore not necessarily (IMO) a bad thing that it loads the receiver down; this makes it more likely that the end user/admin will actually notice that something is wrong. -Craig ------------------------------------------------------------------------------ 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 Thu Jan 16 20:27:24 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03549; Thu, 16 Jan 97 20:27:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03543; Thu, 16 Jan 97 20:27:13 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA24226; Thu, 16 Jan 1997 20:18:38 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA16579 for ; Thu, 16 Jan 1997 20:18:38 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id XAA00830; Thu, 16 Jan 1997 23:32:24 GMT Message-Id: <199701162332.XAA00830@inner.net> To: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2895) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Fri, 17 Jan 1997 12:31:55 +0900." <4843.853471915@mine.aist-nara.ac.jp> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 16 Jan 1997 23:17:35 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4843.853471915@mine.aist-nara.ac.jp>, you write: >(2) But accidents happen. This packets are discarded by a received >kernel because they don't have 255 hop-limit. Incidentally, if you can't trust your routers to properly filter link-locals out, do you trust them to process the hop limit correctly? I guess I'm just not convinced that we have enough experience with this to spec out a mandatory solution to this problem. The ND spec mandates the setting and checking of a hop limit of 255. Maybe some other protocol will want to use zero. We may find that these "cures" are worse than the problem in cases where routers are broken, or we may find that link-locals getting forwarded is rarely/never a problem. For now, I don't see a pressing need to mandate a hop limit and it's not clear to me that it's a good solution to the problem. -Craig ------------------------------------------------------------------------------ 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 Thu Jan 16 21:50:47 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03725; Thu, 16 Jan 97 21:50:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03719; Thu, 16 Jan 97 21:50:34 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA01319; Thu, 16 Jan 1997 21:42:00 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA29964 for ; Thu, 16 Jan 1997 21:41:53 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id OAA26291 for ; Fri, 17 Jan 1997 14:41:50 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id FAA05184; Fri, 17 Jan 1997 05:31:38 GMT To: ipng@sunroof.eng.sun.com Subject: (IPng 2896) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Thu, 16 Jan 1997 09:53:49 -0700" References: <199701161653.JAA04217@kohala.kohala.com> X-Mailer: Mew version 1.54 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 17 Jan 1997 14:31:38 +0900 Message-Id: <5181.853479098@mine.aist-nara.ac.jp> From: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: rstevens@kohala.com (W. Richard Stevens) Subject: Re: (IPng 2863) Forward: hlim and IF on API Date: Thu, 16 Jan 1997 09:53:49 -0700 > > Moreover, if the SO_DONTROUTE option is specified, what will happen? > > As I understand this socket option it says "don't look up the destination > in the routing table, assume it's on-link, and if not, error". I also believe so. In other words, SO_DONTROUTE is interface specification (with a destination) in IPv4 scheme. > The kernel then looks up the destination in its interface tables, > not the routing table. I would say if the interface located this > way is not the same as one specified to sendmsg(), then error. OK. Let's discuss only link-local unicast addresses. How does the kernel lookup a link-local unicast destination in its interface tables? The destination matches all interfaces. From: rstevens@kohala.com (W. Richard Stevens) Subject: Re: (IPng 2875) Re: Forward: hlim and IF on API Date: Thu, 16 Jan 1997 10:05:41 -0700 > I'm not sure you cannot use it, you just need to note that if a conflict > exists, an error is returned. How many applications even use SO_DONTROUTE If DO_DONTROUTE doesn't break IPv6 scheme, just noting this in RFC is OK to me. But I'm not sure that DO_DONTROUTE doesn't do so. > (I recall looking a few months ago and routed was the only one). As far as BSD/OS 2.1 concerned, "ping" also uses it. --Kazu ------------------------------------------------------------------------------ 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 Fri Jan 17 01:05:43 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03914; Fri, 17 Jan 97 01:05:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03908; Fri, 17 Jan 97 01:05:26 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA12476; Fri, 17 Jan 1997 00:56:51 -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 AAA26047 for ; Fri, 17 Jan 1997 00:56:48 -0800 From: Masataka Ohta Message-Id: <199701170854.RAA13542@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA13542; Fri, 17 Jan 1997 17:54:42 +0900 Subject: (IPng 2897) Re: 8+8 Why ESDS are not globally Unique To: jhalpern@us.newbridge.com (Joel Halpern) Date: Fri, 17 Jan 97 17:54:41 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9701101908.AA00370@lobster.nni>; from "Joel Halpern" at Jan 10, 97 2:08 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joel; > On the one hand there is the reverse lookup issue. If ESDs are not globally > unique, then you can not get a unique reverse lookup. If a globally unique ID is not hierarchically structured and is hashed, then, we need a centralized server(s) for the reverse lookup. That is, it is impossible to delegate ID subspace management to end users. It should be noted that hierarchically strucutred ID will almost automatically be globally unique. Note also that, hashed stateless autoconfiguration is insecure. > I would like to sweep this all under the rug by claiming that the 8 byte > ESD will be globally unique, but as observed several times during the IPv6 > debates, that is not a reasonable conclusion. Huh? I have never seen any debate on it. When I presented my proof that 8 byte ID can support 10**15 hosts with organizational hierarchy at Danvers, there was no objection. The point is that, you shouldn't try to have routing hierarchy in IDs. The ID should reflect organizational hierarchy, such as in which country and state/prefecture your company is registered or in which division you belong in your compary. The ID shouldn't reflect routing hierarchy, such as which top level provider your company is using or which subnet in your company your host is located in. > There is an additional issue: Authentication. What? Just in the sense that 8+8 with locator rewriting is insecure, hashed Ipv6 address with stateless autoconfiguration is also insecure. How? First, assume that we don't have real security, because real security solves all the security problems. Second, assume that the issue is inter-site because single-site security issue can be simply solved by a firewall. Now, suppose you visit some foreign site and have your local IP address assigned. You can register it under AAAA of forward DNS of your home site to be useful for weak authentication. Then, suddenly, your host in foreign environment is attacked with a denial of service attack, which can be as simple as cutting wire. And the attacker can override your IP address with full weak authentication. How can you solve the problem? Well, as we know, weak security is meaningful only when network layer is managed reliably. So, the home site should have a firewall and shouldn't trust any host outside of it unless authenticated with real security, which works also with 8+8. 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 Fri Jan 17 01:12:23 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03951; Fri, 17 Jan 97 01:12:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03945; Fri, 17 Jan 97 01:12:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA12991; Fri, 17 Jan 1997 01:03:32 -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 BAA27140 for ; Fri, 17 Jan 1997 01:03:29 -0800 From: Masataka Ohta Message-Id: <199701170858.RAA13574@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA13574; Fri, 17 Jan 1997 17:58:39 +0900 Subject: (IPng 2898) Re: 8+8 Why ESDS are not globally Unique To: bound@zk3.dec.com Date: Fri, 17 Jan 97 17:58:38 JST Cc: dhaskin@BayNetworks.COM, ipng@sunroof.eng.sun.com In-Reply-To: <9701161854.AA23180@wasted.zk3.dec.com>; from "bound@zk3.dec.com" at Jan 16, 97 1:54 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Well I think no scheme should destroy addrconf, ND, the idea of a > Link-Local address at boot time, etc.. but, may simplify or unnecessiate some of them. 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 Fri Jan 17 01:29:50 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03963; Fri, 17 Jan 97 01:29:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03957; Fri, 17 Jan 97 01:29:37 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA14020; Fri, 17 Jan 1997 01:21:02 -0800 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 BAA29574 for ; Fri, 17 Jan 1997 01:21:01 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 17 Jan 1997 09:20:35 +0000 To: ipng@sunroof.eng.sun.com Subject: (IPng 2899) multiple 6bones - 6bone preference routing.... Date: Fri, 17 Jan 1997 09:20:17 +0000 Message-Id: <1207.853492817@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk we just have started discussing a 6bone pilot in the UK academic network, and we had a nice presentation from some guys from Denmark (Martin Peck i think from telebit....) on their trial and implementation work, and the following question came up if we run multiple 6bone pilots with global connectivity, with multiple ipv4 legacy paths between them, can we _choose_ ingress and efgress to ipv4 and ipv6 clouds (i.e. is anyone doing BGP+ or BGP5 or whatever, path preference paramaters that allow an IPv4 net to export route choices that reflect IPv6 source and sink cloud requirements....? sorry if that isn't a clear expression of the requirement, but i'm not up to speed on SIP stuff.... j. ------------------------------------------------------------------------------ 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 Fri Jan 17 04:40:38 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04041; Fri, 17 Jan 97 04:40:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04035; Fri, 17 Jan 97 04:40:25 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA23706; Fri, 17 Jan 1997 04:31:49 -0800 Received: from merit.edu (merit.edu [35.1.1.42]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA26100 for ; Fri, 17 Jan 1997 04:31:50 -0800 Received: from herman.merit.edu (masaki@herman.merit.edu [198.108.60.143]) by merit.edu (8.8.4/merit-2.0) with SMTP id HAA26293; Fri, 17 Jan 1997 07:31:38 -0500 (EST) Message-Id: <199701171231.HAA26293@merit.edu> To: Craig Metz Cc: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= , ipng@sunroof.eng.sun.com Subject: (IPng 2900) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Thu, 16 Jan 1997 22:11:23 EST." <199701162226.WAA00396@inner.net> Date: Fri, 17 Jan 1997 07:31:38 -0500 From: Masaki Hirabaru Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >(2) In my scheme, if link-local scope IPv6 packets don't have 255 > >hop-limit, the kernel must discard it. So, local daemons need not to > >check hop-limit. > > If packets are filtered properly (IMO, source and dest should be > checked for link-locals and the packet never forwarded if either are) then > hop limit tricks shouldn't be needed. Maybe a good chance to ask a question regarding to this topic. At least as long as I know, the RIPng spec requires each implementation to see if the hop limit value in a RIPng packet being received is 255. I can't find the way in the both API drafts to obtain the hop limit value in an inbound packet. If a routing daemon on a Unix-like platform which runs over UDP wants to be conformable, does it have to use the raw IPv6 socket only by this reason? Masaki ------------------------------------------------------------------------------ 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 Fri Jan 17 05:20:30 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04067; Fri, 17 Jan 97 05:20:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04061; Fri, 17 Jan 97 05:20:17 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA26472; Fri, 17 Jan 1997 05:11:41 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA02514 for ; Fri, 17 Jan 1997 05:11:41 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id OAA24723 for ; Fri, 17 Jan 1997 14:11:38 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA29233; Fri, 17 Jan 1997 14:11:38 +0100 Message-Id: <9701171311.AA29233@dxcoms.cern.ch> Subject: (IPng 2901) Re: 8+8 Why do we care? To: ipng@sunroof.eng.sun.com Date: Fri, 17 Jan 1997 14:11:38 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199701132045.PAA00793@pobox.engeast.BayNetworks.COM> from "Dimitry Haskin" at Jan 13, 97 03:45:56 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry, 8+8 supports provider-coalitions above providers; I think that matches the real-world topology better than registry-IDs above providers. Mathematically you are of course correct, but limiting to 256 providers per registry seems infeasible. Brian >--------- Text sent by Dimitry Haskin follows: > > Brian, > > > > > > > 6. Provider Based Addressing RFC 2073: > > > Why not just use this? Whats wrong with it? > > > > It doesn't enforce higher-level aggregation, above ISPs, > > which sets a scaling limit - well above the scaling limit > > for the pre-CIDR Internet, but well below the LSID scaling limit. > > (the small number of bits in the LSID is a key feature) > > > > If you set the ProviderID portion of the RFC-2073 address to 8 bits, > wouldn't you get the same aggregation level as with LSID? > If registries allocate fewer than 8 bits to ProviderID, > even a higher level of aggregation can be achieved with RFC 2073. > > Are you arguing that as far as the level of aggregation is > concerned, it would be better to fix the highest level provider > portion of the address to some small number of bits (to "enforce > higher-level aggregationrather") rather that leave it up to > the registries as is suggested in RFC 2073? > > 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 > ------------------------------------------------------------------------------ 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 Fri Jan 17 05:48:55 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04089; Fri, 17 Jan 97 05:48:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04083; Fri, 17 Jan 97 05:48:43 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA28228; Fri, 17 Jan 1997 05:40:06 -0800 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA07851 for ; Fri, 17 Jan 1997 05:40:08 -0800 Received: from big-dogs.cisco.com ([171.68.53.75]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id FAA10398; Fri, 17 Jan 1997 05:39:26 -0800 Message-Id: <3.0.32.19970117083921.006989c4@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 17 Jan 1997 08:39:28 -0500 To: "Brian Carpenter CERN-CN" From: Paul Ferguson Subject: (IPng 2902) Re: 8+8 Why do we care? Cc: ipng@sunroof.eng.sun.com, kimh@internic.net, dfk@ripe.net, davidc@apnic.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, It might be beneficial to enlist comments of the folks that run the registries. While 256 providers-per-registry might seem like a feasible number, it would be interesting to solicit comments on projected growth in this area. Yes, I know it's hard to project growth with regards to allocation and v6, but perhaps a comparison to v4 allocations would be worthwhile. Of course, this also depends on whether provider-based allocation is the de facto method of allocation. $.02, - paul At 02:11 PM 1/17/97 +0100, Brian Carpenter CERN-CN wrote: >Dimitry, > >8+8 supports provider-coalitions above providers; I think >that matches the real-world topology better than registry-IDs >above providers. Mathematically you are of course correct, but >limiting to 256 providers per registry seems infeasible. > > Brian > >>--------- Text sent by Dimitry Haskin follows: >> >> Brian, >> >> > > >> > > 6. Provider Based Addressing RFC 2073: >> > > Why not just use this? Whats wrong with it? >> > >> > It doesn't enforce higher-level aggregation, above ISPs, >> > which sets a scaling limit - well above the scaling limit >> > for the pre-CIDR Internet, but well below the LSID scaling limit. >> > (the small number of bits in the LSID is a key feature) >> > >> >> If you set the ProviderID portion of the RFC-2073 address to 8 bits, >> wouldn't you get the same aggregation level as with LSID? >> If registries allocate fewer than 8 bits to ProviderID, >> even a higher level of aggregation can be achieved with RFC 2073. >> >> Are you arguing that as far as the level of aggregation is >> concerned, it would be better to fix the highest level provider >> portion of the address to some small number of bits (to "enforce >> higher-level aggregationrather") rather that leave it up to >> the registries as is suggested in RFC 2073? >> >> 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 Fri Jan 17 05:49:30 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04108; Fri, 17 Jan 97 05:49:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04090; Fri, 17 Jan 97 05:48:56 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA28245; Fri, 17 Jan 1997 05:40:19 -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 FAA07889 for ; Fri, 17 Jan 1997 05:40:21 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA100308; Fri, 17 Jan 1997 08:39:40 -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 IAA71870; Fri, 17 Jan 1997 08:39:40 -0500 Received: from lig32-224-57-92.us.lig-dial.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA19260; Fri, 17 Jan 1997 08:40:31 -0500 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 HAA00509; Fri, 17 Jan 1997 07:55:37 -0500 Message-Id: <199701171255.HAA00509@hygro.raleigh.ibm.com> To: Craig Metz Cc: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= , ipng@sunroof.eng.sun.com Subject: (IPng 2903) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Thu, 16 Jan 1997 23:17:35 EST." <199701162332.XAA00830@inner.net> Date: Fri, 17 Jan 1997 07:55:37 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, > Incidentally, if you can't trust your routers to properly filter >link-locals out, do you trust them to process the hop limit >correctly? I think yes. One concern that has been repeatedly expressed is that routers will be tempted to skip the "verify source address != link local" before forwarding in order to shave a few cycles of the (performance critical) forwarding path (despite the arguments that the cost is effectively zero). Doing this won't break things in a way that is instantly apparent to folks, so routers may well be able to get away with it. Indeed, one router vender employee once derisively scoffed at the idea of doing such a check precisely because the cost/benefit. In contrast, a router that doesn't correctly decrement the Hop Limit field is very likely to find itself under scrutiny in a hurry. > I guess I'm just not convinced that we have enough experience with >this to spec out a mandatory solution to this problem. I agree with this too. The main reason the check was put into ND was to insure that ND was no less secure than existing ARP. It is clear that in the absence of bridging, ARP packets originate/terminate on the same link. >The ND spec mandates >the setting and checking of a hop limit of 255. Maybe some other protocol will >want to use zero. I agree with the point you are making, but disagree with your example. :-) Setting the Hop Limit to 0 for ND was also considered, but nixed because of its use to denote node-local scope with multicasting. A packet with a Hop Limit of 0 shouldn't ever appear on a link. 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 Fri Jan 17 05:49:43 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04109; Fri, 17 Jan 97 05:49:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04096; Fri, 17 Jan 97 05:49:02 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA28256; Fri, 17 Jan 1997 05:40:25 -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 FAA07906 for ; Fri, 17 Jan 1997 05:40:26 -0800 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA102086; Fri, 17 Jan 1997 08:39:36 -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 IAA31582; Fri, 17 Jan 1997 08:39:33 -0500 Received: from lig32-224-57-92.us.lig-dial.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA19256; Fri, 17 Jan 1997 08:40:26 -0500 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 IAA00658; Fri, 17 Jan 1997 08:32:12 -0500 Message-Id: <199701171332.IAA00658@hygro.raleigh.ibm.com> To: "W. Richard Stevens" Cc: Kazu Yamamoto , ipng@sunroof.eng.sun.com Subject: (IPng 2904) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Thu, 16 Jan 1997 09:53:49 MST." <199701161653.JAA04217@kohala.kohala.com> Date: Fri, 17 Jan 1997 08:32:12 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, >> Moreover, if the SO_DONTROUTE option is specified, what will happen? >As I understand this socket option it says "don't look up the destination >in the routing table, assume it's on-link, and if not, error". The kernel >then looks up the destination in its interface tables, not the routing >table. I would say if the interface located this way is not the same >as one specified to sendmsg(), then error. One thing I can't help but wonder is whether the SO_DONTROUTE is implemented correctly these days. You observe that the only application that uses it is routed (gated probably does too). Routed needs it so that it can still send out packets, even if the routing tables are empty/incorrect (e.g., routed deleted the route through an interface because the interface is dead). If routed can't send out packets, it won't ever restore the routes should the interface recover. I don't have the BSD sources in front of me right now, but is it the case that when the kernel looks up a route in its interface table it does a proper "longest match" lookup when multiple interfaces match? It seems to me that the clean way to achieve the effect of SO_DONTROUTE is to have the application indicate which interface to send the packet out on (analogous to the multicast case), which is in fact what routed intends to do. 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 Fri Jan 17 05:49:46 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04110; Fri, 17 Jan 97 05:49:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04097; Fri, 17 Jan 97 05:49:03 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA28262; Fri, 17 Jan 1997 05:40:27 -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 FAA07904 for ; Fri, 17 Jan 1997 05:40:26 -0800 Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA100326; Fri, 17 Jan 1997 08:39:45 -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 IAA43930; Fri, 17 Jan 1997 08:39:48 -0500 Received: from lig32-224-57-92.us.lig-dial.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA19264; Fri, 17 Jan 1997 08:40:35 -0500 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 IAA00563; Fri, 17 Jan 1997 08:08:43 -0500 Message-Id: <199701171308.IAA00563@hygro.raleigh.ibm.com> To: huitema@bellcore.com (Christian Huitema) Cc: dhaskin@BayNetworks.COM (Dimitry Haskin), ipng@sunroof.eng.sun.com Subject: (IPng 2905) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Thu, 16 Jan 1997 17:52:06 EST." <9701161752.ZM24288@seawind.bellcore.com> Date: Fri, 17 Jan 1997 08:08:43 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, What does your proposal have to do with 8+8? Seriously. What strikes me about your note is that is how little 8+8 has to do with it. That is, it would seem that the same scheme could be made with PBA and the current IPv6 model. That is: 1) the RG is nothing different than the provider prefix, except that we've decreed that the ISP/provider prefix is the first 8 bytes. (Which is nothing new, since it's pretty much an assumption anyway.) 2) One question is whether you believe the TCP pseudo-header should cover only 8 or 16 bytes of the address (arguments could be made either way). If only 8, that is a feature it retains from 8+8. Otherwise, it isn't obvious to me that it retains any of the 8+8 changes. (It isn't immediately obvious to me that routers still needed to rewrite the RG part.) 3) In your proposal, site renumbering would appear to be done using stateless addrconf/DHCP as already defined. The immediate question I have is whether this is actually "too painful in practice" to be viable. That is, isn't this the problem motivating Mike's 8+8 proposal with rewritable RG in the first place? 4) Lot's of reshuffling in the DNS to make it all work, but it seems feasible at first cut, assuming the circular/recursive dependencies between routing and DNS can be worked out. > The condition there is to step down one notch from Mike O'Dell's initial > objective, and leave domain administrators with some controls on the RG > that can be used on their behalf. basically, if they cannot sign the RG in > teh DNS, then partners have no insurance that the packet does originate > from their domain. One thing that the initial 8+8 proposal glosses over a bit is the DNS. One queries the DNS to get the AAAA record for a name, and the returned AAAA record includes the routing goop as part of the address. Well, ISPs won't be able to just change the RG on their own without closely coordinating such renumberings with DNS administrators. The DNS is glued together via hard-coded IP addresses. Changing a site's RG without also changing the hard-coded IP addresses the site's parent DNS servers have pointing that point to he site's DNS servers would result in DNS lookup failures. 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 Fri Jan 17 06:56:29 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04199; Fri, 17 Jan 97 06:56:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04193; Fri, 17 Jan 97 06:56:18 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA04773; Fri, 17 Jan 1997 06:47:43 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA26781 for ; Fri, 17 Jan 1997 06:47:41 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id JAA24616; Fri, 17 Jan 1997 09:47:33 -0500 Date: Fri, 17 Jan 1997 09:47:33 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9701170947.ZM24614@seawind.bellcore.com> In-Reply-To: Thomas Narten "Re: (IPng 2887) Re: 8+8 Why ESDS are not globally Unique" (Jan 17, 8:08am) References: <199701171308.IAA00563@hygro.raleigh.ibm.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: Thomas Narten Subject: (IPng 2906) Re: 8+8 Why ESDS are not globally Unique 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 On Jan 17, 8:08am, Thomas Narten wrote: > Subject: Re: (IPng 2887) Re: 8+8 Why ESDS are not globally Unique > Christian, > > What does your proposal have to do with 8+8? A lot. Basically, 8+8 aims at facilitating global site renumbering by making it easy to swap prefixes on the fly. The proposal I am making concentrates on organizing data in the DNS so that: a) the equivalence between several RG is well defined, b) all DNS records of an organization are updated simultaneously by changing exactly one entry when a new RG is added, c) DNS security can be applied to "prove" that two RG belong to the same entity, hence enabling TCP connections to survive renumbering and remain safe. The one difference with Mike's initial proposal is that customers are aware of the RG that can be used to reach them, so they can insert these RG in their DNS entries, and also in their partners' firewalls, ACL, etc. > 1) the RG is nothing different than the provider prefix, except that > we've decreed that the ISP/provider prefix is the first 8 > bytes. (Which is nothing new, since it's pretty much an assumption > anyway.) Establishing a well delineated boundary between "site prefix" and ESD, in precisely the way that Mike originally proposed, greatly helps "site renumbering" and "site multihoming". By the way, this should be a site prefix, and the ESD should definitely be 2+6, as Mike originally proposed. The reason for that is the atomicity of changes. When you add a multihoming link, you add it to a "site"; you want to modify exactly one information. > 2) One question is whether you believe the TCP pseudo-header should > cover only 8 or 16 bytes of the address (arguments could be made > either way). If only 8, that is a feature it retains from > 8+8. Otherwise, it isn't obvious to me that it retains any of the 8+8 > changes. (It isn't immediately obvious to me that routers still needed > to rewrite the RG part.) I believe it should be 8, not 16, if we want to allow easy multihoming. What stalled all previous "connection maintenance during renumbering" proposal was the security issue. We can show a clear solution to that problem if a separate DNS record holds all valid RG for a site. The DNS record can be signed, according to DNS security. I also believe that the PCB should be identified (looked for) with the full 16 bytes of address. That gives us two states for TCP: a) today, change nothing except the checksum computation. The pair of addresses (i.e. the two RG+ESD tuples) remain constant for the whole duration of the connection. This is in fact Mike's initial proposal, and the only one that can be adopted without security extensions. b) on a new release, allow PCBs to hold both one ESD and a set of RG for the partner, or alternatively a set of ESD/RG pairs. This implies a secure way to associate the RG+ESD to the destination. Reverse DNS look-up protected by DNSSEC give one solution. There may be other solutions as well, that do not involve the DNS, e.g. using DNS security. In any case, this require evolution of TCP, and possibly extensions to the API. > 3) In your proposal, site renumbering would appear to be done using > stateless addrconf/DHCP as already defined. The immediate question I > have is whether this is actually "too painful in practice" to be > viable. That is, isn't this the problem motivating Mike's 8+8 proposal > with rewritable RG in the first place? I am not sure that Mike assessment is correct. Site renumbering may not be that painful, at least for hosts that use addrconf. But there are several ways in which we can help: a) rewriting destination addresses at site borders for incoming messages is almost free, allow not yet renumbered segments to keep using the same old destination address. b) single point of update for the DNS allows a much easier management, avoid the storm of updates that result from addrconf if each AAAA record had to be modified separately upon renumbering. c) clear 8+8 delineation allow the design of an ICMP message sent to "all routers on the site" that passes the "set of RG of the day". This can be done without changing addrconf, results in all prefixes being updated simulatneously. > 4) Lot's of reshuffling in the DNS to make it all work, but it seems > feasible at first cut, assuming the circular/recursive dependencies > between routing and DNS can be worked out. The proposed split of AAAA records in RG+ESD follows a well known rule of data base design -- store atomic objects in atomic records, use pointers rather than copy values. Following that rule results in a lot of good things. Management is much simpler, there are no batches of updates but only single ones, caching works better. It has one down side, though. Requires two access instead of one to get the addresses. But the better cache efficiency compensates somewhat, and we could always make a rule on the propagation of additional records, i.e. always send the RG when the ESD is asked for. In fact, as soon that the number of RG is larger than 2, the combination of 1 ESD record and N RG records requires less bytes in the DNS response than the raw transmission of N AAAA records. -- 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 Fri Jan 17 08:20:08 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04281; Fri, 17 Jan 97 08:20:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04275; Fri, 17 Jan 97 08:19:57 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA15243; Fri, 17 Jan 1997 08:11:21 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA25307 for ; Fri, 17 Jan 1997 08:11:08 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id JAA05046; Fri, 17 Jan 1997 09:10:48 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id JAA02422; Fri, 17 Jan 1997 09:10:47 -0700 (MST) Message-Id: <199701171610.JAA02422@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Fri, 17 Jan 1997 09:10:47 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Thomas Narten Subject: (IPng 2907) Re: Forward: hlim and IF on API Cc: Kazu Yamamoto , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Jan 17, 8:32am you write:] > > It seems to me that the clean way to achieve the effect of > SO_DONTROUTE is to have the application indicate which interface to > send the packet out on (analogous to the multicast case), which is in > fact what routed intends to do. Since the advanced API provides a way to send a packet out a specified interface (designated by its interface index), doesn't this make the SO_DONTROUTE option unnecessary? Rich Stevens ------------------------------------------------------------------------------ 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 Fri Jan 17 08:30:24 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04301; Fri, 17 Jan 97 08:30:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04295; Fri, 17 Jan 97 08:30:09 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA16800; Fri, 17 Jan 1997 08:21:28 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA29172 for ; Fri, 17 Jan 1997 08:21:28 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA23568 for ; Fri, 17 Jan 1997 17:21:26 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA03326; Fri, 17 Jan 1997 17:21:22 +0100 Message-Id: <9701171621.AA03326@dxcoms.cern.ch> Subject: (IPng 2908) Re: 8+8 Why do we care? To: ipng@sunroof.eng.sun.com Date: Fri, 17 Jan 1997 17:21:22 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9701131505.AA15695@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Jan 13, 97 10:05:20 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > >2.+3. together: 8+8 allows renumbering without breaking TCP sessions > >and SAs, if that is important to you. > > Do you believe the destination address leaving from the application > should have RG + ESD in its address, and not altered by the transit of > the packet? > > If yes then it does not automatically handle existing connections being > renumberd unless you believe the pcb look up will work with just the ESD? > I am not convinced that is true yet for the ESDs. That is the question. As I said later, I don't think there is much point in changing to 8+8 unless we allow for rewriting in transit - that is key for multihoming (see below). If the only issue is aggregation without multihoming, then some slight fiddling with the PBA to make it LSID-based instead of registry-based would be enough. The discussion about ESD uniqueness is raging on another thread. > > If no then the security problems occur that I have to differentiate in > some way at the pcb look up to verify its the same person I am talking > too. > > Also most of us care about UDP too and that has other ramifications. > UNless your in the camp that believes you don't care about UDP? We need UDP. But UDP today trusts an unverified 32 bit identifier, so I think it could trust a 64 bit ESD instead. > > Also the work Pedro, Charlie, and I are working on will renumber > connections without the risk of 8+8. So if all we want is renumbering > that can be done with much less pain than 8+8. > Yes, and what you are doing is an absolute necessity if we do *not* change to 8+8. > >> > >> 7. Is 8+8 useful if we do not permit packets to be altered in > >> transit? > > >It is not useful to deploy it unless we architect it to permit rewriting > > So all the benefits you just listed do not exist without rewriting? > Why is that? It feels like a contradiction? As I said above, it's because of multihoming: the sending host cannot reasonably be asked to do RG selection for a multihomed destination, or to know which local RG to use as its source if the local site is multihomed. Only the routing system can possess that knowledge. > > >> > >> 8. Do we have any implementation experience with in transit > >> packets being altered as it severly breaks the IPv4 model? > >> > >That's why we wrote draft-iab-ip-ad-today-01.txt > > > >NAT was never architected properly - we have a chance to do > >so with 8+8 > > To some degree because the RG can be rewritten. It still don't help > with transition? Or have you changed your view on this because of 8+8? > RFC 1671???? No, in 1671 I was discussing semantic translation of header fields, and I specifically excluded NAT from the discussion. > > >> 9. We have momentum now with IPv6 and the market wants it > >> and needs IPv6 deployed to what extent should 8+8 be > >> permitted to hold up deployement of IPv6? > >> > >It is claimed that the absence of 8+8 will hold up > >deployment, because the ISPs are reluctant to deploy > >provider-based. We need to evaluate this claim. > > I have had some private mail that goes like this: > > If 6bone keeps evolving. If routers keep building IPv6. If UNIX and PC > desktop vendors keep building IPv6. If customers on the Intranet start > deployment. The ISPs will deploy once they see they can make a profit > on IPv6, as opposed to saving person-kind from the evils of provider > basesd addressing. > Yes. But we need to decide whether 8+8 is the right thing to do engineering-wise. Brian ------------------------------------------------------------------------------ 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 Fri Jan 17 08:52:02 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04319; Fri, 17 Jan 97 08:52:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04313; Fri, 17 Jan 97 08:51:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA20117; Fri, 17 Jan 1997 08:43:14 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA07973 for ; Fri, 17 Jan 1997 08:43:11 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id LAA01055; Fri, 17 Jan 1997 11:57:28 GMT Message-Id: <199701171157.LAA01055@inner.net> To: Masaki Hirabaru Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2909) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Fri, 17 Jan 1997 07:31:38 EST." <199701171231.HAA26293@merit.edu> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 17 Jan 1997 11:42:58 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199701171231.HAA26293@merit.edu>, you write: >Maybe a good chance to ask a question regarding to this topic. At >least as long as I know, the RIPng spec requires each >implementation to see if the hop limit value in a RIPng packet >being received is 255. I can't find the way in the both API >drafts to obtain the hop limit value in an inbound packet. If a >routing daemon on a Unix-like platform which runs over UDP wants >to be conformable, does it have to use the raw IPv6 socket only >by this reason? I've proposed (and built, you need it to properly implement traceroute and ping and it helped radvd and should help RIPng): int on=1; if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, &on, sizeof(int)) < 0) ... And an IPPROTO_IPV6/IPV6_HOPLIMIT control message that specifies the hop limit on outgoing datagrams and receives (if turned on as above) the hop limit on incoming datagrams. -Craig ------------------------------------------------------------------------------ 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 Fri Jan 17 09:30:19 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04392; Fri, 17 Jan 97 09:30:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04386; Fri, 17 Jan 97 09:30:07 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA27344; Fri, 17 Jan 1997 09:21:29 -0800 Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA24136 for ; Fri, 17 Jan 1997 09:21:26 -0800 Received: (konczal@localhost) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) id MAA26862; Fri, 17 Jan 1997 12:15:46 -0500 Date: Fri, 17 Jan 1997 12:15:46 -0500 Message-Id: <199701171715.MAA26862@csmes.ncsl.nist.gov> From: Joe Konczal To: narten@raleigh.ibm.com Cc: solensky@ftp.com, ipng@sunroof.eng.sun.com In-Reply-To: <199701140228.VAA14099@hygro.raleigh.ibm.com> (message from Thomas Narten on Mon, 13 Jan 1997 21:28:32 -0500) Subject: (IPng 2910) Re: 8+8 Why ESDS are not globally Unique Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I know a network designer and installer who frequently recieves large shipments of ethernet cards and installs them on a small number of LANs. He says that he occasionally encounters duplicate addresses, and he even recieved one card with an address of all zeros. I'll ask if he can provide any statistics. -- Joe Konczal National Institute of Standards and Technology Building 820, Room 410 Phone: (301) 975-3285 Gaithersburg, MD 20899 USA Fax: (301) 948-0279 ------------------------------------------------------------------------------ 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 Fri Jan 17 09:48:15 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04416; Fri, 17 Jan 97 09:48:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04407; Fri, 17 Jan 97 09:48:00 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA01098; Fri, 17 Jan 1997 09:39:23 -0800 Received: from merit.edu (merit.edu [35.1.1.42]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA01487 for ; Fri, 17 Jan 1997 09:39:19 -0800 Received: from herman.merit.edu (masaki@herman.merit.edu [198.108.60.143]) by merit.edu (8.8.4/merit-2.0) with SMTP id MAA01759; Fri, 17 Jan 1997 12:39:06 -0500 (EST) Message-Id: <199701171739.MAA01759@merit.edu> To: Craig Metz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2911) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Fri, 17 Jan 1997 11:42:58 EST." <199701171157.LAA01055@inner.net> Date: Fri, 17 Jan 1997 12:39:05 -0500 From: Masaki Hirabaru Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, I found your proposal in (IPng 2675) dated Jan 2 (I've missed it, sorry). I'd like to see it in the next revision of API draft. Thanks. Masaki > Message-Id: <199701171157.LAA01055@inner.net> > To: Masaki Hirabaru > cc: ipng@sunroof.Eng.Sun.COM > Subject: Re: (IPng 2890) Re: Forward: hlim and IF on API > In-reply-to: Your message of "Fri, 17 Jan 1997 07:31:38 EST." > <199701171231.HAA26293@merit.edu> > X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. > X-Reposting: With explicit permission only > Date: Fri, 17 Jan 1997 11:42:58 -0500 > From: Craig Metz > > In message <199701171231.HAA26293@merit.edu>, you write: > >Maybe a good chance to ask a question regarding to this topic. At > >least as long as I know, the RIPng spec requires each > >implementation to see if the hop limit value in a RIPng packet > >being received is 255. I can't find the way in the both API > >drafts to obtain the hop limit value in an inbound packet. If a > >routing daemon on a Unix-like platform which runs over UDP wants > >to be conformable, does it have to use the raw IPv6 socket only > >by this reason? > > I've proposed (and built, you need it to properly implement traceroute > and ping and it helped radvd and should help RIPng): > > int on=1; > if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, &on, sizeof(int)) < 0) > ... > > And an IPPROTO_IPV6/IPV6_HOPLIMIT control message that specifies the > hop limit on outgoing datagrams and receives (if turned on as above) the hop > limit on incoming datagrams. > > -Craig ------------------------------------------------------------------------------ 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 Fri Jan 17 09:51:24 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04430; Fri, 17 Jan 97 09:51:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04424; Fri, 17 Jan 97 09:51:11 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA01710; Fri, 17 Jan 1997 09:42:35 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA02922 for ; Fri, 17 Jan 1997 09:42:34 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id MAA01278; Fri, 17 Jan 1997 12:56:53 GMT Message-Id: <199701171256.MAA01278@inner.net> To: Masaki Hirabaru Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2912) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Fri, 17 Jan 1997 12:39:05 EST." <199701171739.MAA01759@merit.edu> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 17 Jan 1997 12:42:25 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199701171739.MAA01759@merit.edu>, you write: >I found your proposal in (IPng 2675) dated Jan 2 (I've missed it, >sorry). I'd like to see it in the next revision of API draft. Last I heard, it will be in the next advanced API draft whever it hits the streets. -Craig ------------------------------------------------------------------------------ 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 Fri Jan 17 09:57:50 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04447; Fri, 17 Jan 97 09:57:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04441; Fri, 17 Jan 97 09:57:38 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA02971; Fri, 17 Jan 1997 09:49:02 -0800 Received: from cnrmail.lbl.gov (buster.lbl.gov [131.243.65.29]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA05785 for ; Fri, 17 Jan 1997 09:49:01 -0800 Received: from [128.3.9.22] by cnrmail.lbl.gov with ESMTP (Apple Internet Mail Server 1.1.1); Fri, 17 Jan 1997 09:48:59 -0800 X-Sender: rlfink@cnrmail.lbl.gov Message-Id: In-Reply-To: <1207.853492817@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Jan 1997 09:48:55 -0800 To: Jon Crowcroft From: Bob Fink LBNL Subject: (IPng 2913) Re: multiple 6bones - 6bone preference routing.... Cc: ipng@sunroof.eng.sun.com, 6bone@isi.edu (6BONE Mailer) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jon, At 1:20 AM -0800 1/17/97, Jon Crowcroft wrote: >we just have started discussing a 6bone pilot in the UK academic >network, and we had a nice presentation from some guys from Denmark >(Martin Peck i think from telebit....) on their trial and >implementation work, and the following question came up > >if we run multiple 6bone pilots with global connectivity, with >multiple ipv4 legacy paths between them, can we _choose_ ingress and >efgress to ipv4 and ipv6 clouds (i.e. is anyone doing BGP+ or BGP5 or >whatever, path preference paramaters that allow an IPv4 net to export >route choices that reflect IPv6 source and sink cloud >requirements....? Don't think we have other than static routes, RIPng and IDRPv6 between various sites at this time. I believe we are waiting on the outcome of the Katz/Haskin et al BGP4 v6 extensions versus IDRPv6 discussions before BGP comes into real use. As far as ingress/egress to the existing 6bone, my opinion is that you should connect as a "core backbone" site and establish connectivity and peering with other backbone sites as you think it makes sense (it is all still v6 over v4 tunnels). That is, at the moment, choice of interconnect is pretty wide open. I have included my newest diagram of the 6bone which may be of use to you: http://www-6bone.lbl.gov/6bone/6bone-newdrawing.GIF >sorry if that isn't a clear expression of the requirement, but >i'm not up to speed on SIP stuff.... Hope you guys hook up - it will be a great addition to the 6bone testbed! Thanks, 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 Fri Jan 17 10:04:59 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04479; Fri, 17 Jan 97 10:04:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04473; Fri, 17 Jan 97 10:04:47 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA04563; Fri, 17 Jan 1997 09:56:11 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA08749 for ; Fri, 17 Jan 1997 09:56:04 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id KAA05169; Fri, 17 Jan 1997 10:55:45 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id KAA02631; Fri, 17 Jan 1997 10:55:45 -0700 (MST) Message-Id: <199701171755.KAA02631@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Fri, 17 Jan 1997 10:55:44 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Masaki Hirabaru , Craig Metz Subject: (IPng 2914) Re: Forward: hlim and IF on API Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig's proposal will indeed be in the next revision of the advanced API. Rich Stevens > Craig, > > I found your proposal in (IPng 2675) dated Jan 2 (I've missed it, > sorry). I'd like to see it in the next revision of API draft. > Thanks. > > Masaki > > > Date: Fri, 17 Jan 1997 11:42:58 -0500 > > From: Craig Metz > > > > I've proposed (and built, you need it to properly implement traceroute > > and ping and it helped radvd and should help RIPng): > > > > int on=1; > > if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, &on, sizeof(int)) < 0) > > ... > > > > And an IPPROTO_IPV6/IPV6_HOPLIMIT control message that specifies the > > hop limit on outgoing datagrams and receives (if turned on as above) the hop > > limit on incoming datagrams. ------------------------------------------------------------------------------ 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 Fri Jan 17 10:23:04 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04525; Fri, 17 Jan 97 10:23:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04519; Fri, 17 Jan 97 10:22:52 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA09524; Fri, 17 Jan 1997 10:14:11 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA16751 for ; Fri, 17 Jan 1997 10:14:10 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA10579; Fri, 17 Jan 1997 13:02:21 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24587; Fri, 17 Jan 1997 13:02:19 -0500 Message-Id: <9701171802.AA24587@wasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2915) Re: 8+8 Why do we care? In-Reply-To: Your message of "Fri, 17 Jan 97 17:21:22 +0100." <9701171621.AA03326@dxcoms.cern.ch> Date: Fri, 17 Jan 97 13:02:18 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Thanks for the response. Multihome: On the multihome problem. I view this not a problem for an application anymore than the problem we have today permitting multiple addresses for a name in DNS. When one does a gethostbyname() one can get back a 100 addresses theoretically. Same is true if it has a different RG attachment for the ESD two times. Christian is I believe trying to address this problem but we need to make sure we address two problems. 1) How does an application know which RG to use? I claim unless their FQDN is different you cannot solve this problem unless we make a significant change to DNS. 2) How does a routing path send to a different multihome destination point? This will work the way 8+8 is designed now because the ESD exists. Renumbering: A problem with packets being altered in transit is when they want to convey addresses in applications to remote end nodes too. Such as the FTP PORT command. Our work on dynamic renumbering permits this to be done on a per connection basis dynamically 8+8 does not, as its out of the control of the end node. Many other things we need to verify don't break either like end-to-end flows between applications. Lots of proposals: I still have not commented on Alan O'Neill's draft but reading it now this is another approach being proposed "engineeringwise". /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 Fri Jan 17 10:42:21 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04578; Fri, 17 Jan 97 10:42:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03755; Thu, 16 Jan 97 22:44:33 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA04712; Thu, 16 Jan 1997 22:35:59 -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 WAA07733 for ; Thu, 16 Jan 1997 22:35:53 -0800 From: Masataka Ohta Message-Id: <199701170633.PAA13140@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA13140; Fri, 17 Jan 1997 15:33:22 +0900 Subject: (IPng 2916) Re: multihoming alternative To: george@gideon.bt.co.uk (George Tsirtsis) Date: Fri, 17 Jan 97 15:33:21 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: ; from "George Tsirtsis" at Jan 16, 97 11:43 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alan O'Neill; > Note that renumbering is a > consequence of this problem because as I change provider, whether simply > for multi-homing, I must change address or suffer routing inefficiencies. No. Renumbering is also necessary when a lower level provider(s) switches upper level providers. It should also be noted that it is quite likely that some provider may be multihomed to multiple upper level providers. 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 Fri Jan 17 10:47:04 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04594; Fri, 17 Jan 97 10:47:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04168; Fri, 17 Jan 97 06:15:10 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA00758; Fri, 17 Jan 1997 06:06:35 -0800 Received: from ncc.ripe.net (ncc.ripe.net [193.0.0.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA14548 for ; Fri, 17 Jan 1997 06:06:33 -0800 Received: from kantoor.ripe.net by ncc.ripe.net with SMTP id AA29279 (5.65a/NCC-2.40); Fri, 17 Jan 1997 15:05:52 +0100 Message-Id: <9701171405.AA29279@ncc.ripe.net> To: Paul Ferguson Cc: "Brian Carpenter CERN-CN" , ipng@sunroof.eng.sun.com, kimh@internic.net, davidc@apnic.net Subject: (IPng 2917) Re: 8+8 Why do we care? In-Reply-To: Your message of Fri, 17 Jan 1997 08:39:28 EST. <3.0.32.19970117083921.006989c4@lint.cisco.com> References: <3.0.32.19970117083921.006989c4@lint.cisco.com> From: Daniel Karrenberg X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Date: Fri, 17 Jan 1997 15:05:49 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The RIPE NCC currently has 544 local IRs (providers) who value independence from upstreams/coalitions enough to pay us directly for registration services. We expect to have short of 900 by the end of the year. Daniel > Paul Ferguson writes: > Brian, > > It might be beneficial to enlist comments of the folks > that run the registries. While 256 providers-per-registry > might seem like a feasible number, it would be interesting > to solicit comments on projected growth in this area. Yes, > I know it's hard to project growth with regards to allocation > and v6, but perhaps a comparison to v4 allocations would > be worthwhile. Of course, this also depends on whether > provider-based allocation is the de facto method of allocation. > > $.02, > > - paul > > At 02:11 PM 1/17/97 +0100, Brian Carpenter CERN-CN wrote: > > >Dimitry, > > > >8+8 supports provider-coalitions above providers; I think > >that matches the real-world topology better than registry-IDs > >above providers. Mathematically you are of course correct, but > >limiting to 256 providers per registry seems infeasible. > > > > Brian > > > >>--------- Text sent by Dimitry Haskin follows: > >> > >> Brian, > >> > >> > > > >> > > 6. Provider Based Addressing RFC 2073: > >> > > Why not just use this? Whats wrong with it? > >> > > >> > It doesn't enforce higher-level aggregation, above ISPs, > >> > which sets a scaling limit - well above the scaling limit > >> > for the pre-CIDR Internet, but well below the LSID scaling limit. > >> > (the small number of bits in the LSID is a key feature) > >> > > >> > >> If you set the ProviderID portion of the RFC-2073 address to 8 bits, > >> wouldn't you get the same aggregation level as with LSID? > >> If registries allocate fewer than 8 bits to ProviderID, > >> even a higher level of aggregation can be achieved with RFC 2073. > >> > >> Are you arguing that as far as the level of aggregation is > >> concerned, it would be better to fix the highest level provider > >> portion of the address to some small number of bits (to "enforce > >> higher-level aggregationrather") rather that leave it up to > >> the registries as is suggested in RFC 2073? > >> > >> 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 Fri Jan 17 10:51:36 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04614; Fri, 17 Jan 97 10:51:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04265; Fri, 17 Jan 97 08:04:19 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA12643; Fri, 17 Jan 1997 07:55:44 -0800 Received: from jazz.internic.net (jazz.internic.net [198.41.0.134]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA20040 for ; Fri, 17 Jan 1997 07:55:43 -0800 Received: (kimh@localhost) by jazz.internic.net (8.8.3/SLAM-1) id LAA04805; Fri, 17 Jan 1997 11:03:25 -0500 (EST) From: Kim Hubbard Message-Id: <199701171603.LAA04805@jazz.internic.net> Subject: (IPng 2918) Re: 8+8 Why do we care? To: Daniel.Karrenberg@ripe.net (Daniel Karrenberg) Date: Fri, 17 Jan 1997 11:03:25 -0500 (EST) Cc: pferguso@Cisco.COM, brian@dxcoms.cern.ch, ipng@sunroof.eng.sun.com, kimh@internic.net, davidc@apnic.net In-Reply-To: <9701171405.AA29279@ncc.ripe.net> from "Daniel Karrenberg" at Jan 17, 97 03:05:49 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would have to say that 256 providers-per-registry would not be feasible. Kim > > The RIPE NCC currently has 544 local IRs (providers) who > value independence from upstreams/coalitions enough to pay > us directly for registration services. We expect to have > short of 900 by the end of the year. > > Daniel > > > Paul Ferguson writes: > > Brian, > > > > It might be beneficial to enlist comments of the folks > > that run the registries. While 256 providers-per-registry > > might seem like a feasible number, it would be interesting > > to solicit comments on projected growth in this area. Yes, > > I know it's hard to project growth with regards to allocation > > and v6, but perhaps a comparison to v4 allocations would > > be worthwhile. Of course, this also depends on whether > > provider-based allocation is the de facto method of allocation. > > > > $.02, > > > > - paul > > > > At 02:11 PM 1/17/97 +0100, Brian Carpenter CERN-CN wrote: > > > > >Dimitry, > > > > > >8+8 supports provider-coalitions above providers; I think > > >that matches the real-world topology better than registry-IDs > > >above providers. Mathematically you are of course correct, but > > >limiting to 256 providers per registry seems infeasible. > > > > > > Brian > > > > > >>--------- Text sent by Dimitry Haskin follows: > > >> > > >> Brian, > > >> > > >> > > > > >> > > 6. Provider Based Addressing RFC 2073: > > >> > > Why not just use this? Whats wrong with it? > > >> > > > >> > It doesn't enforce higher-level aggregation, above ISPs, > > >> > which sets a scaling limit - well above the scaling limit > > >> > for the pre-CIDR Internet, but well below the LSID scaling limit. > > >> > (the small number of bits in the LSID is a key feature) > > >> > > > >> > > >> If you set the ProviderID portion of the RFC-2073 address to 8 bits, > > >> wouldn't you get the same aggregation level as with LSID? > > >> If registries allocate fewer than 8 bits to ProviderID, > > >> even a higher level of aggregation can be achieved with RFC 2073. > > >> > > >> Are you arguing that as far as the level of aggregation is > > >> concerned, it would be better to fix the highest level provider > > >> portion of the address to some small number of bits (to "enforce > > >> higher-level aggregationrather") rather that leave it up to > > >> the registries as is suggested in RFC 2073? > > >> > > >> 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 Fri Jan 17 11:04:51 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04637; Fri, 17 Jan 97 11:04:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04631; Fri, 17 Jan 97 11:04:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA19098; Fri, 17 Jan 1997 10:56:02 -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 KAA07973 for ; Fri, 17 Jan 1997 10:55:58 -0800 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA62424; Fri, 17 Jan 1997 13:53:38 -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 NAA39348; Fri, 17 Jan 1997 13:53:34 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA17262; Fri, 17 Jan 1997 13:54:27 -0500 Message-Id: <9701171854.AA17262@ludwigia.raleigh.ibm.com> To: "W. Richard Stevens" Cc: Kazu Yamamoto , ipng@sunroof.eng.sun.com Subject: (IPng 2919) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Fri, 17 Jan 1997 09:10:47 MST." <199701171610.JAA02422@kohala.kohala.com> Date: Fri, 17 Jan 1997 13:54:27 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Since the advanced API provides a way to send a packet out a specified >interface (designated by its interface index), doesn't this make the >SO_DONTROUTE option unnecessary? I would think so. In fact, with link-local destinations, the SO_DONTROUTE option wouldn't work right anyway, since all interfaces would "match" when sending an outgoing packet. I think SO_DONTROUTE has been around since pretty early days. It's probably outlived its usefulness. 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 Fri Jan 17 15:38:15 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05018; Fri, 17 Jan 97 15:38:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05012; Fri, 17 Jan 97 15:37:54 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA09830; Fri, 17 Jan 1997 15:29:17 -0800 Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA17214 for ; Fri, 17 Jan 1997 15:28:55 -0800 Received: from max121.frontier-networks.co.uk ([195.200.12.121]) by relay-9.mail.demon.net id aa908117; 17 Jan 97 23:03 GMT Message-Id: Date: Fri, 17 Jan 1997 22:28:28 +0000 To: ipng@sunroof.eng.sun.com From: Thomas Lee Subject: (IPng 2920) Re: MOs' 8+8 In-Reply-To: <199701082221.RAA04148@MAILSERV-2HIGH.FTP.COM> Mime-Version: 1.0 X-Mailer: Turnpike Version 3.02 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk x-no-archive: yes In article <199701082221.RAA04148@MAILSERV-2HIGH.FTP.COM>, Frank T Solensky writes >>.. By that time >>the lack of an IPv6 stack on Microsoft desktops and servers will be >>the show stopper. > >#include > >FTP Software has some support for it. Send mail to JD Stanley >(jstanley@ftp.com) for more info.. At teh moment - it's win95 only. The IP6 stuff isn't in the NT version (AIUI). From the packet traces I've seen, it does initialise ok, but I've only got one WIn95 host to test. NT's network monitor does a poor job of decoding packets - I've had to do it by hand. It does look ok though - I'll be doing more testing once our other ws's arrive. Thomas -- Thomas Lee (email: tfl@psp.co.uk, web: http://www.psp.demon.co.uk/tfl/tfl.htm) Microsoft Certified Systems Engineer and Certified Trainer PS Partnership - A Microsoft Solution Provider Ph: +44 1628 850 077 Fax: +44 1628 850 143 ------------------------------------------------------------------------------ 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 Fri Jan 17 17:44:46 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05135; Fri, 17 Jan 97 17:44:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05129; Fri, 17 Jan 97 17:44:34 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA29612; Fri, 17 Jan 1997 17:35:58 -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 RAA24250 for ; Fri, 17 Jan 1997 17:35:58 -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 RAA07729; Fri, 17 Jan 1997 17:35:57 -0800 Message-Id: <3.0.32.19970117173449.007580f4@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 17 Jan 1997 17:35:11 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 2921) Directions and Hotel Information for IPng Interim Meeting Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk LOCATION The IPng working group meeting on Feb 27 and 28 will be held at the Sun Microsystems facility in Palo Alto at 901 San Antonio Road. The building is called "PAL01". Entrance into the building should be at the main lobby, as the meeting rooms are adjacent to the receptionist. No badges will be necessary to access the meeting rooms. Suggested parking is in any spot NOT labeled as a "visitor spot". Any unlabeled parking spot is fine for all day parking. DIRECTIONS Sun Microsystems, PAL01 bldg. 901 San Antonio Road Palo Alto, CA 94303 Going South from San Francisco, take 101 South towards San Jose. Exit on San Antonio Road South towards Los Altos (the first San Antonio Road Exit). Stay in the right hand lane approximately .3 miles and look for the Sun sign and driveway entrance into the Palo Alto campus. Enter at the main Lobby. Going North from San Jose, take 101 North towards San Francisco. Exit on San Antonio Road and turn left at the stop sign (at the end of the off ramp). Travel on San Antonio Road back over the freeway. Stay in the right hand lane approximately .3 miles and look for the Sun sign and driveway entrance into the Palo Alto campus. Enter at the main Lobby. LOCAL HOTELS Palo Alto --------- HYATT RICKEY'S (closest to meeting) 4219 El Camino Real Palo Alto, CA 94306 PH 415/493-8000 FX 415/424-0836 HOLIDAY INN PALO ALTO 625 El Camino Real Palo Alto, CA 94301 PH 415/328-2800 800/874-3516 Mountain View ------------- RESIDENCE INN (next to closest) 1854 El Camino Real West Mt. View, CA 94040 PH 415/940-1300 FX 415/969-4997 Burlingame ---------- DOUBLETREE HOTEL - SFO 835 Airport Blvd. Burlingame, CA 94010 PH 415/344-5500 FX 415/340-8851 Redwood City ------------ HOTEL SOFITEL 223 Twin Dolphin Drive Redwood City, CA 94065 PH 415/598-9000 FX 415/598-0459 ------------------------------------------------------------------------------ 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 Sat Jan 18 10:56:15 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06048; Sat, 18 Jan 97 10:56:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06042; Sat, 18 Jan 97 10:56:03 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA24404; Sat, 18 Jan 1997 10:47:24 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA01024 for ; Sat, 18 Jan 1997 10:47:26 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA31165; Sat, 18 Jan 1997 13:42:22 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14556; Sat, 18 Jan 1997 13:42:17 -0500 Message-Id: <9701181842.AA14556@wasted.zk3.dec.com> To: George Tsirtsis Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2922) Re: multihoming alternative In-Reply-To: Your message of "Thu, 16 Jan 97 11:43:25 GMT." Date: Sat, 18 Jan 97 13:42:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk George, I think I like what was being said but I can't parse it well. Can maybe more examples be provided showing actual addresses changing once the pid absorbs the mhid (thats the part I am having trouble with in the picture where the conjunction takes place). It might make scenario A and B differentiate better, at least for me. This still does not fix the raging DNS problems? I think we still need renumbering for mhid changing on the fly and when the mhid changes the prefix for addrconf in the site has changed too? If I missed something I apologize. Or is this just for the multihoming part, and 8+8 directives for renumbering still apply (e.g. rewriting of packets)? Also relating it back to RFC 2073 or 8+8 I would like to see the bits your using for the site and host part? That I find confusing too.? I did not cc Alan and will assume he is on the IPng WG mail list. If not he should be? /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 Sat Jan 18 16:22:08 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06175; Sat, 18 Jan 97 16:22:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06168; Sat, 18 Jan 97 16:21:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA07562; Sat, 18 Jan 1997 16:13:12 -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 QAA26166 for ; Sat, 18 Jan 1997 16:13:09 -0800 From: Masataka Ohta Message-Id: <199701190010.JAA01845@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA01845; Sun, 19 Jan 1997 09:10:43 +0900 Subject: (IPng 2923) Re: 8+8 Why do we care? To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Sun, 19 Jan 97 9:10:42 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9701171621.AA03326@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Jan 17, 97 5:21 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian; > As I said above, it's because of multihoming: the sending host cannot > reasonably be asked to do RG selection for a multihomed > destination, or to know which local RG to use as its source > if the local site is multihomed. It's a generic problem (even with IPv4 today) of a multihomed host with multiple IP addresses, unrelated to addressing architecture. Note that there may be multiple egress routers from a site and the selection of the proper egress router is also a problem. Today with IPv4, some applications try to use all the destination addresses, if the first one somehow fails. And, the natural way of selecting source address is to use that of the outgoing interface, as the multihomed host tend to have routing information. > Only the routing system can possess > that knowledge. The problem is that only the host possesses the list of addresses of the destination. Thus, we do need some protocol between routers and hosts. If the protocol is that routers advise hosts on src/dst address selection in advance, no rewriting by routers is necessary here. If the protocol is that routers advise hosts on src/dst address selection later, like ICMP redirect. But, this does not work unless the routers have the list of destination addresses IN ADVANCE. So, this approach is not so meaningful. If the protocol is that hosts advise routers on list of available dst addresses, rewriting is always necessary. But, considering the end-to-end principle of the Internet, I don't think this approach, suggested by Mike, so good. Distination rewriting is necessary, instead, for mobility, multicast etc. 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 Sat Jan 18 21:57:45 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06337; Sat, 18 Jan 97 21:57:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06318; Sat, 18 Jan 97 21:57:11 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA22228; Sat, 18 Jan 1997 21:48:34 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA19615 for ; Sat, 18 Jan 1997 21:48:33 -0800 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 VAA25186; Sat, 18 Jan 1997 21:48:32 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id VAA14949; Sat, 18 Jan 1997 21:48:30 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 Jan 1997 21:46:13 -0800 To: bound@zk3.dec.com From: fred@cisco.com (Fred Baker) Subject: (IPng 2925) Re: 8+8 Why do we care? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:17 PM 1/10/97, bound@zk3.dec.com wrote: >9. We have momentum now with IPv6 and the market wants it > and needs IPv6 deployed to what extent should 8+8 be > permitted to hold up deployment of IPv6? In all honesty, I believe that we have some additional window to work with here. A couple of years ago, I might have worried about market window, but NATs (for better or worse) and CIDR have filled the gap for now. In 200X when IP Addresses finally hit the wall, we'd best have an answer, and if IP6 is that answer, so be it. If you want folks to shift to IP6 earlier, I suspect (and hope it isn't politically incorrect for me to say) that there may not be a compelling reason in IP6 as it stands. Yes, it does some good things - I really like the Anycast, and I think provider-based addressing is likely to make IP4 CIDR look like a drop in the bucket as far as route table optimization goes - but in all honesty there is little that IP6 does that cannot in fact be done in IP4 now, and done without worrying about deployment and testing of a major series of new protocols. I wonder if making IP6 actually definitively solve a problem that many folks have and cannot fix with IP4 might turn out to be the definitive reason for people to start using IP6 earlier rather than later. From a marketing perspective, pausing to make IP6 definitively fix multi-homing and site renumbering might be time well spent, provided it doesn't take too very long. ------------------------------------------------------------------------------ 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 Sat Jan 18 21:57:38 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06336; Sat, 18 Jan 97 21:57:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06312; Sat, 18 Jan 97 21:57:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA22225; Sat, 18 Jan 1997 21:48:31 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA19611 for ; Sat, 18 Jan 1997 21:48:30 -0800 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 VAA25182; Sat, 18 Jan 1997 21:48:28 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id VAA14946; Sat, 18 Jan 1997 21:48:26 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 Jan 1997 21:46:09 -0800 To: bound@zk3.dec.com From: fred@cisco.com (Fred Baker) Subject: (IPng 2924) Re: 8+8 What specs need looking into and technology Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:59 PM 1/10/97, bound@zk3.dec.com wrote: >Flow Labels (probably see what it does to RSVP too) Well, for RSVP, it probably means that we need to update the PATH message's sender_template in the RSVP process to correspond to the updated source address. The biggest issue there is the impact on authentication and policy. ------------------------------------------------------------------------------ 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 Sat Jan 18 21:58:01 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06350; Sat, 18 Jan 97 21:58:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06324; Sat, 18 Jan 97 21:57:15 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA22242; Sat, 18 Jan 1997 21:48:39 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA19630 for ; Sat, 18 Jan 1997 21:48:38 -0800 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 VAA25209; Sat, 18 Jan 1997 21:48:37 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id VAA14952; Sat, 18 Jan 1997 21:48:34 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 Jan 1997 21:46:17 -0800 To: bound@zk3.dec.com From: fred@cisco.com (Fred Baker) Subject: (IPng 2926) Re: 8+8 Why do we care? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:17 PM 1/10/97, bound@zk3.dec.com wrote: >8. Do we have any implementation experience with in transit > packets being altered as it severly breaks the IPv4 model? True, but last I checked we were dealing with the IP6 model. As has been pointed out, we have some corollary experience, in XNS IDP and Netware IPX. Not that I'm holding them up as examples of where IP6 wants to wind up, but the clean separation between routing and host identification information is very useful in those protocol suites, and configuring an XNS host or IPX client is peanuts - they get all their information (apart from their actual host ID and the names of any services that they choose to offer) from the router, or at least can do so. At 10:16 AM 1/13/97, bound@zk3.dec.com wrote: >>the world-wide success of IPX and the relative ease of ownership >>is proof that MAC conflicts are not that big a deal. > >I could claim the same about DECnet too and to some degree SNA. But >IPX, DECnet, or SNA are not used on the Global Internet Backbone. The information to walk away with is, I think that the translation of a name to an address must include not only the host identification information, but the current routing information as well, at least the amount that is necessary to route between the two points in the network. What remains untested, of course, is the idea of several points in the network incrementally changing the routing information. This remains untested, as you point out. ------------------------------------------------------------------------------ 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 Sat Jan 18 21:58:14 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06351; Sat, 18 Jan 97 21:58:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06330; Sat, 18 Jan 97 21:57:23 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA22248; Sat, 18 Jan 1997 21:48:46 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA19643 for ; Sat, 18 Jan 1997 21:48:45 -0800 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 VAA25217; Sat, 18 Jan 1997 21:48:44 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id VAA14958; Sat, 18 Jan 1997 21:48:41 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 Jan 1997 21:46:25 -0800 To: bound@zk3.dec.com, Matt Crawford From: fred@cisco.com (Fred Baker) Subject: (IPng 2927) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:48 PM 1/15/97, Matt Crawford wrote: >Of >course you get the full destination address from DNS, and insert it >in your outgoing packet. I'll actually modify that a bit. I'd say that you get sufficient information to get a packet from the requesting source to the requested destination. That may not require the full address. If I have a multihomed network and am translating the name of another system within my own network, I would not be surprised to get back only the portion of the name that was consistent with the level of address specification that had happened to my own source address. I would only expect DNS to actually list out both/all of the various possibilities if the requester were going to be forced to select one of them. At 10:58 PM 1/15/97, bound@zk3.dec.com wrote: >I thought so too at first. But once we started the discussion that >packets can be altered in transit I wanted to make sure that did not >include the destination address. If you think what I said above through, there would be no need to update the destination address in flight. If you think the algorithm through, if there *is* a need to update the destination address in flight, what to change it to is probably indeterminate. ------------------------------------------------------------------------------ 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 Sat Jan 18 21:58:57 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06353; Sat, 18 Jan 97 21:58:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06344; Sat, 18 Jan 97 21:57:54 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA22281; Sat, 18 Jan 1997 21:49:17 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA19687 for ; Sat, 18 Jan 1997 21:49:16 -0800 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 VAA25259; Sat, 18 Jan 1997 21:49:15 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id VAA14980; Sat, 18 Jan 1997 21:49:13 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 Jan 1997 21:46:56 -0800 To: huitema@bellcore.com (Christian Huitema) From: fred@cisco.com (Fred Baker) Subject: (IPng 2929) Re: MOs' 8+8 is evil, breaks firewalls. Cc: "Mike O'Dell" , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:09 PM 1/7/97, Christian Huitema wrote: >On the other hand, renumbering is renumbering is renumbering. Forced >renumbering by the network will meet the same customer resistance as >renumbering to the provider's demand, unless the firewall and other access >control list problems are also solved. Could they not be solved asynchronously, though? It seems to me that we are not talking about having the renumbering events happen at the whim of the ISP, they would likely happen because some event happened that made them necessary, such as a change of providers or a change in the provider's CIDR "food chain". It seems that it would have to be co-ordinated with DNS, which would otherwise have old address records outstanding, in order to ensure a smooth cutover, and that's not going to be an automagic event. Seems like with an agreed degree of notice, firewalls aren't *that* hard to reprogram, especially if it is the firewall that is doing the address rewrite in the first place. ------------------------------------------------------------------------------ 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 Sat Jan 18 21:58:51 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06352; Sat, 18 Jan 97 21:58:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06338; Sat, 18 Jan 97 21:57:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA22275; Sat, 18 Jan 1997 21:49:13 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA19681 for ; Sat, 18 Jan 1997 21:49:12 -0800 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 VAA25251; Sat, 18 Jan 1997 21:49:10 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id VAA14955; Sat, 18 Jan 1997 21:48:38 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 Jan 1997 21:46:21 -0800 To: "Peter Curran" From: fred@cisco.com (Fred Baker) Subject: (IPng 2928) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:58 AM 1/14/97, Peter Curran wrote: >Why don't we simply ask a couple of the major vendors - SMC, 3Com, etc. >what the incidence of duplicate MAC address assignment is? In the use of local addresses (decnet, token thing addresses at least early on, and a few similar cases) I can guarantee that it has happened a lot. How many instances of "decnet area 1 node 1" (aka AA-00-04-00-01-04) would you suppose there are in the world? ------------------------------------------------------------------------------ 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 Sun Jan 19 01:03:28 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06604; Sun, 19 Jan 97 01:03:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06598; Sun, 19 Jan 97 01:03:12 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA29027; Sun, 19 Jan 1997 00:54:34 -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 AAA02374 for ; Sun, 19 Jan 1997 00:54:34 -0800 From: Masataka Ohta Message-Id: <199701190852.RAA02265@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA02265; Sun, 19 Jan 1997 17:52:15 +0900 Subject: (IPng 2930) Re: MOs' 8+8 is evil, breaks firewalls. To: fred@cisco.com (Fred Baker) Date: Sun, 19 Jan 97 17:52:14 JST Cc: huitema@bellcore.com, mo@elmo.uu.net, ipng@sunroof.eng.sun.com In-Reply-To: ; from "Fred Baker" at Jan 18, 97 9:46 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >On the other hand, renumbering is renumbering is renumbering. Forced > >renumbering by the network will meet the same customer resistance as > >renumbering to the provider's demand, unless the firewall and other access > >control list problems are also solved. > > Could they not be solved asynchronously, though? It seems to me that we are > not talking about having the renumbering events happen at the whim of the > ISP, We are, because a temporal and sudden failure of a provider of a multi-homed site means a sudden renumbering to other providers's prefix. This means that the idea of "deprecated address" is deprecated and that ND is simplified. > "food chain". It seems that it would have to be co-ordinated with DNS, > Seems like with an agreed degree of notice, firewalls aren't *that* hard to Sure. DNS and firewalls do not have to react against the temporal failure. 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 Sun Jan 19 01:12:15 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06624; Sun, 19 Jan 97 01:12:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06618; Sun, 19 Jan 97 01:11:58 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA29251; Sun, 19 Jan 1997 01:03: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 BAA02717 for ; Sun, 19 Jan 1997 01:03:20 -0800 From: Masataka Ohta Message-Id: <199701190901.SAA02294@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA02294; Sun, 19 Jan 1997 18:00:56 +0859 Subject: (IPng 2931) Re: 8+8 Why ESDS are not globally Unique To: fred@cisco.com (Fred Baker) Date: Sun, 19 Jan 97 18:00:55 JST Cc: bound@zk3.dec.com, crawdad@FNAL.GOV, ipng@sunroof.eng.sun.com In-Reply-To: ; from "Fred Baker" at Jan 18, 97 9:46 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >I thought so too at first. But once we started the discussion that > >packets can be altered in transit I wanted to make sure that did not > >include the destination address. > > If you think what I said above through, there would be no need to update > the destination address in flight. If you think the algorithm through, if > there *is* a need to update the destination address in flight, what to > change it to is probably indeterminate. Modifying the destination locator of a packet is no worse than a simple denial of service attack to simply consume the packet (with or without proper replay) by a malicious intermediate router. Such an attack is perfectly possible on today's Internet with IPv4 and, from our operational experience, has been harmless. 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 Sun Jan 19 01:16:50 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06636; Sun, 19 Jan 97 01:16:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06630; Sun, 19 Jan 97 01:16:33 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA29355; Sun, 19 Jan 1997 01:07:55 -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 BAA02965 for ; Sun, 19 Jan 1997 01:07:55 -0800 From: Masataka Ohta Message-Id: <199701190906.SAA02320@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA02320; Sun, 19 Jan 1997 18:05:50 +0859 Subject: (IPng 2932) Re: 8+8 What specs need looking into and technology To: fred@cisco.com (Fred Baker) Date: Sun, 19 Jan 97 18:05:49 JST Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: ; from "Fred Baker" at Jan 18, 97 9:46 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Flow Labels (probably see what it does to RSVP too) > > Well, for RSVP, it probably means that we need to update the PATH message's > sender_template in the RSVP process to correspond to the updated source > address. The biggest issue there is the impact on authentication and > policy. What? As the notificaiton of sender locator change is unrelated to RSVP, there is no authentication problem related to RSVP. For weak security, DNS derived list of available static locators should be suffice. For mobile sender, mobile protocop takes care of the change and its authentication. And, once the locator(s) of a sender is known, what is the policy problem unique to RSVP? Nothing. The real relationship between flow labels and 8+8 is that flow should be identified by "ID + flow label", not "address + flow label". 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 Sun Jan 19 05:18:58 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06740; Sun, 19 Jan 97 05:18:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06734; Sun, 19 Jan 97 05:18:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA05761; Sun, 19 Jan 1997 05:10:06 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA12477 for ; Sun, 19 Jan 1997 05:10:06 -0800 Received: from shut.ticl.co.uk (shut.ticl.co.uk [193.32.1.3]) by gate.ticl.co.uk (8.7.4/8.7.3) with ESMTP id MAA18559; Sun, 19 Jan 1997 12:56:35 GMT Message-Id: <199701191256.MAA18559@gate.ticl.co.uk> From: "Peter Curran" To: "Fred Baker" Cc: Subject: (IPng 2933) Re: 8+8 Why ESDS are not globally Unique Date: Sun, 19 Jan 1997 13:05:48 -0000 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1160 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 > > At 8:58 AM 1/14/97, Peter Curran wrote: > >Why don't we simply ask a couple of the major vendors - SMC, 3Com, etc. > >what the incidence of duplicate MAC address assignment is? > > In the use of local addresses (decnet, token thing addresses at least early > on, and a few similar cases) I can guarantee that it has happened a lot. > How many instances of "decnet area 1 node 1" (aka AA-00-04-00-01-04) would > you suppose there are in the world? > > Yes - but these are locally assigned addresses, not global. There is no real comparison here (except for some TRN cards where the local address assignement is 'permament' and overwrites the 'factory' global address). Certainly, the DECnet usage is that the protocol stack assigns the address info on a temporary basis. Looking at the comments on this point during the past few days (weeks) there is a concencus that producing a unique ESD on a global basis using the IEEE MAC address as a starting point is not going to work. The questions we should now address are, does this matter? how do we handle an address collision at the global level? If we cannot use 8+8 without globally unique ESD's and/or we can't handle address collisions at a global level effectively then I suspect that 8+8 is a non-starter! My 0.02 ECU :-) /peter ------------------------------------------------------------------------------ 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 Mon Jan 20 00:23:29 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07679; Mon, 20 Jan 97 00:23:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07673; Mon, 20 Jan 97 00:23:17 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA29190; Mon, 20 Jan 1997 00:14:38 -0800 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id AAA04076 for ; Mon, 20 Jan 1997 00:14:37 -0800 Received: from rama.imag.fr (rama.imag.fr [129.88.26.9]) by imag.imag.fr (8.8.1/8.6.9) with ESMTP id JAA16691; Mon, 20 Jan 1997 09:14:35 +0100 (MET) Received: (from durand@localhost) by rama.imag.fr (8.8.0/8.8.Beta.3) id KAA27041; Mon, 20 Jan 1997 10:15:36 +0100 (MET) From: "Alain Durand" Message-Id: <970120101535.ZM27059@rama.imag.fr> Date: Mon, 20 Jan 1997 10:15:35 +0100 In-Reply-To: Bob Hinden "(IPng 2921) Directions and Hotel Information for IPng Interim Meeting" (Jan 17, 5:35pm) References: <3.0.32.19970117173449.007580f4@mailhost.ipsilon.com> X-Mailer: Z-Mail (4.0b.514 14may96) To: Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 2934) Re: Directions and Hotel Information for IPng Interim Meeting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Will this meeting be on the M-bone for those of us who can't make the trip? - Alain. ------------------------------------------------------------------------------ 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 Mon Jan 20 02:24:01 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07719; Mon, 20 Jan 97 02:24:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07713; Mon, 20 Jan 97 02:23:49 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA05459; Mon, 20 Jan 1997 02:15:10 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA21764 for ; Mon, 20 Jan 1997 02:15:09 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id LAA23485 for ; Mon, 20 Jan 1997 11:15:08 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA05099; Mon, 20 Jan 1997 11:15:08 +0100 Message-Id: <9701201015.AA05099@dxcoms.cern.ch> Subject: (IPng 2935) Re: multihoming alternative To: ipng@sunroof.eng.sun.com Date: Mon, 20 Jan 1997 11:15:07 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: from "George Tsirtsis" at Jan 16, 97 11:43:25 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some comments... > ... It is > important to realise though that the 8+8 scheme drastically reduces the > number of IPv6 addresses, I don't think so. It was always expected that the bottom 6 bytes would be used for the IEEE address in many cases; and anyway the main argument for the 128-bit address size was gut feeling that we needed space for something like 8+8. ... > The Multi-Homing Identifier (mhid) > If the ntuple {mhID,subnet,hostID} is to be globally unique then the mhID must also be globally unique, since it is in effect a site locator. In fact generating an mhID from an arbitrary set of providerIDs, while ensuring that the mhID is unique, is fundamentally a combinatorial problem. By squeezing the mhID into a small number of bits, we force the combinatorial problem to go elsewhere - into router forwarding tables I suspect. I don't understand how the mhID aggregates better than a classful IPv4 prefix. Brian Carpenter ------------------------------------------------------------------------------ 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 Mon Jan 20 07:11:10 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07919; Mon, 20 Jan 97 07:11:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07913; Mon, 20 Jan 97 07:10:58 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA26236; Mon, 20 Jan 1997 07:02:19 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA14118 for ; Mon, 20 Jan 1997 07:02:18 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA21385; Mon, 20 Jan 1997 09:48:39 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA17710; Mon, 20 Jan 1997 09:48:38 -0500 Message-Id: <9701201448.AA17710@wasted.zk3.dec.com> To: fred@cisco.com (Fred Baker) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2936) Re: 8+8 Why do we care? In-Reply-To: Your message of "Sat, 18 Jan 97 21:46:13 PST." Date: Mon, 20 Jan 97 09:48:37 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, >In all honesty, I believe that we have some additional window to work with >here. A couple of years ago, I might have worried about market window, but >NATs (for better or worse) and CIDR have filled the gap for now. In 200X >when IP Addresses finally hit the wall, we'd best have an answer, and if >IP6 is that answer, so be it. If you want folks to shift to IP6 earlier, I >suspect (and hope it isn't politically incorrect for me to say) that there >may not be a compelling reason in IP6 as it stands. A lot of users I know need much bigger address space than 2**32 and also a lot of users cannot get the Class C addresses needed they want right now. For a growing market, IPv4 address space is gone even with CIDR or NAT. In addition many sites IP as exponentiated as the Internet grows, and the growth of the Intranets is happening too. They would rather move to a new protocol now rather than do it later. Another reason is that Addrconf and ND are a big win for system mgmt costs that cannot be done as well in IPv4 at all and any fix is a questionable band-aid at best, and not something I would bet my business on or that all vendors will back port to IPv4 with IPv6 here today. Another reason is that the market is not buying the idea of Private Addresses is my reading, hence, makes NAT not a solution to the IPv4 address space problem. >Yes, it does some good things - I really like the Anycast, and I think >provider-based addressing is likely to make IP4 CIDR look like a drop in >the bucket as far as route table optimization goes - but in all honesty >there is little that IP6 does that cannot in fact be done in IP4 now, and >done without worrying about deployment and testing of a major series of new >protocols. Are you just saying this as a router vendor? Because as a persons that works for a router/host vendor I can tell you there are a lot of gains for the host from IPv6 that will translate to direct customer benefits in technology, efficiency, and performance. >I wonder if making IP6 actually definitively solve a problem that many >folks have and cannot fix with IP4 might turn out to be the definitive >reason for people to start using IP6 earlier rather than later. From a >marketing perspective, pausing to make IP6 definitively fix multi-homing >and site renumbering might be time well spent, provided it doesn't take too >very long. The only two that seem to be able to be back-ported to the IPv4 world is security and dynamic updates to DNS, otherwise not so. Of course if your mail is only from a router perspective I can see why you say what you do, but I still don't agree, as I think the router vendors (including Digital, Bay, Ipsilon, et al) as yourself will gain advantages from IPv6. In addition I believe RSVP, XXX Switching, Video/Audio, and more if I spent my time on such things will execute faster and the code base will be more robust than IPv4 which benefits a customer in performance and less bugs. For example the Cisco DHCP/DNS Mgmt product out (which I applaud and very impressed with) will be more maintainable, efficient, and can add much more value to your customers once we move to DHCPv6 and the IPv6 stack. IPv6 from a host perspective is simply better. I personally consider trying to do IPv6 on IPv4 (and in most cases it cannot be done) like putting the bumper of a cadillac on a volkswagon. It will just cause an accident on the freeways of the Internet and Intranets. Also if Digital, Sun, HP, IBM, Microsoft, SGI, FTP, and other host vendors see a market and cost advantage of IPv6 it will be provided to customers for their Intranets first and then the ISP will get nice packages and the NAPs. The router vendors can follow or participate it depends on how that all plays out, but if there are enough packets with IPv6 as a version in the Internet it will happen. Do you think the 6bone is a fluke? Its happening and its affecting the market already as its on the customer list of questions about where a vendor is headed I am sure for all of us. /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 Mon Jan 20 07:39:28 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07944; Mon, 20 Jan 97 07:39:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07938; Mon, 20 Jan 97 07:39:17 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA28868; Mon, 20 Jan 1997 07:30:37 -0800 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA21634 for ; Mon, 20 Jan 1997 07:30:37 -0800 Received: from big-dogs.cisco.com ([171.68.53.75]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id HAA07468; Mon, 20 Jan 1997 07:30:33 -0800 Message-Id: <3.0.32.19970120103028.006aa7bc@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 20 Jan 1997 10:30:34 -0500 To: bound@zk3.dec.com From: Paul Ferguson Subject: (IPng 2937) Re: 8+8 Why do we care? 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 At 09:48 AM 1/20/97 -0500, bound@zk3.dec.com wrote: > >A lot of users I know need much bigger address space than 2**32 and also >a lot of users cannot get the Class C addresses needed they want right >now. For a growing market, IPv4 address space is gone even with CIDR >or NAT. > Jim, One might suggest that is supposition and not a foregone conclusion. > >Another reason is that the market is not buying the idea of Private >Addresses is my reading, hence, makes NAT not a solution to the IPv4 >address space problem. > You state this, but do not provide any reasoning on the statement. Please elaborate on your reasoning here. > >Do you think the 6bone is a fluke? Its happening and its affecting the >market already as its on the customer list of questions about where a >vendor is headed I am sure for all of us. > A fluke? Perhaps not. A toy? Perhaps. What benefits does the 6Bone offer over the MBone? Curiously, - paul ------------------------------------------------------------------------------ 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 Mon Jan 20 07:59:39 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07986; Mon, 20 Jan 97 07:59:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07980; Mon, 20 Jan 97 07:59:28 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA01213; Mon, 20 Jan 1997 07:50:48 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA27334 for ; Mon, 20 Jan 1997 07:50:48 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id KAA25918; Mon, 20 Jan 1997 10:48:07 -0500 Date: Mon, 20 Jan 1997 10:48:07 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9701201048.ZM25916@seawind.bellcore.com> In-Reply-To: Paul Ferguson "(IPng 2937) Re: 8+8 Why do we care?" (Jan 20, 10:30am) References: <3.0.32.19970120103028.006aa7bc@lint.cisco.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: Paul Ferguson , bound@zk3.dec.com Subject: (IPng 2938) Re: 8+8 Why do we care? 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 On Jan 20, 10:30am, Paul Ferguson wrote: > Subject: (IPng 2937) Re: 8+8 Why do we care? > At 09:48 AM 1/20/97 -0500, bound@zk3.dec.com wrote: > > > >A lot of users I know need much bigger address space than 2**32 and also > >a lot of users cannot get the Class C addresses needed they want right > >now. For a growing market, IPv4 address space is gone even with CIDR > >or NAT. > > > > Jim, > > One might suggest that is supposition and not a foregone conclusion. As far as perception go, I can tell you that there certainly is a perception that a bigger address space is needed *now*. Basically, every large corporation would like its own class A. What they hear is that they can't because we have to ration addresses, and from there on they are dragged into suboptimal solutions. IPv6 is needed now, would in fact have been useful last year. -- 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 Mon Jan 20 09:03:00 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08161; Mon, 20 Jan 97 09:03:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08155; Mon, 20 Jan 97 09:02:48 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA08207; Mon, 20 Jan 1997 08:54:08 -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 IAA17041 for ; Mon, 20 Jan 1997 08:54:08 -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 IAA24954; Mon, 20 Jan 1997 08:54:07 -0800 Message-Id: <3.0.32.19970120085315.0073d1c8@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 20 Jan 1997 08:53:18 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 2939) Updated IPng Pages w/ Interim Meeting Info Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just installed an update to the IPng web pages at http://playground.sun.com/ipng It includes a new page with information on the IPng interim meeting on Feb 27/28 including maps, directions, hotels, etc. Corrections/updates to me. 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 Mon Jan 20 09:07:03 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08181; Mon, 20 Jan 97 09:07:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08167; Mon, 20 Jan 97 09:06:43 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA08544; Mon, 20 Jan 1997 08:58:03 -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 IAA18032 for ; Mon, 20 Jan 1997 08:58:04 -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 IAA25056; Mon, 20 Jan 1997 08:56:43 -0800 Message-Id: <3.0.32.19970120085552.00723990@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 20 Jan 1997 08:55:54 -0800 To: "Alain Durand" From: Bob Hinden Subject: (IPng 2940) Re: Directions and Hotel Information for IPng Interim Meeting 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 Alain, >Will this meeting be on the M-bone for those of us who can't make the trip? Unfortunately we were not able to arrange for the meeting to be on the Mbone. 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 Mon Jan 20 09:31:16 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08230; Mon, 20 Jan 97 09:31:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08224; Mon, 20 Jan 97 09:31:05 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA11791; Mon, 20 Jan 1997 09:22:25 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA26559 for ; Mon, 20 Jan 1997 09:22:24 -0800 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 JAA27645; Mon, 20 Jan 1997 09:22:22 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id JAA16205; Mon, 20 Jan 1997 09:22:19 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jan 1997 09:20:00 -0800 To: Masataka Ohta From: fred@cisco.com (Fred Baker) Subject: (IPng 2941) Re: 8+8 What specs need looking into and technology Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 6:05 PM 1/19/97, Masataka Ohta wrote: >> >Flow Labels (probably see what it does to RSVP too) >> >> Well, for RSVP, it probably means that we need to update the PATH message's >> sender_template in the RSVP process to correspond to the updated source >> address. The biggest issue there is the impact on authentication and >> policy. > >What? > >As the notificaiton of sender locator change is unrelated to RSVP, >there is no authentication problem related to RSVP. > >For weak security, DNS derived list of available static locators >should be suffice. For mobile sender, mobile protocop takes care >of the change and its authentication. > >And, once the locator(s) of a sender is known, what is the policy >problem unique to RSVP? Nothing. > >The real relationship between flow labels and 8+8 is that flow >should be identified by "ID + flow label", not "address + >flow label". not sure how the above comment relates to the relationship between 8+8 and RSVP, which was the question in the parentheses which I attempted to answer. As the source address is stored in the sender_template and copied to the filter spec, the sender_template will have to reflect the address build-out. ------------------------------------------------------------------------------ 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 Mon Jan 20 10:03:17 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08354; Mon, 20 Jan 97 10:03:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08348; Mon, 20 Jan 97 10:03:05 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA16076; Mon, 20 Jan 1997 09:54:25 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA07372 for ; Mon, 20 Jan 1997 09:54:24 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA10179; Mon, 20 Jan 1997 12:41:18 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14394; Mon, 20 Jan 1997 12:41:18 -0500 Message-Id: <9701201741.AA14394@wasted.zk3.dec.com> To: Paul Ferguson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2942) Re: 8+8 Why do we care? In-Reply-To: Your message of "Mon, 20 Jan 97 10:30:34 EST." <3.0.32.19970120103028.006aa7bc@lint.cisco.com> Date: Mon, 20 Jan 97 12:41:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul, >One might suggest that is supposition and not a foregone conclusion. Supposition I would agree with a strong bent towards the edge is close where folks are simply questioning the band-aids for IPv4, if they can deploy IPv6 on their Intranets now to get ready for the year 2000. I also think this is a wise idea if they can afford the investment. Do you think this is not a good idea on customers part? >> >>Another reason is that the market is not buying the idea of Private >>Addresses is my reading, hence, makes NAT not a solution to the IPv4 >>address space problem. >> >You state this, but do not provide any reasoning on the statement. >Please elaborate on your reasoning here. Well I can't list customers names because its against the rules where I work and I have a mortgage to pay this week. But you have heard from several on this list most recently they are ready to begin address planning because of growth and would like to do that with IPv6. The deduction in these and other cases is that Private Addresses are not feasible. The main issue I hear is that they want to be Internet ready on the Intranet. Private Addresses are OK for some and not acceptable to others and security is not a reason to use them. Another phenomena that is taking place is that large Fortune 100 sites are themselves becoming ISPs for their large customer and future customer base (such as Celluar Networks, Banks, Distributed Manufacturing) and they do not know exactly where they want "real" Internet addresses and where they don't need them within the mini-Internet (Intranet) which in fact may become part of the global Internet for various "business" reasons. This is why they are beginning to care about how the addressing architecture is defined and what mechanisms the governments will use to permit encryption and all the phenomena associated with the Internet becoming a dial-tone or a channel on your CATV connection. Private Addresses mean translation too that are much more complex than when you have a real IPv6 address (e.g. for DNS, Autoconfig, Gateways). Avoiding translation where possible is the input I get from customers whereever possible. This brings the issue up of the "Extranets" (just what we need a new term eh!!). These are the nodes that sit in front of a firewall (as we know it today) so they are live on the Internet but are really there to support the Intranet. These will not go away. How they operate with IPv6 is still TBD IMO. The reason is that today we have tunnels set up on the 6bone. When we support IPsec over those tunnels have we put firewall vendors out of business? I think not. But I think it will change the way a firewall is engineered and operated from a users point of view. Private Addresses also make this harder mostly because of the DNS and some believe (including me) better performance can be obtained with real IPv6 addresses. Finally with IPv6 there is simply no reason to use Private Addresses. >> >>Do you think the 6bone is a fluke? Its happening and its affecting the >>market already as its on the customer list of questions about where a >>vendor is headed I am sure for all of us. >> >A fluke? Perhaps not. A toy? Perhaps. What benefits does the 6Bone offer >over the MBone? I view your question as do I like apples or oranges better. I point you to the 6bone WWW page and charter for what it is and its a test bed. Once we convert it to use IPv6 addresses and bring on additional commerical ISPs and NAPs it will be the IPv6 Internet people can use. So I don't think its a toy. I do think its the IPv6 Internet at the "Requirements and Unit Test Stage" from a Project Management perspective though. The point is the project has started. This is why its so important to work quickly on this mail list what the addressing architecture issues are for IPv6, as the project has started adn this issues is "critical path" for the IPv6 project. The Mbone also has not been successful to get Multicast commerically deployed on a wide-scale on the Internet or Intranets. I would like to believe the 6bone will learn from that and evolve to a model that assists with commercial deployment of IPv6. But please see the 6bone www page and read the charter. /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 Mon Jan 20 12:07:29 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08478; Mon, 20 Jan 97 12:07:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08472; Mon, 20 Jan 97 12:07:13 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA03040; Mon, 20 Jan 1997 11:58:34 -0800 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA17424 for ; Mon, 20 Jan 1997 11:58:33 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id LAA18645 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id LAA10135 Posted-Date: Mon, 20 Jan 1997 11:58:25 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id OAA13527; Mon, 20 Jan 1997 14:58:27 -0500 for Date: Mon, 20 Jan 1997 14:58:27 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701201958.OAA13527@pobox.engeast.BayNetworks.COM> To: ip6mib@Research.Ftp.Com Subject: (IPng 2943) IPv6 MIB: per-entity stats Cc: ipng@sunroof.eng.sun.com, sonishi@pobox Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Falks, I'll be updating the IPv6 MIB draft to reflect comments I've received so far. At this point I'm not sure if there is a consensus that the per-entity interface and ICMP statistics are to be deleted from the mib. A number of people view the per-entity, aka per-node, statistics redundant since the information can be derived from the per-interface statistics. So please let me know if you strongly oppose removing the per-entity stats from the v6 mib. If I don't get any protests by the end of this week, the per-entity stats will be as good as gone. Thanks, 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 Mon Jan 20 13:52:20 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08710; Mon, 20 Jan 97 13:52:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08704; Mon, 20 Jan 97 13:52:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA15072; Mon, 20 Jan 1997 13:43:28 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA13986 for ; Mon, 20 Jan 1997 13:43:27 -0800 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 NAA24271; Mon, 20 Jan 1997 13:43:23 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jan 1997 13:43:21 -0800 To: fred@cisco.com (Fred Baker) From: Steve Deering Subject: (IPng 2944) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred Baker wrote: > In the use of local addresses (decnet, token thing addresses at least early > on, and a few similar cases) I can guarantee that it has happened a lot. > How many instances of "decnet area 1 node 1" (aka AA-00-04-00-01-04) would > you suppose there are in the world? Fred, The intention is that the ESDs would be fabricated from the wired-in, factory-supplied MAC address, not from any software-defined local address, so I *think* that that particular example of MAC address duplication is not relevant. 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 Mon Jan 20 14:32:59 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08753; Mon, 20 Jan 97 14:32:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08747; Mon, 20 Jan 97 14:32:48 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA19797; Mon, 20 Jan 1997 14:24:08 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA24221 for ; Mon, 20 Jan 1997 14:24:08 -0800 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 OAA15486; Mon, 20 Jan 1997 14:24:07 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id OAA16535; Mon, 20 Jan 1997 14:24:04 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jan 1997 14:21:45 -0800 To: Steve Deering From: fred@cisco.com (Fred Baker) Subject: (IPng 2945) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:43 PM 1/20/97, Steve Deering wrote: >The intention is that the ESDs would be fabricated from the wired-in, >factory-supplied MAC address, not from any software-defined local address, >so I *think* that that particular example of MAC address duplication is >not relevant. Even on PC add-on cards? It's my understanding that one of the issues in running PPP on such cards using certain protocol suites is that there is no hardware MAC Address PROM. ------------------------------------------------------------------------------ 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 Mon Jan 20 15:21:38 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08807; Mon, 20 Jan 97 15:21:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08801; Mon, 20 Jan 97 15:21:26 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA24861; Mon, 20 Jan 1997 15:12:46 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA05604 for ; Mon, 20 Jan 1997 15:12:46 -0800 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 PAA29299; Mon, 20 Jan 1997 15:12:42 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jan 1997 15:12:40 -0800 To: fred@cisco.com (Fred Baker) From: Steve Deering Subject: (IPng 2946) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, > Even on PC add-on cards? It's my understanding that one of the issues in > running PPP on such cards using certain protocol suites is that there is no > hardware MAC Address PROM. Are you referring to add-on Ethernet cards or add-on cards of some other link type? I presume the latter, since one doesn't generally run PPP over an Ethernet interface. Or maybe you are talking about those PCMCIA cards that combine a modem and an ethernet interface on one card? If you are saying that not all interfaces (e.g., modem interfaces) have factory-assigned MAC addresses, yes, we know that, and Mike's draft has an alternative numbering space defined for such interfaces. If you are saying that there are Ethernet interfaces being shipped for PCs that do not have a factory-assigned, unique MAC address either on the card or on the PC backplane, then that's (distressing) news to me. However, I suppose I shouldn't be surprised, given that it's the PC industry we're talking about. But I should save that flame till I get your clarification. 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 Mon Jan 20 16:01:46 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08921; Mon, 20 Jan 97 16:01:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08915; Mon, 20 Jan 97 16:01:34 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA29308; Mon, 20 Jan 1997 15:52:53 -0800 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA15130 for ; Mon, 20 Jan 1997 15:52:36 -0800 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id XAA27353; Mon, 20 Jan 1997 23:51:27 GMT Date: Mon, 20 Jan 1997 23:51:27 GMT Message-Id: <199701202351.XAA27353@oberon.di.fc.ul.pt> From: Pedro Roque To: Steve Deering Cc: fred@cisco.com (Fred Baker), ipng@sunroof.eng.sun.com Subject: (IPng 2947) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Steve" == Steve Deering writes: Steve> Are you referring to add-on Ethernet cards or add-on cards Steve> of some other link type? I presume the latter, since one Steve> doesn't generally run PPP over an Ethernet interface. Or Steve> maybe you are talking about those PCMCIA cards that combine Steve> a modem and an ethernet interface on one card? Steve> If you are saying that not all interfaces (e.g., modem Steve> interfaces) have factory-assigned MAC addresses, yes, we Steve> know that, and Mike's draft has an alternative numbering Steve> space defined for such interfaces. Steve> If you are saying that there are Ethernet interfaces being Steve> shipped for PCs that do not have a factory-assigned, unique Steve> MAC address either on the card or on the PC backplane, then Steve> that's (distressing) news to me. Steve, to give you an example the host where i'm composing this message on as an add-on isdn card with no link token on it. It can do sync-ppp over isdn or ethernet encapsulation (depending on how you configure your software). The later scenario is usually used when connected to a router in bridging mode (the software i use even as an option to use the ether encapsulation of a particular routing vendor so i guess it might be popular...). The hardware address is configured by hand in such situations. All the card really does is hdlc over isdn, all the rest is software. There is really no one to flame in this case. There are a lot of situations (i.e. use of a popular unroutable "network protocol") when bridging is prefered over routing. Or just the fact that routing is difficult to setup in some environments... or your site is out of class Cs. The number of such hosts should not be significative however... i just refered this as an example of what such an add-on card can be. The person configuring the card already has to make sure it sets an unique token for the link... So i don't think it is a show stopper. regards, ./Pedro. (PS: I do use sync-ppp) ------------------------------------------------------------------------------ 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 Mon Jan 20 16:10:31 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08937; Mon, 20 Jan 97 16:10:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08931; Mon, 20 Jan 97 16:10:11 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA00565; Mon, 20 Jan 1997 16:01:30 -0800 Received: from ncc.ripe.net (ncc.ripe.net [193.0.0.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA17662 for ; Mon, 20 Jan 1997 16:01:29 -0800 Received: from ppp11.ripe.net by ncc.ripe.net with SMTP id AA03139 (5.65a/NCC-2.40); Tue, 21 Jan 1997 01:01:24 +0100 Received: from berklix.ripe.net (localhost [127.0.0.1]) by berklix.ripe.net (8.8.4/8.7.3) with ESMTP id MAA00336; Mon, 20 Jan 1997 12:57:19 +0100 (CET) Message-Id: <199701201157.MAA00336@berklix.ripe.net> To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: (IPng 2948) Re: 8+8 Why do we care? In-Reply-To: Your message of "Mon, 20 Jan 1997 10:48:07 EST." <9701201048.ZM25916@seawind.bellcore.com> Date: Mon, 20 Jan 1997 12:57:18 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 20 Jan 1997 10:48:07 -0500 Christian Huitema wrote: > > >A lot of users I know need much bigger address space than 2**32 and > also > > >a lot of users cannot get the Class C addresses needed they want right > > >now. For a growing market, IPv4 address space is gone even with CIDR > > >or NAT. > > As far as perception go, I can tell you that there certainly is a > perception that a bigger address space is needed *now*. Basically, every > large corporation would like its own class A. What they hear is that they > can't because we have to ration addresses, and from there on they are > dragged into suboptimal solutions. IPv6 is needed now, would in fact have > been useful last year. I don't agree that making statements like 'every corporation needs his own class A' makes sense. To repeat an older discussion, what counts is expected and aimed utilisation factor. This factor consists of actual usage (#hosts), and assignmnent efficiency (the more efficient assignment means it's harder to manage the net). Keep in mind that the total number of hosts on the Internet would still fit in one class A network number. Based on numbers alone, I don't think that any claim for an A would be valid these days. The other issue is assignment efficiency. One must set limits to this (if one would go to the extreme case of assigning 8-bit prefixes of IPv6, we would only be able to make 256 delegations despite the enormous amount of space IPv6 has). As registries we know that 50% utilisation is archievable, though not easy to administer. One percent efficiency (say, two hosts on a class C network, or using a class C network for a P2P link) is easily archievable, and I think it would be reasonable to aim for that. Now, 1% of 2**32 is still roughly 43 million hosts or more than two times the number of hosts on the Internet. I can't envision many companies that would have this amount of machines, so I think there is much difference between perceived need and real need. Unfortunately, also with IPv6, we will only be able to support real need, not perceived need. What am I missing? Geert Jan ------------------------------------------------------------------------------ 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 Mon Jan 20 16:25:30 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08961; Mon, 20 Jan 97 16:25:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08955; Mon, 20 Jan 97 16:25:18 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA02536; Mon, 20 Jan 1997 16:16:39 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA21634 for ; Mon, 20 Jan 1997 16:16:37 -0800 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 QAA21647; Mon, 20 Jan 1997 16:16:35 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id QAA16648; Mon, 20 Jan 1997 16:16:32 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jan 1997 16:14:14 -0800 To: Steve Deering From: fred@cisco.com (Fred Baker) Subject: (IPng 2949) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:12 PM 1/20/97, Steve Deering wrote: >If you are saying that not all interfaces (e.g., modem interfaces) have >factory-assigned MAC addresses, yes, we know that, and Mike's draft has >an alternative numbering space defined for such interfaces. I'm saying that modem interfaces generally don't have ethernet addresses. ------------------------------------------------------------------------------ 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 Mon Jan 20 18:18:44 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09129; Mon, 20 Jan 97 18:18:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09123; Mon, 20 Jan 97 18:18:28 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA13032; Mon, 20 Jan 1997 18:09:48 -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 SAA16437 for ; Mon, 20 Jan 1997 18:09:41 -0800 From: Masataka Ohta Message-Id: <199701210159.KAA04916@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA04916; Tue, 21 Jan 1997 10:59:25 +0900 Subject: (IPng 2950) Re: 8+8 What specs need looking into and technology To: fred@cisco.com (Fred Baker) Date: Tue, 21 Jan 97 10:59:23 JST Cc: mohta@necom830.hpcl.titech.ac.jp, bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: ; from "Fred Baker" at Jan 20, 97 9:20 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > not sure how the above comment relates to the relationship between 8+8 and > RSVP, What, do you think, is "the relationship between 8+8 and RSVP"? There is none. > As the source address is stored in the sender_template and copied > to the filter spec, the sender_template will have to reflect the address > build-out. And, they are receivers who reflect the updated address in RESV messages. The update occurs with best effort or resource reserved, unicast or multicast communication. Nothing are RSVP specific. 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 Mon Jan 20 18:54:00 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09296; Mon, 20 Jan 97 18:54:00 PST Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09278; Mon, 20 Jan 97 18:53:40 PST Received: by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA11868; Mon, 20 Jan 1997 18:44:57 -0800 Date: Mon, 20 Jan 1997 18:44:57 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199701210244.SAA11868@jurassic.eng.sun.com> To: brian@dxcoms.cern.ch Subject: (IPng 2951) Re: 8+8 Why do we care? 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 > As I said above, it's because of multihoming: the sending host cannot > reasonably be asked to do RG selection for a multihomed > destination, or to know which local RG to use as its source > if the local site is multihomed. Only the routing system can possess > that knowledge. There are solutions where the host need not know how to select the source RG but the routers need not rewrite it either. You just need an ICMP "please use this source RG for this destination address" type message. 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 Mon Jan 20 19:08:50 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09337; Mon, 20 Jan 97 19:08:50 PST Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09331; Mon, 20 Jan 97 19:08:34 PST Received: by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA12325; Mon, 20 Jan 1997 18:59:52 -0800 Date: Mon, 20 Jan 1997 18:59:52 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199701210259.SAA12325@jurassic.eng.sun.com> To: dhaskin@BayNetworks.COM Subject: (IPng 2952) Re: IPv6 MIB: per-entity stats Cc: ipng@sunroof.eng.sun.com, ip6mib@Research.Ftp.Com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'll be updating the IPv6 MIB draft to reflect comments I've received > so far. At this point I'm not sure if there is a consensus that > the per-entity interface and ICMP statistics are to be deleted > from the mib. A number of people view the per-entity, aka per-node, statistics > redundant since the information can be derived from the per-interface > statistics. It is correct that the per-entity counters can be derived using the sum of the per-interface counters. But somebody raised the issue of what happens to "the sum of the per-interface counters" as interfaces are deleted. Is this still an outstanding issue? 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 Mon Jan 20 20:05:56 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09390; Mon, 20 Jan 97 20:05:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09384; Mon, 20 Jan 97 20:05:44 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA20735; Mon, 20 Jan 1997 19:57:03 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA03256 for ; Mon, 20 Jan 1997 19:57:03 -0800 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 TAA12825; Mon, 20 Jan 1997 19:56:15 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199701201157.MAA00336@berklix.ripe.net> References: Your message of "Mon, 20 Jan 1997 10:48:07 EST." <9701201048.ZM25916@seawind.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jan 1997 19:56:12 -0800 To: Geert Jan de Groot From: Steve Deering Subject: (IPng 2953) Re: 8+8 Why do we care? Cc: huitema@bellcore.com (Christian Huitema), ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Geert Jan de Groot wrote: > On Mon, 20 Jan 1997 10:48:07 -0500 Christian Huitema wrote: > > > As far as perception go, I can tell you that there certainly is a > > perception that a bigger address space is needed *now*. Basically, every > > large corporation would like its own class A. What they hear is that they > > can't because we have to ration addresses, and from there on they are > > dragged into suboptimal solutions. IPv6 is needed now, would in fact have > > been useful last year. > > I don't agree that making statements like 'every corporation needs > his own class A' makes sense. That's not what Christian said. He said that every *large* corporation would *like* its own Class A. You then explained why your distorted version of Christian's statement is wrong, but I'm sure Christian would agree with your counter-arguments to the strawman you (and not he) stated. He understands very well the capacity of address spaces -- after all, he *is* the inventor of the H Ratio. :-) Nonetheless, you don't have to exagerate the desires of the end users to conclude that IPv4 address space is already effectively exhausted. Some evidence: - Some sites (large, medium, and small) are being forced to use private address space, when they would prefer -- for good technical reasons -- not to do so. (Yes, there are also some sites that prefer to use private address space; that doesn't change the point.) This is *not* just a matter of those sites being lazy in how efficiently they use the address space they have -- sites with hundreds or thousands of computers are having to live with a single public Class C, and small offices and homes with more than one computer are having to live with a single global address. - Dial-up ISPs that would prefer to give each of their customers their own IP address are forced instead by the prefix police to assign addresses dynamically at dial-up time from a smaller pool. What's going to happen next year when all those offices and homes migrate to full-time IP connectivity, e.g., over cable or xDSL, rather than dial-up service? - Serious proposals are being made to institute a charging scheme for address space (*separate* from routing-table space), as a means of reducing the rate of address consumption (rather than just to recover registration costs). It seems bizarre to me to roll out all the economic machinery for allocating scarce resources for something whose scarcity is so articifial and amenable to technical fix. It's like keeping everyone locked in an airtight room and then rationing oxygen. Migrating to IPv6 as soon as possible would completely eliminate those problems -- every site could have 64 or 80 bits of address space, and every provider could have enough bits to number all of its customers. And doing that would *not* make the routing-scaling problem or prefix allocation problem any worse, since those are issues in managing the high-order parts of the address, not the low-order parts. Whether a site has one address or one billion addresses, and whether an ISP has two customers or two million customers, is irrelevant to the inter-ISP routing issues, since all of a site's addresses are aggregated into a single site prefix, and all of an ISP's customer sites are aggregated under the single prefix of the ISP. (Though it is also possible for widely topologically-distributed ISPs to cluster their customer site IDs, and inject more than one cluster prefix into the inter-ISP routing to enable more efficient delivery paths). Furthermore, as I said in another recent message, moving quickly to IPv6 is likely to offer some relief to the backbone routing problems, if not a final solution, since (a) it would eliminate all the unaggregated lagacy routes to individual sites, and (b) its renumbering support mechanisms (whether "8+8" or "classic") could reduce the pain of occasionally renumbering the ISPs for better top-level aggregation. The address space issue and the routing aggregation issue are *orthogonal*, but many folks seem intent on obscuring that fact. By blocking the provision of more address space to end sites until everyone agrees on the backbone routing solution, even though that top-level routing is *completely unaffected* by how many addesses any site has, a lot of unnecessary collateral damage is being done to the Internet -- to the architecture (e.g., NAT), to the users' experience and expenses, and to the reputation of the IETF and the ISPs. > What am I missing? Did that help? 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 Mon Jan 20 22:23:58 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09592; Mon, 20 Jan 97 22:23:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09586; Mon, 20 Jan 97 22:23:46 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA29807; Mon, 20 Jan 1997 22:15:06 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA22248 for ; Mon, 20 Jan 1997 22:14:53 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id PAA04183 for ; Tue, 21 Jan 1997 15:14:51 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id GAA09064; Tue, 21 Jan 1997 06:04:32 GMT To: ipng@sunroof.eng.sun.com Subject: (IPng 2954) flag for getaddrinfo X-Mailer: Mew version 1.54 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Jan 1997 15:04:32 +0900 Message-Id: <9061.853826672@mine.aist-nara.ac.jp> From: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, One month ago, Craig(2583) and Jean-Luc(2617) proposed an additional flag to getaddrinfo() to specify a return value in the numeric form. I also think this flag is necessary. Will this flag be included into the next basic API? If so, how? Thanks. --Kazu ------------------------------------------------------------------------------ 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 Tue Jan 21 05:05:26 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09892; Tue, 21 Jan 97 05:05:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09886; Tue, 21 Jan 97 05:05:12 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA20518; Tue, 21 Jan 1997 04:56:31 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA21405 for ; Tue, 21 Jan 1997 04:56:30 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id VAA13563 for ; Tue, 21 Jan 1997 21:56:22 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id MAA09505; Tue, 21 Jan 1997 12:46:05 GMT To: ipng@sunroof.eng.sun.com Subject: (IPng 2955) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Fri, 17 Jan 1997 11:42:58 -0500" References: <199701171157.LAA01055@inner.net> X-Mailer: Mew version 1.54 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Jan 1997 21:46:05 +0900 Message-Id: <9502.853850765@mine.aist-nara.ac.jp> From: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Craig Metz Subject: (IPng 2909) Re: Forward: hlim and IF on API Date: Fri, 17 Jan 1997 11:42:58 -0500 > I've proposed (and built, you need it to properly implement traceroute > and ping and it helped radvd and should help RIPng): > > int on=1; > if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, &on, sizeof(int)) < 0) > ... > > And an IPPROTO_IPV6/IPV6_HOPLIMIT control message that specifies the > hop limit on outgoing datagrams and receives (if turned on as above) the hop > limit on incoming datagrams. To my understanding... (1) setsockopt with IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS defines a default hop-limit for outgoing packets of unicast and multicast, respectively. (2) sendmsg with IPV6_HOPLIMIT overrides (1). (3) If turned on, recvmsg tells the hop-limit of incoming packets. Is this right? If so, this suggests that we can make IPV6_TXINFO and IPV6_RXINFO together. For example, (i) IPV6_UNICAST_IF(if consensus is achieved) and IPV6_MULTICAST_IF defines a default IF for outgoing packets of unicast and multicast, respectively. (ii) sendmsg with IPV6_PKTINFO overrides (i). (iii) If turned on, recvmsg tells the packet information of incoming packets. *OR* divide IPV6_HOPLIMIT into IPV6_TXHOPS and IPV6_RXHOPS. Comments? P.S. The argument of setsockopt with IPV6_UNICAST_HOPS should be *unsigned* int (instead of int) because that of IPV6_MULTICAST_HOPS is unsigned int in the basic API draft. --Kazu ------------------------------------------------------------------------------ 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 Tue Jan 21 05:09:48 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09904; Tue, 21 Jan 97 05:09:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09898; Tue, 21 Jan 97 05:09:36 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA21404; Tue, 21 Jan 1997 05:00:55 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAB22149 for ; Tue, 21 Jan 1997 05:00:55 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id GAA11900; Tue, 21 Jan 1997 06:00:54 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id GAA10433; Tue, 21 Jan 1997 06:00:53 -0700 (MST) Message-Id: <199701211300.GAA10433@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 21 Jan 1997 06:00:53 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Kazu Yamamoto , ipng@sunroof.eng.sun.com Subject: (IPng 2956) Re: flag for getaddrinfo Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Jan 21, 3:04pm you write:] > > One month ago, Craig(2583) and Jean-Luc(2617) proposed an additional > flag to getaddrinfo() to specify a return value in the numeric form. I > also think this flag is necessary. > > Will this flag be included into the next basic API? If so, how? Yes. There will be a 7th argument ("flags") with the following bit values: NI_NOFQDN, NI_NUMERICHOST, NI_NUMERICSERV, and NI_DGRAM. I finished the revision to the basic API draft this weekend. The coauthors are proofing the changes, and it should then be available this week. Rich Stevens ------------------------------------------------------------------------------ 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 Tue Jan 21 05:18:08 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09926; Tue, 21 Jan 97 05:18:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09914; Tue, 21 Jan 97 05:17:46 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA21887; Tue, 21 Jan 1997 05:09:05 -0800 Received: from pitneybowes-bh.pb.com (pitneybowes-bh.pb.com [204.164.207.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA23621 for ; Tue, 21 Jan 1997 05:09:05 -0800 Received: (from uucp@localhost) by pitneybowes-bh.pb.com (8.6.12/8.6.11) id IAA05192 for ; Tue, 21 Jan 1997 08:10:05 -0500 Received: from micro2.pb.com by pitneybowes-bh.pb.com via smap (V1.3) id sma005116; Tue Jan 21 08:09:49 1997 Received: by micro2.pb.com (5.65v3.2/DEC-Ultrix/4.3) id AA01524; Tue, 21 Jan 1997 08:09:10 -0500 Received: by tsap.ct.pb.com (5.57/Ultrix3.0-C/PB-11-2-93) id AA13866; Tue, 21 Jan 97 08:08:15 -0500 Received: from ccMail by smtppc.ct.pb.com (SMTPLINK V2.11.01) id AA853862841; Mon, 20 Jan 97 13:10:23 EST Date: Mon, 20 Jan 97 13:10:23 EST From: "Arthur Parkos" Message-Id: <9700218538.AA853862841@smtppc.ct.pb.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2957) Strong encryption export and IPSEC Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk if u.s. export control on strong encryption applies to ipv6 packets, how will data be prevented from exiting u.s.? will routers with international links have to assume burden of filtering? using the spi or sensitivity level to make a determination as to how strongly is the data encrypted? would this impact routers performance significantly? does the control on strong encryption weaken ipsec to the point where it becomes a non-feature for international exchange of data? ------------------------------------------------------------------------------ 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 Tue Jan 21 05:18:10 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09927; Tue, 21 Jan 97 05:18:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09919; Tue, 21 Jan 97 05:17:48 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA21890; Tue, 21 Jan 1997 05:09:06 -0800 Received: from pitneybowes-bh.pb.com (pitneybowes-bh.pb.com [204.164.207.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA23629 for ; Tue, 21 Jan 1997 05:09:07 -0800 Received: (from uucp@localhost) by pitneybowes-bh.pb.com (8.6.12/8.6.11) id IAA05208 for ; Tue, 21 Jan 1997 08:10:07 -0500 Received: from micro2.pb.com by pitneybowes-bh.pb.com via smap (V1.3) id sma005120; Tue Jan 21 08:09:52 1997 Received: by micro2.pb.com (5.65v3.2/DEC-Ultrix/4.3) id AA01529; Tue, 21 Jan 1997 08:09:13 -0500 Received: by tsap.ct.pb.com (5.57/Ultrix3.0-C/PB-11-2-93) id AA13869; Tue, 21 Jan 97 08:08:17 -0500 Received: from ccMail by smtppc.ct.pb.com (SMTPLINK V2.11.01) id AA853862851; Mon, 20 Jan 97 13:31:49 EST Date: Mon, 20 Jan 97 13:31:49 EST From: "Arthur Parkos" Message-Id: <9700218538.AA853862851@smtppc.ct.pb.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2958) performance of ipv6 design Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk was there a study or common sense that pointed to routers as opposed to size/number of packets as major contributor to performance degradation of internet that led to an increase in size of ip packet in ipv6 but a reduction in amount of work that a router needs to perform? who/what is the consumer of internet services that is considered to be the primary design goal benefactor? another way:when tradeoffs are made, who/what do the design decisions favor? in terms of transmission speeds and related infrastructure attributes, has ipv6 been designed for a future target and if so is there a general guide as to what it is? has there been any performance analysis on the mbone? is the data available? does it seem to susbtantiate that performance in routers is better given the lesser amount of work that needs to be done w.r.t. headers? is there evidence that this will play out when it is full scale? as long as ipv4 needs to be supported, will there be any gain from the new design, or will performance suffer as long as two protocols are supported? ------------------------------------------------------------------------------ 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 Tue Jan 21 05:18:44 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09934; Tue, 21 Jan 97 05:18:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09928; Tue, 21 Jan 97 05:18:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA21946; Tue, 21 Jan 1997 05:09:39 -0800 Received: from pitneybowes-bh.pb.com (pitneybowes-bh.pb.com [204.164.207.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA23736 for ; Tue, 21 Jan 1997 05:09:39 -0800 Received: (from uucp@localhost) by pitneybowes-bh.pb.com (8.6.12/8.6.11) id IAA05304 for ; Tue, 21 Jan 1997 08:10:39 -0500 Received: from micro2.pb.com by pitneybowes-bh.pb.com via smap (V1.3) id sma005270; Tue Jan 21 08:10:31 1997 Received: by micro2.pb.com (5.65v3.2/DEC-Ultrix/4.3) id AA01569; Tue, 21 Jan 1997 08:09:52 -0500 Received: by tsap.ct.pb.com (5.57/Ultrix3.0-C/PB-11-2-93) id AA13904; Tue, 21 Jan 97 08:08:52 -0500 Received: from ccMail by smtppc.ct.pb.com (SMTPLINK V2.11.01) id AA853862861; Mon, 20 Jan 97 13:40:09 EST Date: Mon, 20 Jan 97 13:40:09 EST From: "Arthur Parkos" Message-Id: <9700218538.AA853862861@smtppc.ct.pb.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2959) key distribution and management Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk is isakmp or skip going to be the clear choice for ipsec? or will multiple methods be supported and identified in the spi? will public/private key encryption be used? will public/private key usage be primarily to encrypt the session key? will routing manufacturers install keys in routers or will it be up to network admin to install keys? will certificate authority style services be needed to verify keys and if so by whom? some ietf group or commercial entity?where and how maintain certificate revocation list for routers and such? is there a source or site that i should look to for the answers to this 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 Tue Jan 21 05:42:41 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10001; Tue, 21 Jan 97 05:42:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09988; Tue, 21 Jan 97 05:42:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA23354; Tue, 21 Jan 1997 05:33:26 -0800 Received: from pitneybowes-bh.pb.com (pitneybowes-bh.pb.com [204.164.207.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA28507 for ; Tue, 21 Jan 1997 05:33:27 -0800 Received: (from uucp@localhost) by pitneybowes-bh.pb.com (8.6.12/8.6.11) id IAA07187 for ; Tue, 21 Jan 1997 08:34:27 -0500 Received: from micro2.pb.com by pitneybowes-bh.pb.com via smap (V1.3) id sma007171; Tue Jan 21 08:34:15 1997 Received: by micro2.pb.com (5.65v3.2/DEC-Ultrix/4.3) id AA02002; Tue, 21 Jan 1997 08:33:35 -0500 Received: by tsap.ct.pb.com (5.57/Ultrix3.0-C/PB-11-2-93) id AA14583; Tue, 21 Jan 97 08:32:39 -0500 Received: from ccMail by smtppc.ct.pb.com (SMTPLINK V2.11.01) id AA853864589; Tue, 21 Jan 97 08:31:32 EST Date: Tue, 21 Jan 97 08:31:32 EST From: "Arthur Parkos" Message-Id: <9700218538.AA853864589@smtppc.ct.pb.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2962) performance of ipv6 design Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk was there a study or common sense that pointed to routers as opposed to size/number of packets as major contributor to performance degradation of internet that led to an increase in size of ip packet in ipv6 but a reduction in amount of work that a router needs to perform? who/what is the consumer of internet services that is considered to be the primary design goal benefactor? another way:when tradeoffs are made, who/what do the design decisions favor? in terms of transmission speeds and related infrastructure attributes, has ipv6 been designed for a future target and if so is there a general guide as to what it is? has there been any performance analysis on the mbone? is the data available? does it seem to susbtantiate that performance in routers is better given the lesser amount of work that needs to be done w.r.t. headers? is there evidence that this will play out when it is full scale? as long as ipv4 needs to be supported, will there be any gain from the new design, or will performance suffer as long as two protocols are supported? ------------------------------------------------------------------------------ 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 Tue Jan 21 05:42:26 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09999; Tue, 21 Jan 97 05:42:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09981; Tue, 21 Jan 97 05:42:03 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA23342; Tue, 21 Jan 1997 05:33:21 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA28489 for ; Tue, 21 Jan 1997 05:33:19 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id GAA11946; Tue, 21 Jan 1997 06:33:18 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id GAA10529; Tue, 21 Jan 1997 06:33:17 -0700 (MST) Message-Id: <199701211333.GAA10529@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 21 Jan 1997 06:33:17 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Kazu Yamamoto , ipng@sunroof.eng.sun.com Subject: (IPng 2960) Re: Forward: hlim and IF on API Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Jan 21, 9:46pm you write:] > > (1) setsockopt with IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS defines > a default hop-limit for outgoing packets of unicast and multicast, > respectively. Correct. > (2) sendmsg with IPV6_HOPLIMIT overrides (1). Correct, for that sendmsg() only, regardless whether the destination is unicast or multicast. Also, for consistency with the other per-packet flags that can be set using ancillary data in the advanced API, the cmsg_type will be IPV6_TXHOPLIMIT. > (3) If turned on, recvmsg tells the hop-limit of incoming packets. There is a new socket option, IPV6_RXHOPLIMIT, that when enabled, causes the received hop limit to be returned as ancillary data with each call to recvmsg(). The cmsg_type of the ancillary data will be set to IPV6_RXHOPLIMIT. > If so, this suggests that we can make IPV6_TXINFO and IPV6_RXINFO > together. For example, > > (i) IPV6_UNICAST_IF(if consensus is achieved) and IPV6_MULTICAST_IF > defines a default IF for outgoing packets of unicast and multicast, > respectively. > > (ii) sendmsg with IPV6_PKTINFO overrides (i). > > (iii) If turned on, recvmsg tells the packet information of incoming > packets. > > *OR* divide IPV6_HOPLIMIT into IPV6_TXHOPS and IPV6_RXHOPS. That's what we're planning. As things currently stand, there is one type of ancillary data to set and receive the hop limit, and another type of ancillary data to set and receive the interface index and src/dst IPv6 address. As I understand the above, you are proposing to combine all three of these into one structure of "packet information" that can be returned by recvmsg() with the interface index, destination IPv6 address, and hop limit. The same structure can be specified to sendmsg() containing the outgoing interface index, source IPv6 address, and hop limit (with a way to say "use the default" for each three, of course). > The argument of setsockopt with IPV6_UNICAST_HOPS should be *unsigned* > int (instead of int) because that of IPV6_MULTICAST_HOPS is unsigned > int in the basic API draft. Both have been changed to "int" in the new basic API draft, to allow a value of -1 to tell the system to go back to its default. Rich Stevens ------------------------------------------------------------------------------ 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 Tue Jan 21 05:42:39 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10000; Tue, 21 Jan 97 05:42:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09987; Tue, 21 Jan 97 05:42:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA23352; Tue, 21 Jan 1997 05:33:26 -0800 Received: from pitneybowes-bh.pb.com (pitneybowes-bh.pb.com [204.164.207.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA28506 for ; Tue, 21 Jan 1997 05:33:27 -0800 Received: (from uucp@localhost) by pitneybowes-bh.pb.com (8.6.12/8.6.11) id IAA07186 for ; Tue, 21 Jan 1997 08:34:27 -0500 Received: from micro2.pb.com by pitneybowes-bh.pb.com via smap (V1.3) id sma007160; Tue Jan 21 08:34:11 1997 Received: by micro2.pb.com (5.65v3.2/DEC-Ultrix/4.3) id AA01993; Tue, 21 Jan 1997 08:33:32 -0500 Received: by tsap.ct.pb.com (5.57/Ultrix3.0-C/PB-11-2-93) id AA14582; Tue, 21 Jan 97 08:32:38 -0500 Received: from ccMail by smtppc.ct.pb.com (SMTPLINK V2.11.01) id AA853864591; Tue, 21 Jan 97 08:31:38 EST Date: Tue, 21 Jan 97 08:31:38 EST From: "Arthur Parkos" Message-Id: <9700218538.AA853864591@smtppc.ct.pb.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2961) Strong encryption export and IPSEC Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk if u.s. export control on strong encryption applies to ipv6 packets, how will data be prevented from exiting u.s.? will routers with international links have to assume burden of filtering? using the spi or sensitivity level to make a determination as to how strongly is the data encrypted? would this impact routers performance significantly? does the control on strong encryption weaken ipsec to the point where it becomes a non-feature for international exchange of data? ------------------------------------------------------------------------------ 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 Tue Jan 21 05:47:23 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10038; Tue, 21 Jan 97 05:47:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10032; Tue, 21 Jan 97 05:47:08 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA23741; Tue, 21 Jan 1997 05:38:27 -0800 Received: from pitneybowes-bh.pb.com (pitneybowes-bh.pb.com [204.164.207.66]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA09290 for ; Tue, 21 Jan 1997 05:38:27 -0800 Received: (from uucp@localhost) by pitneybowes-bh.pb.com (8.6.12/8.6.11) id IAA07188 for ; Tue, 21 Jan 1997 08:34:27 -0500 Received: from micro2.pb.com by pitneybowes-bh.pb.com via smap (V1.3) id sma007172; Tue Jan 21 08:34:15 1997 Received: by micro2.pb.com (5.65v3.2/DEC-Ultrix/4.3) id AA02005; Tue, 21 Jan 1997 08:33:36 -0500 Received: by tsap.ct.pb.com (5.57/Ultrix3.0-C/PB-11-2-93) id AA14584; Tue, 21 Jan 97 08:32:40 -0500 Received: from ccMail by smtppc.ct.pb.com (SMTPLINK V2.11.01) id AA853864587; Tue, 21 Jan 97 08:31:24 EST Date: Tue, 21 Jan 97 08:31:24 EST From: "Arthur Parkos" Message-Id: <9700218538.AA853864587@smtppc.ct.pb.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2963) key distribution and management Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk is isakmp or skip going to be the clear choice for ipsec? or will multiple methods be supported and identified in the spi? will public/private key encryption be used? will public/private key usage be primarily to encrypt the session key? will routing manufacturers install keys in routers or will it be up to network admin to install keys? will certificate authority style services be needed to verify keys and if so by whom? some ietf group or commercial entity?where and how maintain certificate revocation list for routers and such? is there a source or site that i should look to for the answers to this 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 Tue Jan 21 06:12:53 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10129; Tue, 21 Jan 97 06:12:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10123; Tue, 21 Jan 97 06:12:41 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA25972; Tue, 21 Jan 1997 06:03:59 -0800 Received: from pitneybowes-bh.pb.com (pitneybowes-bh.pb.com [204.164.207.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA06206 for ; Tue, 21 Jan 1997 06:03:59 -0800 Received: (from uucp@localhost) by pitneybowes-bh.pb.com (8.6.12/8.6.11) id JAA09855 for ; Tue, 21 Jan 1997 09:04:59 -0500 Received: from micro2.pb.com by pitneybowes-bh.pb.com via smap (V1.3) id sma009824; Tue Jan 21 09:04:52 1997 Received: by micro2.pb.com (5.65v3.2/DEC-Ultrix/4.3) id AA02369; Tue, 21 Jan 1997 09:04:06 -0500 Received: by tsap.ct.pb.com (5.57/Ultrix3.0-C/PB-11-2-93) id AA14943; Tue, 21 Jan 97 09:03:11 -0500 Received: from ccMail by smtppc.ct.pb.com (SMTPLINK V2.11.01) id AA853866428; Tue, 21 Jan 97 09:02:33 EST Date: Tue, 21 Jan 97 09:02:33 EST From: "Arthur Parkos" Message-Id: <9700218538.AA853866428@smtppc.ct.pb.com> To: ipng@sunroof.eng.sun.com, "Arthur Parkos" Subject: (IPng 2964) Re: Strong encryption export and IPSEC Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sorry for the dual posting. i assumed our internet email gateway was down once again since i received no messages yesterday. ------------------------------------------------------------------------------ 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 Tue Jan 21 06:21:40 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10178; Tue, 21 Jan 97 06:21:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10155; Tue, 21 Jan 97 06:21:14 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA26630; Tue, 21 Jan 1997 06:12:34 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA09002 for ; Tue, 21 Jan 1997 06:12:32 -0800 Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.4/8.6.12) with SMTP id JAA03248; Tue, 21 Jan 1997 09:11:13 -0500 (EST) Message-Id: <199701211411.JAA03248@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: "Arthur Parkos" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2965) Re: Strong encryption export and IPSEC In-Reply-To: Your message of "Tue, 21 Jan 1997 08:31:38 EST." <9700218538.AA853864591@smtppc.ct.pb.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 21 Jan 1997 09:11:08 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Arthur Parkos" writes: > if u.s. export control on strong encryption applies to ipv6 packets, > how will data be prevented from exiting u.s.? The prohibition is on cryptographic software, not on encrypted data. Perry ------------------------------------------------------------------------------ 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 Tue Jan 21 06:34:05 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10210; Tue, 21 Jan 97 06:34:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10204; Tue, 21 Jan 97 06:33:54 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA28551; Tue, 21 Jan 1997 06:25:13 -0800 Received: from pitneybowes-bh.pb.com (pitneybowes-bh.pb.com [204.164.207.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA12245 for ; Tue, 21 Jan 1997 06:25:12 -0800 Received: (from uucp@localhost) by pitneybowes-bh.pb.com (8.6.12/8.6.11) id JAA12261; Tue, 21 Jan 1997 09:26:05 -0500 Received: from micro2.pb.com by pitneybowes-bh.pb.com via smap (V1.3) id sma012238; Tue Jan 21 09:26:00 1997 Received: by micro2.pb.com (5.65v3.2/DEC-Ultrix/4.3) id AA02676; Tue, 21 Jan 1997 09:25:20 -0500 Received: by tsap.ct.pb.com (5.57/Ultrix3.0-C/PB-11-2-93) id AA15386; Tue, 21 Jan 97 09:24:26 -0500 Received: from ccMail by smtppc.ct.pb.com (SMTPLINK V2.11.01) id AA853867594; Tue, 21 Jan 97 09:19:32 EST Date: Tue, 21 Jan 97 09:19:32 EST From: "Arthur Parkos" Message-Id: <9700218538.AA853867594@smtppc.ct.pb.com> To: parkosar@pb.com, perry@piermont.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2966) Re[2]: Strong encryption export and IPSEC Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i apologize for asking a non-issue question, and i appreciate the responses. ______________________________ Reply Separator _________________________________ Subject: Re: (IPng 2961) Strong encryption export and IPSEC Author: perry@piermont.com at SMTPGWY Date: 1/21/97 9:17 AM "Arthur Parkos" writes: > if u.s. export control on strong encryption applies to ipv6 packets, > how will data be prevented from exiting u.s.? The prohibition is on cryptographic software, not on encrypted data. Perry ------------------------------------------------------------------------------ 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 Tue Jan 21 06:44:59 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10263; Tue, 21 Jan 97 06:44:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10257; Tue, 21 Jan 97 06:44:46 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA29740; Tue, 21 Jan 1997 06:36:06 -0800 Received: from pitneybowes-bh.pb.com (pitneybowes-bh.pb.com [204.164.207.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA15399 for ; Tue, 21 Jan 1997 06:36:05 -0800 Received: (from uucp@localhost) by pitneybowes-bh.pb.com (8.6.12/8.6.11) id JAA13516 for ; Tue, 21 Jan 1997 09:37:06 -0500 Received: from micro2.pb.com by pitneybowes-bh.pb.com via smap (V1.3) id sma013475; Tue Jan 21 09:36:40 1997 Received: by micro2.pb.com (5.65v3.2/DEC-Ultrix/4.3) id AA02779; Tue, 21 Jan 1997 09:35:50 -0500 Received: by tsap.ct.pb.com (5.57/Ultrix3.0-C/PB-11-2-93) id AA15488; Tue, 21 Jan 97 09:32:21 -0500 Received: from ccMail by smtppc.ct.pb.com (SMTPLINK V2.11.01) id AA853868176; Tue, 21 Jan 97 09:25:48 EST Date: Tue, 21 Jan 97 09:25:48 EST From: "Arthur Parkos" Message-Id: <9700218538.AA853868176@smtppc.ct.pb.com> To: ipng@sunroof.eng.sun.com, "Arthur Parkos" Subject: (IPng 2967) Re: performance of ipv6 design Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i would like to change mbone to 6BONE in this question. ------------------------------------------------------------------------------ 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 Tue Jan 21 06:48:09 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10283; Tue, 21 Jan 97 06:48:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10277; Tue, 21 Jan 97 06:47:50 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA00004; Tue, 21 Jan 1997 06:39:08 -0800 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA16382; Tue, 21 Jan 1997 06:39:07 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id GAA19627 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id GAA15413 Posted-Date: Tue, 21 Jan 1997 06:39:03 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id JAA21901; Tue, 21 Jan 1997 09:39:02 -0500 for Date: Tue, 21 Jan 1997 09:39:02 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701211439.JAA21901@pobox.engeast.BayNetworks.COM> To: erik.nordmark@Eng Subject: (IPng 2968) Re: IPv6 MIB: per-entity stats Cc: ipng@sunroof.eng.sun.com, ip6mib@Research.Ftp.Com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > > > I'll be updating the IPv6 MIB draft to reflect comments I've received > > so far. At this point I'm not sure if there is a consensus that > > the per-entity interface and ICMP statistics are to be deleted > > from the mib. A number of people view the per-entity, aka per-node, statistics > > redundant since the information can be derived from the per-interface > > statistics. > > It is correct that the per-entity counters can be derived > using the sum of the per-interface counters. > But somebody raised the issue of what happens to "the sum of the > per-interface counters" as interfaces are deleted. > > Is this still an outstanding issue? > > Erik One can take a view that when an interface is deleted its statistics become irrelevant and should be excluded from the per-node stats. 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 Tue Jan 21 08:01:31 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10536; Tue, 21 Jan 97 08:01:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10530; Tue, 21 Jan 97 08:01:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA09124; Tue, 21 Jan 1997 07:52:39 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA12583 for ; Tue, 21 Jan 1997 07:52:37 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA02275; Tue, 21 Jan 1997 10:38:03 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA10848; Tue, 21 Jan 1997 10:37:57 -0500 Message-Id: <9701211537.AA10848@wasted.zk3.dec.com> To: Steve Deering Cc: Geert Jan de Groot , huitema@bellcore.com (Christian Huitema), ipng@sunroof.eng.sun.com Subject: (IPng 2969) Re: 8+8 Why do we care? In-Reply-To: Your message of "Mon, 20 Jan 97 19:56:12 PST." Date: Tue, 21 Jan 97 10:37:56 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, That was wonderful!!!!! /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 Tue Jan 21 08:18:05 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10552; Tue, 21 Jan 97 08:18:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10546; Tue, 21 Jan 97 08:17:53 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA11410; Tue, 21 Jan 1997 08:09:11 -0800 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA19236 for ; Tue, 21 Jan 1997 08:09:07 -0800 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA24648; Tue, 21 Jan 97 10:58:07 EST Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id LAA02984; Tue, 21 Jan 1997 11:08:05 -0500 Date: Tue, 21 Jan 1997 11:08:05 -0500 Message-Id: <199701211608.LAA02984@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com, ipv6imp@munnari.OZ.AU, 6bone@ISI.EDU, rdr@cs.unh.edu, rdb@cs.unh.edu, mattyc@leonis.nus.sg, qv@iol.unh.edu, whl@whitec.sr.unh.edu, yunzhou@ee.nus.sg, scip4166@leonis.nus.org Subject: (IPng 2970) Another IPv6 Implementation. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, We at the University of New Hampshire would like to announce another Public Domain Implementation for IPv6. It was started with an aim to develop a 64 bit implementation for the public domain. It has several significant differences from existing IPv6 implementations. It has been developed on NetBSD 1.2 running on Digital Alpha 64 bit processor. It might also run over 32 bit architectures (though I have not tested this, but it should not be a big problem). I have tested the implementation using the UNH InterOperabilty Labs. test suite and it interoperates with other implementations. The code base is accessible at : ftp://sun4.iol.unh.edu/pub/ipv6 The packages can be accesses in gzipped or compressed form. unh-ipv6-kit-0.0.tar.gz (for gunzip) unh-ipv6-kit-0.0.tar.Z (for uncompress) Some documentation is provided in the README and NOTES file about the installation procedure and about features supported by this implementation. Public Domain DHCPv6 code has also been written for this code base by Yunzhou Li. This was announced a couple of weeks back. If you have questions, suggestions etc., contact me at : qv@sun4.iol.unh.edu For discussion of this implementation and associated problems, use the IPv6 implementors list at : ipv6imp@munnari.oz.au You can subscribe to it by sending a mail to : ipv6imp-request@munnari.oz.au The release has a postscript file which has discusses this implementation. It is unh-ipv6-proj.ps I am very grateful to a bunch of people for this, who are : Bill Lenharth at InterOperability Lab. (UNH) Jim Bound (Digital Equipment Corp.) Prof. Robert D. Russell (UNH) Yunzhou Li (NUS) Digital Alpha DUNIX IPv6 Team A special thanks goes to the NetBSD community and IETF. Sincerely, Quaizar ------------------------------------------------------------------------ Quaizar Vohra InterOperabilty Lab. (UNH) (603)-862-0090 qv@sun4.iol.unh.edu ------------------------------------------------------------------------------ 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 Tue Jan 21 09:30:28 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10651; Tue, 21 Jan 97 09:30:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04353; Fri, 17 Jan 97 09:09:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA23285; Fri, 17 Jan 1997 09:00:43 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA15309 for ; Fri, 17 Jan 1997 09:00:42 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id MAA01072; Fri, 17 Jan 1997 12:15:03 GMT Message-Id: <199701171215.MAA01072@inner.net> To: Masaki Hirabaru Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2971) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Fri, 17 Jan 1997 11:42:58 EST." <199701171157.LAA01055@inner.net> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 17 Jan 1997 12:00:34 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199701171157.LAA01055@inner.net>, I write: > I've proposed (and built, you need it to properly implement traceroute >and ping and it helped radvd and should help RIPng): > > int on=1; > if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, &on, sizeof(int)) < 0) > ... > > And an IPPROTO_IPV6/IPV6_HOPLIMIT control message that specifies the >hop limit on outgoing datagrams and receives (if turned on as above) the hop >limit on incoming datagrams. Oh, I forgot the most important part: the argument is an int (going along with the general trend). -Craig From dth@lucent.com Fri Jan 17 13:52:12 1997 Return-Path: Received: from sunroof.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA16212; Fri, 17 Jan 1997 13:52:11 -0800 Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04985; Fri, 17 Jan 97 14:00:44 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA20106; Fri, 17 Jan 1997 13:52:08 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA13211 for ; Fri, 17 Jan 1997 13:52:07 -0800 Received: by snoopy.agile.com with Internet Mail Service (5.0.1389.3) id <01BC046E.662D9BF0@snoopy.agile.com>; Fri, 17 Jan 1997 12:03:06 -0500 Message-Id: From: "Harrington, Dan" To: "'owner-ipng@sunroof.Eng.Sun.COM'" Subject: RE: (IPng 2908) Re: 8+8 Why do we care? Date: Fri, 17 Jan 1997 12:03:05 -0500 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) X-Lines: 18 Status: RO Content-Type: text/plain Content-Length: 577 Brian, I'm not sure I follow you here... > As I said above, it's because of multihoming: the sending host cannot > reasonably be asked to do RG selection for a multihomed > destination, or to know which local RG to use as its source > if the local site is multihomed. Only the routing system can possess > that knowledge. As I read 8+8, the sending host is still responsible for choosing the destination address, RG and all. The draft only talks about rewriting the *source* address as it exits the site...did I miss something important in the subsequent discussions? Dan From owner-ipng@sunroof.eng.sun.com Sat Jan 18 00:39:47 1997 Return-Path: Received: from sunroof.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA28040; Sat, 18 Jan 1997 00:39:46 -0800 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05673; Sat, 18 Jan 97 00:48:21 PST Date: Sat, 18 Jan 97 00:48:21 PST Message-Id: <9701180848.AA05673@sunroof.eng.sun.com> To: owner-ipng@sunroof.eng.sun.com From: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Non-member submission from ["David R. Conrad" ] Content-Length: 2085 X-Lines: 45 Status: RO From davidc@apnic.net Sat Jan 18 00:48:04 1997 Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05667; Sat, 18 Jan 97 00:48:04 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA02387; Sat, 18 Jan 1997 00:39:27 -0800 Received: from apnic-ttc.apnic.net (apnic-ttc.apnic.net [203.178.142.242]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA15091 for ; Sat, 18 Jan 1997 00:39:25 -0800 Received: by apnic-ttc.apnic.net; id RAA21517; Sat, 18 Jan 1997 17:29:13 +0900 Received: from unknown(10.0.10.4) by apnic-ttc.apnic.net via smap (g3.0.3) id xma021505; Sat, 18 Jan 97 17:28:56 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.8.2/8.7.1) with ESMTP id RAA12905; Sat, 18 Jan 1997 17:31:56 +0900 (JST) Message-Id: <199701180831.RAA12905@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: Paul Ferguson Cc: "Brian Carpenter CERN-CN" , ipng@sunroof.eng.sun.com, kimh@internic.net, dfk@ripe.net, davidc@apnic.net Subject: Re: (IPng 2901) Re: 8+8 Why do we care? In-Reply-To: Your message of "Fri, 17 Jan 1997 08:39:28 EST." <3.0.32.19970117083921.006989c4@lint.cisco.com> Date: Sat, 18 Jan 1997 17:31:56 +0900 From: "David R. Conrad" Hi, Unless there is a radical change in the way the registries operated, 256 providers per registry would be insufficient. Regards, -drc --------- >Brian, > >It might be beneficial to enlist comments of the folks >that run the registries. While 256 providers-per-registry >might seem like a feasible number, it would be interesting >to solicit comments on projected growth in this area. Yes, >I know it's hard to project growth with regards to allocation >and v6, but perhaps a comparison to v4 allocations would >be worthwhile. Of course, this also depends on whether >provider-based allocation is the de facto method of allocation. > >$.02, > >- paul ------------------------------------------------------------------------------ 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 Tue Jan 21 09:31:58 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10658; Tue, 21 Jan 97 09:31:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05667; Sat, 18 Jan 97 00:48:04 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA02387; Sat, 18 Jan 1997 00:39:27 -0800 Received: from apnic-ttc.apnic.net (apnic-ttc.apnic.net [203.178.142.242]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA15091 for ; Sat, 18 Jan 1997 00:39:25 -0800 Received: by apnic-ttc.apnic.net; id RAA21517; Sat, 18 Jan 1997 17:29:13 +0900 Received: from unknown(10.0.10.4) by apnic-ttc.apnic.net via smap (g3.0.3) id xma021505; Sat, 18 Jan 97 17:28:56 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.8.2/8.7.1) with ESMTP id RAA12905; Sat, 18 Jan 1997 17:31:56 +0900 (JST) Message-Id: <199701180831.RAA12905@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: Paul Ferguson Cc: "Brian Carpenter CERN-CN" , ipng@sunroof.eng.sun.com, kimh@internic.net, dfk@ripe.net, davidc@apnic.net Subject: (IPng 2972) Re: 8+8 Why do we care? In-Reply-To: Your message of "Fri, 17 Jan 1997 08:39:28 EST." <3.0.32.19970117083921.006989c4@lint.cisco.com> Date: Sat, 18 Jan 1997 17:31:56 +0900 From: "David R. Conrad" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Unless there is a radical change in the way the registries operated, 256 providers per registry would be insufficient. Regards, -drc --------- >Brian, > >It might be beneficial to enlist comments of the folks >that run the registries. While 256 providers-per-registry >might seem like a feasible number, it would be interesting >to solicit comments on projected growth in this area. Yes, >I know it's hard to project growth with regards to allocation >and v6, but perhaps a comparison to v4 allocations would >be worthwhile. Of course, this also depends on whether >provider-based allocation is the de facto method of allocation. > >$.02, > >- paul ------------------------------------------------------------------------------ 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 Tue Jan 21 10:29:42 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11091; Tue, 21 Jan 97 10:29:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08104; Mon, 20 Jan 97 08:29:42 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA04217; Mon, 20 Jan 1997 08:21:02 -0800 Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA06094 for ; Mon, 20 Jan 1997 08:21:01 -0800 Received: from elmo.uu.net by relay4.UU.NET with ESMTP (peer crosschecked as: elmo.UU.NET [153.39.245.203]) id QQbzif10127; Mon, 20 Jan 1997 11:20:55 -0500 (EST) Received: from elmo.uu.net (localhost.UU.NET [127.0.0.1]) by elmo.uu.net (8.7.5/8.7.3) with ESMTP id LAA10819; Mon, 20 Jan 1997 11:20:52 -0500 (EST) Message-Id: <199701201620.LAA10819@elmo.uu.net> To: huitema@bellcore.com (Christian Huitema) Cc: Paul Ferguson , bound@zk3.dec.com, ipng@sunroof.eng.sun.com, mo@elmo.uu.net Subject: (IPng 2973) Re: 8+8 Why do we care? In-Reply-To: Your message of "Mon, 20 Jan 1997 10:48:07 EST." <9701201048.ZM25916@seawind.bellcore.com> Date: Mon, 20 Jan 1997 11:20:52 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk part of the reason companies want a class-A is because (1) the name (who wants to be other than class-A?) (2) fear of running out (get the biggest one - that can't be wrong, can it??) (3) the incredible wastefulness of current IPv4 address usage people feel forced to encode topology in addresses that were never, ever intended to do so at this scale. mix in a little fomented hysteria and you have an amusing azeotrope. -mo ------------------------------------------------------------------------------ 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 Tue Jan 21 10:30:52 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11098; Tue, 21 Jan 97 10:30:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11092; Tue, 21 Jan 97 10:30:36 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA07954; Tue, 21 Jan 1997 10:21:54 -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 KAA15867 for ; Tue, 21 Jan 1997 10:21:27 -0800 Received: from dasexc1.das.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA08878; Tue, 21 Jan 1997 13:07:36 -0500 (EST) Received: by dasexc1.das.dec.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC079C.56B18B60@dasexc1.das.dec.com>; Tue, 21 Jan 1997 13:09:31 -0500 Message-Id: From: Eunice Moreno To: "'Paul Ferguson'" , "'David R. Conrad'" Cc: "'Brian Carpenter CERN-CN'" , "'ipng@sunroof.Eng.Sun.COM'" , "'kimh@internic.net'" , "'dfk@ripe.net'" Subject: (IPng 2974) Re: 8+8 Why do we care? Date: Tue, 21 Jan 1997 13:09:04 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please get me off your distribution list. you are cluttering up my e-mail Eunice Moreno Digital Equipment Corporation ---------- From: David R. Conrad[SMTP:davidc@apnic.net] Sent: Saturday, January 18, 1997 3:31 AM To: Paul Ferguson Cc: Brian Carpenter CERN-CN; ipng@sunroof.Eng.Sun.COM; kimh@internic.net; dfk@ripe.net; davidc@apnic.net Subject: (IPng 2972) Re: 8+8 Why do we care? Hi, Unless there is a radical change in the way the registries operated, 256 providers per registry would be insufficient. Regards, -drc --------- >Brian, > >It might be beneficial to enlist comments of the folks >that run the registries. While 256 providers-per-registry >might seem like a feasible number, it would be interesting >to solicit comments on projected growth in this area. Yes, >I know it's hard to project growth with regards to allocation >and v6, but perhaps a comparison to v4 allocations would >be worthwhile. Of course, this also depends on whether >provider-based allocation is the de facto method of allocation. > >$.02, > >- paul ----------------------------------------------------------------------- ------- 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 ------------------------------------------------------------------------------ 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 Tue Jan 21 10:41:32 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11149; Tue, 21 Jan 97 10:41:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08119; Mon, 20 Jan 97 08:49:02 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA06612; Mon, 20 Jan 1997 08:40:22 -0800 From: mrf@epilogue.com Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA12852 for ; Mon, 20 Jan 1997 08:40:20 -0800 To: narten@raleigh.ibm.com Cc: solensky@ftp.com, ipng@sunroof.eng.sun.com In-Reply-To: <199701140228.VAA14099@hygro.raleigh.ibm.com> (message from Thomas Narten on Mon, 13 Jan 1997 21:28:32 -0500) Subject: (IPng 2975) Re: 8+8 Why ESDS are not globally Unique Date: Mon, 20 Jan 97 11:40:13 -0500 Message-Id: <9701201140.aa27683@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I've heard this statement made made several times, but the information >is always second hand. Do you (or anyone) have references to specific >examples of this? That is, how many duplicate addresses actually got >shipped, who were the manufacturers, were they all recalled, etc.? I >don't doubt that it _could_ happen, but I can't help but wonder if >there is also a bit of urban legend here as well. I don't know all of the details (would any manufacturer actually want them released?) but I know for a *fact* that duplicate boards have been manufactured. Several years ago (~5 years ago) before SMC bought Western Digital, WD shipped us a box of boards in which 3 of the boards had the same hardware address. There was no recall (as far as I know). When we contacted them, they were very apologetic and responsive (immediately replacing the boards). The support person told us that, due to human error, "hundreds" of boards had been produced with the same Ethernet address. I am sure that this was not an isolated incident, but it was the only time it ever happened to me. Regardless, I agree with Mike O'Dell's description that hardware addresses are "unique enough". For connections where a very slim possibility of an accidental match could cause major security or reliability issues, it would seem logical to use some type of security, anyway. Wouldn't it? mrf Margaret Forsythe mrf@epilogue.com Epilogue Technology Corp. (617) 245-0804 333 North Ave, 4th Floor Fax: (617) 245-8122 Wakefield, MA 01880, USA Sales: (505) 271-9933 ------------------------------------------------------------------------------ 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 Tue Jan 21 10:45:50 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11164; Tue, 21 Jan 97 10:45:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08980; Mon, 20 Jan 97 16:36:29 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA03781; Mon, 20 Jan 1997 16:27:50 -0800 Received: from dresden.bmc.com (dresden.bmc.com [198.64.253.250]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA24329 for ; Mon, 20 Jan 1997 16:27:45 -0800 Received: by dresden.bmc.com (1.40.112.4/16.2) id AA159526931; Mon, 20 Jan 1997 18:35:31 -0600 Received: from crow.bmc.com(198.147.191.100) by dresden.bmc.com via smap (3.2) id xma015943; Mon, 20 Jan 97 18:35:29 -0600 Received: from dorothy.peer.com by crow.bmc.com (AIX 3.2/UCB 5.64/4.03) id AA46255; Mon, 20 Jan 1997 18:21:13 -0600 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA045296453; Mon, 20 Jan 1997 16:27:33 -0800 Date: Mon, 20 Jan 1997 16:27:33 -0800 From: Randy Presuhn Message-Id: <199701210027.AA045296453@dorothy.peer.com> To: ip6mib@Research.Ftp.Com Subject: (IPng 2976) Re: IPv6 MIB: per-entity stats Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi - > Date: Mon, 20 Jan 1997 14:58:27 -0500 > From: dhaskin@BayNetworks.COM (Dimitry Haskin) > Message-Id: <199701201958.OAA13527@pobox.engeast.BayNetworks.COM> > To: ip6mib@Research.Ftp.Com > Subject: IPv6 MIB: per-entity stats > Cc: ipng@sunroof.Eng.Sun.COM, sonishi@pobox.FTP.COM ... > I'll be updating the IPv6 MIB draft to reflect comments I've received > so far. At this point I'm not sure if there is a consensus that > the per-entity interface and ICMP statistics are to be deleted > from the mib. A number of people view the per-entity, aka per-node, statistics > redundant since the information can be derived from the per-interface > statistics. So please let me know if you strongly oppose removing > the per-entity stats from the v6 mib. If I don't get any protests > by the end of this week, the per-entity stats will be as good as gone. ... Without commenting on the need (or lack thereof) for per-entity stats: If the per-entity stats are kept, bear in mind that there are interactions with the Agentx work in configurations where an implementer choses to employ separate subagents for different interfaces, and to use Agentx protocol as the communication mechanism. The Agentx working group is coming to closure on some of these features; whether to support them now, in a future version, or never. If you're thinking about doing per-interface subagents, and supporting per-node aggregated statistics, and want this to be handled by the Agentx subagent infrastructure, it's important to let the Agentx folks know of your specific requirements. ----------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- ------------------------------------------------------------------------------ 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 Tue Jan 21 11:13:40 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11311; Tue, 21 Jan 97 11:13:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11305; Tue, 21 Jan 97 11:13:24 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA17931; Tue, 21 Jan 1997 11:04:41 -0800 Received: from mailhost3.BayNetworks.COM (shrimp.corpeast.baynetworks.com [192.32.253.7]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA07504 for ; Tue, 21 Jan 1997 11:04:23 -0800 Received: from ns1.BayNetworks.COM (ns1.baynetworks.com [134.177.1.107]) by mailhost3.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id OAA21247 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id LAA27152 Posted-Date: Tue, 21 Jan 1997 11:02:04 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id OAA12184; Tue, 21 Jan 1997 14:02:06 -0500 for Date: Tue, 21 Jan 1997 14:02:06 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701211902.OAA12184@pobox.engeast.BayNetworks.COM> To: ip6mib@Research.Ftp.Com, ipng@sunroof.eng.sun.com, rpresuhn@peer.com Subject: (IPng 2977) Re: IPv6 MIB: per-entity stats Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hi - > > > Date: Tue, 21 Jan 1997 09:39:02 -0500 > > From: dhaskin@BayNetworks.COM (Dimitry Haskin) > > Message-Id: <199701211439.JAA21901@pobox.engeast.BayNetworks.COM> > > To: erik.nordmark@Eng.Sun.COM > > Subject: Re: (IPng 2952) Re: IPv6 MIB: per-entity stats > > Cc: ipng@sunroof.Eng.Sun.COM, ip6mib@Research.Ftp.Com > ... > > One can take a view that when an interface is deleted its statistics > > become irrelevant and should be excluded from the per-node stats. > ... > > This could be very confusing if the per-node stats are of counter types. > It could cause counters to appear to run backwards, etc. Since counter > deltas are what are of interest, there is no need to exclude the former > interface's contribution. > Yes, this seems to be a good argument against deleting the per-node statistics counters. If the per-node stats are calculated by the summarization of the per-interface stats, the counters deltas would be seriously distorted if an interface were deleted between snapshots. 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 Tue Jan 21 11:17:34 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11340; Tue, 21 Jan 97 11:17:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08401; Mon, 20 Jan 97 10:49:03 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA23390; Mon, 20 Jan 1997 10:40:22 -0800 Received: from ns2.eds.com (ns2.eds.com [199.228.142.78]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA25740 for ; Mon, 20 Jan 1997 10:40:23 -0800 Received: from nnsp.eds.com (nnsp.eds.com [130.174.32.78]) by ns2.eds.com (8.8.4/8.8.4) with ESMTP id NAA11981; Mon, 20 Jan 1997 13:40:22 -0500 (EST) Received: from [130.175.183.223] (netmac.iscg.eds.com [130.175.183.223]) by nnsp.eds.com (8.7.6/8.7.3) with ESMTP id NAA05432; Mon, 20 Jan 1997 13:39:51 -0500 (EST) X-Sender: jcutle01@info1.iscg.eds.com Message-Id: In-Reply-To: <3.0.32.19970120103028.006aa7bc@lint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jan 1997 13:34:32 -0500 To: Paul Ferguson From: "James R. Cutler" Subject: (IPng 2978) Re: 8+8 Why do we care? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The EDS experience so far is that private addressing is somewhat of a management nightmare for large intranets. Especially ones with decentralized deployment teams who do NOT always do things in exact lock step. The number of addresses in the combined intranets we support makes the simple decision "is this an interior or exterior destination?" difficult to implement on, for example, a typical ANS gateway or the like. As of now, we will do all we can to avoid large scale deployment of private addressing, only using it for certain tightly controlled sites. Few sites can be "tightly controlled". With a world-wide intranet there are too many opportunities for "back door" connections to the Internet for us to want to use private addressing. All this argues for IPv6 deployed last year! James R. Cutler >At 09:48 AM 1/20/97 -0500, bound@zk3.dec.com wrote: >> >>A lot of users I know need much bigger address space than 2**32 and also >>a lot of users cannot get the Class C addresses needed they want right >>now. For a growing market, IPv4 address space is gone even with CIDR >>or NAT. >> > >Jim, > >One might suggest that is supposition and not a foregone conclusion. > >> >>Another reason is that the market is not buying the idea of Private >>Addresses is my reading, hence, makes NAT not a solution to the IPv4 >>address space problem. >> > >You state this, but do not provide any reasoning on the statement. >Please elaborate on your reasoning here. > >> >>Do you think the 6bone is a fluke? Its happening and its affecting the >>market already as its on the customer list of questions about where a >>vendor is headed I am sure for all of us. >> > >A fluke? Perhaps not. A toy? Perhaps. What benefits does the 6Bone offer >over the MBone? > >Curiously, > >- paul > >------------------------------------------------------------------------------ >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 - James R. Cutler EDS Mail Stop 4165 800 Tower Drive, Troy, MI 48007-7012 Phone: 810-265-7514 FAX: 810-265-7514 EDS Internal Web: World Wide Web: ------------------------------------------------------------------------------ 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 Tue Jan 21 11:20:15 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11350; Tue, 21 Jan 97 11:20:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09680; Tue, 21 Jan 97 01:51:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA11593; Tue, 21 Jan 1997 01:42:59 -0800 Received: from apnic-ttc.apnic.net (apnic-ttc.apnic.net [203.178.142.242]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA19287 for ; Tue, 21 Jan 1997 01:40:44 -0800 Received: by apnic-ttc.apnic.net; id SAA03259; Tue, 21 Jan 1997 18:30:24 +0900 Received: from unknown(10.0.10.4) by apnic-ttc.apnic.net via smap (g3.0.3) id xma003249; Tue, 21 Jan 97 18:30:10 +0900 Received: from apnic.net (davidc@localhost) by moonsky.jp.apnic.net (8.8.2/8.7.1) with ESMTP id SAA19618; Tue, 21 Jan 1997 18:33:20 +0900 (JST) Message-Id: <199701210933.SAA19618@moonsky.jp.apnic.net> X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs To: Steve Deering Cc: Geert Jan de Groot , huitema@bellcore.com (Christian Huitema), ipng@sunroof.eng.sun.com, davidc@apnic.net Subject: (IPng 2979) Re: 8+8 Why do we care? In-Reply-To: Your message of "Mon, 20 Jan 1997 19:56:12 PST." Date: Tue, 21 Jan 1997 18:33:20 +0900 From: "David R. Conrad" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >That's not what Christian said. He said that every *large* corporation >would *like* its own Class A. I've heard this statement from IPv6 proponents in the past, yet the number of times APNIC has received requests for even /16 over the last 2 years or more can be counted on 2 hands. In fact, I just responded to a request from someone who wants to return a /16 since they just renumbered their network. While I don't deny there is interest in getting a larger address space (in most cases for ease of administration, which _is_ a valid concern (IMHO)), I think saying "every large organization" is a bit of an overstatement. Almost all "large" organizations I'm aware of hide their networks behind firewalls or the "evil dreaded"(tm) NAT and are perfectly happy, even though they are violating the "architecture of the Internet". Guess they just want to get their work done. >Nonetheless, you don't have to exagerate the desires of the end users >to conclude that IPv4 address space is already effectively exhausted. Again, a bit of an overstatement. IPv4 address space is limited, but not scarce at this time. >Some evidence: > - Some sites (large, medium, and small) are being forced to use > private address space, when they would prefer -- for good > technical reasons -- not to do so. Evidence? If it is not for administrative convenience, then the organizations in question did not explain their requirements in sufficient detail. The registries will allocate space if the request is justified. We're required to as per RFC 1814. > - Dial-up ISPs that would prefer to give each of their customers > their own IP address are forced instead by the prefix police "Prefix police"? Wow, cool. Does this mean I can wear a spiffy badge? By the way, we do allocate to ISPs that statically assign addresses. > to assign addresses dynamically at dial-up time from a smaller > pool. What's going to happen next year when all those offices > and homes migrate to full-time IP connectivity, e.g., over cable > or xDSL, rather than dial-up service? Please see the allocations which have been made to cable TV based IP providers such as @Home. They seem to have obtained sufficient IPv4 space to address (:-)) their needs. > - Serious proposals are being made to institute a charging scheme > for address space (*separate* from routing-table space), as a > means of reducing the rate of address consumption (rather than > just to recover registration costs). Are they? Where? PIARA was pretty much shot down last I checked. The rough consensus on the PAGAN (formerly IRE) list was that address space is _NOT_ scarce at this time, albeit it is limited and should be managed intelligently. However, I don't understand why you have such a revulsion to this idea -- after all, it would provide a concrete incentive to move to IPv6. >Migrating to IPv6 as soon as possible would completely eliminate those >problems -- every site could have 64 or 80 bits of address space, and >every provider could have enough bits to number all of its customers. >And doing that would *not* make the routing-scaling problem or prefix >allocation problem any worse, since those are issues in managing the >high-order parts of the address, not the low-order parts. You are correct. One of the best excuses I have seen for IPv6 deployment has been that we could get rid of all the historical baggage associated with "legacy" IPv4 assignments -- wipe the slate clean and start over. Of course, it means people have to renumber and suffer the slings and arrows of early adopters. If I'm in charge of a production network where people are trying to get real work done, I'm unconvinced I'd be interested in spending the time debugging other people's work just to be on the cutting edge. I think I'd probably hang out a while and see if IPv6 catches on and whether or not it offers something that I can't get in v4. After all, one of the big features of IPv6 was that you can automagically renumber your network... why not wait until that actually works and in the meantime use mature code? >Whether a site >has one address or one billion addresses, and whether an ISP has two >customers or two million customers, is irrelevant to the inter-ISP >routing issues, since all of a site's addresses are aggregated into a >single site prefix, and all of an ISP's customer sites are aggregated >under the single prefix of the ISP. Hey, that sounds like CIDR in use with IPv4 (except for the billion part). Why are the IPv4 routing tables still growing? Why won't the same happen to IPv6 routing tables? For the record -- as soon as any ISP in the Asia Pacific Rim region comes to APNIC and requests IPv6 address space with intent to assign to customers, we are prepared to allocate from the provider space designated as APNIC administered space should the IANA deem it appropriate to do so. We have discussed the possible ways of performing the provider based allocations internally (even though we were told that this isn't something the registries should be doing) and will allocate on demand. However, we haven't been asked. Regards, -drc ------------------------------------------------------------------------------ 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 Tue Jan 21 11:24:57 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11371; Tue, 21 Jan 97 11:24:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10420; Tue, 21 Jan 97 07:38:13 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA06004; Tue, 21 Jan 1997 07:29:32 -0800 Received: from fasmail.fas.harvard.edu (fasmail.fas.harvard.edu [140.247.30.46]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA02844 for ; Tue, 21 Jan 1997 07:29:30 -0800 Received: from default.fas.harvard.edu by fasmail.fas.harvard.edu with SMTP id KAA29822; Tue, 21 Jan 1997 10:29:24 -0500 (EST) Message-Id: <2.2.32.19970121153046.006f3d2c@pop.fas.harvard.edu> X-Sender: bconway@pop.fas.harvard.edu X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Jan 1997 10:30:46 -0500 To: ipng@sunroof.eng.sun.com From: Brendan Conway Subject: (IPng 2980) Re: 8+8 (further discussion) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Return-Path: owner-ipng@sunroof.Eng.Sun.COM >Subject: (IPng 2585) Re: 8+8 (further discussion) >To: ipng@sunroof.Eng.Sun.COM >Date: Wed, 11 Dec 1996 16:15:14 +0100 (MET) From: "Brian Carpenter CERN-CN" >Sender: owner-ipng@sunroof.Eng.Sun.COM >X-Status: > >Even more generally, wherever you get the new RG >from must be a trusted source. If the source is DNS, >it must be an authenicated DNS. > > > Brian > > >> > On the other hand, I would agree with Pedro that allowing replacment of >> > the stored routing goop for an existing TCP connection clearly does >> > require authentication. >> >> Not necessarily. >> >> It is good enough to check that the Internet Locator part of >> source address is registered to DNS forward path of the source >> host. >> >> So, first, use the Internet ID part to know the host name, and then, >> lookup AAAA RR of the host. If the Internet Locator of incoming packets >> is not listed up in AAAA RR, it's a bogus packets. >> >> 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 >> > >------------------------------------------------------------------------------ >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 > > ------------------------------------------------------------------------------ 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 Tue Jan 21 11:30:41 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11397; Tue, 21 Jan 97 11:30:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10430; Tue, 21 Jan 97 07:49:11 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA07458; Tue, 21 Jan 1997 07:40:30 -0800 From: Steve.Silverman@adn.alcatel.com Received: from adn.alcatel.com (postman.adn.alcatel.com [198.205.32.33]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA07402 for ; Tue, 21 Jan 1997 07:40:23 -0800 Received: from by adn.alcatel.com with SMTP (1.40.112.8/16.2) id AA023381193; Tue, 21 Jan 1997 10:39:53 -0500 X-Openmail-Hops: 1 Date: Tue, 21 Jan 97 10:39:42 -0500 Message-Id: In-Reply-To: <9700218538.AA853862841@smtppc.ct.pb.com> Subject: (IPng 2981) Strong encryption export and IPSEC Mime-Version: 1.0 To: parkosar@pb.com Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset=US-ASCII; name="(IPng" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > if u.s. export control on strong encryption applies to ipv6 packets, As I understand it, the encryption laws prevent the export of equipemnt that can do strong encryption. So long as somebody manufactures equivalent equipment in a country that does not prevent the export of such equipment (like Canada) ships it to users in other countries, there is no problem shipping encrypted packets across the border. > how will data be prevented from exiting u.s.? It won't. > will routers with international links have to assume burden of > filtering? They couldn't. This could make it difficult for countries that like to read other people's mail. How sad! Steve Silverman ------------------------------------------------------------------------------ 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 Tue Jan 21 11:38:53 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11420; Tue, 21 Jan 97 11:38:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11099; Tue, 21 Jan 97 10:31:23 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA08111; Tue, 21 Jan 1997 10:22:42 -0800 Received: from dresden.bmc.com (dresden.bmc.com [198.64.253.250]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA16032 for ; Tue, 21 Jan 1997 10:21:51 -0800 Received: by dresden.bmc.com (1.40.112.4/16.2) id AA126151367; Tue, 21 Jan 1997 12:29:27 -0600 Received: from crow.bmc.com(198.147.191.100) by dresden.bmc.com via smap (3.2) id xma012483; Tue, 21 Jan 97 12:29:09 -0600 Received: from dorothy.peer.com by crow.bmc.com (AIX 3.2/UCB 5.64/4.03) id AA42049; Tue, 21 Jan 1997 12:14:45 -0600 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA257090867; Tue, 21 Jan 1997 10:21:07 -0800 Date: Tue, 21 Jan 1997 10:21:07 -0800 From: Randy Presuhn Message-Id: <199701211821.AA257090867@dorothy.peer.com> To: ip6mib@Research.Ftp.Com, ipng@sunroof.eng.sun.com Subject: (IPng 2982) Re: IPv6 MIB: per-entity stats Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi - > Date: Tue, 21 Jan 1997 09:39:02 -0500 > From: dhaskin@BayNetworks.COM (Dimitry Haskin) > Message-Id: <199701211439.JAA21901@pobox.engeast.BayNetworks.COM> > To: erik.nordmark@Eng.Sun.COM > Subject: Re: (IPng 2952) Re: IPv6 MIB: per-entity stats > Cc: ipng@sunroof.Eng.Sun.COM, ip6mib@Research.Ftp.Com ... > One can take a view that when an interface is deleted its statistics > become irrelevant and should be excluded from the per-node stats. ... This could be very confusing if the per-node stats are of counter types. It could cause counters to appear to run backwards, etc. Since counter deltas are what are of interest, there is no need to exclude the former interface's contribution. ----------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- ------------------------------------------------------------------------------ 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 Tue Jan 21 13:05:49 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11655; Tue, 21 Jan 97 13:05:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11649; Tue, 21 Jan 97 13:05:37 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA10954; Tue, 21 Jan 1997 12:56:56 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA17278 for ; Tue, 21 Jan 1997 12:56:29 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id UAA03721; Tue, 21 Jan 1997 20:56:10 GMT Message-Id: <199701212056.UAA03721@inner.net> To: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Cc: ipng@sunroof.eng.sun.com, rstevens@kohala.com Subject: (IPng 2983) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Tue, 21 Jan 1997 21:46:05 +0900." <9502.853850765@mine.aist-nara.ac.jp> X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 21 Jan 1997 15:56:09 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <9502.853850765@mine.aist-nara.ac.jp>, you write: >The argument of setsockopt with IPV6_UNICAST_HOPS should be *unsigned* >int (instead of int) because that of IPV6_MULTICAST_HOPS is unsigned >int in the basic API draft. Absolutely not. This precludes the definition of the value '-1' to mean "use the default". Admittedly, this is not particularly useful in a send control message (where the "default" is set by UNICAST_HOPS/ MULTICAST_HOPS), but it is useful to cancel a previous UNICAST_HOPS/ MULTICAST_HOPS setsockopt() and return to the vendor's/sysadmin's default. -Craig ------------------------------------------------------------------------------ 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 Tue Jan 21 13:19:39 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11685; Tue, 21 Jan 97 13:19:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11627; Tue, 21 Jan 97 13:02:09 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA10175; Tue, 21 Jan 1997 12:53:27 -0800 Received: from dresden.bmc.com (dresden.bmc.com [198.64.253.250]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA16039 for ; Tue, 21 Jan 1997 12:53:22 -0800 Received: by dresden.bmc.com (1.40.112.4/16.2) id AA264710471; Tue, 21 Jan 1997 15:01:11 -0600 Received: from crow.bmc.com(198.147.191.100) by dresden.bmc.com via smap (3.2) id xma026445; Tue, 21 Jan 97 15:01:08 -0600 Received: from dorothy.peer.com by crow.bmc.com (AIX 3.2/UCB 5.64/4.03) id AA57450; Tue, 21 Jan 1997 14:46:48 -0600 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA025409990; Tue, 21 Jan 1997 12:53:10 -0800 Date: Tue, 21 Jan 1997 12:53:10 -0800 From: Randy Presuhn Message-Id: <199701212053.AA025409990@dorothy.peer.com> To: ip6mib@Research.Ftp.Com, ipng@sunroof.eng.sun.com Subject: (IPng 2984) Re: IPv6 MIB: per-entity stats Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi - | Date: Tue, 21 Jan 1997 14:02:06 -0500 | From: dhaskin@BayNetworks.COM (Dimitry Haskin) | Message-Id: <199701211902.OAA12184@pobox.engeast.BayNetworks.COM> | To: ip6mib@Research.Ftp.Com, ipng@sunroof.Eng.Sun.COM, rpresuhn@peer.com | Subject: Re: (IPng 2952) Re: IPv6 MIB: per-entity stats ... | > > From: dhaskin@BayNetworks.COM (Dimitry Haskin) | > ... | > > One can take a view that when an interface is deleted its statistics | > > become irrelevant and should be excluded from the per-node stats. | > ... | > | > This could be very confusing if the per-node stats are of counter types. | > It could cause counters to appear to run backwards, etc. Since counter | > deltas are what are of interest, there is no need to exclude the former | > interface's contribution. | | Yes, this seems to be a good argument against deleting the per-node | statistics counters. If the per-node stats are calculated by the | summarization of the per-interface stats, the counters deltas would | be seriously distorted if an interface were deleted between snapshots. ... This was not intended as an argument for (or against) deleting per-node statistics counters. My point was that if one is going to compute a per node counter, whether locally or at a management station, one should not simply sum the per-interface counters. To get consistant behaviour, one could add the sum of the valid deltas of the per-interface counters to the previous value of the per-node counter. A valid delta requires that the current value can be retrieved, that the previous value was recorded, and that no discontinuity was indicated. An alternative would be to consider encountering a transition between valid and invalid deltas for a given interface to be a discontinuity condition for the aggregate. Per RFC 1902 clause 7.1.6 this would require identifying a special discontinuity indicator for the aggregate. In either case events counted between interface activation and the first sample would be lost (because counters don't generally have known initial values) as well as events counted between the last sample and interface deletion, as well as any samples disqualified due to discontinuity detection. ----------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- ------------------------------------------------------------------------------ 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 Tue Jan 21 14:29:39 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11824; Tue, 21 Jan 97 14:29:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11818; Tue, 21 Jan 97 14:29:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA00124; Tue, 21 Jan 1997 14:20:37 -0800 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA19051 for ; Tue, 21 Jan 1997 14:20:24 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id OAA27101 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id OAA11614 Posted-Date: Tue, 21 Jan 1997 14:19:47 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id RAA27600; Tue, 21 Jan 1997 17:19:48 -0500 for Date: Tue, 21 Jan 1997 17:19:48 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701212219.RAA27600@pobox.engeast.BayNetworks.COM> To: ip6mib@Research.Ftp.Com, ipng@sunroof.eng.sun.com, rpresuhn@peer.com Subject: (IPng 2985) Re: IPv6 MIB: per-entity stats Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy, > .. > > An alternative would be to consider encountering a transition between > valid and invalid deltas for a given interface to be a discontinuity > condition for the aggregate. Per RFC 1902 clause 7.1.6 this would > require identifying a special discontinuity indicator for the aggregate. > So I guess ipv6IfTableLastChange can be such an discontinuity indicator, right? I'm sorry for being too tense but the net management is not at the top of my expertise list and I appreciate an expert opinion on whether removing the per-node stats counters will cause an undue hardship to the data collection process. Thanks, 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 Tue Jan 21 15:01:20 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11858; Tue, 21 Jan 97 15:01:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11852; Tue, 21 Jan 97 15:01:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA08458; Tue, 21 Jan 1997 14:52:26 -0800 Received: from neon.ingenia.ca (neon.ingenia.com [205.207.220.57]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA28655 for ; Tue, 21 Jan 1997 14:51:35 -0800 Received: (from shaver@localhost) by neon.ingenia.ca (8.8.4/8.7.3) id RAA31575; Tue, 21 Jan 1997 17:50:19 -0500 From: Mike Shaver Message-Id: <199701212250.RAA31575@neon.ingenia.ca> Subject: (IPng 2986) Re: Strong encryption export and IPSEC In-Reply-To: from "Steve.Silverman@adn.alcatel.com" at "Jan 21, 97 10:39:42 am" To: Steve.Silverman@adn.alcatel.com Date: Tue, 21 Jan 1997 17:50:18 -0500 (EST) Cc: parkosar@pb.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL28 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake Steve.Silverman@adn.alcatel.com: > As I understand it, the encryption laws prevent the export of equipemnt > that can do strong encryption. So long as somebody manufactures > equivalent equipment in a country that does not prevent the export of > such equipment (like Canada) ships it to users in other countries, there > is no problem shipping encrypted packets across the border. Don't think Canada's export regulations are much different from the US's, which is why you're allowed to export strong crypto to us. Mike -- #> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation #> Resident Linux bigot and kernel hacker. (OOPS!) #> `If you get bitten by a bug, tough luck...the one thing I won't do #> is feel sorry for you. In fact, I might ask you to do it all over #> again, just to get more information. I'm a heartless bastard.' #> -- Linus Torvalds (on development kernels) ------------------------------------------------------------------------------ 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 Tue Jan 21 15:08:06 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11876; Tue, 21 Jan 97 15:08:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11870; Tue, 21 Jan 97 15:07:54 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA10270; Tue, 21 Jan 1997 14:59:11 -0800 Received: from ) by Sun.COM (4.1/mail.byaddr) id AA06796 for ipng@sunroof.Eng; Tue, 21 Jan 97 14:58:25 PST Received: from csmes.ncsl.nist.gov(129.6.54.2) by sun-barr.EBay.Sun.COM (SMI-8.7.4/SMI-SVR4) id IAA05140; Tue Jan 21 14:41:30 1997 Received: (konczal@localhost) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) id RAA13210; Tue, 21 Jan 1997 17:32:07 -0500 Date: Tue, 21 Jan 1997 17:32:07 -0500 Message-Id: <199701212232.RAA13210@csmes.ncsl.nist.gov> From: Joe Konczal To: Steve.Silverman@adn.alcatel.com Cc: parkosar@pb.com, ipng@sunroof.eng.sun.com In-Reply-To: (Steve.Silverman@adn.alcatel.com) Subject: (IPng 2987) Re: Strong encryption export and IPSEC Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Isn't it illegal to ship encrypted packets into some countries, like France, unless the keys are escrowed with the national government? -- Joe Konczal National Institute of Standards and Technology Building 820, Room 410 Phone: (301) 975-3285 Gaithersburg, MD 20899 USA Fax: (301) 948-0279 ------------------------------------------------------------------------------ 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 Tue Jan 21 22:11:33 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12631; Tue, 21 Jan 97 22:11:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12625; Tue, 21 Jan 97 22:11:21 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA16493; Tue, 21 Jan 1997 22:02:41 -0800 Received: from mailgate.aist-nara.ac.jp (fsb1.aist-nara.ac.jp [163.221.76.12]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA28538 for ; Tue, 21 Jan 1997 22:02:04 -0800 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id PAA08975 for ; Wed, 22 Jan 1997 15:00:11 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id FAA09953; Wed, 22 Jan 1997 05:49:59 GMT To: ipng@sunroof.eng.sun.com Subject: (IPng 2988) Re: Forward: hlim and IF on API In-Reply-To: Your message of "Tue, 21 Jan 1997 06:33:17 -0700" References: <199701211333.GAA10529@kohala.kohala.com> X-Mailer: Mew version 1.54 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 22 Jan 1997 14:49:58 +0900 Message-Id: <9950.853912198@mine.aist-nara.ac.jp> From: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, From: rstevens@kohala.com (W. Richard Stevens) Subject: Re: (IPng 2955) Re: Forward: hlim and IF on API Date: Tue, 21 Jan 1997 06:33:17 -0700 > As things currently stand, there is one type of ancillary data to set > and receive the hop limit, and another type of ancillary data to set > and receive the interface index and src/dst IPv6 address. > > As I understand the above, you are proposing to combine all three of > these into one structure of "packet information" that can be returned > by recvmsg() with the interface index, destination IPv6 address, and > hop limit. The same structure can be specified to sendmsg() containing > the outgoing interface index, source IPv6 address, and hop limit (with > a way to say "use the default" for each three, of course). Integrating three information above may be a good idea. Actually I hit upon the same idea. But I don't know which is better, separating approach or integrating approach, at present. I would like to hear other's voice. --Kazu ------------------------------------------------------------------------------ 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 Wed Jan 22 04:57:45 1997 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13267; Wed, 22 Jan 97 04:57:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13261; Wed, 22 Jan 97 04:57:33 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA17371; Wed, 22 Jan 1997 04:48:50 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA26762 for ; Wed, 22 Jan 1997 04:48:47 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.3/8.7.3) with ESMTP id FAA13538; Wed, 22 Jan 1997 05:48:43 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.3/8.8.3) id FAA12662; Wed, 22 Jan 1997 05:48:42 -0700 (MST) Message-Id: <199701221248.FAA12662@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Wed, 22 Jan 1997 05:48:42 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Kazu Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= , ipng@sunroof.eng.sun.com Subject: (IPng 2989) Re: Forward: hlim and IF on API Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Jan 22, 2:49pm you write:] > > > As I understand the above, you are proposing to combine all three of > > these into one structure of "packet information" that can be returned > > by recvmsg() with the interface index, destination IPv6 address, and > > hop limit. The same structure can be specified to sendmsg() containing > > the outgoing interface index, source IPv6 address, and hop limit (with > > a way to say "use the default" for each three, of course). > > Integrating three information above may be a good idea. Actually I hit > upon the same idea. > > But I don't know which is better, separating approach or integrating > approach, at present. I would like to hear other's voice. Craig Metz makes a compelling argument *not* to put the hop limit into the in6_pkthdr{} structure, and keeping it separate, and that's what I am going to write up. Craig's point is that when the in6_pktinfo{} structure contains just the received interface and destination address from recvmsg(), then the application can use this returned control buffer for sendmsg(), without changing *anything*, to send the packet out the received interface and with a source address that is the destination address of the received packet. That's a nice feature. But if we put the hop limit into the in6_pktinfo{} structure, then the application must parse the returned control information and explicitly set the hop limit to -1 ("use the kernel default") before calling sendmsg(). Rich Stevens ------------------------------------------------------------------------------ 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 Jan 22 13:09:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00973; Wed, 22 Jan 1997 13:09:07 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00966; Wed, 22 Jan 1997 13:09:00 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA13898; Wed, 22 Jan 1997 13:09:12 -0800 Received: from thumper.bellcore.com (thumper-13.bellcore.com [192.4.13.7]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA05863 for ; Wed, 22 Jan 1997 13:08:43 -0800 Received: from huitema-pc.bellcore.com (pya-ppp167.cc.bellcore.com [192.4.221.167]) by thumper.bellcore.com (8.8.3/8.7.3) with SMTP id QAA07559; Wed, 22 Jan 1997 16:08:22 -0500 (EST) Message-ID: <32E67C86.B61@bellcore.com> Date: Wed, 22 Jan 1997 15:45:58 -0500 From: Christian Huitema X-Mailer: Mozilla 2.01 (Win95; I) MIME-Version: 1.0 To: Joe Konczal CC: ipng@sunroof.eng.sun.com Subject: (IPng 2990) Re: (IPng 2987) Re: Strong encryption export and IPSEC References: <199701212232.RAA13210@csmes.ncsl.nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 958 Joe Konczal wrote: > > Isn't it illegal to ship encrypted packets into some countries, like > France, unless the keys are escrowed with the national government? Discussion of the French laws is way outside the scope of this group. In any case, your assertion is wrong, too generic. The proposed French laws specify escrow through some kind of public notaries; this is bad enough, but different from giving the keys outright to the national government. Entities with special needs may obtain special provisions. In any case, I have never heard that the law would apply to packets that are merely in transit; the law essentially applies to the sender and receivers. ------------------------------------------------------------------------------ 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 Jan 24 13:23:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA04814; Fri, 24 Jan 1997 13:22:38 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA04807; Fri, 24 Jan 1997 13:22:29 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA20119; Fri, 24 Jan 1997 13:22:43 -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 NAA29661 for ; Fri, 24 Jan 1997 13:22:41 -0800 Received: by mail.noris.net id <35144-189>; Fri, 24 Jan 1997 22:22:40 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 2991) Re: (IPng 2937) Re: 8+8 Why do we care? Date: 24 Jan 1997 22:22:09 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 52 Message-ID: <5cb961$c8a$1@work.smurf.noris.de> References: <3.0.32.19970120103028.006aa7bc@lint.cisco.com> <853774961.7044@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:1267 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2752 In dist.ipng, article <853774961.7044@noris.de>, Paul Ferguson writes: > At 09:48 AM 1/20/97 -0500, bound@zk3.dec.com wrote: > > > >Another reason is that the market is not buying the idea of Private > >Addresses is my reading, hence, makes NAT not a solution to the IPv4 > >address space problem. > > You state this, but do not provide any reasoning on the statement. > Please elaborate on your reasoning here. > Just ask the market. When I, as an ISP, try to teach customers that for their five servers and 100 PCs they need effectively eight addresses and not 128, they simply refuse to understand the solution. Then they go to a competitor who's willing to fake their network space usage application so that they get their very own Class C network. > > > >Do you think the 6bone is a fluke? Its happening and its affecting the > >market already as its on the customer list of questions about where a > >vendor is headed I am sure for all of us. > > A fluke? Perhaps not. A toy? Perhaps. What benefits does the 6Bone offer > over the MBone? > What the *** has the 6bone to do with the Mbone? They're, as of now, totally different animals. The 6bone is needed for testing that IPv6 does in fact work in the Real World before unleashing it on same. Therefore it's necessary. Simple, no? Now, let me add my personal perspective on 8+8, acquired by reading about this list going in circles about 8+8 for the past few months or so. - I think it's basically a good idea. - Do the minimum necessary to make it work. Going-in-circles about the proposal(s) isn't helpful. - Don't try to globally assign ESDs, and don't try to do ESD->name lookup or ESD->RG lookup or whatever. Don't even think about it. - 8+8 == 8+(2+6). How much of the 2 is actually under my control needs to be configurable. - DNS stuff should be indirectable. Optionally. Anywhere, not just at the 8/8 border. Surprise -- with CNAMEs, it already is. So don't invent yet another play-with-addresses mechanism for 8+8. -- He is one of those people who would be enormously improved by death. -- 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 Sun Jan 26 01:46:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA06523; Sun, 26 Jan 1997 01:42:25 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA06516; Sun, 26 Jan 1997 01:42:18 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA25082; Sun, 26 Jan 1997 01:42:33 -0800 Received: from relay-7.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA24928 for ; Sun, 26 Jan 1997 01:42:33 -0800 Received: from th020.ftech.co.uk ([195.200.13.20]) by relay-6.mail.demon.net id aa610184; 26 Jan 97 9:36 GMT Message-ID: Date: Sun, 26 Jan 1997 02:40:06 +0000 To: ipng@sunroof.eng.sun.com From: Thomas Lee Subject: (IPng 2992) Re: (IPng 2849) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Version 3.02 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1233 x-no-archive: yes In article , Malcolm Campbell writes >Another point of experience - I once got a 10-pack of ethernet cards from >a vendor who shall remain nameless, and they all had the same MAC address I got a 5-pack the same. Said vendor quite embarrased - replaced them and gave me a free t-shirt. The summary seems to be that although MAC addresses are almost always unique, the industry can not guarantee it. The question then become: is the very rare occurances of duplicates worth the fuss of creating yet another identifier? Stateless autoconfig is really rather nice - I'd hate to loose it. Thomas -- Thomas Lee (email: tfl@psp.co.uk, web: http://www.psp.demon.co.uk/tfl/tfl.htm) Microsoft Certified Systems Engineer and Certified Trainer PS Partnership - A Microsoft Solution Provider Ph: +44 1628 850 077 Fax: +44 1628 850 143 ------------------------------------------------------------------------------ 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 Jan 26 03:21:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA06602; Sun, 26 Jan 1997 03:21:07 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA06595; Sun, 26 Jan 1997 03:21:00 -0800 Received: from Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA28213; Sun, 26 Jan 1997 03:21:15 -0800 Received: from ) by Sun.COM (4.1/mail.byaddr) id AA19784 for ipng@sunroof.Eng; Sun, 26 Jan 97 03:20:28 PST Received: from munnari.oz.au(128.250.1.21) by sun-barr.EBay.Sun.COM (SMI-8.7.4/SMI-SVR4) id IAA19756; Sun Jan 26 03:18:50 1997 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id LA19106; Sun, 26 Jan 1997 22:15:45 +1100 (from kre@munnari.OZ.AU) To: Thomas Lee Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2993) Re: (IPng 2992) Re: (IPng 2849) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Sun, 26 Jan 1997 02:40:06 -0000." Date: Sun, 26 Jan 1997 22:15:33 +1100 Message-Id: <2715.854277333@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3727 Date: Sun, 26 Jan 1997 02:40:06 +0000 From: Thomas Lee Message-ID: The question then become: is the very rare occurances of duplicates worth the fuss of creating yet another identifier? Stateless autoconfig is really rather nice - I'd hate to loose it. Whatever happens, we won't be losing stateless autoconfig. At worst, if there happen to be duplicates on the same level 2 connected media, the 2nd node to start will try DAD, find the problem, and refuse to go further without human help. This is the real easy case for duplicate MAC addresses, if they would all be like that there would never be a problem worth worrying about. The problem comes with 8+8 type addressing, where the MAC addr is the basis of (really the whole) the ESD, which is supposed to identify nodes world wide. There, there's no way that DAD, or anything else plausible, can find the problem ahead of when it comes on you out of the blue half way through some important work. So, the question has been whether the MAC addresses are "unique enough" for this purpose. If they are, then 8+8 can ignore this issue - or rather, simply perhaps stick some words in saying how to die as gracefully as possible on the very few occasions when the problem might occur. If they're not, then 8+8 as currently defined can't work. The addresses originally planned for IPv6 have no problem either way, duplicate mac addresses are only an issue locally, and DAD can cope. One solution for 8+8 (if MAC address uniqueness poses a problem) might be to go back to what (I think) was being proposed for SIP with stateless autoconfig - that is, not use the entire 48 bits, but perhaps create a 24 bit hash based upon the MAC addr. (Perhaps even 16 would do, but that would limit L2's to about 4K nodes, which is probably too small, the 1M you could coax out of a 24 bit hash would be better). If one wanted to, one could easily mix in some other number one might find, to lessen the chances of local duplication after the hash, either as a result of hash function collisions, or because of starting with duplicate mac addrs. I doubt it would be worth the effort (even of discussing what other number might work). Then in the 8 bytes of ESD that 8+8 (6+2+8) provides, we'd have 3 bytes for the stateless autoconfig token, and 5 bytes that could be used as an administered ID space, probably 256 per organisation (with extras allocated as the size of the organisation becomes big enough to require it). That would allow 2^32 unique organisations. That's a lot - and there's no reason at all why small ones couldn't share, perhaps we would allocate in blocks of 16 instead of 256. The only lossage in this allocation would be registry ineffeciencies (numbers not yet allocated, but pending) - as the numbers are allocated one by one this can be just as effecient as was done, for example, in the 192.* class C space when it was being allocated which was generally pretty good (we'd actually do better, as there would never be a need for a new number for that link over there because of routing problems). Not only would the administered number guarantee uniqueness (simply fixed human errors aside), but would also allow the ESD to be used as a key in the DNS, and so allow ESD -> name (etc) lookups. The rest of Mike's 8+8 proposal (The RG etc) is obviously unaffected by any of this. 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 Sun Jan 26 08:32:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06899; Sun, 26 Jan 1997 08:32:01 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06892; Sun, 26 Jan 1997 08:31:55 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA09794; Sun, 26 Jan 1997 08:32:10 -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 IAA17826 for ; Sun, 26 Jan 1997 08:32:09 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA10902; Sun, 26 Jan 1997 11:25:17 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24290; Sun, 26 Jan 1997 11:25:13 -0500 Message-Id: <9701261625.AA24290@wasted.zk3.dec.com> To: Robert Elz Cc: Thomas Lee , ipng@sunroof.eng.sun.com Subject: (IPng 2994) Re: (IPng 2993) Re: (IPng 2992) Re: (IPng 2849) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Sun, 26 Jan 97 22:15:33 +1100." <2715.854277333@munnari.OZ.AU> Date: Sun, 26 Jan 97 11:25:12 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1239 >So, the question has been whether the MAC addresses are "unique >enough" for this purpose. >If they're not, then 8+8 as currently defined can't work. >The addresses originally planned for IPv6 have no problem either >way, duplicate mac addresses are only an issue locally, and DAD >can cope. I don't agree. 8+8 can work for an ESD in a site via the PTP bits. So even if 2 links in the site have duplicate EDSs they would be different because of the different PTP bits. The RG will differentiate the ESDs globally. So I would say if you believe 8+8 only has value if we rewrite packets then as you say above 8+8 cannot work, because you cannot rely on the ESD being unique for 8 byte (ESD) transport connection identifiers. But if one believes that rewriting packets is not necessary for 8+8 to be a useful addressing architecture then what you say is not valid, as the RG would be considered at all layers and would make the ESD unique. /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 Jan 26 09:15:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06955; Sun, 26 Jan 1997 09:14:26 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06948; Sun, 26 Jan 1997 09:14:18 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA11724; Sun, 26 Jan 1997 09:14: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 JAA21178 for ; Sun, 26 Jan 1997 09:14:31 -0800 Received: by munnari.OZ.AU (5.83--+1.3.1+0.56) id RA01895; Mon, 27 Jan 1997 04:11:52 +1100 (from kre) Date: Mon, 27 Jan 1997 04:11:52 +1100 From: Robert Elz Message-Id: <9701261711.1895@munnari.OZ.AU> To: bound@zk3.dec.com Subject: (IPng 2995) Re: (IPng 2993) Re: (IPng 2992) Re: (IPng 2849) Re: 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1094 Jim, if we're considering the RG "at all layers" then 8+8 and provider based addressing are the same thing, with a little different terminology thrown around. The only benefit comes if we can avoid using the RG for anything but what it is intended - routing. I know Mike also intends it to be used as part of the ip6.int type lookup (addr->name) and that wouldn't be fatal, but if we can find a way to avoid that too, we'll be much better off. To the other point - certainly - within a site duplicate MAC addresses can be hidden by the PTP bits, but that doesn't help at all beyond the site boundaries (where all the small sites are using PTP==0). This minor benefit is almost irrelevant (you will notice I jumped straight from one L2 area to the world, that was precisely to ignore this irrelevance). 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 Sun Jan 26 10:32:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA07106; Sun, 26 Jan 1997 10:32:05 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA07099; Sun, 26 Jan 1997 10:31:59 -0800 From: bound@ZK3.DEC.COM Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA15976; Sun, 26 Jan 1997 10:32:13 -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 KAA00180 for ; Sun, 26 Jan 1997 10:32:14 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA22191; Sun, 26 Jan 1997 13:29:31 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA09949; Sun, 26 Jan 1997 13:29:30 -0500 Message-Id: <9701261829.AA09949@wasted.zk3.dec.com> To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2996) Re: (IPng 2993) Re: (IPng 2992) Re: (IPng 2849) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Mon, 27 Jan 97 04:11:52 +1100." <9701261711.1895@munnari.OZ.AU> Date: Sun, 26 Jan 97 13:29:30 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4516 Robert, >Jim, if we're considering the RG "at all layers" then 8+8 and provider >based addressing are the same thing, with a little different terminology >thrown around. I don't agree. The format is different and its my impression that ISPs like 8+8 LSID and ESD bits regardless of rewriting packets. Other mail has discussed this. >To the other point - certainly - within a site duplicate MAC addresses can >be hidden by the PTP bits, but that doesn't help at all beyond the site >boundaries (where all the small sites are using PTP==0). This minor >benefit is almost irrelevant (you will notice I jumped straight from one >L2 area to the world, that was precisely to ignore this irrelevance). I know.....but they are unique in the site and most vendors revenue comes from Intranets/Extranets as opposed to the Internet. I think we are at a conjunction in the 8+8 discussion. On one side we have those who believe 8+8 is not useful without rewriting packets. On the other side we have folks who believe a hybrid is possible using this addressing architecture. Another side is that rewriting of packets should be optional. If 8+8 is only to be done if rewriting of packets is accepted then I would withdraw my support for 8+8 now and at the Interim meeting. Lets just use provider based addressing and get on with the deployment of IPv6. 1. Rewriting of packets has not been tested or implemented to determine if it can be done. It completely leaves any Internet model we have done with real products and real networks. At a minimum we need to test this concept. The problem is that as much mail has stated we are ready to deploy IPv6 very soon in the market and if 8+8 will take to long to verify rewriting of packets its simply not practical to wait. Have we learned nothing from the RSVP work? 2. Rewriting of packets is not needed for renumbering or packets changing addresses on the fly. Or for the concepts of Rehoming. 3. Rewriting of packets causes a security problem at the network layer and transport layer if we are only using the ESD to identify connections. We cannot get all the governments to agree on anything just yet except for authentication to cross the Internet's international boundaries, having ISPs alter packets in transit without verifying the security parameters for the complete address (RG + ESD) with encryption seems very dangerous and questionable how it is to be done given the politics of encryption on the planet. 4. I believe consensus is we cannot define or state that ESDs are globally unique 100%. This puts risk into the rewriting of packets into products for TCP/IP and possibly a liability that would have to be addressed by vendors to their customers. I am not sure how this can even be stated. 5. The code base ramifications are significant enough if we say that the model is to use 8bytes instead of 16bytes in the kernel and user space. This has nothing to do with the IPv6 architecture. Its a major change to how implementations function. We would also have to understand what the RG is used for as opposed to the ESD. Think about traceroute? Think about FTP 3rd party connections for the PORT and PASV commands? 6. If the ESD is not unique why and how can I possibly trust a wire transfer of 1 million dollars using an end-to-end flow label from my application on a host that crosses several ISP networks. If I can't select my source address using 128 bits (RG + ESD) as a source address + flow-label? 7. This affects Neighbor Discovery NUD cache implementations and Routing Table implementations in existing IPv4 stacks for vendors that will supply both an IPv4/IPv6 dual or hybrid stack for interoperation btw IPv4 and IPv6. These are just two examples. To make a change to support Rewriting of Packets is significant, it really needs to be proven it will work before adopted. I don't think that can be done in six months and in the next six months you will see real IPv6 products on the market in addition to the ones out there now. This is why using 8+8 with rewriting as an option may be a smart idea as proposed by Dan Harrington. We can evolve to rewriting of packets if it will work and all the issues are resolved. /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 Jan 26 10:52:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA07131; Sun, 26 Jan 1997 10:52:16 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA07124; Sun, 26 Jan 1997 10:52:08 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA17226; Sun, 26 Jan 1997 10:52:21 -0800 Received: from mailhost1.BayNetworks.COM ([134.177.3.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA06812 for ; Sun, 26 Jan 1997 10:52:22 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id KAA06603 Received: from pobox.corpwest.BayNetworks.COM (mailhost.corpwest.baynetworks.com [134.177.1.95]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id KAA03674 Posted-Date: Sun, 26 Jan 1997 10:52:12 -0800 (PST) Received: from dhaskin.baynetworks.com ([192.32.171.166]) by pobox.corpwest.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id KAA10897; Sun, 26 Jan 1997 10:52:11 -0800 for Message-Id: <2.2c.32.19970126184646.00c0ac04@pobox.corpeast.baynetworks.com> X-Sender: dhaskin@pobox.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 2.2c (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 26 Jan 1997 13:46:46 -0500 To: Robert Elz From: Dimitry Haskin Subject: (IPng 2997) Re: (IPng 2993) 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1948 At 10:15 PM 1/26/97 +1100, Robert Elz wrote: > >One solution for 8+8 (if MAC address uniqueness poses a problem) >might be to go back to what (I think) was being proposed for SIP >with stateless autoconfig - that is, not use the entire 48 bits, >but perhaps create a 24 bit hash based upon the MAC addr. (Perhaps >even 16 would do, but that would limit L2's to about 4K nodes, >which is probably too small, the 1M you could coax out of a 24 >bit hash would be better). Actually, I don't think there would be any need to go this low for the token size. I would say that the size of the hierarchical portion of the RG and the globally administered portion of the ESD should be the same since both effectively identify a site and you'd like the ESD to have hierarchical properties similar to those of the RG for the sake of the reverse DNS lookup. Then you would need at least one extra ESD byte for the site-local routing hierarchy (assuming in average 256 subnets per site and the CIDR-type allocation). Now, if a few of the most significant RG bits need to be used for some other than routing purpose, I'd dare to say that the size of the RG should be the same as the total size of the globally and locally administered portion of the ESD. If you claim that 5 bytes is enough for the administered ESD space, I'd suggest that 5 bytes would be also enough for the RG and we can leave 6 bytes for the autoconfiguration token, i.e. 5+(5+6). This would allow to address more than 10**11 networks and to scale to 10**9 networks required in rfc1752 with the less than 1% assignment efficiency. Of cause, we can also consider other layouts, e.g. 6+(6+4). 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 Sun Jan 26 22:24:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA07701; Sun, 26 Jan 1997 22:23:49 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA07694; Sun, 26 Jan 1997 22:23:43 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA26232; Sun, 26 Jan 1997 22:23:58 -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 WAA26885 for ; Sun, 26 Jan 1997 22:23:56 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id GA18016; Mon, 27 Jan 1997 17:23:44 +1100 (from kre@munnari.OZ.AU) To: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2998) Re: (IPng 2993) 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Sun, 26 Jan 1997 13:46:46 CDT." <2.2c.32.19970126184646.00c0ac04@pobox.corpeast.baynetworks.com> Date: Mon, 27 Jan 1997 17:23:32 +1100 Message-Id: <3195.854346212@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2014 Date: Sun, 26 Jan 1997 13:46:46 -0500 From: Dimitry Haskin Message-ID: <2.2c.32.19970126184646.00c0ac04@pobox.corpeast.baynetworks.com> I would say that the size of the hierarchical portion of the RG and the globally administered portion of the ESD should be the same since both effectively identify a site No, the RG needs space for bits to be wasted to allow for future aggregation. If I have one number now, and my neighbour wants one tomorrow, we want the RG's tobe related. That means when mine was assigned enough "nearby" space needs to be reserved to allow some more numbers to be allocated without renumbering lots of people very frequently. For the ESD that isn't relevant - there's no reason for my neighbour's ESD to be in any way related to mine - so if 10 more have been allocated today before my neighbour applies tomorrow anywhere in the country/world/universe then his will be 10 higher than mine, and the intervening ones don't matter. This means that non-routing related assignments can be much more compact, and hence need less bits. So, a 6 byte RG and a 4 byte assigned ESD probably fit reasonably well as a pair. (Or 8 and 5 if the site's internal structure is included as well). Then you would need at least one extra ESD byte for the site-local routing hierarchy No, that's what the "2" in 6+2+8 is supposed to be. The 8 is the ESD, the 2 is local routing hierarchy, and the 6 is inter-site (global) routing. You'd want an extra byte in the site's internal ESD space to allow the site to divide up their space administratively (not for routing), and not require one big directory of all the (hashed) MAC addresses. 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 Sun Jan 26 22:26:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA07718; Sun, 26 Jan 1997 22:26:24 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA07711; Sun, 26 Jan 1997 22:26:17 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA26367; Sun, 26 Jan 1997 22:26:33 -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 WAA27252 for ; Sun, 26 Jan 1997 22:26:30 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id GA21697; Mon, 27 Jan 1997 17:23:44 +1100 (from kre@munnari.OZ.AU) To: bound@ZK3.DEC.COM Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2999) Re: (IPng 2993) Re: (IPng 2992) Re: (IPng 2849) Re: 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Sun, 26 Jan 1997 13:29:30 CDT." <9701261829.AA09949@wasted.zk3.dec.com> Date: Mon, 27 Jan 1997 17:23:30 +1100 Message-Id: <3192.854346210@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3521 Date: Sun, 26 Jan 97 13:29:30 -0500 From: bound@ZK3.DEC.COM Message-ID: <9701261829.AA09949@wasted.zk3.dec.com> The format is different In trivial ways, yes, but nothing that couldn't be done to provider addresses without changing their nature. and its my impression that ISPs like 8+8 LSID and ESD bits yes, of course - but the ESD bits are only ESD bits if they have an identity of their own. If you require the RG to make them meaningful, you may as well call them "token", and be done with it. regardless of rewriting packets. Rewriting packets is a whole other issue, and is largely separable. That one isn't essential to make 8+8 useful, it might be nice, it might even make things much better, or it might be horrid. That it is probably better to discover after experience. What's more important is that it be possible for the rewriting to be done without destroying communicatins than that it actually be done. On one side we have those who believe 8+8 is not useful without rewriting packets. I truly wish that the packet rewriting part had not been mentioned, I don't think its really an issue that matters, and I suspect you're focussing on it a little too much. The question is really whether the ESD is to be used as a connection identifier, or whether the routing info is essential to make the ESD unique (enough) for that purpose. I'm going to omit all your "rewriting is untested, unsafe, and insecure" as I don't think any of that really matters now. 4. I believe consensus is we cannot define or state that ESDs are globally unique 100%. As defined in Mike's draft, probably. I think we agree that MAC addresses aren't 100% unique. I think we have always agreed that. The question has been whether they are 99.99% unique or not (they easily might be) and whether that is good enough for most purposes. 5. The code base ramifications are significant enough This one I'll leave, but I suspect that they're not going to be totally unmanageable. There are certainly more issues to be decided. 6. If the ESD is not unique why and how can I possibly trust a wire transfer of 1 million dollars Unless you're a total dork, you're using some kind of real security, with real keys, that not anly guarantees who you're talking to, but who you are, and that once the transfer is done, prevents you from claiming that it never occurred. Forget about any kind of addresses for real security for anything that matters - the only time address type security is useful is for the stuff that doesn't really matter - like when I connect to www.dec.com and find a www page that says "we're out of business" can I believe I am really connected to a DEC host, or has someone usurped the connection (or something like that). 7. This affects Neighbor Discovery NUD cache implementations I can't think why - that uses addresses, the addresses are 128 bits, in all of these schemes. Who or what assigns the addresses, and how many bits of them are used for what purposes should have no affect at all once you get down to this level. It's at the TCP level, perhaps above, and not much below, that the differences really become apaprent. 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 Mon Jan 27 07:41:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA08116; Mon, 27 Jan 1997 07:41:09 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA08109; Mon, 27 Jan 1997 07:41:00 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA08571; Mon, 27 Jan 1997 07:41:13 -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 HAA15452 for ; Mon, 27 Jan 1997 07:41:14 -0800 Received: from gungnir.fnal.gov ("port 40149"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IEPBNCUG3O001CAI@FNAL.FNAL.GOV>; Mon, 27 Jan 1997 09:41:08 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA07096; Mon, 27 Jan 1997 09:41:07 -0600 Date: Mon, 27 Jan 1997 09:41:07 -0600 From: Matt Crawford Subject: (IPng 3000) Re: (IPng 2997) Re: (IPng 2993) 8+8 Why ESDS are not globally Unique In-reply-to: "26 Jan 1997 13:46:46 EST." <"2.2c.32.19970126184646.00c0ac04"@pobox.corpeast.baynetworks.com> To: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com Message-id: <199701271541.JAA07096@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{ I would say that the size of the hierarchical portion of the RG and > the globally administered portion of the ESD should be the same > since both effectively identify a site and you'd like the ESD to > have hierarchical properties similar to those of the RG for > the sake of the reverse DNS lookup. I disagree with your conclusion, Dimitry. For the sake of argument, I'll grant that hierarchical lookup keyed on ESD is desirable. (But in fact, I don't grant that it's necessary.) The ESD hierarchy does not need any particular aggregation properties, while the RG hierarchy most definitely does. The aggregation needs imposed on the RG by the topology can only be met at the cost some bits in the string used as the RG. ESD hierarchy can be assigned with perfect density (considering only the hierarchical portion) and at no maintenance cost other than the upkeep of the DNS servers that delegate pieces of the space. Thus, it is quite reasonable to expect any hierarchical portion of the ESD space to be shorter than the hierarchical RG. _________________________________________________________ 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 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 Jan 27 08:16:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA08249; Mon, 27 Jan 1997 08:15:40 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA08242; Mon, 27 Jan 1997 08:15:32 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA14324; Mon, 27 Jan 1997 08:15:45 -0800 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA28325 for ; Mon, 27 Jan 1997 08:15:36 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id IAA00825 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id IAA07606 Posted-Date: Mon, 27 Jan 1997 08:15:19 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id LAA17838; Mon, 27 Jan 1997 11:15:19 -0500 for Date: Mon, 27 Jan 1997 11:15:19 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701271615.LAA17838@pobox.engeast.BayNetworks.COM> To: kre@munnari.OZ.AU Subject: (IPng 3001) Re: (IPng 2998) Re: (IPng 2993) 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3115 Robert, > > I would say that the size of the hierarchical portion of the RG and > the globally administered portion of the ESD should be the same > since both effectively identify a site > > No, the RG needs space for bits to be wasted to allow for > future aggregation. If I have one number now, and my neighbour > wants one tomorrow, we want the RG's tobe related. That means > when mine was assigned enough "nearby" space needs to be reserved > to allow some more numbers to be allocated without renumbering lots > of people very frequently. > > For the ESD that isn't relevant - there's no reason for my > neighbour's ESD to be in any way related to mine - so if 10 > more have been allocated today before my neighbour applies tomorrow > anywhere in the country/world/universe then his will be 10 higher > than mine, and the intervening ones don't matter. This means > that non-routing related assignments can be much more compact, and > hence need less bits. > > So, a 6 byte RG and a 4 byte assigned ESD probably fit reasonably > well as a pair. (Or 8 and 5 if the site's internal structure is > included as well). > Yes, I know. But 5 bytes of the assigned ESD space includes the site-internal structure whereas a RG only identify a site. A 5 byte RG can support 10**9 sites with less than 1% assignment efficiency which I think allows more than enough to be wasted for the sake of future aggregation. And since we strive for easier re-numbering, I think a much better RG space utilization is achievable. As a side note, I think there will be need for an ESD aggregation and therefore an unavoidable wastage of the ESD space. This aggregation probably will be needed to scale the reverse DNS lookup as well as to allow for some routing hierarchy within sites. But that should not be a problem with the 5 byte assigned ESD space any more than with a 5 byte RG. > Then you would need at least one extra ESD byte for the > site-local routing hierarchy > > No, that's what the "2" in 6+2+8 is supposed to be. The 8 is > the ESD, the 2 is local routing hierarchy, and the 6 is inter-site > (global) routing. You'd want an extra byte in the site's internal > ESD space to allow the site to divide up their space administratively > (not for routing), and not require one big directory of all the > (hashed) MAC addresses. > My point is that that 2 bytes don't have to be clearly separated from the ESD if a CIDR-type allocation is adopted. There should be no pre-define boundary between global and site-local ESD space assignments. Basically the administered ESD space is allocated the same way the IPv4 address space is currently allocated except there will be 5 bytes to play with -- larger sites get larger contiguous chunks of the administered ESD space than smaller ones. > kre 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 Mon Jan 27 08:53:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA08329; Mon, 27 Jan 1997 08:53:06 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA08322; Mon, 27 Jan 1997 08:52:57 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA22099; Mon, 27 Jan 1997 08:53:10 -0800 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA14819 for ; Mon, 27 Jan 1997 08:53:00 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id IAA23285 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id IAA23287 Posted-Date: Mon, 27 Jan 1997 08:51:24 -0800 (PST) Received: from andover.engeast (andover [192.32.174.39]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id LAA22263; Mon, 27 Jan 1997 11:51:24 -0500 for Date: Mon, 27 Jan 1997 11:51:24 -0500 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199701271651.LAA22263@pobox.engeast.BayNetworks.COM> To: crawdad@FNAL.GOV Subject: (IPng 3002) Re: (IPng 2997) Re: (IPng 2993) 8+8 Why ESDS are not globally Unique Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1456 Matt, > > I disagree with your conclusion, Dimitry. For the sake of argument, > I'll grant that hierarchical lookup keyed on ESD is desirable. (But > in fact, I don't grant that it's necessary.) The ESD hierarchy does > not need any particular aggregation properties, while the RG > hierarchy most definitely does. The aggregation needs imposed on the > RG by the topology can only be met at the cost some bits in the > string used as the RG. ESD hierarchy can be assigned with perfect > density (considering only the hierarchical portion) and at no > maintenance cost other than the upkeep of the DNS servers that > delegate pieces of the space. > > Thus, it is quite reasonable to expect any hierarchical portion of > the ESD space to be shorter than the hierarchical RG. Actually, to be conservative, my premise was that the administered ESD space will be utilized as *bad* as the RG space -- not that the RG space utilization can be as good as it may be theoretically possible for ESD. The question really is if supporting 10**9 sites with a less than 1% assignment efficiency (i.e. 99% wastage) is a reasonable goal. If so then a 5 byte RG will do. 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 Mon Jan 27 14:15:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA08920; Mon, 27 Jan 1997 14:14:59 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA08913; Mon, 27 Jan 1997 14:14:50 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA08333; Mon, 27 Jan 1997 14:15:04 -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 OAA19959 for ; Mon, 27 Jan 1997 14:14:40 -0800 Received: from gungnir.fnal.gov ("port 40233"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IEPPDCFE520017HZ@FNAL.FNAL.GOV> for ipng@sunroof.Eng.Sun.COM; Mon, 27 Jan 1997 16:13:55 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA20911; Mon, 27 Jan 1997 16:13:55 -0600 Date: Mon, 27 Jan 1997 16:13:54 -0600 From: Matt Crawford Subject: (IPng 3003) IPv6 trivia puzzle To: ipng@sunroof.eng.sun.com Message-id: <199701272213.QAA20911@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 QAA09214; Mon, 27 Jan 1997 16:12:32 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA09207; Mon, 27 Jan 1997 16:12:10 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA07340; Mon, 27 Jan 1997 16:12:22 -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 KAA09394 for ; Mon, 27 Jan 1997 10:50:38 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA03730; Mon, 27 Jan 1997 13:13:13 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA29328; Mon, 27 Jan 1997 13:13:04 -0500 Message-Id: <9701271813.AA29328@wasted.zk3.dec.com> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3004) Re: (IPng 3001) Re: (IPng 2998) Re: (IPng 2993) 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Mon, 27 Jan 97 11:15:19 EST." <199701271615.LAA17838@pobox.engeast.BayNetworks.COM> Date: Mon, 27 Jan 97 13:13:04 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 801 Dimitry. If we have 6bytes for the Interface and 2 bytes for the Partitioning of the site that will make a "site-only" reverse DNS lookup be unique even if two distinct links have the same 6byte interface ID. That permits 2**15 subnets. The RG in the site can be ignored. This is one thing I really like about 8+2+6 address structure. In addtion to the "modes" defined in the 6bytes of the Interface per Mike O'dell's proposal. It also supports addrconf. The prefix for RG in the site can be all zeroes. /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 Jan 28 06:26:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA09992; Tue, 28 Jan 1997 06:25:33 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA09985; Tue, 28 Jan 1997 06:25:25 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA02428; Tue, 28 Jan 1997 06:25:41 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA20128 for ; Tue, 28 Jan 1997 06:25:39 -0800 Received: by SNOOPY with Internet Mail Service (5.0.1389.3) id <01BC0CFD.8EF4FA50@SNOOPY>; Tue, 28 Jan 1997 09:28:02 -0500 Message-ID: From: "Harrington, Dan" To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 3006) RE: (IPng 3004) 8+8 Why ESDS are not globally Unique Date: Tue, 28 Jan 1997 09:28:01 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1020 Hi Jim, > It also supports addrconf. The prefix for RG in the site can be all > zeroes. I'd be careful about using an all-zeros prefix in conjunction with addrconf...we already use ::/96 for IPv4-compatible, and using a substring of that for another purpose seem like an open invitation to confusion. I would envision addrconf in the 8+8 environment as using either the actual RG (leaked into the site), or a new "Exportable Site Local" prefix which would be replaced with the actual RG at the site egress router. The scope of this new prefix would be global for purposes of source address selection, but it would not be valid outside the site. Something of this sort is implied in the 8+8 draft...Section 4, labeled "Note:". Dan ------------------------------------------------------------------------------ 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 Jan 28 07:18:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA10068; Tue, 28 Jan 1997 07:18:10 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA10061; Tue, 28 Jan 1997 07:18:03 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA08655; Tue, 28 Jan 1997 07:18:19 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA09422 for ; Tue, 28 Jan 1997 07:18:18 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id KAA29985; Tue, 28 Jan 1997 10:18:06 -0500 Date: Tue, 28 Jan 1997 10:18:06 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9701281018.ZM29983@seawind.bellcore.com> In-Reply-To: "Harrington, Dan" "(IPng 3006) RE: (IPng 3004) 8+8 Why ESDS are not globally Unique" (Jan 28, 9:28am) References: X-Mailer: Z-Mail (3.2.1 10oct95) To: "Harrington, Dan" , "'ipng@sunroof.eng.sun.com'" Subject: (IPng 3007) Re: (IPng 3006) RE: (IPng 3004) 8+8 Why ESDS are not globally Unique Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 623 > I would envision addrconf in the 8+8 environment as using either > the actual RG (leaked into the site), or a new "Exportable Site > Local" prefix which would be replaced with the actual RG at the > site egress router. Why not use a geographic address there ? It would be a nice step towards "number protability". -- 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 Tue Jan 28 08:20:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10199; Tue, 28 Jan 1997 08:20:23 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10192; Tue, 28 Jan 1997 08:20:16 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA17508; Tue, 28 Jan 1997 08:20:31 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA03081 for ; Tue, 28 Jan 1997 08:19:52 -0800 Received: by SNOOPY with Internet Mail Service (5.0.1389.3) id <01BC0D0D.6E3E3DC0@SNOOPY>; Tue, 28 Jan 1997 11:21:39 -0500 Message-ID: From: "Harrington, Dan" To: "'ipng@sunroof.eng.sun.com'" Cc: "'huitema@bellcore.com'" Subject: (IPng 3008) RE: (IPng 3007) 8+8 Why ESDS are not globally Unique Date: Tue, 28 Jan 1997 11:21:38 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1253 Hi Christian, > > I would envision addrconf in the 8+8 environment as using either > > the actual RG (leaked into the site), or a new "Exportable Site > > Local" prefix which would be replaced with the actual RG at the > > site egress router. > > Why not use a geographic address there ? It would be a nice step towards > "number protability". Not that I've got anything in particular against geographical addresses, but let me toss this back and ask Why? What would be gained by having a site use an internal prefix which would A) not exit the site, and B) not provide any routing topology info not already present in the 2 byte PTP field? If it were visible outside the site it might have some value, but if we're talking RG-overwrite then a site-local prefix (common across all sites and all implementations) seems to fit the bill just fine. If you could flesh out your vision a bit I'd be thrilled, as I get the feeling I'm missing something important... Dan ------------------------------------------------------------------------------ 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 Jan 28 08:23:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10222; Tue, 28 Jan 1997 08:22:52 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10215; Tue, 28 Jan 1997 08:22:46 -0800 From: bound@zk3.dec.com Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA17950; Tue, 28 Jan 1997 08:23:01 -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 IAA21743 for ; Tue, 28 Jan 1997 08:22:59 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA01099; Tue, 28 Jan 1997 11:10:49 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA29688; Tue, 28 Jan 1997 11:10:43 -0500 Message-Id: <9701281610.AA29688@wasted.zk3.dec.com> To: "Harrington, Dan" Cc: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 3009) Re: (IPng 3006) RE: (IPng 3004) 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Tue, 28 Jan 97 09:28:01 EST." Date: Tue, 28 Jan 97 11:10:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2105 Dan, >> It also supports addrconf. The prefix for RG in the site can be all >> zeroes. >I'd be careful about using an all-zeros prefix in conjunction >with addrconf...we already use ::/96 for IPv4-compatible, and >using a substring of that for another purpose seem like an open >invitation to confusion. OK but I thought compatible addresses per ngtrans at San Jose decreed that compatible addresses would not be on-link and only used for tunnels? Is this not the case (have not seen any ngtrans minutes). >I would envision addrconf in the 8+8 environment as using either >the actual RG (leaked into the site), or a new "Exportable Site >Local" prefix which would be replaced with the actual RG at the >site egress router. The scope of this new prefix would be global >for purposes of source address selection, but it would not be >valid outside the site. Something of this sort is implied in the >8+8 draft...Section 4, labeled "Note:". No comment on leaking the RG. I think that discussion is in process as to when and how its defined. But assuming its not for now. We could also have everyone use the site-local Format prefix instead of all zeros too. If you send to a destination that is not site-local then if we do end up permitting the RG to be attached at a site-border-router the routers could forward to an anycast address when they see this which would get it to the place where the packet is altered at the source address. Likewise this would have to be done then on a response to the source node ack ack ack ...YUCK. And people wonder why I don't like rewRiting of packets. Just the performance hit is bogus. Anyway I need to know if compatible addresses are permitted on links as I was not at ngtrans in San Jose but I heard that they were not anymore? To finish this discussion. 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 Tue Jan 28 08:41:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10254; Tue, 28 Jan 1997 08:41:22 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10247; Tue, 28 Jan 1997 08:41:16 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA21489; Tue, 28 Jan 1997 08:41:30 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA13245 for ; Tue, 28 Jan 1997 08:41:24 -0800 Received: by SNOOPY with Internet Mail Service (5.0.1389.3) id <01BC0D10.829211E0@SNOOPY>; Tue, 28 Jan 1997 11:43:42 -0500 Message-ID: From: "Harrington, Dan" To: "'ipng@sunroof.eng.sun.com'" Cc: "'bound@zk3.dec.com'" Subject: (IPng 3010) RE: (IPng 3009) 8+8 Why ESDS are not globally Unique Date: Tue, 28 Jan 1997 11:43:41 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 676 Hi Jim, > Anyway I need to know if compatible addresses are permitted on links as > I was not at ngtrans in San Jose but I heard that they were not anymore? > To finish this discussion. Per my notes IPv4-compatible addresses are not used on-link...I have not seen NGTRANS minutes from San Jose. I still think a non-zero value for the Exportable Site-Local prefix is preferable, though. Dan ------------------------------------------------------------------------------ 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 Jan 28 09:05:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10321; Tue, 28 Jan 1997 09:05:07 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10314; Tue, 28 Jan 1997 09:04:58 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA26224; Tue, 28 Jan 1997 09:05:12 -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 JAA23576 for ; Tue, 28 Jan 1997 09:04:50 -0800 Received: from gungnir.fnal.gov ("port 40264"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IEQSUIQYZI0010D5@FNAL.FNAL.GOV> for ipng@sunroof.Eng.Sun.COM; Tue, 28 Jan 1997 11:04:04 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id LAA27501; Tue, 28 Jan 1997 11:04:03 -0600 Date: Tue, 28 Jan 1997 11:04:03 -0600 From: Matt Crawford Subject: (IPng 3012) Re: (IPng 3010) RE: (IPng 3009) 8+8 Why ESDS are not globally Unique In-reply-to: "28 Jan 1997 11:43:41 EST." <"D7014D55F851D0118203080009DCE8F15D03"@SNOOPY> To: "ipng@sunroof.eng.sun.com" Message-id: <199701281704.LAA27501@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{ I still think a non-zero value for the Exportable Site-Local > prefix is preferable, though. Yes, certainly, not an all-zero RG. But does this prefix need to be markedly different from the ordinary site-local prefix fec0::/10? It could at least come from the same format prefix. If the destination address is global-scope and the source address matches fec0::/N, where N is the (known constant) length of 8+8's FP+RG, then the site border routers may forward the packet off-site, changing the first N bits of the source address to a suitable FP+RG for the site as they do so. This requires the identity mapping between site-local subnets and the 8+8 PTP field, but in return it cuts down on the number of source addresses hosts must choose among. _________________________________________________________ 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 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 Jan 28 09:08:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10338; Tue, 28 Jan 1997 09:07:23 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10331; Tue, 28 Jan 1997 09:07:19 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29057; Tue, 28 Jan 1997 09:07:35 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA24834; Tue, 28 Jan 1997 09:07:21 -0800 Date: Tue, 28 Jan 1997 09:07:21 -0800 From: jrh@jurassic (John Hird) Message-Id: <199701281707.JAA24834@stinker.eng.sun.com> To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2995 Return-Path: Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10293; Tue, 28 Jan 1997 08:57:48 -0800 From: Martin.Pabst@mch.sni.de Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA24798; Tue, 28 Jan 1997 08:58:02 -0800 Received: from thoth.mch.sni.de (thoth.mch.sni.de [192.35.17.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA20648 for ; Tue, 28 Jan 1997 08:57:58 -0800 Received: from rhodos.mch.sni.de (rhodos.mch.sni.de [139.22.10.131]) by thoth.mch.sni.de (8.8.5/8.8.5) with SMTP id RAA02547 for <@mail:ipng@sunroof.eng.sun.com>; Tue, 28 Jan 1997 17:57:51 +0100 (MET) Date: Tue, 28 Jan 97 17:57 MET Message-ID: <9701281758.AA04404@rhodos.mch.sni.de> To: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-linkname-00.txt Content-Type: text content-length: 1827 Comment on draft-ietf-ipngwg-linkname-00.txt Chapter 5 - Interaction with DNS and resolver routines The search ordering proposed in the document is BIND/LOCAL/LINK. If the nameserver resides outside the link, any host has to leave the link before it can communicate with it's neighbour; depending on the search list specified in /etc/resolv.conf, not only one query to the nameserver is necessary. Overmore, if the neighbour is registered with the DNS, the link local address never will be used. So we lose both advantages: link layer information from the link local IPv6 address and the restriction of traffic to the local link. On the other hand, using the LINK information first will possibly result in wrong results, if there are hosts of more than one DNS domain on the link. The uniqueness of a hostname inside the link does not necessaryly coincide with the uniqueness of the hostname over all DNS domains that are present on the link. Introducing the domainnames into the protocol would complicate the protocol and corrupt its elegance (e.g. a DNS domain may not be defined). Perhaps, the advantages of the link local addresses would be more widely explored, if there was a hint to that not more than one DNS domain has to be on one link: then the ordering can be LINK/LOCAL/BIND (perhaps as a SHOULD). Martin Pabst ------------------------------------------+------------------------------------ Martin Pabst | e-mail: Martin.Pabst@mch.sni.de Siemens Nixdorf Informationssysteme AG | phone: ..49-89-636-48074 OEC HES XP1 | fax: ..49-89-636-48976 Otto-Hahn-Ring 6 / 81739 Munich / Germany | ------------------------------------------+------------------------------------ ------------------------------------------------------------------------------ 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 Jan 28 09:23:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10366; Tue, 28 Jan 1997 09:23:17 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10359; Tue, 28 Jan 1997 09:23:11 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA00301; Tue, 28 Jan 1997 09:23:25 -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 JAA01866 for ; Tue, 28 Jan 1997 09:23:15 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA10174; Tue, 28 Jan 1997 12:12:49 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA03417; Tue, 28 Jan 1997 12:12:44 -0500 Message-Id: <9701281712.AA03417@wasted.zk3.dec.com> To: "Harrington, Dan" Cc: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 3013) Re: (IPng 3009) 8+8 Why ESDS are not globally Unique In-Reply-To: Your message of "Tue, 28 Jan 97 11:43:41 EST." Date: Tue, 28 Jan 97 12:12:44 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 331 dan...OK i agree...non-zero is best... 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 Tue Jan 28 09:48:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10510; Tue, 28 Jan 1997 09:48:00 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10503; Tue, 28 Jan 1997 09:47:53 -0800 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA05954; Tue, 28 Jan 1997 09:48:07 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA29908 for ; Tue, 28 Jan 1997 09:48:05 -0800 Received: by SNOOPY with Internet Mail Service (5.0.1389.3) id <01BC0D19.CCFDCD60@SNOOPY>; Tue, 28 Jan 1997 12:50:12 -0500 Message-ID: From: "Harrington, Dan" To: "ipng@sunroof.eng.sun.com" Subject: (IPng 3014) RE: (IPng 3012) Re: (IPng 3010) RE: (IPng 3009) 8+8 Why ESDS are not globally Unique Date: Tue, 28 Jan 1997 12:50:11 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1748 Hi Matt, > Yes, certainly, not an all-zero RG. But does this prefix need to be > markedly different from the ordinary site-local prefix fec0::/10? It > could at least come from the same format prefix. If the destination > address is global-scope and the source address matches fec0::/N, > where N is the (known constant) length of 8+8's FP+RG, then the site > border routers may forward the packet off-site, changing the first N > bits of the source address to a suitable FP+RG for the site as they > do so. I've been wondering about this...certainly it could come from the same format prefix. If we tried to use the existing FEC0:: prefix, then RFC 1884 would need some massaging, as it currently says that a site-local *source* address should not be forwarded. That would have to be flipped around to checking the destination. My gut tells me that there should be a distinction between "pure" site-local (as defined today) and the proposed "exportable" site-local for use with 8+8+Overwrite. Overloading is bad (in general). (Is an Overwriting Router a Wrouter?) > This requires the identity mapping between site-local subnets and the > 8+8 PTP field, but in return it cuts down on the number of source > addresses hosts must choose among. Good question...I guess I have been assuming all along (i.e. since long before 8+8 came along) that a single subnet numbering would be used with any number of prefixes, including both global and site-local. Dan ------------------------------------------------------------------------------ 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