From owner-ipng@sunroof.eng.sun.com Fri Feb 7 16:12:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA04419; Fri, 7 Feb 1997 14:22:11 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA04412; Fri, 7 Feb 1997 14:22:08 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA06783; Fri, 7 Feb 1997 14:22:28 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA05150; Fri, 7 Feb 1997 14:22:11 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA03109; Fri, 7 Feb 1997 04:02:26 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA04512; Fri, 7 Feb 1997 04:02:45 -0800 Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id EAA22542 for ; Fri, 7 Feb 1997 04:02:47 -0800 Message-Id: <199702071202.EAA22542@mercury.Sun.COM> Received: from bcarsfba.ott.bnr.ca by bcarsde4.localhost; Fri, 7 Feb 1997 06:59:26 -0500 Received: from bnr.ca by bcarsfba.bnr.ca id <12782-0@bcarsfba.bnr.ca>; Fri, 7 Feb 1997 06:42:38 -0500 Date: 07 Feb 1997 06:42 EST To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com From: "Andrew Hollbach" Subject: (IPng 3041) Re: Geographic Addresses for IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 811 speaking of geographic ESDs.. If anyone is ever foolish (or careless) enough to transmit a source address containing a geo-ESD over the global internet without first encrypting/translating/disguising it, they may be revealing their physical location within GPS-type accuracy? (maybe not enough bits there in 6 bytes?) This makes me very, very uneasy. Hopefully, this has already been thought of and an airtight solution proposed (or, would scrambling the geo-ESD defeat the whole purpose of them?) i'm confused :) ..Andy ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 7 16:12:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03862; Fri, 7 Feb 1997 10:14:36 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03854; Fri, 7 Feb 1997 10:14:23 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA14286; Fri, 7 Feb 1997 10:14:31 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA26099; Fri, 7 Feb 1997 10:13:59 -0800 Received: by SNOOPY with Internet Mail Service (5.0.1389.3) id <01BC14F9.0A9AF170@SNOOPY>; Fri, 7 Feb 1997 13:15:51 -0500 Message-ID: From: "Harrington, Dan" To: Andrew Hollbach , "'owner-ipng@sunroof.Eng.Sun.COM'" Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 3040) Re: Geographic Addresses for IPv6 Date: Fri, 7 Feb 1997 13:15:50 -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: 976 Hi Jim, > [...] But that is an interesting point, but > on the other hand I have gotten lost in the woods on a canoe trip before > I had a gps device I'm sure you're well aware of the limits of technology, but I thought you might find this interesting...One of my wife's friends is a U.S. Forest Ranger up in the White Mts. According to her, they've already had to pull multiple folks out of the woods who had relied a bit too heavily upon their GPS systems. They didn't realize that A) it doesn't help much without a map, B) the batteries can go dead, C) carrying a compass is still very useful, etc. etc. Perhaps multicast groups will help, but I doubt it... :-) 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 Fri Feb 7 16:12:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA03172; Fri, 7 Feb 1997 04:50:27 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA03165; Fri, 7 Feb 1997 04:50:20 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA07918; Fri, 7 Feb 1997 04:50:40 -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 EAA00935 for ; Fri, 7 Feb 1997 04:50:41 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id HAA20513; Fri, 7 Feb 1997 07:42:24 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16315; Fri, 7 Feb 1997 07:42:21 -0500 Message-Id: <9702071242.AA16315@wasted.zk3.dec.com> To: "Andrew Hollbach" Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 3039) Re: Geographic Addresses for IPv6 In-Reply-To: Your message of "07 Feb 97 06:42:00 EST." <199702071209.HAA32232@mail11.digital.com> Date: Fri, 07 Feb 97 07:42:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 999 Andrew, I don't recall that discussion. But that is an interesting point, but on the other hand I have gotten lost in the woods on a canoe trip before I had a gps device. With IPv6 if I got lost I would like to multicast an S.O.S. from my gps device to all joined-members, to come save my butt. We don't encrypt the addresses at present, and if we did (or invented some kind of decrypt on a route path) that would make routing much slower and everyone would have to know how to do that. Part of the goal here is to keep IP ubiquitous. Disguising addresses in packets seems like a non-starter. Also this problem (if a real problem) is valid for non-geo-addresses too. But I am agnostic on this issue. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Feb 7 16:12:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00619; Thu, 6 Feb 1997 08:22:45 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00612; Thu, 6 Feb 1997 08:22:31 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA27441; Thu, 6 Feb 1997 08:22:50 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA26653 for ; Thu, 6 Feb 1997 08:22:44 -0800 Received: by SNOOPY with Internet Mail Service (5.0.1389.3) id <01BC1420.72313DF0@SNOOPY>; Thu, 6 Feb 1997 11:25:24 -0500 Message-ID: From: "Harrington, Dan" To: ipng@sunroof.eng.sun.com Cc: "'Martin.Pabst@mch.sni.de'" Subject: (IPng 3037) RE: draft-ietf-ipngwg-linkname-01.txt Date: Thu, 6 Feb 1997 11:25:23 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 10913 Hi Martin, First of all, thank you very much for the extensive comments...I really appreciate it. I've responded to it all at once, which leads to a rather lengthy mail message...if we end up discussing multiple points at length, perhaps each one should have its own thread? > The extensions and suggestions are very interesting. Though, the > protocol seems to be closer entwisted step by step with DNS. What > does Paul Vixie think about this? I had a chat with Paul in San Jose in December, and he saw the need for a mechanism such as this, and he agreed to the idea of providing a separate pseudo-domain such as .link. Such a mechanism is necessary to provide a consistent presentation of the names, while making sure that they remain distinct from "real" DNS names. In fact, he thought the IANA might want to create a dedicated TLD for non-DNS naming mechanisms, so that instead of jessica.link you might have jessica.link.notDNS (or some such thing). > You addressed the concerns of the ambiguity of a hostname over two > domains residing on a single link with the possibility to include > the full domainname in the protocol. This has clear advantages over > a merely recommendation to have only one DNS-domain on a single > link (which would result in a restriction). Correct...this was due to feedback from the initial (00) version of the draft. > The search order BIND/LOCAL/LINK wasn't changed. [...] I wasn't trying to dictate the only possible setting...I was trying to point out that it would have to be taken into consideration when configuring the resolver to deal with multiple lookup mechanisms. The BIND/LOCAL/LINK happens to represent my guess of the common setting, but it's not written in stone. > (1) The ".link" Domain > ---------------------- > I don't exactly understand what do you intent with this domain. Then I must clarify what I stated in the draft (which *is* a bit muddled, when I look back at it). The .link pseudo-domain is a user-visible indication that the address associated with this name is a restricted Link Local address, and also that this name/address mapping was accomplished using this protocol, and not using DNS. You are correct when you state (further down) that the use of the tag within the protocol itself is redundant...it need only be dealt with by the resolver as an input/output tag. > With the introduction of this domain, and with the exchange of domainnames > locally you suggest to integrate the new name resolution completely > into the DNS. A domainname should be searched first by the BIND mechanism; > this interprets the appendix ".link" as a hint to search the host on the > local link; when failing, the search will be continued in the known manner > by queries to DNS nameservers and finally by lookups in a local statical > file (/etc/hosts). No, I don't want this tied into the DNS protocol at all. That's part of the reason for having a distinct naming domain (.link). However, to be useful it *does* have to be tied into the resolver software (which also happens to use DNS). > For my feeling, introducing the ".link" domain is a bit a misuse of > the DNS naming scheme. The order where to search first can be given to > the resolver mechanism by several other means, reaching from fixed > implementation of the ordering to a keyword in some configuration file > (e.g. /etc/resolv.conf). The really crucial point is to apply the correct > ordering to avoid ambiguities (see below); this isn't any guaranteed by > the possibility of a ".link" suffix: who will append it and when? You're right, in that the use of .link alone isn't sufficient to configure the search order. However, it is still needed as a means by which a user can force the use of this particular lookup method. If a user types "telnet jessica.link", then the telnet connection had better use a link local address, else fail. > Or do you think in introducing a new naming hierarchie, link local > and below the ".link" domain?; admitting privat domainnames independently > from the DNS? Heavens no! That's not the intent at all...I just want to disambiguate name/address pairs learned using this protocol from those using DNS. > The ".link" appendix transmitted between the link local neighbours > is completely redundant: from the source address (and from the protocol > itself!) it is clear that the origin of the information is link local. You're absolutely right. Thanks. > To my taste, we should leave the naming hierarchy untouched; finally > this could encourage other working groups or even companies to misuse > the DNS naming scheme. I don't see any striking advantages of the ".link" > suffix over other methods to control the ordering of the name resolution. I'm certainly not trying to abuse the domain naming scheme...I just want these mechanisms to live side by side. > Appending the ".link" domain can be conceived as a hint on the method of > how and where to search the host. But this is nothing but an implementation > detail. There is no *need* to include this into the protocol. Again, I admit that the .link need not be in the protocol itself. However, it *is* necessary to have a standard method of presenting these names to/from the resolver. > > (3) Possible Cases > ------------------ > So, what's about the often mentioned ambiguities? I've studied your cases and analysis, and gone through my own list of what could happen. The potential for confusion arises when there is a mix of systems on the link, some configured to use DNS and some not. If the requesting system is also configured for DNS, the task is simpler in that it has a default domain and possibly search lists to use. If the requesting node is NOT configured for DNS, and has to choose from multiple replies (e.g. jessica and jessica.A and jessica.B), then it must use some other criteria. Possible tiebreakers include longest response, largest TTL value, first received response, or others. > (5) Trucated Domainnames > ------------------------ > In a last effort to keep the protocol simple I recommend to avoid > truncated domainnames in the local domain, e.g. jessica.egn instead of > jessica.egn.acme.com. We can admit queries like those; but it doesn't > seems necessary making them to work with success within local link queries. I, too, would prefer to keep things simple, and adding configuration options to the resolver adds complexity (and a place to introduce error). Any other opinions out there? > (6) Completition Of The Protocol > -------------------------------- > In order to have an effective plug'n play protocol, it would be advantageous > that hosts plugging into the link not only announce themselves, but > also have the possibility to learn quickly about their neighbours, in > order to install a first database (what you named "dynamic storage for > link local addresses"). I recognize that this might be desirable in some instances, but would prefer not to institutionalize it. > I propose to let the hosts to interpret queries with address field zero > and host field zero as queries to all hosts on the link to announce > themselves (perhaps answered by every host to the link local multicast > group; by this providing an oportunity for a general update of all > databases on the link). [...] I don't think this would scale nicely at all. > [...] Every host plugging into the link should send > such a query. I don't see any problem with extensive net load provoked > by this: the entering to a link has to be performed by human beeings and > so it is within macroscopic times. If it was only done occasionally when a new system joined the link, it might not be so bad. But consider the effect when thousands of nodes reboot after a power hit. > > (8) Extensions To The Protocol > ------------------------------ > The insinuated use of the protocol for other purposes seems to be a quite > interesting idea. Users can learn not only their neighbours addresses > but also machine names, owners etc.. > > This leads back to the relation with the DNS: why not to define the > same types of information? why not to exchange the information in the > same format? > > By this the protocol definitively would lose its simplicity. True...I also mention that it shares some concepts with the Service Location protocol. I would rather keep it limited to name/address issues, but I mentioned the other possibility as an extension in the same vein. > The extension towards link local name servers would be even more > bulky. To my feeling, the protocol's elegance just results from > the fact that the scheme is really decentral. We should try to > guard this until further needs. As mentioned above, net load > won't be a problem. Agreed. But again, for the sake of completeness I figured it should be mentioned and discussed. I would really prefer to avoid any sort of proxy servers. > (9) Security > ------------ > Lamentablemente, I could not avoid to encounter gaps that should be > mentioned. If the search order is that the link local resolution will > be performed first (what, again, is necessary to enable the use of the > link local addresses), a workstation will be able to simulate another > host: The LAN is a common resource, and as such it assumes a certain amount of trust amongst the users. If this trust is abused, then simple mechanisms such as this proposal are not appropriate for the environment, and the linkname mechanism should be disabled. I suppose it's possible to define the use of this protocol in conjunction with IPsec, but that raises the image of swatting flies with a sledgehammer. > (10) Status Of The Draft > ------------------------ > Perhaps, I am not sufficiantly familiar with the rules of assigning > states to the IETF documents. But I estimate the necessity for a similar > protocol for link local address resolution very urgent. Therefore, I don't > understand exactly, why this draft is stated only as "experimental". That was due to caution on my part...I conceived of this protocol after having to type in a long list of IEEE hardware addresses, which made me think that there must be a better way. But I'd rather make sure it can work before asking the working group to sanction it as a proposed standard. In fact, it's probably innappropriate to label it "experimental"...I'll remove that language. Thanks again for your extensive comments, Martin! If anybody else has feedback I'd love to hear it. I'd like to resubmit an updated draft soon (next month or so), then get started on an implementation. 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 Fri Feb 7 16:12:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28075; Wed, 5 Feb 1997 09:30:26 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28068; Wed, 5 Feb 1997 09:30:22 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA11182; Wed, 5 Feb 1997 09:30:43 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA03039; Wed, 5 Feb 1997 09:30:26 -0800 Date: Wed, 5 Feb 1997 09:30:26 -0800 From: jrh@jurassic (John Hird) Message-Id: <199702051730.JAA03039@stinker.eng.sun.com> To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1929 Return-Path: Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA27470; Wed, 5 Feb 1997 01:27:39 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA24174; Wed, 5 Feb 1997 01:28:00 -0800 Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA05235 for ; Wed, 5 Feb 1997 01:28:00 -0800 Message-Id: <199702050928.BAA05235@mercury.Sun.COM> Received: from bcarsfba.ott.bnr.ca by bcarsde4.localhost; Wed, 5 Feb 1997 04:25:03 -0500 Received: from bnr.ca by bcarsfba.bnr.ca id <29760-0@bcarsfba.bnr.ca>; Wed, 5 Feb 1997 04:07:57 -0500 Date: 05 Feb 1997 04:07 EST Sender: "Andrew Hollbach" To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com From: "Andrew Hollbach" Subject: re:(IPng 3032) Geographic Addresses for IPv6 content-length: 685 jim bound said: ... >I am a-moral on this one its just input!!!! I just want "a" IPv6 >addressing architecture that will work. How about two ESD types, with an embedded type-indicator, leaving open the possibility for other types of ESD in the future; initially, MAC addr based and geographic based. Summarizing all the debate about MAC addr uniqueness, perhaps ESDs based on MAC addr need only be unique enough, with diagnostic tools for the (hopefully rare) cases where they collide. A similar approach could apply to the geographic ESDs; at least colliders should be physically adjacent.. ..Andy junior network architect (network architects hand wave over the tricky stuff :) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 7 16:12:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA27806; Wed, 5 Feb 1997 05:21:58 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA27799; Wed, 5 Feb 1997 05:21:51 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA13624; Wed, 5 Feb 1997 05:22:10 -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 FAA14553 for ; Wed, 5 Feb 1997 05:22:12 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA23481; Wed, 5 Feb 1997 08:14:19 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24704; Wed, 5 Feb 1997 08:13:48 -0500 Message-Id: <9702051313.AA24704@wasted.zk3.dec.com> To: "Andrew Hollbach" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3035) Re: Geographic Addresses for IPv6 In-Reply-To: Your message of "05 Feb 97 04:07:00 EST." <199702050934.EAA17637@mail11.digital.com> Date: Wed, 05 Feb 97 08:13:47 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1685 >How about two ESD types, with an embedded type-indicator, leaving open the possibility >for other types of ESD in the future; initially, MAC addr based and geographic based. Yes thats fine. In fact the 8+8 ESD is made up of a 2byte Partition, and 6byte Identifier. Bit 15 of the Partition bytes is used as a Mode type to designate Identifier types. >Summarizing all the debate about MAC addr uniqueness, perhaps ESDs based >on MAC addr need only be unique enough, with diagnostic tools for the (hopefully >rare) cases where they collide. A similar approach could apply to the geographic >ESDs; at least colliders should be physically adjacent.. In my suggestion/thought I am only concerned about the "site" proper. I am not debating or asking if the ESD is globally unique on the Internet. Thats another discussion when we discuss routability of the upper 8 bytes. For the site each link using DAD will make sure the ESD-Identifier is unique. The ESD-Partition bytes will make sure the entire ESD is site-unique. So the ESD in my scenario for deployment now will provide a unique AAAA and PTR (reverse dns look ups) for the sites domain proper and any zone delgations that exist in that site. DNS with DNSSEC for IPv6 may assist with the firewalls that will be used to implement NAT 8+8 for IPv6 on an Intranet. The ESD would be unique for the PTR records for a site in my thought. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Feb 7 16:12:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA27222; Tue, 4 Feb 1997 19:37:16 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA27215; Tue, 4 Feb 1997 19:37:09 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA18114; Tue, 4 Feb 1997 19:37:27 -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 TAA02662 for ; Tue, 4 Feb 1997 19:37:27 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA04469; Tue, 4 Feb 1997 22:33:49 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA06923; Tue, 4 Feb 1997 22:33:20 -0500 Message-Id: <9702050333.AA06923@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3033) ESD in 8+8 is a good idea. Date: Tue, 04 Feb 97 22:33:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4022 I would also like to put the attached on the discussion agenda for the IETF Interim meeting Feb 27 and 28. Regardless of what we do with the upper 8bytes of 8+8 I think the ESD is really a good idea and should maybe be defined in RFC 2073 too. The reason is that for a site 2+6 will work to define unique nodes within the site. How we use the upper 8 bytes is another discussion and what we do with them regarding routing IMHO. Also RFC 1897 uses the low-order 8 bytes the same way. 2 bytes subnet and 6 bytes interface ID (does not have the modes as 8+8) but the bit positions are the same. Lets suppose that all bought into the above scenario for the ESD. Here is what could be done. Lets also assume that the vendors port all the really used IPv6 applications to IPv6 (e.g. network utilities, ftp, telnet, smtp, nfs, web server/browser, snmp, ipsec, ntp, firewall filters, dhcp, dynamic updates to DNS, etc. etc.). This is not that far fetched either given the implementation state in the community. A user could begin deploying IPv6 on an Intranet using the ESD with the Interface set to the factory-installed communcations adapter address. The user could use ND and Stateless Addrconf to advertise the 2byte Partitions in their site. Or DHCPv6. Or a combination of both. At the site or at subnets within the site a translator can be developed to use up the IP address space they all ready have for addresses to be translated when an IPv6 node with an ESD address wants to communicate on the Internet, within their Intranet, and other scenarios. The translator could be something as simple as another radix AF_FAMILY tree and IPv4 addresses could be rationed out based on the 2byte partition by an administrator. There are many ways to build a translator I am just looking at this idea at present trying to make it efficient for a Host. This means the user can use their present IPv4 addresses and do not have to ask for new addresses or resort to using Private Addresses which have problems for some users as stated in the end of RFC 1918 and clearly in RFC 1627 (which is obsolete but I think still valuable). It also means the site can immmediately communicate on the 6bone by creating a prefix from RFC 1897 and the translator is not needed for that part of the Internet. This could potentially be an evolution plan for the 6bone to become the IPv6 Internet connection for the world (internationally). It also means that when the IPv6 addressing architecture is selected for the upper 8bytes, that the user does not have to renumber except for a new prefix whether we choose 8+8, RFC 2073, or another proposal, if we state the ESD is defined for the lower 8bytes. Given ND, Stateless Addrconf, DHCPv6, and the Router Renumbering proposal by Bob Hinden, this will make it quite simple to convert a site that deployed ESDs in their Intranet to move to IPv6 quickly and in addition permit users to start using IPv6 to expand their address space and begin to take advantage of the extensive new capabilities in IPv6 non-existent in IPv4. So if we can get consensus on the low order 8bytes we can make a lot of deployment progress and also do a great service to the problems of IPv4 address space exhaustion, and extend the capability of Intranet users via IPv6. Its time to deploy IPv6 IMHO. This also gives us a little more time to address the variants regarding the most efficient and robust way to route IPv6 addresses and use them in applications (locators or as part of the identifiers). It also puts the routing decision on 8bytes which is a big win over 16. In that sense we would have made a critical decision too by buying into the ESD concept for the lower 8bytes. Comments....!!!!!! /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Feb 7 16:12:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA27166; Tue, 4 Feb 1997 19:03:36 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA27159; Tue, 4 Feb 1997 19:03:29 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA12345; Tue, 4 Feb 1997 19:03:46 -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 TAA25246 for ; Tue, 4 Feb 1997 19:03:46 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id VAA00082; Tue, 4 Feb 1997 21:58:38 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28650; Tue, 4 Feb 1997 21:58:09 -0500 Message-Id: <9702050258.AA28650@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3032) Geographic Addresses for IPv6 Date: Tue, 04 Feb 97 21:58:09 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1286 As some input to all the geographic address believers. I had the opportunity to speak with a Sr. Networking Architect for a large Fortune 50 Financial Company (wishes to remain anon) who has satellite offices, ATM Machines, and Internet Banking access thru out the Americas. They told me that it would be really good if IPv6 addresses permitted them to know from an "address" what geographical location the packet was being sent from (with security of course) and they could determine all kinds of services and the best access for them automatically based on the application program analysis for that geography. They also believed that multihomed to them was not just 2 ISP access points but possibly 20. In fact they could be an ISP hub for the finanical sector they live in. The person again believes for that case geographical addresses are a win too much for the same reasons above. I am a-moral on this one its just input!!!! I just want "a" IPv6 addressing architecture that will work. /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 Feb 9 06:55:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA05993; Sun, 9 Feb 1997 06:54:43 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA05985; Sun, 9 Feb 1997 06:54:34 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA07065; Sun, 9 Feb 1997 06:54:56 -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 GAA18996; Sun, 9 Feb 1997 06:54:57 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA28205; Sun, 9 Feb 1997 09:43:34 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA17569; Sun, 9 Feb 1997 09:42:31 -0500 Message-Id: <9702091442.AA17569@wasted.zk3.dec.com> To: "Harrington, Dan" Cc: Andrew Hollbach , "'owner-ipng@sunroof.Eng.Sun.COM'" , ipng@sunroof.eng.sun.com Subject: (IPng 3042) Re: Geographic Addresses for IPv6 In-Reply-To: Your message of "Fri, 07 Feb 97 13:15:50 EST." Date: Sun, 09 Feb 97 09:42:30 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 923 Dan, Yes places like the WHite MOuntains have a very brutal side too..not good to make errors out there. I met some couples backpacking once that only brought modern ignitors for their stove and fires but forgot real matches. I gave them some as I had spare but wanted to charge them $5.00 as a wake up call. I even carry magnesium and flint bar. I view rewriting of packets like trusting GPS devices right now. Having a complete packet at the end systems (locator + ESD) I think will make sure my manual compass will always work right now on the Internet. Plus the gov't doesn't let you get 100% accuracy.. via the satellite. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Feb 13 01:06:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA11905; Thu, 13 Feb 1997 01:05:19 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA11898; Thu, 13 Feb 1997 01:05:09 -0800 From: Martin.Pabst@mch.sni.de Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA01214; Thu, 13 Feb 1997 01:05:34 -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 BAA26843 for ; Thu, 13 Feb 1997 01:05:31 -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 KAA12962 for <@mail:ipng@sunroof.Eng.Sun.COM>; Thu, 13 Feb 1997 10:05:29 +0100 (MET) Date: Thu, 13 Feb 97 09:58 MET Message-ID: <9702131006.AA01139@rhodos.mch.sni.de> To: ipng@sunroof.eng.sun.com Cc: dth@lucent.com Subject: (IPng 3044) draft-ietf-ipngwg-linkname-01.txt Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 15286 Hi Dan, It would be a good idea, to give every point its own thread, but for the moment, I see a lot of relations and I don't know how to separate; therefore another lenghty mail, sorry. With your answer, I better understand what you are planning and I clearly see the advantages. Doubts and differences have their reasons mostly in different associations with the notions; in what special scenario we are thinking. Perhaps, it's not the right place for those questions; overmore, they can't be anwered now definitively, depending on future experiences with IPv6. Nevertheless: What purpose does the facility of link local addresses serve, including the RfC1971, Stateless Address Autoconfiguration? Thomson and Narten write: "...when a site is not particularly concerned with the exact addresses hosts use,...". Can we assume, that the presence of the link layer address in the link local address should or will be used by the link layer, in order to improve the address resolution within this layer? Is one goal of the link local addresses to simplify the address resolution, avoiding DNS nameserver queries, without the need of a static local database (/etc/hosts)? Does mobile computing will be a frequent case for the use of RfC1971 and link local addresses? In how much hosts we think when mentioning "link local": tens or thousands? Are they changing frequently? Do the users know them each other? What will be the future situation and what the common case then? What role the DNS names play (what is a not-"real" DNS name)? To start with the last question and to be less abstract: >I had a chat with Paul in San Jose in December, and he saw the need >for a mechanism such as this, and he agreed to the idea of providing >a separate pseudo-domain such as .link. Such a mechanism is necessary >to provide a consistent presentation of the names, while making sure >that they remain distinct from "real" DNS names. In fact, he thought >the IANA might want to create a dedicated TLD for non-DNS naming >mechanisms, >so that instead of jessica.link you might have jessica.link.notDNS (or >some such thing). Although I still don't see the *need* for the pseudo domain, I don't want to object against those decisions from last year. At least, now I see the advantage for the user: >The .link pseudo-domain is a user-visible indication that the address >associated with this name is a restricted Link Local address, [...] So the user can force the connection to a neighbour's host, which has the same name as another host from the default domain but is outside the link. Very good! But we shouldn't overestimate the common user's knowledge of his or her link containing a large amount of hosts. Thanks for having clarified the following, too: >No, I don't want this tied into the DNS protocol at all. That's part of >the reason for having a distinct naming domain (.link). However, to be >useful it *does* have to be tied into the resolver software (which also >happens to use DNS). So I see, that the coupling of DNS and the new protocol is effected only by the resolver software, not by DNS itself. Nevertheless, I think we should have only one "real" domainname: the DNS name; o.k. with some appendix like ".link.notDNS". But the coupling by the resolver means, that the next method will be used if the preceding failed; and the decision on success or not is entwisted with the official DNS name. So I fear for trouble (i.e. ambiguities) if everyone feels free to create whatever domain name crosses his or her mind. And you, too, seem to be little amazed by this idea: >Heavens no! That's not the intent at all...I just want to disambiguate >name/address pairs learned using this protocol from those using DNS. So the protocol should underline the common of the link local DNS name and the domainname obtained by a DNS nameserver. In fact, for a neighbour host, there is no difference in the address/name pair, despite the different addresses; until no other information hold in the nameserver's database is required, for a neighbour the name/address pair will be of full, not only of restricted use; in my opinion of even better use (see below). Concerning the order in which the different resolver machanisms are applied, I suppose clear advantages of link local addresses over those obtained by DNS nameservers: respective the possible use of the contained link layer address and in order to reduce nameserver queries. This assumptions are not certain - as stated out by the above questions list. But for the moment (and the following), I'll assume it. To make use of the link local addresses, the link local resolver mechanism should be applied before any DNS query. Otherwise, only those hosts on the link can be reached by the new protocol, that don't have any valid DNS name; those, that aren't registered with any nameserver. Is that your point of view, too, and your intention?: >> The search order BIND/LOCAL/LINK wasn't changed. [...] > >I wasn't trying to dictate the only possible setting...I was trying >to point out that it would have to be taken into consideration when >configuring the resolver to deal with multiple lookup mechanisms. >The BIND/LOCAL/LINK happens to represent my guess of the common >setting, but it's not written in stone. You are right, there shouldn't be any fixed rules on this. But wouldn't it be nice to give a recommendation, at least to outline the consequences of the distinct choices?; to present one choice, one scenario that works well. And this depends on the different ideas of what may be the general, the frequent case - in short: the question list above claims to be checked, again. Perhaps we can clarify this point a bit when looking on what is BIND; then, the naming "BIND/LOCAL/LINK" may seem somewhat misleading; by the way, methods of how to control the search order are remembered: The BIND implementaion of Paul Vixie contains a DNS nameserver and a resolver. The resolver uses queries to nameservers and, when they failed, lookups in a static database (/etc/hosts) (i.e. LOCAL). Using pure BIND, the search order today is fixed as DNS/LOCAL. Implementing the new resolution method within BIND, it would be fixed as DNS/LOCAL/LINK or whatever the implementator chooses. Then, the selection by an trailing ".link.notDNS" could remain the only possibility for an application to have any influence on the order of the search methods - unless there won't be introduced some configurations parameter, set for example in /etc/resolv.conf. ".link.notDNS" could be included in the DNS resolver's search list; only if BIND would apply to all names with this appendix a local name resolution first, the ordering of the methods could be controlled by such an entry in the search list in resolv.conf (ending in something like DNSorLINK/LOCAL). Other systems make use of the various kinds of name resolution having respective libraries; the methods the system administrator wants to make available, are listed in a file like /etc/netconfig - controlling by the list order the setting of the search order, too. Sites may use BIND only for DNS queries, having other libraries for statical searches. Where and how do you plan to integrate the new resolution method? (Sorry for delving into such implementation details! Although commenting a draft, for me it's not too bad to take a glance at possible realizations with its consequences, now. At least in order to lighten the relations between BIND, DNS, LOCAL, LINK) >> So, what's about the often mentioned ambiguities? > >I've studied your cases and analysis, and gone through my own list of >what could happen. The potential for confusion arises when there is >a mix of systems on the link, some configured to use DNS and some not. >If the requesting system is also configured for DNS, the task is simpler >in that it has a default domain and possibly search lists to use. [...] All right, no problems when queries are with hostname or FQDN and answers from the local link are always with FQDN. But again, if BIND (DNS) really will be applied first (as you proposes), there will be no chance to detect any link local address, since the official DNS name already will be found within the DNS system. So, I assume the other search ordering (at least, this should work, too, so far as there are no strict rules). The only remaining difference I see to the conclusion out of my cases is in that you apply a default domain or a search list only after receipt of a response. This also should work fine (although that's not the way DNS queries are performed). Now, instead of comparing the FQDN, the queried host MUST send its FQDN - so far it has one. The advantage of your proposal is the searching host may receive some answers at once, with different domains appended; all of them can be stored. >[...] If >the requesting node is NOT configured for DNS, and has to choose from >multiple replies (e.g. jessica and jessica.A and jessica.B), then it >must use some other criteria. Possible tiebreakers include longest >response, largest TTL value, first received response, or others. In case of jessica and jessica.A your solution still works, since after applying the default domainname (here: "") the searching host sees jessica as FQDN and takes its response as the valid one. In case of jessica.A and jessica.B, tiebreakers like the mentioned are possible. But I think it would be advantageous for the user to know of the problem and therefore to present her the hosts in question; so, she can choose to which host to connect. Perhaps, this may be an implementation detail (again!); but, as mentioned, I think it's easier to consider feasible, somewhat concrete solutions, at least in the discussion. With all that, we made the quiet assumption that there aren't any other hosts with the same FQDN (modulo ".link.notDNS") outside the link, in the Internet world. If not, it would be difficult to define (or recommend) a "correct" order of the search methods and to avoid ambiguities. Therefore my perhaps somewhat neurotic insistence on that there should be nothing but real domain names (eventually with some appendix); to avoid the impression, that anyone can consider his or her link as privat and by this to create behind the shelter of ".link.notDNS" whatever domain names he or her likes. >> (6) Completition Of The Protocol >> -------------------------------- The opinions on that seem to depend on how we anticipate the future use of the new protocol and of the importance we think RfC1971 will gain over time. Again, the question list above reclaims attention; especially: how often a host will plug into the link? (mobile computing?); how many hosts we think on a link? >> In order to have an effective plug'n play protocol, it would be >advantageous >> that hosts plugging into the link not only announce themselves, but >> also have the possibility to learn quickly about their neighbours, in >> order to install a first database (what you named "dynamic storage for >> link local addresses"). > >I recognize that this might be desirable in some instances, but would >prefer not to institutionalize it. > If this isn't institutionalized, a host won't have any means to learn about all neighbours with one single query all at once (see below). >> I propose to let the hosts to interpret queries with address field >zero >> and host field zero as queries to all hosts on the link to announce >> themselves (perhaps answered by every host to the link local multicast > >> group; by this providing an oportunity for a general update of all >> databases on the link). [...] > >I don't think this would scale nicely at all. > What do you mean with this? Do you think in the following problems?: >> [...] Every host plugging into the link should send >> such a query. I don't see any problem with extensive net load provoked > >> by this: the entering to a link has to be performed by human beeings >and >> so it is within macroscopic times. > >If it was only done occasionally when a new system joined the link, it >might not be so bad. But consider the effect when thousands of nodes >reboot after a power hit. With "dynamic storage" I still think in a file, that will be updated dynamically. So, there will be no problem to restrict complete rebuild of the database (by means of the proposed general query) to those hosts that haven't any such database/file. Otherwise, there can be thought in other solutions, such as delays of own queries when receiving a request. So, I don't see any insolvable problem with this. But with this arises an interesting question: whether a link should be thought as possibly thousands of hosts; what is and what will be the frequent case? > >> (9) Security >> ------------ >> [...] > >The LAN is a common resource, and as such it assumes a certain amount >of trust amongst the users. If this trust is abused, then simple >mechanisms >such as this proposal are not appropriate for the environment, and the >linkname mechanism should be disabled. I suppose it's possible to >define >the use of this protocol in conjunction with IPsec, but that raises the >image of swatting flies with a sledgehammer. I agree with you completely in what you say about the LAN. Nevertheless, in the todays "culture" of passwords and similar restrictions, without having any limitations respective the security, the protocol may have difficulties to reach any popularity. It is not necessary to think in villains, but playing and experimenting natures are omnipresent. With thousands of hosts connected to one link, there won't remain much trust (even with a smaller number, say dozens). Following your recommendation, the link local address resolution must be disabled then, letting the link local addresses of little (or no?) use. But just in this case of very much hosts, advantages can be supposed easily if nameserver queries can be avoided for all on-link communication. Again, we end up with the question of the importance of this protocol and whether the link local addresses one day will become the common case. If so, this should not be limited from the beginning on by security shortages of the protocol for the name resolution. Therefore, I think its worth to propose (or at least to discuss) some security mechanism; indeed those that are somewhat more lightweight than a sledgehammer. >> (10) Status Of The Draft >> ------------------------ >> [...] With your explanation, I now better realize of how such a project starts and will be developed over time. Surely I would have made it similar and qualified my ideas first as experimental. But what's really important and is greatly appreciated is that, thanks to your efforts (and to the long list of IEEE hardware addresses you had to type), now there is a draft for this kind of name resolution! Thanks again for your detailed answer, Dan! Martin ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Feb 13 20:53:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA13238; Thu, 13 Feb 1997 20:52:37 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA13231; Thu, 13 Feb 1997 20:52:23 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA15267; Thu, 13 Feb 1997 20:52:47 -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 UAA13877 for ; Thu, 13 Feb 1997 20:52:47 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA07075; Thu, 13 Feb 1997 23:40:06 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14378; Thu, 13 Feb 1997 23:39:56 -0500 Message-Id: <9702140439.AA14378@wasted.zk3.dec.com> To: "Harrington, Dan" Cc: ipng@sunroof.eng.sun.com, "'Martin.Pabst@mch.sni.de'" Subject: (IPng 3045) Re: draft-ietf-ipngwg-linkname-01.txt In-Reply-To: Your message of "Thu, 06 Feb 97 11:25:23 EST." Date: Thu, 13 Feb 97 23:39:55 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3291 Dan, I think this is getting far to complicated for its worth. I believe most host vendors will support having a router on an interface and RA's will provide site-local addresses in the dentist office scenario or a DHCPv6 server. The link-local address is really intended for ND, ICMP, Addrconf, and configuration of the link via IPv6. But I do think being able to avoid the cut and paste of a link-local address would be nice and using names. I would like to suggest we remove the idea of a .link domain and just use a simple protocol to tell all about your LL name which would be no greater-than 30 characters and a two byte LL at the end. So an LL name would be: tobyLL jessicaLL harleydavidsonLL So a total of 32 characters. Your protocol could be used to do this (I have suggestion to the packet formats though below). The file the data is stored in should be the LLname. The LLname would be a cache only which would be gone with any system shutdown or reboot and never kept on disk. This will keep it fast and avoid yet another evil place to store "network addresses". Your protocol could be used as part of the addrconf modules on an implementation. The problems of duplicate names on the network exist but each system can recognize this problem and report the error on the link and leave resolution to the sysadmins if it happens. It also avoids messing with the resolver routines. But if we want this to work with various library routines we could add the LLname/address tuple to /etc/hosts then all the resolver routines for normal applications would find the name anyway. The only reason they would be in /etc/hosts is to circumvent the use of having any new DNS parts for this simple requirment. The LLcache when altered would also alter /etc/hosts. If the TTL for a cache expires they MUST remove those entrys from /etc/hosts. For systems that do not support /etc/hosts what ever they support as LOCAL for BIND would work. On your packets: : I suggest all we need is one packet format TYPE - 1 byte 1 = Advertisement 2 = Request 3 = Reply [for each type you can tell what by if LL Address and/or LL Name fields below exist in the simple UDP protocol] Values 4-??? Reserved. SEQUENCE NUMBER - 2 bytes RESERVED - 1 byte LENGTH - 2 bytes TTL - 2 bytes LL Address - 16 bytes LL Name - 32 bytes Multilink issues: I don't think this changes your text. Duplicate/Names/Addresses: Your text plus updates to /etc/host and the LL-Cache can see this on advertisements and report system error. Security: I agree with you. There is one case to consider, a rogue mobile node coming on the link. But I would claim this is deprecated to much greater problems for this network and stupidity at the site and they deserve to be violated in cyberspace brutally. I think unless we proceed towards this simple approach we will still be discussing it in 1999, and maybe even not have any running code. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Feb 14 08:02:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA13854; Fri, 14 Feb 1997 08:01:22 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA13847; Fri, 14 Feb 1997 08:01:10 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA17391; Fri, 14 Feb 1997 08:01:35 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA02211 for ; Fri, 14 Feb 1997 08:01:31 -0800 Received: by SNOOPY with Internet Mail Service (5.0.1389.3) id <01BC1A66.DD2A6220@SNOOPY>; Fri, 14 Feb 1997 11:04:35 -0500 Message-ID: From: "Harrington, Dan" To: "'bound@zk3.dec.com'" Cc: ipng@sunroof.eng.sun.com, "'Martin.Pabst@mch.sni.de'" Subject: (IPng 3046) Re: draft-ietf-ipngwg-linkname-01.txt Date: Fri, 14 Feb 1997 11:04:34 -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: 3988 Hi Jim, > I would like to suggest we remove the idea of a .link domain [...] I think we need to have some sort of tag, be it ".link" or "LL". The nice aspect of a pseudo-domain of .link is that it would be reserved by the IANA, and thus not subject to misinterpretation or accidental overlap with any other naming convention. (For example, what if there were a host called CliffordBALL...the "LL" tag would be ambiguous.) I've heard back from the IANA that they're not keen on the ".link" pseudo-TLD...hopefully we can work out something short and sweet. > Your protocol could be used to do this (I have suggestion to the packet > formats though below). The file the data is stored in should be the > LLname. The LLname would be a cache only which would be gone with any > system shutdown or reboot and never kept on disk. This will keep it fast > and avoid yet another evil place to store "network addresses". That is also my vision of how these names/addresses should be stored...but I'm confused by your references to /etc/hosts below... > The problems of duplicate names on the network exist but each system can > recognize this problem and report the error on the link and leave > resolution to the sysadmins if it happens. The feedback from the group (esp. at Montreal) was that they wanted this to work with duplicate names which were configured in separate subdomains. The example given was www.[x].foo.com, where there might be dozens of hosts responding to a query for "www". In my mind, if you've got a situation like that, and you're already using DNS, then using this linkname mechanism to get Link Local addresses is not vital. But folks wanted to see the problem dealt with, so I've tried to solve it. > It also avoids messing with the resolver routines. But if we want this > to work with various library routines we could add the LLname/address > tuple to /etc/hosts then all the resolver routines for normal > applications would find the name anyway. The only reason they would be > in /etc/hosts is to circumvent the use of having any new DNS parts for > this simple requirment. The LLcache when altered would also alter > /etc/hosts. If the TTL for a cache expires they MUST remove those > entrys from /etc/hosts. For systems that do not support /etc/hosts what > ever they support as LOCAL for BIND would work. This is the part that confuses me...a file like /etc/hosts is traditionally a static, manually configured file. The linkname data is meant to be dynamic. So I guess you could avoid touching the resolver routines at the cost of manipulating /etc/hosts directly, but I don't like that model myself. It is also nice to make this a discrete service for purposes of ordering your lookups. > I suggest all we need is one packet format > > TYPE - 1 byte > 1 = Advertisement > 2 = Request > 3 = Reply > [for each type you can tell what by if LL Address and/or LL Name > fields below exist in the simple UDP protocol] > Values 4-??? Reserved. Currently the Advertisement is used to reply to requests, so there are only two packet types now. The Request has two sub-types, so I suppose you could just give them each their own type, Request-Name and Request-Address. Or you could let it be driven off the data values as you suggest, but I'd rather have the protocol be explicit in terms of what it's asking for. > I think unless we proceed towards this simple approach we will still be > discussing it in 1999, and maybe even not have any running code. I'm hoping to get this nailed down by March, and then get on to coding...I don't want this to linger indefinitely, either. Thanks for the comments! 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 Fri Feb 14 08:22:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA13884; Fri, 14 Feb 1997 08:21:08 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA13877; Fri, 14 Feb 1997 08:20:57 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA20345; Fri, 14 Feb 1997 08:21:22 -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 IAA09766 for ; Fri, 14 Feb 1997 08:21:19 -0800 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA09145; Fri, 14 Feb 1997 10:48:14 -0500 (EST) Received: from usr401.zko.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA10676; Fri, 14 Feb 1997 10:48:10 -0500 Message-Id: <3.0.32.19970214104751.006c4b1c@netrix.lkg.dec.com> X-Sender: popmatt@netrix.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Fri, 14 Feb 1997 10:48:23 -0500 To: ipng@sunroof.eng.sun.com From: Matt Thomas Subject: (IPng 3047) inet_pton(AF_INET6, "10.0.0.1", buf) Cc: rstevens%kohala.com@inner.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1138 According to the basic api 07 draft: If the af argument is AF_INET6, then the function accepts a string in one of the standard IPv6 text forms defined in Section 2.2 of the addressing architecture specification [2]. A numeric IPv4 address (e.g. 1.2.3.4) is not one of the standard IPv6 text forms defined in rfc1884. However, it seems to me that inet_pton should return an IPv4 mapped address if supplied a numeric IPv4 address. Otherwise every IPv6 aware application will need to have extra code to deal with this case. Is it too late to modify the draft? -- Matt Thomas Internet: matt@lkg.dec.com UNIX Networking WWW URL: http://ftp.digital.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Feb 14 08:45:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA13900; Fri, 14 Feb 1997 08:44:11 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA13893; Fri, 14 Feb 1997 08:43:59 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA23928; Fri, 14 Feb 1997 08:44:23 -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 IAA18693 for ; Fri, 14 Feb 1997 08:44:09 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.5/8.7.3) with ESMTP id JAA02010; Fri, 14 Feb 1997 09:42:40 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id JAA09618; Fri, 14 Feb 1997 09:42:39 -0700 (MST) Message-Id: <199702141642.JAA09618@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Fri, 14 Feb 1997 09:42:39 -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.6 beta(3) 11/17/96) To: Matt Thomas , ipng@sunroof.eng.sun.com Subject: (IPng 3048) Re: inet_pton(AF_INET6, "10.0.0.1", buf) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1971 [In your message of Feb 14, 10:48am you write:] > According to the basic api 07 draft: > > If the af argument is AF_INET6, then the function accepts a string in > one of the standard IPv6 text forms defined in Section 2.2 of the > addressing architecture specification [2]. > > A numeric IPv4 address (e.g. 1.2.3.4) is not one of the standard IPv6 > text forms defined in rfc1884. > > However, it seems to me that inet_pton should return an IPv4 mapped > address if supplied a numeric IPv4 address. Otherwise every IPv6 aware > application will need to have extra code to deal with this case. > > Is it too late to modify the draft? I specifically use this feature, as follows: /* * Make certain that we can test the difference between 0.0.0.0 * being acceptable for AF_INET (but not acceptable for AF_INET6) * and 0::0 being OK for AF_INET6 (but not OK for AF_INET). * This way a server can be coded as protocol independent (IPv4 or * IPv6) but let the user specify the local IP address as either * 0.0.0.0 or 0::0 as an indirect way of telling the server when * it starts, which protocol to use (but still allowing the server * to bind the wildcard address). */ And I see that the BIND releases that support inet_pton() [>= 4.9.4] do not accept dotted-decimal notation if AF_INET6 is specified. I think your scenario is a problem only for programs that specifically handle either an IP address or a domain name. They have to change the code from inet_addr() to inet_pton() anyway, so perhaps they should just change to getaddrinfo() to simplify their code. So I don't think we should make the change. 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 Fri Feb 14 08:59:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA13916; Fri, 14 Feb 1997 08:58:36 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA13909; Fri, 14 Feb 1997 08:58:24 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA26748; Fri, 14 Feb 1997 08:58:49 -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 IAA24671 for ; Fri, 14 Feb 1997 08:58:48 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA09194; Fri, 14 Feb 1997 11:44:45 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA20954; Fri, 14 Feb 1997 11:44:53 -0500 Message-Id: <9702141644.AA20954@wasted.zk3.dec.com> To: "Harrington, Dan" Cc: ipng@sunroof.eng.sun.com, "'Martin.Pabst@mch.sni.de'" Subject: (IPng 3049) Re: draft-ietf-ipngwg-linkname-01.txt In-Reply-To: Your message of "Fri, 14 Feb 97 11:04:34 EST." Date: Fri, 14 Feb 97 11:44:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 7346 Dan, >I think we need to have some sort of tag, be it ".link" >or "LL". The nice aspect of a pseudo-domain of .link is >that it would be reserved by the IANA, and thus not subject >to misinterpretation or accidental overlap with any other >naming convention. (For example, what if there were a host >called CliffordBALL...the "LL" tag would be ambiguous.) I don't think so. No. it would be CliffordBaLLLL. >I've heard back from the IANA that they're not keen on the >".link" pseudo-TLD...hopefully we can work out something short >and sweet. I agree with IANA. >> Your protocol could be used to do this (I have suggestion to the >packet >> formats though below). The file the data is stored in should be the >> LLname. The LLname would be a cache only which would be gone with any >> system shutdown or reboot and never kept on disk. This will keep it >fast >> and avoid yet another evil place to store "network addresses". >That is also my vision of how these names/addresses should be >stored...but I'm confused by your references to /etc/hosts below... I will respond below. >> The problems of duplicate names on the network exist but each system >can >> recognize this problem and report the error on the link and leave >> resolution to the sysadmins if it happens. >The feedback from the group (esp. at Montreal) was that they >wanted this to work with duplicate names which were configured >in separate subdomains. The example given was www.[x].foo.com, >where there might be dozens of hosts responding to a query >for "www". In my mind, if you've got a situation like that, >and you're already using DNS, then using this linkname mechanism >to get Link Local addresses is not vital. But folks wanted to >see the problem dealt with, so I've tried to solve it. Well I would like to readdress it with the group. The names should not have anything to do with DNS. DNS already has to many records. THat is why I proposed the LLname. If the node has a valid www AAAA record address in the DNS on the link it don't need the LLname. We need to permit common sense to enter the engineering trade-off discussion for this and I would like to inject that common sense part to this discussion and see what the response is. >> It also avoids messing with the resolver routines. But if we want >this >> to work with various library routines we could add the LLname/address >> tuple to /etc/hosts then all the resolver routines for normal >> applications would find the name anyway. The only reason they would >be >> in /etc/hosts is to circumvent the use of having any new DNS parts for >> this simple requirment. The LLcache when altered would also alter >> /etc/hosts. If the TTL for a cache expires they MUST remove those >> entrys from /etc/hosts. For systems that do not support /etc/hosts >what >> ever they support as LOCAL for BIND would work. >This is the part that confuses me...a file like /etc/hosts >is traditionally a static, manually configured file. The >linkname data is meant to be dynamic. So I guess you could >avoid touching the resolver routines at the cost of manipulating >/etc/hosts directly, but I don't like that model myself. It >is also nice to make this a discrete service for purposes of >ordering your lookups. Well I like that model and would like the group to hear it for these reasons: 1. Adding an additional search to the libraries associated with locating a name (or and address which is an optimization of gethosbyname2 (if you look at that code check out "isdigit" function). This puts an entire additional amount of work to these library routines and should not be decided lightly. I am in this code daily because of Dyn Upd to DNS and integration with addr conf and DHCPv6. We need to be careful what we do here to implementations. FOr what is not a showstopper in the scheme of things for IPv6. )---> you have key in a LL address. That is all that is driving this effort. 2. It is a discrete service and you did not comment on my suggestion of the LLname cache. The /etc/host update is not a big deal it is a simple read and write and for the intensity of the LL address/naming requirement I think its just fine. So emphatically disagree with you that this is even a problem or complex. Its simple actually. It also avoids changing any of syntax or semantics of addrlib.c, gethnamaddr.c, etc.... Which again should not be changed lightly. >> I suggest all we need is one packet format >> >> TYPE - 1 byte >> 1 = Advertisement >> 2 = Request >> 3 = Reply >> [for each type you can tell what by if LL Address and/or LL Name >> fields below exist in the simple UDP protocol] >> Values 4-??? Reserved. >Currently the Advertisement is used to reply to requests, >so there are only two packet types now. The Request has >two sub-types, so I suppose you could just give them each >their own type, Request-Name and Request-Address. Or you >could let it be driven off the data values as you suggest, >but I'd rather have the protocol be explicit in terms of >what it's asking for. Well I disagree with you and I believe that whenever protocol design can overload the classification of a packet it is superior to discrete additional components for clarity. I really believe most computer science problems can be solved by another level of indirection. That is what I am essentially proposing over your scheme presently. It also makes writing the code much simpler and reuse of the routines to process the packet more likely. So I guess I would like to get others comments on this too. ALso in your present scheme the length field is not big enough (8 bits) because a FQDN can be 255 bytes. >> I think unless we proceed towards this simple approach we will still >be >> discussing it in 1999, and maybe even not have any running code. > >I'm hoping to get this nailed down by March, and then get >on to coding...I don't want this to linger indefinitely, either. I don't think you will get consensus on the .link domain being coordinated with the resolver softwarwe on this list by March at all. I have some other comments I will send to you on editing and nomenclature on the draft off line. Also not everyone that joined this list may know what the "dentist" office scenario is and it might be good to put it in an appendix of your draft. As you use it as an example where this is important too and I agree it is. But it should be documented for others. If we go with a scheme thtat does not affect the resolver routines it could be coded in 3 person days and running. How implementors do the LLcache and integrate with addrconf is up to them. But if we go with an affect the resolve routines and a .link domain then Martin's mail becomes very critical regarding the DNS and I think just the beginning of the discussion and March will be impossible I think. I also have not seen a response to Martin's last mail? /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 Sat Feb 15 12:35:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA15239; Sat, 15 Feb 1997 12:33:53 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA15232; Sat, 15 Feb 1997 12:33:37 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA19509; Sat, 15 Feb 1997 12:34:01 -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 MAA05365 for ; Sat, 15 Feb 1997 12:34:02 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.5/8.7.3) with ESMTP id NAA04769 for ; Sat, 15 Feb 1997 13:34:01 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id NAA12064 for ipng@sunroof.Eng.Sun.COM; Sat, 15 Feb 1997 13:34:00 -0700 (MST) Message-Id: <199702152034.NAA12064@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Sat, 15 Feb 1997 13:34:00 -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.6 beta(3) 11/17/96) To: ipng@sunroof.eng.sun.com Subject: (IPng 3050) updated I-D: Advanced Sockets API for IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4219 A new version of the "Advanced Sockets API for IPv6" was just submitted and should appear in the normal I-D locations within a few days. You can also grab a copy now from ftp://ftp.kohala.com/pub/rstevens/draft-stevens-advanced-api-01.txt I've attached the list of changes from the previous -00 version. We would like to resolve any outstanding issues before the next IETF in April, if possible, so we'd appreciate any comments in the next 4 weeks or so. Thanks, Rich Stevens ----------------------------------------------------------------------- Changes from the October 1996 Edition (-00 draft) - Numerous rationale added using the format (Note: ...). - Added note that not all errors may be defined. - Added note about ICMPv4, IGMPv4, and ARPv4 terminology. - Changed the name of to . - Change some names in Section 2.2.1: ICMPV6_PKT_TOOBIG to ICMPV6_PACKET_TOOBIG, ICMPV6_TIME_EXCEED to ICMPV6_TIME_EXCEEDED, ICMPV6_ECHORQST to ICMPV6_ECHOREQUEST, ICMPV6_ECHORPLY to ICMPV6_ECHOREPLY, ICMPV6_PARAMPROB_HDR to ICMPV6_PARAMPROB_HEADER, ICMPV6_PARAMPROB_NXT_HDR to ICMPV6_PARAMPROB_NEXTHEADER, and ICMPV6_PARAMPROB_OPTS to ICMPV6_PARAMPROB_OPTION. - Prepend the prefix "icmp6_" to the three members of the icmp6_dataun union of the icmp6hdr structure (Section 2.2). - Moved the neighbor discovery definitions into the header, instead of being in their own header (Section 2.2.1). - Changed Section 2.3 ("Address Testing"). The basic macros are now in the basic API. - Added the new Section 2.4 on "Protocols File". - Added note to raw sockets description that something like BPF or DLPI must be used to read or write entire IPv6 packets. - Corrected example of IPV6_CHECKSUM socket option (Section 3.1). Also defined value of -1 to disable. - Noted that defines all the ICMPv6 filtering constants, macros, and structures (Section 3.2). - Added note on magic number 10240 for amount of ancillary data (Section 4.1). - Added possible padding to picture of ancillary data (Section 4.2). - Defined header for CMSG_xxx() functions (Section 4.2). - Note that the data returned by getsockopt(IPV6_PKTOPTIONS) for a TCP socket is just from the optional headers, if present, of the most recently received segment. Also note that control information is never returned by recvmsg() for a TCP socket. - Changed header for struct in6_pktinfo from to (Section 5). - Removed the old Sections 5.1 and 5.2, because the interface identification functions went into the basic API. - Redid Section 5 to support the hop limit field. - New Section 5.4 ("Next Hop Address"). - New Section 6 ("Flow Labels"). - Changed all of Sections 7 and 8 dealing with Hop-by-Hop and Destination options. We now define a set of inet6_option_XXX() functions. - Changed header for IPV6_SRCRT_xxx constants from to (Section 9). - Add inet6_srcrt_lasthop() function, and fix errors in description of source routing (Section 9). - Reworded some of the source routing descriptions to conform to the terminology in [1]. - Added the example from [1] for the Routing header (Section 9.9). - Expanded the example in Section 10 to show multiple options per ancillary data object, and to show the receiver's ancillary data objects. - New Section 11 ("IPv6-Specific Options with IPv4-Mapped IPv6 Addresses"). - New Section 12 ("rresvport_af"). - Redid old Section 10 ("Additional Items") into new Section 13 ("Future Items"). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 17 05:50:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA16838; Mon, 17 Feb 1997 05:49:21 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA16831; Mon, 17 Feb 1997 05:49:03 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA03054; Mon, 17 Feb 1997 05:49:27 -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 FAA29629 for ; Mon, 17 Feb 1997 05:49:29 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA25501; Mon, 17 Feb 1997 08:42:37 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA01673; Mon, 17 Feb 1997 08:42:35 -0500 Message-Id: <9702171342.AA01673@wasted.zk3.dec.com> To: "W. Richard Stevens" Cc: Matt Thomas , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 3051) Re: inet_pton(AF_INET6, "10.0.0.1", buf) In-Reply-To: Your message of "Fri, 14 Feb 97 09:42:39 MST." <199702141642.JAA09618@kohala.kohala.com> Date: Mon, 17 Feb 97 08:42:34 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4363 Richard, >> According to the basic api 07 draft: >> >> If the af argument is AF_INET6, then the function accepts a string in >> one of the standard IPv6 text forms defined in Section 2.2 of the >> addressing architecture specification [2]. >> >> A numeric IPv4 address (e.g. 1.2.3.4) is not one of the standard IPv6 >> text forms defined in rfc1884. >> >> However, it seems to me that inet_pton should return an IPv4 mapped >> address if supplied a numeric IPv4 address. Otherwise every IPv6 aware >> application will need to have extra code to deal with this case. >> >> Is it too late to modify the draft? >I specifically use this feature, as follows: > > /* > * Make certain that we can test the difference between 0.0.0.0 > * being acceptable for AF_INET (but not acceptable for AF_INET6) > * and 0::0 being OK for AF_INET6 (but not OK for AF_INET). > * This way a server can be coded as protocol independent (IPv4 or > * IPv6) but let the user specify the local IP address as either > * 0.0.0.0 or 0::0 as an indirect way of telling the server when > * it starts, which protocol to use (but still allowing the server > * to bind the wildcard address). > */ > >And I see that the BIND releases that support inet_pton() [>= 4.9.4] >do not accept dotted-decimal notation if AF_INET6 is specified. > >I think your scenario is a problem only for programs that specifically >handle either an IP address or a domain name. They have to change the >code from inet_addr() to inet_pton() anyway, so perhaps they should just >change to getaddrinfo() to simplify their code. I think that is an extreme answer and don't agree with it as one of the co-authors. Also as one who is writing code in this space and delivering it to my users who are running it "live" not as an academic exercise (maybe as a 6bone exercise). I think what Matt suggests is a good optimization for the interoperation of IPv4 and IPv6 at the API. I don't see the harm with what Matt suggests. I have accomplished the same objective with alteration to gethnamaddr.c, but Matt's approach removes an extra conditon and eliminates lines of code. But I realize too we want to put this API spec to bed as an informational RFC and turn it over to standards bodies that formally do APIs like X/Open Group, which we don't do in the IETF. This is just one issue we will need to resolve for IPv4 and IPv6 interoperation. Here is another one I just ran into: Premises: Site has deployed IPv6: Host dooby.duh.org: Has A record 1.2.3.4 Has AAAA record 1::2 Telnet Server has been ported to use IPv4 or IPv6 FTP Server Dameon still only does IPv4 Host dowdy.duh.org: Has A record 1.2.3.5 Has AAAA record 1::3 Telnet client has been ported to use IPv4 or IPv6 FTP Client has been ported to use IPv4 or IPv6 dowdy wants to establish a telnet session to dooby. It first looks for IPv6 AAAA records in the spirit of moving to IPv6. dowdy gets back 1::2. It connects to dooby all works fine. dowdy wants to to the same with FTP. It looks for dooby again and trys to connect using 1::2. But dowdy gets connection refused. dooby can't communicate with IPv6 addresses. One way to resolve this is for dowdy to get back not just AAAA records but also A records for a node. This would be a change to gethostent struct or the applications would need to build their own structure. I have found other problems like this that will occur and that are subtle and not obvious until you start to think about real deployment. In many cases each vendor will provide a work around. But library routines that can do the robust thing as Matt has requested will guarantee that some of these problems can be coded for (as he addressed the IPv4 Mapped address in his mail to you). WHat we may need to do is develop a list of all these change types and then address them in a future info RFC or just do it in X/Open who is starting work on IPv6 APIs this spring. But I think Matt's suggestion is completely valid and does no harm at all. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Feb 17 08:08:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17014; Mon, 17 Feb 1997 08:07:36 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17000; Mon, 17 Feb 1997 08:06:56 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA15960; Mon, 17 Feb 1997 08:07:21 -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 IAA03746; Mon, 17 Feb 1997 08:07:13 -0800 Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by mailhub.axion.bt.co.uk with SMTP (PP); Mon, 17 Feb 1997 16:06:09 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA07322; Mon, 17 Feb 1997 16:02:01 GMT Date: Mon, 17 Feb 1997 16:02:01 +0000 (GMT) From: George Tsirtsis To: ipng@sunroof.eng.sun.com Cc: ngtrans Subject: (IPng 3052) NAT box and Protocol Translator Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 7061 Dear all We put down some old and some new thoughts about the possible use of NAT boxes and Protocol Translators in the transition period from IPv4 to IPv6. Please comment as appropriate. Regards George Tsirtsis -------------------------------------------------------------------------- Network Research Tel : 0044-1473-640756 BT Labs Fax : 0044-1473-640709 Ipswich e-mail: george@gideon.bt.co.uk -------------------------------------------------------------------------- NAT box & Protocol Translator ----------------------------- by Alan O'Neill and George Tsirtsis Summary This document proposes the use of a combined NAT box and Protocol Translator (PT) (NAT-PT) to allow communication between IPv6 and IPv4 hosts. Each time a host migrates to IPv6 it can 'donate' its IPv4 address to the local NAT-PT. In this way allocation of new IPv4 addresses can be minimised while the current aggregation capability of IPv4 network can be sustained. It is also explained how a host outside the NAT box can invoke communication with a host inside the NAT box. NAT box When the allocated addresses are less than the hosts required to be connected to the global Internet, a NAT box can dynamically allocate a unique address to a host. Another, very important characteristic of the NAT box is that it isolates the hosts that are situated behind it because, the global IP address is dynamically allocated to a host for the duration of a particular session. This means that a host outside the NAT box can not know the address of any host inside the NAT box. Protocol Translator (PT) A protocol translator adapts the requirements of one protocol, expressed by its header, to the requirements of another protocol and its corresponding header. Network Address Translator - Protocol Translator (NAT-PT) -------------------------------------------------------- Outgoing Communication NAT-PT combines the functionality of a Protocol Translator with that of a NAT box. When a IPv6 packet internal to NAT-PT has to go to the global Internet, the Protocol Translator (PT) will translate the IPv6 header to an IPv4 header and the NAT box will change the IPv6 source address to a dynamically allocated IPv4 address. This IPv4 address will be one of a small number of IPv4 addresses allocated to the particular site. That will not be a problem, since the IPv4 addresses can be assigned to the NAT-PT for dynamic allocation when an IPv4 host upgrades to IPv6. In this way there will be no need for allocation of new IPv4 addresses The Destination Address of the original (IPv6) packet has to be an IPv4 compatible IPv6 address. IPv6 has to be able to recognise IPv4 addresses, when a DNS request returns an IPv4 address, and to convert them to suitable IPv6 form (IPv4 compatible IPv6). Incoming communication This is not as easy as the outgoing communication One way to tackle this is described here: 1.we assume for clarity that only one host (host1.uk) is inside NAT-PT 2.host1.uk only has IPv6 addresses. 3.NAT dynamically allocates IPv4 addresses to the IPv6 host1.uk for incoming communications 4.PT translates the IPv6 header to IPv4 header and vice versa. 5.Host.com is an external, to NAT-PT, IPv4 host The IPv4 host could find out which is the IPv4 address of the IPv6 hosts in the following way: 1.Host.com makes a DNS query for the IP(v4) address of host1.uk in order to invoke a connection with it; note that the naming of hosts is common in IPv4 and IPv6. 2.The local DNS server does not have the address and passes the query to another DNS server "closer" to the destination; 3.Some DNS is eventually connected to the NAT-PT and passes the query to it; 4.The NAT dynamically allocates an IPv4 address to host1.uk and returns this address as reply to the query; 5.Communication now can start between Host.com and host1.uk using IPv4 addresses. PT will now have to translate the headers from IPv4 to IPv6 and vice versa. NOTE: It should be noted that the above rational seems to work for the NAT boxes as used in IPv4 as well, to permit (v4) hosts outside the NAT box to invoke communication to (v4) hosts inside the NAT box. a. One obvious problem is that DNS is working with a lot of caching. This means that the first time that the above procedure will take place all intermediate DNS servers will cache the IPv4 address which is going to be invalid after the end of this session. DNS, however, has a Time To Live (TTL) field that can be assigned for a domain at its primary DNS server. TTL could be zero (for no caching at all) or could have the average time of a session. For servers you could have semi-permanent (IPv4) addresses. Can DNS's TTL be used in this way ? Is there any other way of doing this? b. Another potential problem is that NAT-PT has to operate as DNS. What are the implications of that? c. It is also obvious that we will have an increase in the amount of DNS traffic, because of the limited caching. What are the scaling limitations of such a traffic and does DNSind mechanisms solve/contain it? Protocol Translation Protocol Translation has well known problems, like performance and functionality problems. Note that no IPv6 functionality is lost due to PT because, this is used for communication with IPv4 host and only IPv4 functionality is required. Are there any other implications? Is the performance hit bearable? Usability and limitations The NAT-PT appears to be ideal for private networks that need to use the advanced features of IPv6, like Stateless Autoconfiguration, Neighbour Discovery, Security and Flow Labels, without loosing their connectivity with the IPv4 based Internet. NAT-PT is only required for interoperation and will therefore be a transient feature of the internet until everyone has transitioned to IPv6. During transition the cost / overhead of NAT-PT will first be incurred by IPv6 users, then ISPs, then backbones and finally the remaining IPv4 islands The major issue, however, is the scalability of such an architecture when the IPv6 island become very big and the NAT-PTs move to the backbone. Has this been looked at / quantified? _____________________________________________________________________ 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@sunroof.eng.sun.com Mon Feb 17 10:53:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA17310; Mon, 17 Feb 1997 10:52:50 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA17303; Mon, 17 Feb 1997 10:52:34 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA03563; Mon, 17 Feb 1997 10:53:01 -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 KAA18965 for ; Mon, 17 Feb 1997 10:53:02 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.5/8.7.3) with ESMTP id LAA07773; Mon, 17 Feb 1997 11:52:58 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id LAA16161; Mon, 17 Feb 1997 11:52:58 -0700 (MST) Message-Id: <199702171852.LAA16161@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Mon, 17 Feb 1997 11:52:58 -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.6 beta(3) 11/17/96) To: bound@zk3.dec.com Subject: (IPng 3056) Re: inet_pton(AF_INET6, "10.0.0.1", buf) Cc: Matt Thomas , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3516 [In your message of Feb 17, 8:42am you write:] > Here is another one I just ran into: > > Premises: Site has deployed IPv6: > > Host dooby.duh.org: > Has A record 1.2.3.4 > Has AAAA record 1::2 > Telnet Server has been ported to use IPv4 or IPv6 > FTP Server Dameon still only does IPv4 > > Host dowdy.duh.org: > Has A record 1.2.3.5 > Has AAAA record 1::3 > Telnet client has been ported to use IPv4 or IPv6 > FTP Client has been ported to use IPv4 or IPv6 > > dowdy wants to establish a telnet session to dooby. It first looks for > IPv6 AAAA records in the spirit of moving to IPv6. dowdy gets back > 1::2. It connects to dooby all works fine. > > dowdy wants to to the same with FTP. It looks for dooby again and trys > to connect using 1::2. But dowdy gets connection refused. dooby can't > communicate with IPv6 addresses. > > One way to resolve this is for dowdy to get back not just AAAA records > but also A records for a node. This would be a change to gethostent > struct or the applications would need to build their own structure. I'll put on my getaddrinfo() hat again ... :-) The hostent{} can only return one type of address, even though it can return multiple addresses of that one type. If we change the hostent{} then it's not backward compatible to the hostent{} that everyone uses today. But look at the addrinfo{}: not only can it return multiple addresses, but each one can have its own type. Searching for both AAAA records and A records could easily be hidden in getaddrinfo(), preventing any changes to the resolver. The client code becomes quite simple: int sockfd, n; struct addrinfo hints, *res, *ressave; bzero(&hints, sizeof(struct addrinfo)); hints.ai_socktype = SOCK_STREAM; if ( (n = getaddrinfo(host, serv, &hints, &res)) != 0) return(-n); /* assumes EAI_xxx are all positive */ ressave = res; do { sockfd = Socket(res->ai_family, res->ai_socktype, res->ai_protocol); if (connect(sockfd, res->ai_addr, res->ai_addrlen) == 0) break; /* success */ Close(sockfd); } while ( (res = res->ai_next) != NULL); freeaddrinfo(ressave); if (res == NULL) /* errno should be set from final connect() */ return(-999); /* assumes 999 is not a valid EAI_xxx value */ return(sockfd); It does require changing the client a little (but I assume you're doing that already just to support IPv6 sockets), but I've got to believe that the 25 lines of code above are simpler than coding the client to call inet_pton(), then gethostbyname() if that fails, then dealing with some new hostent{}. > I have found other problems like this that will occur and that are > subtle and not obvious until you start to think about real deployment. > In many cases each vendor will provide a work around. It would sure be nice to come up with a generic solution, so every vendor doesn't have to do this. I really think getaddrinfo() is a good move in that direction. I think Craig Metz has been using it extensively as he ports applications to IPv6. I guess I'd like to know just what scenarios getaddrinfo() cannot be used in, and why? 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 Mon Feb 17 13:02:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA17500; Mon, 17 Feb 1997 13:01:06 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA17486; Mon, 17 Feb 1997 13:00:23 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA23074; Mon, 17 Feb 1997 13:00:49 -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 NAA20794; Mon, 17 Feb 1997 13:00:51 -0800 Received: from big-dogs.cisco.com (sj-dial-3-24.cisco.com [171.68.179.25]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id NAA25904; Mon, 17 Feb 1997 13:00:32 -0800 (PST) Message-Id: <3.0.32.19970217152826.00698b20@lint.cisco.com> X-Sender: pferguso@lint.cisco.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 17 Feb 1997 16:00:31 -0500 To: George Tsirtsis From: Paul Ferguson Subject: (IPng 3057) Re: NAT box and Protocol Translator Cc: ipng@sunroof.eng.sun.com, ngtrans Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 7256 I always thought that it was somewhat shortsighted to not have mentioned this as a possibility within NG Trans; running dual v4/v6 stacks is not an always a practical methodology. Having said that, is it appropriate for the IPng WG to go into any amount of detail on how v4 <---> v6 translation could be done, or would it more appropriate to simply document the feasibility? Food for thought. - paul At 04:02 PM 2/17/97 +0000, George Tsirtsis wrote: > >Dear all > >We put down some old and some new thoughts about the possible use of >NAT boxes and Protocol Translators in the transition period from IPv4 to >IPv6. Please comment as appropriate. > >Regards >George Tsirtsis >-------------------------------------------------------------------------- >Network Research Tel : 0044-1473-640756 >BT Labs Fax : 0044-1473-640709 >Ipswich e-mail: george@gideon.bt.co.uk >-------------------------------------------------------------------------- > > > > > NAT box & Protocol Translator > ----------------------------- > by Alan O'Neill and George Tsirtsis > > >Summary > >This document proposes the use of a combined NAT box and Protocol >Translator (PT) (NAT-PT) to allow communication between IPv6 and IPv4 >hosts. Each time a host migrates to IPv6 it can 'donate' its IPv4 >address to the local NAT-PT. In this way allocation of new IPv4 addresses >can be minimised while the current aggregation capability of IPv4 >network can be sustained. It is also explained how a host outside the >NAT box can invoke communication with a host inside the NAT box. > > >NAT box > >When the allocated addresses are less than the hosts required to be >connected to the global Internet, a NAT box can dynamically allocate a >unique address to a host. >Another, very important characteristic of the NAT box is that it isolates >the hosts that are situated behind it because, the global IP address is >dynamically allocated to a host for the duration of a particular session. >This means that a host outside the NAT box can not know the address of >any host inside the NAT box. > > >Protocol Translator (PT) > >A protocol translator adapts the requirements of one protocol, expressed >by its header, to the requirements of another protocol and its >corresponding header. > > Network Address Translator - Protocol Translator (NAT-PT) > -------------------------------------------------------- > >Outgoing Communication > >NAT-PT combines the functionality of a Protocol Translator with that >of a NAT box. > >When a IPv6 packet internal to NAT-PT has to go to the global Internet, >the Protocol Translator (PT) will translate the IPv6 header to an IPv4 >header and the NAT box will change the IPv6 source address to a >dynamically allocated IPv4 address. This IPv4 address will be one of a >small number of IPv4 addresses allocated to the particular site. That >will not be a problem, since the IPv4 addresses can be assigned to the >NAT-PT for dynamic allocation when an IPv4 host upgrades to IPv6. >In this way there will be no need for allocation of new IPv4 addresses > >The Destination Address of the original (IPv6) packet has to be an IPv4 >compatible IPv6 address. >IPv6 has to be able to recognise IPv4 addresses, when a DNS request >returns an IPv4 address, and to convert them to suitable IPv6 form (IPv4 >compatible IPv6). > > >Incoming communication > >This is not as easy as the outgoing communication >One way to tackle this is described here: >1.we assume for clarity that only one host (host1.uk) is inside NAT-PT >2.host1.uk only has IPv6 addresses. >3.NAT dynamically allocates IPv4 addresses to the IPv6 host1.uk for >incoming communications >4.PT translates the IPv6 header to IPv4 header and vice versa. >5.Host.com is an external, to NAT-PT, IPv4 host > >The IPv4 host could find out which is the IPv4 address >of the IPv6 hosts in the following way: > >1.Host.com makes a DNS query for the IP(v4) address of host1.uk in >order to invoke a connection with it; note that the naming of hosts is >common >in IPv4 and IPv6. >2.The local DNS server does not have the address and passes the query to >another DNS server "closer" to the destination; >3.Some DNS is eventually connected to the NAT-PT and passes the >query to it; >4.The NAT dynamically allocates an IPv4 address to host1.uk >and returns this address as reply to the query; >5.Communication now can start between Host.com and host1.uk using IPv4 >addresses. PT will now have to translate the headers from IPv4 to IPv6 >and vice versa. > >NOTE: It should be noted that the above rational seems to work for the >NAT boxes as used in IPv4 as well, to permit (v4) hosts outside the NAT >box to invoke communication to (v4) hosts inside the NAT box. > >a. One obvious problem is that DNS is working with a lot of caching. This >means that the first time that the above procedure will take place all >intermediate DNS servers will cache the IPv4 address which is going to be >invalid after the end of this session. DNS, however, has a Time To Live >(TTL) field that can be assigned for a domain at its primary DNS server. >TTL could be zero (for no caching at all) or could have the average time >of a session. For servers you could have semi-permanent (IPv4) addresses. >Can DNS's TTL be used in this way ? Is there any other way of doing this? > >b. Another potential problem is that NAT-PT has to operate as DNS. What >are the implications of that? > >c. It is also obvious that we will have an increase in the amount of DNS >traffic, because of the limited caching. What are the scaling limitations >of such a traffic and does DNSind mechanisms solve/contain it? > > >Protocol Translation > >Protocol Translation has well known problems, like performance and >functionality problems. > >Note that no IPv6 functionality is lost due to PT because, this is used >for communication with IPv4 host and only IPv4 functionality is required. >Are there any other implications? Is the performance hit bearable? > >Usability and limitations > >The NAT-PT appears to be ideal for private networks that need to use >the advanced features of IPv6, like Stateless Autoconfiguration, >Neighbour Discovery, Security and Flow Labels, without loosing their >connectivity with the IPv4 based Internet. > >NAT-PT is only required for interoperation and will therefore be a >transient feature of the internet until everyone has transitioned to IPv6. >During transition the cost / overhead of NAT-PT will first be incurred by >IPv6 users, then ISPs, then backbones and finally the remaining IPv4 >islands > >The major issue, however, is the scalability of such an >architecture when the IPv6 island become very big and the NAT-PTs >move to the backbone. Has this been looked at / quantified? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 17 15:06:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA17708; Mon, 17 Feb 1997 15:05:38 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA17694; Mon, 17 Feb 1997 15:04:26 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA12673; Mon, 17 Feb 1997 15:04:52 -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 PAA16376; Mon, 17 Feb 1997 15:04:53 -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 PAA13743; Mon, 17 Feb 1997 15:04:22 -0800 Message-Id: <3.0.1.32.19970217150306.00f5abd4@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 17 Feb 1997 15:03:06 -0800 To: Paul Ferguson From: Bob Hinden Subject: (IPng 3058) Re: NAT box and Protocol Translator Cc: ipng@sunroof.eng.sun.com, ngtrans In-Reply-To: <3.0.32.19970217152826.00698b20@lint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1240 Paul, >I always thought that it was somewhat shortsighted to >not have mentioned this as a possibility within NG Trans; >running dual v4/v6 stacks is not an always a practical >methodology. I recollect that it was done to create more focus in the ngtrans working group. The original proposal to the IPng directorate included IPv4<->IPv6 translation. My personal opinion is that translators allowing an IPv6-only organization to talk to an IPv4 internet would turn out to be very interesting. >Having said that, is it appropriate for the IPng WG to go >into any amount of detail on how v4 <---> v6 translation >could be done, or would it more appropriate to simply >document the feasibility? Food for thought. I don't think the IPng working group should work on this, but I think it is very appropriate for the ngtrans working group to take this on. Bob p.s. I suggest that this thread be moved to the ngtrans list (e.g., not both ipng and ngtrans). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 17 18:13:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA18309; Mon, 17 Feb 1997 18:12:24 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA18302; Mon, 17 Feb 1997 18:12:12 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA02068; Mon, 17 Feb 1997 18:12:38 -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 SAA24949 for ; Mon, 17 Feb 1997 18:12:39 -0800 Received: from bwasted.zk3.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA23699; Mon, 17 Feb 1997 18:07:49 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA32380; Mon, 17 Feb 1997 21:04:01 -0500 Message-Id: <9702180204.AA32380@wasted.zk3.dec.com> To: "W. Richard Stevens" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3059) Re: inet_pton(AF_INET6, "10.0.0.1", buf) In-Reply-To: Your message of "Mon, 17 Feb 97 11:52:58 MST." <199702171852.LAA16161@kohala.kohala.com> Date: Mon, 17 Feb 97 21:04:01 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4180 Richard, >> One way to resolve this is for dowdy to get back not just AAAA records >> but also A records for a node. This would be a change to gethostent >> struct or the applications would need to build their own structure. >I'll put on my getaddrinfo() hat again ... :-) >But look at the addrinfo{}: not only can it return multiple addresses, >but each one can have its own type. Searching for both AAAA records >and A records could easily be hidden in getaddrinfo(), preventing any >changes to the resolver. The client code becomes quite simple: int sockfd, n; struct addrinfo hints, *res, *ressave; bzero(&hints, sizeof(struct addrinfo)); hints.ai_socktype = SOCK_STREAM; if ( (n = getaddrinfo(host, serv, &hints, &res)) != 0) return(-n); /* assumes EAI_xxx are all positive */ ressave = res; do { sockfd = Socket(res->ai_family, res->ai_socktype, res->ai_protocol); if (connect(sockfd, res->ai_addr, res->ai_addrlen) == 0) break; /* success */ Close(sockfd); } while ( (res = res->ai_next) != NULL); freeaddrinfo(ressave); if (res == NULL) /* errno should be set from final connect() */ return(-999); /* assumes 999 is not a valid EAI_xxx value */ return(sockfd); >It does require changing the client a little (but I assume you're doing >that already just to support IPv6 sockets), but I've got to believe that >the 25 lines of code above are simpler than coding the client to call >inet_pton(), then gethostbyname() if that fails, then dealing with some >new hostent{}. Very elegant. Yes putting a wrapper inside getaddrinfo() would be not difficult. But the code just exists elsewhere nothing is gained. The question is buying into getaddrinfo() as a programmer working on apps where there is little time but to add a new updated spec, fix a bug, or increase performance. This is the first example of getaddrinfo() I have seen I find convincing. >> I have found other problems like this that will occur and that are >> subtle and not obvious until you start to think about real deployment. >> In many cases each vendor will provide a work around. >It would sure be nice to come up with a generic solution, so every >vendor doesn't have to do this. I really think getaddrinfo() is a >good move in that direction. I think Craig Metz has been using it >extensively as he ports applications to IPv6. Thats why I brought it up. I think I agree. But will try a few routines first. I think vendors will support the entire API spec. How they engineer their systems to implement transition mechanisms is TBD. I think X/OPen will have to solve that problem and the implementors list. This is not typically done in the IETF as a work item. We tried to fight that battle already. APIs are not a charter here, we have probably over stepped our bounds already. >I guess I'd like to know just what scenarios getaddrinfo() cannot be >used in, and why? Because I don't want to in some cases. I prefer to use what we use now if I can, unless getaddrinfo() provides a benefit. In this case it does. If all you care about is AF_INET and AF_INET6 its not as big a deal to do things as they are done today. But, this case does make getaddrinfo() nice. IN addition early on there was discussion of this vs using the standard calls and libraries. It was decided to have both. Also getaddrinfo() could get changed by X/Open or even POSIX and unless we are tracking that work it could happen and not be known by this community. The standard calls for BSD Sockets should remain in tact even if work proceeds in X/Open. I am more sure of our API spec not changing than other efforts in the industry. Its on our DUNIX IPv6 implementation if folks want to use it. I just don't use it. This issue could be a good reason to at least attempt 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@sunroof.eng.sun.com Mon Feb 17 19:32:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA18405; Mon, 17 Feb 1997 19:31:02 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA18398; Mon, 17 Feb 1997 19:30:48 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA09158; Mon, 17 Feb 1997 19:31:14 -0800 Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA07874; Mon, 17 Feb 1997 19:31:16 -0800 Received: from bwasted.zk3.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA01650; Mon, 17 Feb 1997 19:24:57 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA01471; Mon, 17 Feb 1997 22:21:08 -0500 Message-Id: <9702180321.AA01471@wasted.zk3.dec.com> To: George Tsirtsis Cc: ipng@sunroof.eng.sun.com, ngtrans Subject: (IPng 3060) Re: NAT box and Protocol Translator In-Reply-To: Your message of "Mon, 17 Feb 97 16:02:01 GMT." Date: Mon, 17 Feb 97 22:21:08 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 12551 George, >We put down some old and some new thoughts about the possible use of >NAT boxes and Protocol Translators in the transition period from IPv4 to >IPv6. Please comment as appropriate. Yes deployment is beginning and time to consider this. I am not clear you can standardize much beyond examples though? My initial comments below. >This document proposes the use of a combined NAT box and Protocol >Translator (PT) (NAT-PT) to allow communication between IPv6 and IPv4 >hosts. Each time a host migrates to IPv6 it can 'donate' its IPv4 >address to the local NAT-PT. In this way allocation of new IPv4 addresses >can be minimised while the current aggregation capability of IPv4 >network can be sustained. It is also explained how a host outside the >NAT box can invoke communication with a host inside the NAT box. This seems to be doable. >NAT box > >When the allocated addresses are less than the hosts required to be >connected to the global Internet, a NAT box can dynamically allocate a >unique address to a host. I have went down this path too. For initial deployment it is also an issue for hosts inside the site that have not moved to IPv6 to communicate with the new hosts using IPv6. This means sites internally will need NAT boxes too. But that is problematic and the performance hit would not be acceptable for internal traffic. So for the Intranet for "initial" deployment the site can use private IPv4 addresses on the IPv6 nodes deployed (as all will support both stacks) to communicate within the site. For external communications I would claim if we can all agree to use the O'dell ESD for the low order 8 bytes I could develop a very efficient algorithm (as best as you can do with translation) to do the translation and provide a very good path to IPv6 on the Internet via the 6bone. So one input is that I think any work or draft in this area must be concerned about the Intranet too. >Another, very important characteristic of the NAT box is that it isolates >the hosts that are situated behind it because, the global IP address is >dynamically allocated to a host for the duration of a particular session. >This means that a host outside the NAT box can not know the address of >any host inside the NAT box. Yes. ALso depending on how this is deployed and built the other issue is if a firewall exists in front of the NAT box. So location of the NAT box within the topology into and from the Internet connection is important to note too. >Protocol Translator (PT) > >A protocol translator adapts the requirements of one protocol, expressed >by its header, to the requirements of another protocol and its >corresponding header. Network Address Translator - Protocol Translator (NAT-PT) -------------------------------------------------------- >Outgoing Communication > >NAT-PT combines the functionality of a Protocol Translator with that >of a NAT box. >When a IPv6 packet internal to NAT-PT has to go to the global Internet, >the Protocol Translator (PT) will translate the IPv6 header to an IPv4 >header and the NAT box will change the IPv6 source address to a >dynamically allocated IPv4 address. This IPv4 address will be one of a >small number of IPv4 addresses allocated to the particular site. That >will not be a problem, since the IPv4 addresses can be assigned to the >NAT-PT for dynamic allocation when an IPv4 host upgrades to IPv6. >In this way there will be no need for allocation of new IPv4 addresses You should state I think to an "IPv4" address on the Global Internet. I would not assume that some parts of the Global INternet are not running IPv6 native. You also might want to note that which can not be translated without some manner of encapsualtion that is integral to IPv6 like the flow label, or use of Source Routes, etc.. the new features in IPv6. For example, if an IPv6 application wanted to ftp to a node on the Internet that was IPv4 use of an end to end flow label would not work from the IPv4 host. >The Destination Address of the original (IPv6) packet has to be an IPv4 >compatible IPv6 address. I think this will need some discussion. An IPv6 implementation per ngtrans just decided these are always tunneled. But for NAT we may want to re-discuss that issue. It could also be a v4-mapped address I think. >IPv6 has to be able to recognise IPv4 addresses, when a DNS request >returns an IPv4 address, and to convert them to suitable IPv6 form (IPv4 >compatible IPv6). This is not hard. >Incoming communication > >This is not as easy as the outgoing communication >One way to tackle this is described here: >1.we assume for clarity that only one host (host1.uk) is inside NAT-PT >2.host1.uk only has IPv6 addresses. >3.NAT dynamically allocates IPv4 addresses to the IPv6 host1.uk for >incoming communications >4.PT translates the IPv6 header to IPv4 header and vice versa. >5.Host.com is an external, to NAT-PT, IPv4 host >The IPv4 host could find out which is the IPv4 address >of the IPv6 hosts in the following way: >1.Host.com makes a DNS query for the IP(v4) address of host1.uk in >order to invoke a connection with it; note that the naming of hosts is >common >in IPv4 and IPv6. >2.The local DNS server does not have the address and passes the query to >another DNS server "closer" to the destination; >3.Some DNS is eventually connected to the NAT-PT and passes the >query to it; >4.The NAT dynamically allocates an IPv4 address to host1.uk >and returns this address as reply to the query; >5.Communication now can start between Host.com and host1.uk using IPv4 >addresses. PT will now have to translate the headers from IPv4 to IPv6 >and vice versa. That is really messy and lots of assumptions and DNS will have to be changed or added to, or the NAT-PT would need to be part of the DNS search path. How did host.com get an address for host1.uk? WHat if host.com did a gethostbyname2() for host1.uk? One thought is to determine if this will work at .uk zone: host1.uk IN CNAME host1.nat.uk AND host1.nat.uk IN AAAA 1::2 When host1.nat.uk looked for where DNS supports the NAT-PT then the NAT-PT would be called and the query would return a dynamically assigned IPv4 address. >NOTE: It should be noted that the above rational seems to work for the >NAT boxes as used in IPv4 as well, to permit (v4) hosts outside the NAT >box to invoke communication to (v4) hosts inside the NAT box. I would like you to expound on this as right now it has some handwaving associated with the DNS. >a. One obvious problem is that DNS is working with a lot of caching. This >means that the first time that the above procedure will take place all >intermediate DNS servers will cache the IPv4 address which is going to be >invalid after the end of this session. DNS, however, has a Time To Live >(TTL) field that can be assigned for a domain at its primary DNS server. >TTL could be zero (for no caching at all) or could have the average time >of a session. For servers you could have semi-permanent (IPv4) addresses. >Can DNS's TTL be used in this way ? Is there any other way of doing this? We would need to not cache the IPv6 AAAA records. BIND lets you have a smaller value than the SOA TTL (the default) and thus it can be zero, but I want to test that for sure as I am able. >b. Another potential problem is that NAT-PT has to operate as DNS. What >are the implications of that? Well DNS is already pretty maxed and I don't think that is a good idea from a software perspective. What I think we would need is a means to have DNS query the NAT-PT RR. I have been thinking do we need a NAT RR type? WHich would make this much easier and not interfere with IPv6 DNS name/address resolution. One hint is that the request for an AAAA record came in on an AF_INET connection. >c. It is also obvious that we will have an increase in the amount of DNS >traffic, because of the limited caching. What are the scaling limitations >of such a traffic and does DNSind mechanisms solve/contain it? I think just for the NAT-PT AAAA RR's. So it should not affect the IPv4 DNS server RR's. For IPv6 nodes that are used that often by an IPv4 GlobaL Internet one of the precious real IPv4 addresses can be used. Like a WWW server that lives on the 6bone and on the Internet as an IPv4 node. We are doing this now with Altavista in Palo ALto so that should not be an issue. DNSind in of itself will not help. But the NAT-PT can update the DNS more efficiently. But should nodes become really accessed a lot from the NAT-PT then the IPv6 nodes could be their own zone with its own SOA record. A reasonable TTL could be set as a default for their TTL values. A firewall complicates this a bit more and big time if your using addreses to key on for a security mechanism. >Protocol Translation > >Protocol Translation has well known problems, like performance and >functionality problems. >Note that no IPv6 functionality is lost due to PT because, this is used >for communication with IPv4 host and only IPv4 functionality is required. >Are there any other implications? Is the performance hit bearable? Ah OK you said that.... >Usability and limitations > >The NAT-PT appears to be ideal for private networks that need to use >the advanced features of IPv6, like Stateless Autoconfiguration, >Neighbour Discovery, Security and Flow Labels, without loosing their >connectivity with the IPv4 based Internet. I think this is a viable initial deployment scenario clearly. But the early adopters will need a solution for their Intranet too. >NAT-PT is only required for interoperation and will therefore be a >transient feature of the internet until everyone has transitioned to IPv6. >During transition the cost / overhead of NAT-PT will first be incurred by >IPv6 users, then ISPs, then backbones and finally the remaining IPv4 >islands Well I am not sure you can cast this in concrete or assume any order in the market. I can see ISPs deploying first where they give out IPv6 addresses to gain address space and then translate for new customers to the IPv4 Internet. But for end-users they can start deploying IPv6 even if their ISPs have not moved to IPv6 quite yet. This is why the ESD concept I stated previously would be ideal. Once the INternet goes IPv6 all the end-user has to do is inject the IPv6 prefix into their site and they are live. But you cannot predict how this will evolve and assume nothing. Transition is not a science but a user choice. For the end user, ISP, and Telco's. >The major issue, however, is the scalability of such an >architecture when the IPv6 island become very big and the NAT-PTs >move to the backbone. Has this been looked at / quantified? I don't believe so. IPv6 is pretty new... But I would use caution on any assumptions regarding transtion. I think it can scale. But the DNS part needs serious investigation. I think the NAT-PT could be resident with the Primary DNS Server as a separate process. I floated the idea around that on BSD the Radix tree could be used for the NAT-PT via its own address family like AF_NATV6. The ESDs if selected could be used for the mask for the search and the IPv4 address would be dynamically allocated from the route-table-structure. A flag would be set when an address from the pool was in use. Then PT could be done in the kernel once communications was established. Another thought for scalability is that once an IPv6 node is assigned the IPv4 address I don't see why the NAT-PT is needed. All IPv6 nodes for a long time will support both stacks. On the way out the NAT-PT could inform me of my src address via the work we are doing for rehoming transacations. It would have to support IPv4 but that is doable. Coming in on a connection from the outside an IPv4 packet can be sent to the IPv6 node. This will permit NAT-PT to only have a connecton setup cost. So the IPv6 node only uses the IPv4 address temporarily. We could use a variation of the dyn address work to cause an IPv6 node to use the IPv4 address as a temporary address for the duration of the connection. This would need to be well thought out but its an idea in the back of my head. /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@sunroof.eng.sun.com Mon Feb 17 19:45:59 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA18461; Mon, 17 Feb 1997 19:45:00 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA18452; Mon, 17 Feb 1997 19:44:52 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA10657; Mon, 17 Feb 1997 19:45:17 -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 TAA10260; Mon, 17 Feb 1997 19:45:19 -0800 Received: from bwasted.zk3.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA14712; Mon, 17 Feb 1997 19:39:18 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA01945; Mon, 17 Feb 1997 22:35:30 -0500 Message-Id: <9702180335.AA01945@wasted.zk3.dec.com> To: Paul Ferguson Cc: George Tsirtsis , ipng@sunroof.eng.sun.com, ngtrans Subject: (IPng 3061) Re: NAT box and Protocol Translator In-Reply-To: Your message of "Mon, 17 Feb 97 16:00:31 EST." <3.0.32.19970217152826.00698b20@lint.cisco.com> Date: Mon, 17 Feb 97 22:35:29 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2228 Paul, >I always thought that it was somewhat shortsighted to >not have mentioned this as a possibility within NG Trans; >running dual v4/v6 stacks is not an always a practical >methodology. It was not shortsighted. It was not time until now. We have the market contemplating deployment of IPv6. In addition we cannot guess what policy each organization will want to pursue. IPv6 is evolving. First we got the 6bone up, the implementations are moving real well, the core specs are at PS status, the next wave of specs are moving to PS soon, and now customers and some ISPs are beginning to figure out that IPv6 can help them with a problem, or the next big change is 2 years from now and they might as well use IPv6. Translation to assist deployment of IPv6 is a worthwhile discussion. But, translation long ago was used to attempt to kill and prevent IPv6 deployment. So I guess it is how you approach the purpose of translation. I mean given the right hardware and software environment I could probably write code to get a robot to mow my lawn, which would be really neat. The IPv6 machinery is in place to move to the next steps. >Having said that, is it appropriate for the IPng WG to go >into any amount of detail on how v4 <---> v6 translation >could be done, or would it more appropriate to simply >document the feasibility? Food for thought. I think George's mail has opened the sprout for discussion personally. I just responded to his draft and I do note to use caution on any assumptions you make in the market about transtion or what I think is a better term "interoperation between IPv4 and IPv6". We also cannot forget about the Intranet's, as I pointed out in my input to George on his draft. I also am not clear you can define exactly how NAT-PT will work with an implementation. I think identifying the issues and a framework is doable today. I think George's draft is a good start (and Alan O.'s too). /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Feb 17 23:11:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA18737; Mon, 17 Feb 1997 23:10:53 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA18723; Mon, 17 Feb 1997 23:10:14 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA25053; Mon, 17 Feb 1997 23:10:39 -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 XAA22160; Mon, 17 Feb 1997 23:10:41 -0800 Received: from big-dogs.cisco.com (sj-dial-3-31.cisco.com [171.68.179.32]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id XAA15892; Mon, 17 Feb 1997 23:10:38 -0800 (PST) Message-Id: <3.0.32.19970217175253.0069c424@lint.cisco.com> X-Sender: pferguso@lint.cisco.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Feb 1997 02:10:37 -0500 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Paul Ferguson Subject: (IPng 3062) Re: NAT box and Protocol Translator Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 920 One thought that I wanted to clarify here was that the protocol specifications for both IPv4 and IPv6 are in place (well, sort of), so let's not reivent the wheel. - paul At 04:00 PM 2/17/97 -0500, Paul Ferguson wrote: >I always thought that it was somewhat shortsighted to >not have mentioned this as a possibility within NG Trans; >running dual v4/v6 stacks is not an always a practical >methodology. > >Having said that, is it appropriate for the IPng WG to go >into any amount of detail on how v4 <---> v6 translation >could be done, or would it more appropriate to simply >document the feasibility? Food for thought. > >- 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@sunroof.eng.sun.com Tue Feb 18 02:45:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA18910; Tue, 18 Feb 1997 02:44:53 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA18903; Tue, 18 Feb 1997 02:44:40 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA11689; Tue, 18 Feb 1997 02:45:08 -0800 Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id CAA01060 for ; Tue, 18 Feb 1997 02:45:04 -0800 Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id LAA21690 for ; Tue, 18 Feb 1997 11:45:00 +0100 Received: from unknown(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma021523; Tue Feb 18 11:44:01 1997 Received: from hades.mpn.cp.philips.com (hades.mpn.cp.philips.com [130.139.64.31]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-970214) with ESMTP id LAA22304 for ; Tue, 18 Feb 1997 11:43:59 +0100 Received: from pc239.nwm.wan.philips.com (pc239.nwm.wan.philips.com [161.89.1.239]) by hades.mpn.cp.philips.com (8.6.10/8.6.10-1.2a-960910) with SMTP id LAA26074 for ; Tue, 18 Feb 1997 11:43:05 +0100 Message-Id: <1.5.4.32.19970218104315.006e6d34@hades.mpn.cp.philips.com> X-Sender: rhunter@hades.mpn.cp.philips.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Feb 1997 11:43:15 +0100 To: ipng@sunroof.eng.sun.com From: Ray Hunter Subject: (IPng 3063) Explicit site multi-homing is important to me (long post) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 8999 I want to give some commercial input to the debate on addressing et al from the view point of an end user of IP. I do not want to flame anyone. I just want to communicate what I think is important to me at the moment. I was triggered in to action by the publication of the Provider Based Addressing RFC as a proposed standard. I have worked for a long time (7 years) on big (>100 router) multi-protocol networks. All of this is IMHO. I speak for myself.... not Origin, IBM, Philips nor ESA. [I'll try to stay clear of taking sides between the 2 current proposals for addressing. I have attempted to read all the email for the last month or so and understand the proposals. I retired from being associated with rocket scientists when I left ESA ;-) ] I will also try to bring in a number of analogies from the voice world. As with all analogies, it cannot be taken too far, because voice is still pretty regulated and is connection orientated. Still I think a number of commercial lessons can be taken for the ubiqitous use of telephone calls to do business. 1. Why you need to revisit the address architecture =================================================== - the address architecture was designed a long time ago - the internet has since changed significantly in function and structure - it did not address scaling issues (really the same issues as V4) some will argue that was not the function of IPng but I say part of the charter asked IPng to "repair any deficiencies with respect to current or near-term addressing requirements." It all depends what you call near term really, how fast you think the wall is coming, and which limit will hit first. - it did not address the commercialisation of the internet 2. What IMVHO sort of questions do you need to answer now? ========================================================== - I contend that you cannot have _scalable_ aggregation without sufficient structure in the address space. Auto-aggregation of non strucutured addresses is doomed to failure. The debate then becomes... "what strucuture do we need?" You need to answer questions on: the structure of addresses, how it will work TODAY (no fancy protocols, just manually condfigured backward compatability) how the address space will scale in terms of numbers of bits per field an _idea_ of how routing table size/aggregation can be scaled in the future These would be questions such as - Is it the n+n fixed boundary style model or the prefix style model? - Are the prefixes fixed or variable length? - Is the first portion of the address dynamic or static? - Can the first portion be rewritten? - Is it enough to assign portions of "provider independent addresses" to address multi-homing? - how should I map existing AS numbers/IP addresses to this new addressing scheme? - will the end users take it on board [remember the inverse relationship between the complexity of OSI CLNS compared to its success] I purposefully do not address the choice here. I do not see that exactly HOW the routing will work in the future needs to be addressed now. The protocol problems can be addressed later in the new BGP 6 or whatever. That's the way it was done in the past. _However_ a sneak architectural change was required last time just to keep things running... You had to throw away Classes and introduce CIDR just to keep the internet running. That was hardly a long well thought out architectural debate! [Although full marks for getting it done on time] Therefore you must be absolutely sure you have picked the correct model! I agree with your decision to spend the entire next meeting debating the merits of an alternative scheme. I do not see that you have to rubber stamp any alternative scheme in it's entirety. There are many things that could be left open, provided backwards compatability with todays protocols has been demonstrated. - I personally do not believe that the user community is ready to accept having the address space mandated to them by ISP's. I may be wrong on this. I have been wrong before. 3. Commercial users demand provider independence at SEVERAL levels ================================================================== I have seen arguments that multi-homing itself is BAD. Also that these users are portrayed as trouble makers, and that everything should be left to the model of ISP's providing full interconnectivity. Large corporations/organisations are the ones with most money, and the ones who started it all in the first place.(e.g. DoD) - multi-homing is not technically easy to do... I accept that it is difficult Sorry, but on balance I reject this argument for not explicitly addressing multi-homing for several reasons. I think you need explicit multi-homing support in IPv6 to provide: 3.1 The right to choose an ISP for commercial independence - no commercial user in their right mind will commit to using ISP's address space, when renumbering/changing providers means a lot of work. (see related renumbering comment) - When changing voice providers, you have to change the prefix just on the switch that enters your network. Internal renumbering does not take place on a large scale. It is still costly. - it is also costly to reprint stationary with contact info etc.... (the voice equivalent of DNS) 3.2 The right to have multiple ISPs simultaneously for fail-over - no large commercial user will use internet for business critical traffic if they cannot have independent connection points that provide fail-over to a back-up. Fail-over times will vary by company requirement, but will be less than one day. In the voice world you would have multiple telephone numbers from different providers. I think we can do better than this. 3.3 The right to have multiple ISPs to control your own routing policy - no large commercial user will have their routing policy, and hence their tarifs, determined entirely by a single ISP. In the voice world you have multiple long distance carriers. You select them based on cost. _You_ determine where to call with whch provider using access codes. The equivalent "return packets" come back the same path. 3.4 Protect the integrity of the Internet from Bozos I have seen several cases where an end user demanding multi-homing has short circuited 2 providers. To some extent you must protect the internet from this kind of mis-configuration. Avoiding the issue of multi-homing means that users need to become a provider. Becoming a provider in the current model means that you could become a transit network. There is only one BGP network on the internet. It currently has in the order of 2000 AS's (and hence people) working on it. What happens when this becomes 10,000+? Whatever happened to the distinction made in BGP/AS path style routing between i) a stub AS ii) a multi-homed AS iii) a transit AS? At the risk of saying it too often: Item ii) has been quietly forgotten about and integrated in to iii) With some work couldn't you work it the other way around and say that i) is the limiting case of ii) i.e. a multi-homed AS with only one connection? The ISP itself could still act on behalf of real stoopid stub networks if necessary. 4. My personal perception problems with renumbering as a solution ================================================================= - sorry, and all due respect to the people working on this. I still do not see how the work on renumbering can be 'trusted' by a large network user (500+ routers). You have a lot of mistrust and past experience with large scale renumbering to overcome. - change-overs/renumbering in the voice world happen over many months. It took the PTT's in europe years to develop a renumbering plan just to change the area codes. Both area codes were valid for a very long time (much longer than a TCP session/voice call is normally active for) - I do not see the equivalent process in IPv6 renumbering which is being mooted as a disruptive 'flash' changeover (please flame me/give me a pointer if I've misunderstood) - Renumbering _will_ be a _very_ useful migration/reconfiguration tool It may even cover requirement 3.1. - Renumbering does not really address the requirements in 3.2-3.4. Simple as that. I promise that I will devote time to any replies I receive, and try to clarify any issues you have with wording etc. very best regards, Ray Hunter on contract to Origin Building VA-130, Postbus 218, 5600MD Eindhoven, The Netherlands. email: Ray.Hunter@mpn.cp.philips.com email: Ray.Hunter@globis.net www: http://www.globis.net/~rhunter phone: +31 40 2787988 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 18 04:38:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA19081; Tue, 18 Feb 1997 04:38:12 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA19067; Tue, 18 Feb 1997 04:37:36 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA19131; Tue, 18 Feb 1997 04:38:03 -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 EAA23167; Tue, 18 Feb 1997 04:38:03 -0800 Received: from bwasted.zk3.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA24811; Tue, 18 Feb 1997 04:31:34 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA17530; Tue, 18 Feb 1997 07:27:46 -0500 Message-Id: <9702181227.AA17530@wasted.zk3.dec.com> To: ngtrans@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3064) Re: (ngtrans) Re: NAT box and Protocol Translator In-Reply-To: Your message of "Tue, 18 Feb 97 02:10:37 EST." <3.0.32.19970217175253.0069c424@lint.cisco.com> Date: Tue, 18 Feb 97 07:27:45 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 591 Paul, No they are not for what we are talking now. For the strategy I sent last night. To promote IPv6 deployment. If they are please send a ptr. p.s. Paul I sent two mails last night. A lengthy response to George and a response to your note on shortsighted. But they have not gotten back to me? /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 Feb 18 06:42:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA19340; Tue, 18 Feb 1997 06:41:27 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA19326; Tue, 18 Feb 1997 06:40:48 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA00810; Tue, 18 Feb 1997 06:41: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 GAA28112; Tue, 18 Feb 1997 06:41:09 -0800 Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 18 Feb 1997 14:38:25 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA08571; Tue, 18 Feb 1997 14:33:20 GMT Date: Tue, 18 Feb 1997 14:33:20 +0000 (GMT) From: George Tsirtsis To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com, ngtrans Subject: (IPng 3065) Re: NAT box and Protocol Translator In-Reply-To: <9702180321.AA01471@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 content-length: 8569 Jim, Thanks for your comments, I hope this will clarify some things On Mon, 17 Feb 1997 bound@zk3.dec.com wrote: > George, > > > > >When the allocated addresses are less than the hosts required to be > >connected to the global Internet, a NAT box can dynamically allocate a > >unique address to a host. > > I have went down this path too. > > For initial deployment it is also an issue for hosts inside the site > that have not moved to IPv6 to communicate with the new hosts using > IPv6. This means sites internally will need NAT boxes too. But that is > problematic and the performance hit would not be acceptable for internal > traffic. So for the Intranet for "initial" deployment the site can use > private IPv4 addresses on the IPv6 nodes deployed (as all will support > both stacks) to communicate within the site. > OK! you seem to have two options here with pros and cons: a) Migrate your hosts in groups (e.g LAN after LAN) and use their IPv4 addresses as a v4 pool that the NAT-PT uses in order to allow communication with the global Internet AND the v4 hosts in your intranet. PROBLEM: Performance hit in the internal traffic may be unacceptable b)Migrate hosts as you like and use Private IPv4 Addressing to allow your dual stack machines to talk to v4 only machines. PROBLEM:What happens with your connectivity to the external v4 hosts? You can not use your private addresses for that because these are not global. Could you have NAT-PTs only for the external v6-v4 traffic and use private v4 addresses for the internal communication? Maybe, but looks fairly complicated from the administration point of view... > For external communications I would claim if we can all agree to use the > O'dell ESD for the low order 8 bytes I could develop a very efficient > algorithm (as best as you can do with translation) to do the translation > and provide a very good path to IPv6 on the Internet via the 6bone. > I do not understand why that matters. My thinking is that the v6 host has one global IPv6 address that uses for all communications (I do not care about multihoming for now). The NAT box will change this address to a global IPv4 address and will keep an entry mapping the two addresses for the rest of the session. I am not sure I understood you here in the first place so forgive me if the above paragraph is irrelevant > > >Another, very important characteristic of the NAT box is that it isolates > >the hosts that are situated behind it because, the global IP address is > >dynamically allocated to a host for the duration of a particular session. > >This means that a host outside the NAT box can not know the address of > >any host inside the NAT box. > > Yes. > > ALso depending on how this is deployed and built the other issue is if a > firewall exists in front of the NAT box. So location of the NAT box > within the topology into and from the Internet connection is important > to note too. > It looks like NAT-PTs will make firewalls better. I see NAT-PT as an enhansement to firewalls. > ... > You also might want to note that which can not be translated without > some manner of encapsualtion that is integral to IPv6 like the flow > label, or use of Source Routes, etc.. the new features in IPv6. For > example, if an IPv6 application wanted to ftp to a node on the Internet > that was IPv4 use of an end to end flow label would not work from the > IPv4 host. > When you communicate with an IPv4 host, you should not expect to have IPv6 functionality. The protocol translator should probably ignore IPv6 specific fields in the translation from IPv6 to IPv4. >>Incoming communication ... > That is really messy and lots of assumptions and DNS will have to be > changed or added to, or the NAT-PT would need to be part of the DNS > search path. > I agree, it looks very messy but is the only solution that I am aware of at this point. I hope we find a better one, but I think that we detailed study of the DNS implications we might find that is not as difficult as it looks. > How did host.com get an address for host1.uk? > host.com could get the address NAME from a search engine. I understand that it is restrictive; for example you can not telnet to IPv6 hosts from an IPv4 host using their IPv6 address (number) but only using their NAME. However, it is better than nothing. > >b. Another potential problem is that NAT-PT has to operate as DNS. What > >are the implications of that? > > Well DNS is already pretty maxed and I don't think that is a good idea > from a software perspective. What I think we would need is a means to > have DNS query the NAT-PT RR. I have been thinking do we need a NAT RR > type? WHich would make this much easier and not interfere with IPv6 DNS > name/address resolution. One hint is that the request for an AAAA > record came in on an AF_INET connection. > I have heard before that it is not a good idea to put DNS on a router, it is not clear to me ,however, what the technical or other limitations of that are. Could you explain briefly? > >c. It is also obvious that we will have an increase in the amount of DNS > >traffic, because of the limited caching. What are the scaling limitations > >of such a traffic and does DNSind mechanisms solve/contain it? > > I think just for the NAT-PT AAAA RR's. So it should not affect the IPv4 > DNS server RR's. For IPv6 nodes that are used that often by an IPv4 > GlobaL Internet one of the precious real IPv4 addresses can be used. > Like a WWW server that lives on the 6bone and on the Internet as an IPv4 > node. We are doing this now with Altavista in Palo ALto so that should > not be an issue. > I agree, IPv4 semi-permantent or permantent addresses could be given to IPv6 based servers that have a lot of interaction with both IPv6 and IPv4. > > >NAT-PT is only required for interoperation and will therefore be a > >transient feature of the internet until everyone has transitioned to IPv6. > >During transition the cost / overhead of NAT-PT will first be incurred by > >IPv6 users, then ISPs, then backbones and finally the remaining IPv4 > >islands > > Well I am not sure you can cast this in concrete or assume any order in > the market. I can see ISPs deploying first where they give out IPv6 > addresses to gain address space and then translate for new customers to > the IPv4 Internet. > You are correct, we should not (and we do not) assume any kind of order in the transition period. This plan, however, can be a viable migration strategy for big intranets, ISP etc. Now, if some networks delay in following this strategy should not be a problem for those how do. An important thing about this strategy is that the cost of moving to IPv6 goes step by step from the IPv6 users to IPv4 users and that could make some 'resisting' sites to migrate as well... > >The major issue, however, is the scalability of such an > >architecture when the IPv6 island become very big and the NAT-PTs > >move to the backbone. Has this been looked at / quantified? > > I don't believe so. IPv6 is pretty new... But I would use caution on > any assumptions regarding transtion. > > I think it can scale. But the DNS part needs serious investigation. I agree, it is very important to clarify all the parameters that can affect DNS and network performance. > > Another thought for scalability is that once an IPv6 node is assigned > the IPv4 address I don't see why the NAT-PT is needed. I do not agree here. The point of combining a NAT box with the PT is based on the assumption that we do not (or soon we will not have) enough IPv4 global addresses. Then the global v4 addresses will be less than the hosts (IPv6 + IPv4) and as a result you will need to dynamically allocate addresses to IPv6 hosts for IPv6-v4 communication. Again sorry if I missed your point Thanks for your very good comments George Tsirtsis -------------------------------------------------------------------------- Network Research Tel : 0044-1473-640756 BT Labs Fax : 0044-1473-640709 Ipswich e-mail: george@gideon.bt.co.uk -------------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Feb 20 08:57:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA23468; Thu, 20 Feb 1997 08:56:29 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA23461; Thu, 20 Feb 1997 08:56:21 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA18991; Thu, 20 Feb 1997 08:56:49 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10264; Thu, 20 Feb 1997 08:56:25 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA23301; Thu, 20 Feb 1997 07:20:53 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA16930; Thu, 20 Feb 1997 07:21:23 -0800 Received: from external.BSDI.COM (external.BSDI.COM [205.230.225.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA01537 for ; Thu, 20 Feb 1997 07:21:22 -0800 Received: from forge.BSDI.COM (dab@forge.BSDI.COM [205.230.224.24]) by external.BSDI.COM (8.8.5/8.8.2) with ESMTP id IAA05721; Thu, 20 Feb 1997 08:21:21 -0700 (MST) Received: (from dab@localhost) by forge.BSDI.COM (8.8.2/8.7.3) id IAA04431; Thu, 20 Feb 1997 08:21:20 -0700 (MST) Date: Thu, 20 Feb 1997 08:21:20 -0700 (MST) From: David Borman Message-Id: <199702201521.IAA04431@forge.BSDI.COM> To: iesg-secretary@ietf.org Subject: (IPng 3067) draft-borman-jumbograms-01.txt Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 947 To: IESG Secretary Subject: TCP and UDP over IPv6 Jumbograms I would like to have the document draft-borman-jumbograms-01.txt, "TCP and UDP over IPv6 Jumbograms", put out for Last Call to be considered for publication as a Proposed Standard. When it was first published as an ID, it was discussed on the ipng@sunroof.Eng.Sun.COM mailing list, and I received feedback on how to improve the document. I incorporated those changes, and it was re-published as the current document. I have not had any suggestions for additional changes since then. The current ID is about to expire, so it would be good to move it along. Thanks. -David Borman, dab@bsdi.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Feb 20 11:35:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA23702; Thu, 20 Feb 1997 11:34:51 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA23695; Thu, 20 Feb 1997 11:34:37 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA14024; Thu, 20 Feb 1997 11:35: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 LAA27174 for ; Thu, 20 Feb 1997 11:34:59 -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 LAA22268; Thu, 20 Feb 1997 11:34:50 -0800 Message-Id: <3.0.1.32.19970220113332.0070b8e8@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 20 Feb 1997 11:33:32 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3069) Attendee List 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 content-length: 1805 Attached is the list the people who have indicated they are planning to attend next week's (Feb 27 & 28) interim IPng meeting. If you plan to attend and have not let me know, please do so ASAP. I need to tell the local host how many people will be attending. Information on the meeting can be found at: http://playground.sun.com/ipng/interim.html Thanks, Bob p.s. A revised 8+8 draft should be out very soon. Bob --------------------------------------------------------------------------- Alex Conta Allyn Romanow Amy Huang Bob Fink Bob Hinden Carl Williams Dan Harrington Dimitry Haskin Edwin J. Moelder Francis Dupont Geoff Bryant Jayakumar Ramalingam Jack McCann Jean-Pierre Roch Jeremy McCooey Jim Bound Joel M. Halpern Kevin M. Lahey Margaret Forsythe Matt Thomas Mike O'Dell Sebastien Roy Silvano Gai Steve Deering Thomas Narten Tom Pusateri William Lenharth ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Feb 20 17:35:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA24418; Thu, 20 Feb 1997 17:34:28 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA24411; Thu, 20 Feb 1997 17:34:16 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA16645; Thu, 20 Feb 1997 17:34:43 -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 RAA22616 for ; Thu, 20 Feb 1997 17:34:45 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA06925; Thu, 20 Feb 1997 17:34:44 -0800 Message-Id: <3.0.1.32.19970220173326.006cac80@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 20 Feb 1997 17:33:26 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3070) W.G. Last Call on "TCP and UDP over IPv6 Jumbograms" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 784 This is an ipng working group last call for comments on advancing the following document to Proposed Standard: Title : TCP and UDP over IPv6 Jumbograms Author(s) : David Borman Filename : Pages : 3 Date : August 1996 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. The last call period will end one weeks from today on 3/6/97. Bob Hinden / Steve Deering ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 23 17:37:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA28352; Sun, 23 Feb 1997 17:36:36 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA28345; Sun, 23 Feb 1997 17:36:24 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA14136; Sun, 23 Feb 1997 17:36:52 -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 RAA26709 for ; Sun, 23 Feb 1997 17:36:54 -0800 Received: by rodan.UU.NET id QQcefe00156; Sun, 23 Feb 1997 20:36:53 -0500 (EST) Date: Sun, 23 Feb 1997 20:36:53 -0500 (EST) From: mo@UU.NET (Mike O'Dell) Message-Id: To: ipng@sunroof.eng.sun.com Subject: (IPng 3071) draft-ipng-gseaddr-00.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 582 this draft has been sent to the ID folks at the secretariat for those who can't wait, ftp.uu.net:/pub/mo/draft-ipng-gseaddr-00.{txt,ps} are available for your enjoyment GSE means Global-Site-ESD - tying the name to byte boundaries became less amusing when it stopped being "8+8" cheers, -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@sunroof.eng.sun.com Mon Feb 24 01:01:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA28623; Mon, 24 Feb 1997 01:00:05 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA28616; Mon, 24 Feb 1997 00:59:55 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA17226; Mon, 24 Feb 1997 01:00:25 -0800 Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA00866 for ; Mon, 24 Feb 1997 01:00:24 -0800 Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id KAA09498; Mon, 24 Feb 1997 10:00:21 +0100 Received: from unknown(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma009289; Mon Feb 24 09:59:26 1997 Received: from hades.mpn.cp.philips.com (hades.mpn.cp.philips.com [130.139.64.31]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-970214) with ESMTP id JAA03202; Mon, 24 Feb 1997 09:59:25 +0100 Received: from pc239.nwm.wan.philips.com (pc239.nwm.wan.philips.com [161.89.1.239]) by hades.mpn.cp.philips.com (8.6.10/8.6.10-1.2a-960910) with SMTP id JAA09027; Mon, 24 Feb 1997 09:58:28 +0100 Message-Id: <1.5.4.32.19970224085829.006c2538@hades.mpn.cp.philips.com> X-Sender: rhunter@hades.mpn.cp.philips.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Feb 1997 09:58:29 +0100 To: ipng@sunroof.eng.sun.com From: Ray Hunter Subject: (IPng 3072) ESD in 8+8 is a good idea. Cc: bound@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 11153 Re: your note of 4 February soliciting feedback in advance of the Feb 27 meeting: > >I would also like to put the attached on the discussion agenda for the >IETF Interim meeting Feb 27 and 28. I shall not be able to attend, and have entered the debate very late in the day anyway. I hope my input is still of use. > >Regardless of what we do with the upper 8bytes of 8+8 I think the ESD is >really a good idea and should maybe be defined in RFC 2073 too. The >reason is that for a site 2+6 will work to define unique nodes within >the site. How we use the upper 8 bytes is another discussion and what >we do with them regarding routing IMHO. agreed. You should not rule out future technology today. I personally cannot see the 16 bytes scaling using CIDR... even with the enforced renumbering. I think the over reliance on the CIDR mantra is a mistake. CIDR is relatively new and was invented in a hurry to address the specific problems of today's IPv4 routing tables on today's routers. CIDR works very well today on 3 byte routing, but I do not think you can build an entire _architecture_ around this for 16 byte routing. I could imagine that explicitly splitting the routing problem back to the original internet model of inter AS and intra AS using 8 bytes each may scale. The protocol used for each part does not have to be the same. [as proven by today's use of EIGRP, RIP, OSPF, BGP, EGP et al] > >Also RFC 1897 uses the low-order 8 bytes the same way. 2 bytes subnet >and 6 bytes interface ID (does not have the modes as 8+8) but the >bit positions are the same. > >Lets suppose that all bought into the above scenario for the ESD. Here >is what could be done. > >Lets also assume that the vendors port all the really used IPv6 >applications to IPv6 (e.g. network utilities, ftp, telnet, smtp, >nfs, web server/browser, snmp, ipsec, ntp, firewall filters, dhcp, >dynamic updates to DNS, etc. etc.). >This is not that far fetched either given the implementation state in >the community. I presume you mean ipv4 applications. this is a typo. > >A user could begin deploying IPv6 on an Intranet using the ESD with the >Interface set to the factory-installed communcations adapter address. yup. once the new IPng IGP's are sorted out. They are simple to specify, because they only have to select on a small portion of the address. This portion of the address can be analogous to today's subnets. Therefore they use existing technology. Therefore they will work. > >The user could use ND and Stateless Addrconf to advertise the 2byte >Partitions in their site. Or DHCPv6. Or a combination of both. yup. getting rid of a huge burden of administering ipv4 addresses. > >At the site or at subnets within the site a translator can be developed >to use up the IP address space they all ready have for addresses to be >translated when an IPv6 node with an ESD address wants to communicate >on the Internet, within their Intranet, and other scenarios. The >translator could be something as simple as another radix AF_FAMILY tree >and IPv4 addresses could be rationed out based on the 2byte partition by >an administrator. There are many ways to build a translator I am >just looking at this idea at present trying to make it efficient for a >Host. yup > >This means the user can use their present IPv4 addresses and do not have >to ask for new addresses or resort to using Private Addresses which have >problems for some users as stated in the end of RFC 1918 and clearly in >RFC 1627 (which is obsolete but I think still valuable). > >It also means the site can immmediately communicate on the 6bone by >creating a prefix from RFC 1897 and the translator is not needed for >that part of the Internet. This could potentially be an evolution plan >for the 6bone to become the IPv6 Internet connection for the world >(internationally). > >It also means that when the IPv6 addressing architecture is selected for >the upper 8bytes, that the user does not have to renumber except for a new >prefix whether we choose 8+8, RFC 2073, or another proposal, if we state >the ESD is defined for the lower 8bytes. yup. This leaves room for new technology, once it matures. It may once again split the routing decision in to intra and inter AS as per the ipv4 model. You could consider encoding the current AS in a _very_ small portion of the top 8 bytes as a _transition_ mechanism until you work out how to use the top 8 bytes to their full. Again, today's protocols such as BGP4 technology would work with alterations to message format and the part of the address a router selected on. There is no complete dive in to the unknown. AS numbers are already globally unique, so the combination of [site unique] ESD plus [globally unique] AS number would give a globally unique interface address... or as good as makes no difference in an operational network. Any NAT or gateway or whatever would only have to run at the boundary between ipV6 and ipV4. You could get to that gateway in release 1 by using a simple default route. > >Given ND, Stateless Addrconf, DHCPv6, and the Router Renumbering >proposal by Bob Hinden, this will make it quite simple to convert a site >that deployed ESDs in their Intranet to move to IPv6 quickly and in addition >permit users to start using IPv6 to expand their address space and begin >to take advantage of the extensive new capabilities in IPv6 non-existent >in IPv4. > >So if we can get consensus on the low order 8bytes we can make a lot of >deployment progress and also do a great service to the problems of IPv4 >address space exhaustion, and extend the capability of Intranet users >via IPv6. > >Its time to deploy IPv6 IMHO. This also gives us a little more time to >address the variants regarding the most efficient and robust way to >route IPv6 addresses and use them in applications (locators or as part >of the identifiers). It also puts the routing decision on 8bytes which >is a big win over 16. In that sense we would have made a critical >decision too by buying into the ESD concept for the lower 8bytes. > >Comments....!!!!!! The above is a great idea for discussion... This is what I intended in my note on what decisions are required NOW and what can be deferred until later, especially w.r.t. multi-homing. At the meeting IMHO you should not debate the proposals as 2 alterantives taking in to account ALL the baggage of ALL the issues raised over the last months. Instead you could debate the proposals in the light of a gut feeling for what is possible in the future, and what will work today. The people who invented classes of network knew nothing of BGP version 1 nor subnets, never mind CIDR! With regard to the specific questions I asked in my note of 18 February: >the structure of addresses, >how it will work TODAY for 8+8 ======= top 8 bytes are mostly 'reserved' and statically defined (to be discussed, with the option of encoding AS number as an interim measure) other assigments for multi-cast etc. are honoured bottom 8 bytes defined in the meeting for 2073 ======== top 8 bits are registry prefixes followed by variable length provider specific or geographic addresses >(no fancy protocols, just manually condfigured backward compatability) as per your proposal >how the address space will scale in terms of numbers of bits per field for 8+8 ======= there are 2^16 sub locations within a site (we currently have over 1000 subnets in our backbone routing table... plus over 500 host routes. This is increasing at about 20% per year. we aggregate manually to a 'slice' = /21 = 255.255.248.0 using EIGRP. This must be one of the largest private commercial networks in the world at the moment. or do you know otherwise?? I am not positive this is enough, unless you offer an alternative to the 2 identifier plus 6 MAC address scheme for those people who think they need it. Despite the claimed benefits of switching, the old style use of broadcasts still demands subnetting.... of course multi-cast should fix this. It would not be too much work to split us in to 4 or more 'sites' e.g. asia-pacific, US, Europe and S. America. That would give us plenty of subnets then, and also fits with our business model.) there are 2^48 hosts within a site. I can't see this being a problem unless the IEEE says otherwise. there are 2^64 routing goops (to be argued about later) for 2073 ======== there are sufficient registries there are sufficient provider IDs to me there is an over complex parsing of variable length fields (done in the interests of address space efficiency) plus there is IMVHO unworkable structure for aggregation based solely on CIDR. >an _idea_ of how routing table size/aggregation can be scaled in the future This is one of my main problems with the current 2073 v 8+8 debate. for 2073 ======== I think it is naive to think that CIDR is the complete answer. Therefore I do not beleive that 2073 will scale for too long. for 8+8 ======= Inventing a new inter-provider protocol for the future to take over from static assignment is not such an onerous task. I can imagine that lots of vendors will want to work on a rich routing policy based protocol for providers.... that's why BGP started in the first place to take over from EGP. Thta's also why one particular router vendor fell out of favour with a lot of large users. Trying to complete this process in one month is certainly impossible! > >These would be questions such as >- Is it the n+n fixed boundary style model or the prefix style model? I vote for m+n. The spacing of m+n is up for grabs. It leaves room for future technology, as well as future expansion. >- Are the prefixes fixed or variable length? I may live to regret saying that the address space is 'big enough' but fixed lengths sure has efficiency and parsing issues as raised by Ran of Cisco. >- Is the first portion of the address dynamic or static? initially static to make it simple >- Can the first portion be rewritten? initially no to make it simple, except for statically defined translations at the site boundary. >- Is it enough to assign portions of "provider independent addresses" to address multi-homing? not a generic enough solution to multi-homing IMHO this a major attraction of 8+8 to me. for now, you can address multi-homing in the same old ipV4 way i.e. become an AS. finally you have room to explicitly address site multi-homing as a possible new service. >- how should I map existing AS numbers/IP addresses to this new addressing scheme? statically. >- will the end users take it on board we'll see. :-) best regards, Ray Hunter on contract to Origin Building VA-130, Postbus 218, 5600MD Eindhoven, The Netherlands. email: Ray.Hunter@mpn.cp.philips.com email: Ray.Hunter@globis.net www: http://www.globis.net/~rhunter phone: +31 40 2787988 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 24 17:02:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA00615; Mon, 24 Feb 1997 17:01:47 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA00608; Mon, 24 Feb 1997 17:01:40 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA11157; Mon, 24 Feb 1997 17:02:10 -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 RAA02451 for ; Mon, 24 Feb 1997 17:00:54 -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 RAA23156; Mon, 24 Feb 1997 17:00:15 -0800 Message-Id: <3.0.1.32.19970224165857.006dc150@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 24 Feb 1997 16:58:57 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3073) Start Times for Interim IPng 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 content-length: 645 Coffee will be served at 8:30am. The meeting will start promptly at 9:00am. Due to the number of people who said they will be attending, the room we will be meeting in the first day will be a bit tight. Suggest that you arrive early if you want a good seat. Information on the meeting can be found at: http://playground.sun.com/ipng/interim.html Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Feb 24 17:09:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA00640; Mon, 24 Feb 1997 17:08:37 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA00633; Mon, 24 Feb 1997 17:08:31 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA12693; Mon, 24 Feb 1997 17:09:00 -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 RAA04786 for ; Mon, 24 Feb 1997 17:08:05 -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 RAA23497; Mon, 24 Feb 1997 17:07:21 -0800 Message-Id: <3.0.1.32.19970224170559.007370b0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 24 Feb 1997 17:05:59 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3074) New 8+8 Draft Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 945 In case you missed this (like I did) the new 8+8 draft is out. Bob >Date: Sun, 23 Feb 1997 20:36:53 -0500 (EST) >From: mo@UU.NET (Mike O'Dell) >To: ipng@sunroof.Eng.Sun.COM >Subject: (IPng 3071) draft-ipng-gseaddr-00.txt >Sender: owner-ipng@sunroof.Eng.Sun.COM > > >this draft has been sent to the ID folks at the secretariat > >for those who can't wait, > >ftp.uu.net:/pub/mo/draft-ipng-gseaddr-00.{txt,ps} > >are available for your enjoyment > > >GSE means Global-Site-ESD - tying the name to byte >boundaries became less amusing when it stopped being "8+8" > > cheers, > -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@sunroof.eng.sun.com Tue Feb 25 04:59:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA00523; Tue, 25 Feb 1997 04:54:38 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA00516; Tue, 25 Feb 1997 04:54:30 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA00301; Tue, 25 Feb 1997 04:55:02 -0800 Received: from manuel.nta.no (manuel.nta.no [128.39.1.196]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA10613 for ; Tue, 25 Feb 1997 04:55:03 -0800 X400-Received: by mta tf in /PRMD=telenor/ADMD=TELEMAX/C=no/; Relayed; Tue, 25 Feb 1997 13:54:50 +0100 Date: Tue, 25 Feb 1997 13:54:50 +0100 X400-Originator: Jan-Kjetil.Andersen@kjeller.fou.telenor.no X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=telenor/ADMD=TELEMAX/C=no/;3421 97/02/25 13:54] Content-Identifier: 3421 97/02/25 Alternate-Recipient: Allowed From: Jan Kjetil Andersen Message-ID: <"3421 97/02/25 13:54*/G=Jan-Kjetil/S=Andersen/OU=kjeller/O=fou/PRMD=telenor/ADMD=TELEMAX/C=no/"@MHS> To: ipng@sunroof.eng.sun.com Subject: (IPng 3075) IPv6 over SONET/SDH activity Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1906 dear Ipv6'ers I am a bit puzzled by the lack of any IPv6 over SONET/SDH activity. Considering the facts that: -SONET / SDH /PDH networks are the most important carrier of WAN and POTS -Properly managed SONET/SDH networks offers a flexible transmission platform with dynamic allocable synchronous links in step of 1.5 or 2.0 Megabit/s up to 10 Gigabit/s. -Current deployment rate of SONET/SDH network by all telecommunication operators indicate that SONET/SDH soon will be THE transmission network (LANs not included). -New router designs like the Netstars gigarouter and others, shows that multgigabit IP routers are on the way, which may eliminate the need for high speed packet switching techniques such as ATM and Frame relay . As I see it, terabit IPv6 routers over multi-terabit SONET/SDH Cross-Connects are capable of solving all the worlds tele and data communication problems for at least the next 2 to 3 decades. I think there is a quite high probability for seeing such network elements developed during the next decade. In the meantime gigabit routers with minimum OC3 interfaces to SONET/SDH is the way to go. So why no IPv6 over SONET/SDH WG? Topics of study for the WG should be: -transmission of IP flows over multiple DSx and OCx connections. -Interoperation of IP routing and SNMP or CMIP agents for SONET/SDH to dynamically manage the bandwidth resorces. something I have missed? Regards Jan Kjetil Andersen Telenor R&D Phone: (+47) 63 84 83 77; Fax: 63 80 05 11; Home: 63 87 70 52; Pager: 96 50 46 03 email: jan-kjetil.andersen@fou.telenor.no Mail: Telenor FoU, Box 83, N-2007 Kjeller ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 25 07:19:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00650; Tue, 25 Feb 1997 07:14:29 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00643; Tue, 25 Feb 1997 07:14:21 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA19896; Tue, 25 Feb 1997 07:14:53 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA22088 for ; Tue, 25 Feb 1997 07:14:49 -0800 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA83071; Tue, 25 Feb 1997 15:14:40 GMT Date: Tue, 25 Feb 1997 15:14:40 GMT Message-Id: <9702251514.AA83071@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3077) Re: IPv6 over SONET/SDH activity To: Jan-Kjetil.Andersen@kjeller.fou.telenor.no (Jan Kjetil Andersen) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <"3421.97/02/25.13:54*/G=Jan-Kjetil/S=Andersen/OU=kjeller/O=fou/PRMD=telenor/ADMD=TELEMAX/C=no/"@MHS> from "Jan Kjetil Andersen" at Feb 25, 97 01:54:50 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2491 Jan Kjetil, I think the assumption is that we will run IP over PPP (RFC 2023) and PPP over SONET/SDH (RFC 1619). Flows over PPP should come from the ISSLL WG. Brian >- Jan Kjetil Andersen said: > > dear Ipv6'ers > > I am a bit puzzled by the lack of any IPv6 over SONET/SDH activity. > > Considering the facts that: > -SONET / SDH /PDH networks are the > most important carrier of WAN and POTS > > -Properly managed SONET/SDH networks offers a flexible > transmission platform with dynamic allocable synchronous links in step of > 1.5 or 2.0 Megabit/s up to 10 Gigabit/s. > > -Current deployment rate of SONET/SDH network by all telecommunication operators > indicate that SONET/SDH soon will be THE transmission network (LANs not included). > > -New router designs like the Netstars gigarouter and others, shows that > multgigabit IP routers are on the way, which may eliminate the need for > high speed packet switching techniques such as ATM and Frame relay . > > As I see it, terabit IPv6 routers over multi-terabit SONET/SDH Cross-Connects > are capable of solving all the worlds tele and data communication problems for at > least the next 2 to 3 decades. I think there is a quite high > probability for seeing such network elements developed during the next decade. > > In the meantime gigabit routers with minimum OC3 interfaces to SONET/SDH > is the way to go. > > So why no IPv6 over SONET/SDH WG? > > Topics of study for the WG should be: > -transmission of IP flows over multiple DSx and OCx connections. > > -Interoperation of IP routing and SNMP or CMIP agents > for SONET/SDH to dynamically manage the bandwidth resorces. > > something I have missed? > > Regards > > Jan Kjetil Andersen Telenor R&D > Phone: (+47) 63 84 83 77; Fax: 63 80 05 11; Home: 63 87 70 52; > Pager: 96 50 46 03 > email: jan-kjetil.andersen@fou.telenor.no > Mail: Telenor FoU, Box 83, N-2007 Kjeller > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: 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@sunroof.eng.sun.com Tue Feb 25 07:44:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00674; Tue, 25 Feb 1997 07:38:56 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00667; Tue, 25 Feb 1997 07:38:47 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA24379; Tue, 25 Feb 1997 07:39:20 -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 HAA01144 for ; Tue, 25 Feb 1997 07:39:09 -0800 Received: from gungnir.fnal.gov ("port 34804"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IFTU1EWGFG000DZ5@FNAL.FNAL.GOV>; Tue, 25 Feb 1997 09:38:46 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA19751; Tue, 25 Feb 1997 09:38:45 -0600 Date: Tue, 25 Feb 1997 09:38:44 -0600 From: Matt Crawford Subject: (IPng 3078) Re: IPv6 over SONET/SDH activity In-reply-to: "25 Feb 1997 13:54:50 +0100." <"3421 97/02/25 13:54*/G=Jan-Kjetil/S=Andersen/OU=kjeller/O=fou/PRMD=telenor/ADMD=TELEMAX/C=no/"@MHS> To: Jan Kjetil Andersen Cc: ipng@sunroof.eng.sun.com Message-id: <199702251538.JAA19751@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{ dear Ipv6'ers > I am a bit puzzled by the lack of any IPv6 over SONET/SDH activity. You are welcome to step up to the plate and propose a specification for IPv6-over-SONET/SDH. However, have you considered PPP over SONET/SDH (RFC1619) plus IPv6 over PPP (RFC2023)? You may be better able than I to judge whether those two proposed standards form an acceptable solution. Matt Crawford ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 25 07:47:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00684; Tue, 25 Feb 1997 07:41:05 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00677; Tue, 25 Feb 1997 07:40:55 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA24760; Tue, 25 Feb 1997 07:41:28 -0800 Received: from sundance.corpeast.baynetworks.com (sundance.corpeast.baynetworks.com [192.32.174.139]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA02009 for ; Tue, 25 Feb 1997 07:41:13 -0800 Received: from localhost by sundance.corpeast.baynetworks.com (8.8.5/1.43r) id PAA03149; Tue, 25 Feb 1997 15:40:33 GMT Message-Id: <199702251540.PAA03149@sundance.corpeast.baynetworks.com> From: Jeffrey Burgan To: "(Brian E Carpenter)" cc: Jan-Kjetil.Andersen@kjeller.fou.telenor.no (Jan Kjetil Andersen), ipng@sunroof.eng.sun.com Subject: (IPng 3079) Re: IPv6 over SONET/SDH activity In-reply-to: Your message of "Tue, 25 Feb 1997 15:14:40 GMT." <9702251514.AA83071@hursley.ibm.com> Date: Tue, 25 Feb 1997 10:40:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 580 > I think the assumption is that we will run IP over PPP (RFC 2023) > and PPP over SONET/SDH (RFC 1619). Flows over PPP should come > from the ISSLL WG. This is a correct assumption. I should also point out that there is ongoing work to revise RFC 1619 based on implementation experience. Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 25 07:52:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00706; Tue, 25 Feb 1997 07:45:10 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00699; Tue, 25 Feb 1997 07:44:54 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA25659; Tue, 25 Feb 1997 07:45:27 -0800 Received: from central-services.east.isi.edu (central-services.east.isi.edu [38.245.76.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA03651 for ; Tue, 25 Feb 1997 07:45:25 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by central-services.east.isi.edu (8.7.5/8.7.3) with SMTP id KAA15622 for ; Tue, 25 Feb 1997 10:45:04 -0500 (EST) Message-Id: <199702251545.KAA15622@central-services.east.isi.edu> X-Authentication-Warning: central-services.east.isi.edu: Host LOCALHOST [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 3080) comments/questions on new "GSE" addressing document X-Phone: +1 703 812 3704 From: "John W. Stewart III" Date: Tue, 25 Feb 1997 10:45:03 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4764 i was glad to see a new version of the "alternative addressing architecture" internet-draft. thanks mike i've got some questions on it. it's obviously getting real close to the interim meeting, but maybe a little e-mail before the meeting can help establish some priorities and focus... (1) how does a multi-homed Site control the traffic that goes over its multiple links? currently a multi-homed site can do things like AS path manipulation, announcement of more-specifics, etc. to control which pieces of the net use which link. they can do this because they're known by one prefix. however, in GSE they're known by multiple prefixes. for flows which the multi- homed site initiates, the source address written by the egress router in the Site determines the return path; does this egress router have any knowledge of the topology to optimize the return path? and for flows which are initiated outside of the multi- homed Site, DNS determines the ingress link; again, is there any support for optimizing which of the multiple links is chosen? (2) The Site is attached to each ISP via some link and we postulate some kind of keep-alive protocol which determines when reachability to the Site's border router is lost. The ISP routers serving the dual-homed Site are identified to each other (via static configuration information in the simplest case or a dynamic protocol in the more general case), and when a link to the Site is lost, the ISP router anchoring the dead link simply tunnels any traffic destined for the Site via the other ISP router. assume that SiteA is multi-homed to ISP1 and ISP2. now assume that i address a packet to SiteA using RG which specifies going through ISP1, but the packet transits the router in ISP2 where the Site connects. (note that this does over-lap somewhat with my question number 1 above, though it isn't necessarily non- optimal depending on the link speeds involved.) so in this case ISP2's router should forward it towards ISP1. but if the Site's link to ISP1 is down and ISP1's router tunnels the packet to ISP2's router, without some dynamic protocol, how does ISP2's router know to forward it to the Site rather than back over to ISP1? also, more generally, what if ISP1's router itself goes down (i.e., it's not there to do the tunneling)? (3) Two consenting Large Structures remain free to share a tangency below the top level and exchange routes so as to provide for improved routing between the two of them (formalizing cut-throughs in the natural hierarchy). The goal is to provide for manageable complexity of the ultimate default-free zone (the top level of the global hierarchy) while allowing for controlled circumvention of the natural hierarchical paths. the use of the words "Two consenting Large Structures" implies, to me, some kind of administrative organization behind LSs. however, what i thought i understood from the document (and used in my example), is that LSs encompass both public and private topology of many organizations. so what does "consent" mean? i also don't understand the technical need of involving the LS as a whole .. it seems necessary to only have the "consent" of the sub-partitions that have the adjacency. which part did i misunderstand? (4) If two Large Structures share a tangency somewhere below the top level, then some interior routers of both Large Structures will share routes to exploit the tangency for optimizing paths. How this cut- through information is distributed within the two Large Structures is not revealed elsewhere in the global topology. The exact "shape" of the optimization region is controlled by the decisions about which routes to advertise across the cut-through. is it envisioned that the distribution of the more granular routing information be controlled in ways that we already use (i.e., bgp4 and filtering using AS paths, communities, etc.)? what i'm getting at here is the interaction between GSE addressing and current inter-domain routing .. the GSE prefixes give us a semantic that we don't currently have (5) architectural question: if a Site is multi-homed to providers in different Large Structures, then is that Site considered part of both? is that different than "sharing a tangency"? more generally, if a reseller is multi-homed to providers in different Large Structures, then is it and all of its customers considered part of both? /jws ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Feb 25 08:05:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00744; Tue, 25 Feb 1997 08:00:03 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00728; Tue, 25 Feb 1997 07:59:55 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA28395; Tue, 25 Feb 1997 08:00:28 -0800 Received: from corona.jcmax.com (corona.jcmax.com [204.69.248.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA09279 for ; Tue, 25 Feb 1997 08:00:25 -0800 Received: from extreme.jcmax.com by corona.jcmax.com (5.65/2.48G/4.1.3_U1) id AA14057; Tue, 25 Feb 97 11:00:16 -0500 Received: from extreme.jcmax.com (localhost.jcmax.com [127.0.0.1]) by extreme.jcmax.com (8.7.5/8.7.3) with ESMTP id LAA04480; Tue, 25 Feb 1997 11:00:17 -0500 (EST) Message-Id: <199702251600.LAA04480@extreme.jcmax.com> To: "(Brian E Carpenter)" Cc: Jan-Kjetil.Andersen@kjeller.fou.telenor.no (Jan Kjetil Andersen), ipng@sunroof.eng.sun.com Subject: (IPng 3081) Re: IPv6 over SONET/SDH activity In-Reply-To: Your message of "Tue, 25 Feb 1997 15:14:40 GMT." <9702251514.AA83071@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <4477.856886411.1@extreme.jcmax.com> Date: Tue, 25 Feb 1997 11:00:11 -0500 From: Tom Pusateri Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 621 In message <9702251514.AA83071@hursley.ibm.com> you write: >Jan Kjetil, > >I think the assumption is that we will run IP over PPP (RFC 2023) >and PPP over SONET/SDH (RFC 1619). Flows over PPP should come >from the ISSLL WG. > > Brian I believe running IP over Frame Relay Encapsulation over SONET/SDH will also become fashionable. Tom ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 25 08:11:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00793; Tue, 25 Feb 1997 08:05:20 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00786; Tue, 25 Feb 1997 08:05:15 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA19322; Tue, 25 Feb 1997 08:05:49 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16145; Tue, 25 Feb 1997 08:05:24 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA00618; Tue, 25 Feb 1997 06:38:21 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA13311; Tue, 25 Feb 1997 06:38:53 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA09229 for ; Tue, 25 Feb 1997 06:38:55 -0800 Received: from ietf.ietf.org by ietf.org id aa08411; 25 Feb 97 9:31 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org@jurassic@jurassic cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3082) I-D ACTION:draft-ietf-ipngwg-gseaddr-00.txt Date: Tue, 25 Feb 1997 09:31:48 -0500 Message-ID: <9702250931.aa08411@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3822 --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 : GSE - An Alternate Addressing Architecture for IPv6 Author(s) : M. O'Dell Filename : draft-ietf-ipngwg-gseaddr-00.txt Pages : 20 Date : 02/24/1997 This document presents an alternative addressing architecture for IPv6 which controls global routing growth by very aggressive topological aggregation. It includes support for scalable multi-homing as a distinguished service. It provides for future independent evolution of routing and forwarding models with essentially no impact on end systems. Finally, it frees sites and service resellers from the tyranny of CIDR-based aggregation by providing transparent re-homing of both. 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-gseaddr-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-gseaddr-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-gseaddr-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: <19970224104130.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-gseaddr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-gseaddr-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970224104130.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@sunroof.eng.sun.com Tue Feb 25 08:30:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00885; Tue, 25 Feb 1997 08:24:54 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00878; Tue, 25 Feb 1997 08:24:42 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA03792; Tue, 25 Feb 1997 08:25:16 -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 IAA18886 for ; Tue, 25 Feb 1997 08:24:53 -0800 Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.5/8.6.12) with SMTP id LAA12462; Tue, 25 Feb 1997 11:23:43 -0500 (EST) Message-Id: <199702251623.LAA12462@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Jan Kjetil Andersen cc: ipng@sunroof.eng.sun.com Subject: (IPng 3083) Re: IPv6 over SONET/SDH activity In-reply-to: Your message of "Tue, 25 Feb 1997 13:54:50 +0100." <"3421 97/02/25 13:54*/G=Jan-Kjetil/S=Andersen/OU=kjeller/O=fou/PRMD=telenor/ADMD=TELEMAX/C=no/"@MHS> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 25 Feb 1997 11:23:41 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 583 Jan Kjetil Andersen writes: > I am a bit puzzled by the lack of any IPv6 over SONET/SDH activity. I'm a bit puzzled by your question. > So why no IPv6 over SONET/SDH WG? We have IPv4 and IPv6 over PPP, and there is a standard for PPP over SONET/SDH, so yes, you can run IPv6 over SONET/SDH 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@sunroof.eng.sun.com Tue Feb 25 09:32:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01058; Tue, 25 Feb 1997 09:26:37 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01051; Tue, 25 Feb 1997 09:26:29 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA27700; Tue, 25 Feb 1997 09:27:00 -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 JAA14049 for ; Tue, 25 Feb 1997 09:26:27 -0800 Received: from big-dogs.cisco.com ([171.68.53.92]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id JAA23858; Tue, 25 Feb 1997 09:25:29 -0800 (PST) Message-Id: <3.0.32.19970225122523.006b1414@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 25 Feb 1997 12:25:30 -0500 To: Tom Pusateri From: Paul Ferguson Subject: (IPng 3084) Re: IPv6 over SONET/SDH activity Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 528 At 11:00 AM 2/25/97 -0500, Tom Pusateri wrote: > >I believe running IP over Frame Relay Encapsulation over SONET/SDH >will also become fashionable. > Whatever for? This would be a horribly inefficient use of SONET/SDH, worse than ATM. - 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@sunroof.eng.sun.com Tue Feb 25 10:23:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA01142; Tue, 25 Feb 1997 10:18:04 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA01135; Tue, 25 Feb 1997 10:17:55 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA14086; Tue, 25 Feb 1997 10:18:28 -0800 Received: from manuel.nta.no (manuel.nta.no [128.39.1.196]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA04740 for ; Tue, 25 Feb 1997 10:18:10 -0800 X400-Received: by mta tf in /PRMD=telenor/ADMD=TELEMAX/C=no/; Relayed; Tue, 25 Feb 1997 19:17:44 +0100 Date: Tue, 25 Feb 1997 19:17:44 +0100 X400-Originator: Jan-Kjetil.Andersen@kjeller.fou.telenor.no X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=telenor/ADMD=TELEMAX/C=no/;3448 97/02/25 19:17] Content-Identifier: 3448 97/02/25 Alternate-Recipient: Allowed From: Jan Kjetil Andersen Message-ID: <"3448 97/02/25 19:17*/G=Jan-Kjetil/S=Andersen/OU=kjeller/O=fou/PRMD=telenor/ADMD=TELEMAX/C=no/"@MHS> To: ipng@sunroof.eng.sun.com Subject: (IPng 3085) RE:IPv6 over SONET/SDH activity Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1574 > Jan Kjetil, > > I think the assumption is that we will run IP over PPP (RFC 2023) > and PPP over SONET/SDH (RFC 1619). Flows over PPP should come > from the ISSLL WG. > > Brian > As I read RFC1619, PPP is meant as a user to network connection. I quote from page 1 in the RFC: - "This specification is intended for those implementations which desire - to use the PPP encapsulation over high speed private point-to-point - links, such as intra-campus single-mode fiber which may already be - installed and unused." No talk about backbone router to router communication there. I was not aware of the changed perspective on PPP usage. But I suppose it is correct as you say, which implies that the intended use of PPP has widened since the RFC was written. I’m sure PPP WG take care of the RFC1619 shortcomings for backbone routing. ( problem solved all happy :-) ) The framing part is only a minor problem however, a far more complex but also important task to study is how to make use of the SONET/SDH management to dynamically configure the bandwidth resources offered to the router. Jan Kjetil Andersen Phone: (+47) 63 84 83 77; Fax: 63 80 05 11; Home: 63 87 70 52; Pager: 96 50 46 03 email: jan-kjetil.andersen@fou.telenor.no Mail: Telenor FoU, Box 83, N-2007 Kjeller ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 25 11:14:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01204; Tue, 25 Feb 1997 11:08:52 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01197; Tue, 25 Feb 1997 11:08:41 -0800 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA27942; Tue, 25 Feb 1997 11:09:11 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA02839 for ; Tue, 25 Feb 1997 11:09:07 -0800 Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.5/8.6.12) with SMTP id OAA00233; Tue, 25 Feb 1997 14:08:44 -0500 (EST) Message-Id: <199702251908.OAA00233@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Jan Kjetil Andersen cc: ipng@sunroof.eng.sun.com Subject: (IPng 3086) Re: IPv6 over SONET/SDH activity In-reply-to: Your message of "Tue, 25 Feb 1997 19:17:44 +0100." <"3448 97/02/25 19:17*/G=Jan-Kjetil/S=Andersen/OU=kjeller/O=fou/PRMD=telenor/ADMD=TELEMAX/C=no/"@MHS> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 25 Feb 1997 14:08:42 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 655 Jan Kjetil Andersen writes: > > I think the assumption is that we will run IP over PPP (RFC 2023) > > and PPP over SONET/SDH (RFC 1619). Flows over PPP should come > > from the ISSLL WG. > > As I read RFC1619, PPP is meant as a user to network connection. PPP is a generic Point to Point Protocol. It is intended for use wherever there is a Point to Point link. 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@sunroof.eng.sun.com Tue Feb 25 11:58:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01268; Tue, 25 Feb 1997 11:52:50 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01261; Tue, 25 Feb 1997 11:52:42 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA10860; Tue, 25 Feb 1997 11:53:13 -0800 Received: from corona.jcmax.com (corona.jcmax.com [204.69.248.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA16472 for ; Tue, 25 Feb 1997 11:53:05 -0800 Received: from extreme.jcmax.com by corona.jcmax.com (5.65/2.48G/4.1.3_U1) id AA19808; Tue, 25 Feb 97 14:52:41 -0500 Received: from extreme.jcmax.com (localhost.jcmax.com [127.0.0.1]) by extreme.jcmax.com (8.7.5/8.7.3) with ESMTP id OAA05373; Tue, 25 Feb 1997 14:52:40 -0500 (EST) Message-Id: <199702251952.OAA05373@extreme.jcmax.com> To: Paul Ferguson Cc: Tom Pusateri , ipng@sunroof.eng.sun.com Subject: (IPng 3087) Re: IPv6 over SONET/SDH activity In-Reply-To: Your message of "Tue, 25 Feb 1997 12:25:30 EST." <3.0.32.19970225122523.006b1414@lint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <5370.856900355.1@extreme.jcmax.com> Date: Tue, 25 Feb 1997 14:52:35 -0500 From: Tom Pusateri Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1041 In message <3.0.32.19970225122523.006b1414@lint.cisco.com> you write: >At 11:00 AM 2/25/97 -0500, Tom Pusateri wrote: > >> >>I believe running IP over Frame Relay Encapsulation over SONET/SDH >>will also become fashionable. >> > >Whatever for? This would be a horribly inefficient use of SONET/SDH, >worse than ATM. > >- paul (Being worse than ATM is quite a claim!) Note: I did say in the previous note about just using the frame relay encapsulation. I did NOT say anything about running frame relay to a switch over SONET in case you misread it. This is strictly between two routers. I believe frame relay encapsulation is being talked about for demuxing channelized OC-x interfaces allowing one interface instead of n where n might be quite large. Tom ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 25 12:31:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA01290; Tue, 25 Feb 1997 12:26:14 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA01283; Tue, 25 Feb 1997 12:26:05 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA24489; Tue, 25 Feb 1997 12:26:37 -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 MAA29591 for ; Tue, 25 Feb 1997 12:26:29 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcelt06022; Tue, 25 Feb 1997 15:25:52 -0500 (EST) Message-Id: To: Tom Pusateri cc: "(Brian E Carpenter)" , Jan-Kjetil.Andersen@kjeller.fou.telenor.no (Jan Kjetil Andersen), ipng@sunroof.eng.sun.com Subject: (IPng 3088) Re: IPv6 over SONET/SDH activity In-reply-to: Your message of "Tue, 25 Feb 1997 11:00:11 EST." <199702251600.LAA04480@extreme.jcmax.com> Date: Tue, 25 Feb 1997 15:25:52 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 465 PPP over sonet is basically byte-stuffed HDLC with the PPP stuff a byte-stuffed HDLC engine will also do FR/1490 with no problem expect this to be popular, as has been suggested ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 25 14:14:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA01544; Tue, 25 Feb 1997 14:09:29 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA01537; Tue, 25 Feb 1997 14:09:22 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA26421; Tue, 25 Feb 1997 14:09:55 -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 OAA09494 for ; Tue, 25 Feb 1997 14:09:43 -0800 Received: from big-dogs.cisco.com ([171.68.53.92]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id OAA07177; Tue, 25 Feb 1997 14:08:38 -0800 (PST) Message-Id: <3.0.32.19970225170836.006b4a58@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 25 Feb 1997 17:08:38 -0500 To: Tom Pusateri From: Paul Ferguson Subject: (IPng 3089) Re: IPv6 over SONET/SDH activity Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 867 At 02:52 PM 2/25/97 -0500, Tom Pusateri wrote: > >(Being worse than ATM is quite a claim!) > >Note: I did say in the previous note about just using the frame >relay encapsulation. I did NOT say anything about running frame relay >to a switch over SONET in case you misread it. This is strictly >between two routers. > Mea culpa. My fault for second-guessing this was indeed the suggestion. :-) - paul >I believe frame relay encapsulation is being talked about for demuxing >channelized OC-x interfaces allowing one interface instead of n where >n might be quite large. > >Tom > > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 25 14:50:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA01627; Tue, 25 Feb 1997 14:45:18 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA01620; Tue, 25 Feb 1997 14:45:10 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA05619; Tue, 25 Feb 1997 14:45:43 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA23040 for ; Tue, 25 Feb 1997 14:45:28 -0800 Received: by SNOOPY with Internet Mail Service (5.0.1389.3) id <01BC2344.2D1747E0@SNOOPY>; Tue, 25 Feb 1997 17:48:58 -0500 Message-ID: From: "Harrington, Dan" To: ipng@sunroof.eng.sun.com Cc: "'bound@zk3.dec.com'" , "'Martin.Pabst@mch.sni.de'" Subject: (IPng 3090) RE: draft-ietf-ipngwg-linkname-01.txt Date: Tue, 25 Feb 1997 17:48:56 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 9841 Hello all, 1234567890123456789012345678901234567890123456789012345678901234567890 I'm including a response to the messages I've received in the past couple of weeks. Sorry it's so long, and that it has taken me this long to reply. Here goes...please let me know if I missed (or skipped) any important points. Martin Pabst wrote (2/13/97): > What purpose does the facility of link local addresses serve, > including the RfC1971, Stateless Address Autoconfiguration? Link local addresses, by combining a fixed prefix and link specific token, are meant to be simple to form during link initialization, and thus insure that at least one unicast address is associated with an interface in the absence of manual or dynamic address configuration. With it, plug and play is possible. > Can we assume, that the presence of the link layer address in the link local > address should or will be used by the link layer, in order to improve the > address resolution within this layer? No, the link layer address (if any) in the link local address is used as a token to insure uniqueness. It is explicitly NOT used for address resolution. See RFC 1970 for full details... > Is one goal of the link local addresses to simplify the address resolution, > avoiding DNS nameserver queries, without the need of a static local database > (/etc/hosts)? Not really...link local addresses are critical if you don't have any other addresses, but they quickly become less interesting as your infrastructure builds up (and you gain global addresses visible through DNS). > Does mobile computing will be a frequent case for the use of RfC1971 and > link local addresses? Yes, I suppose so...any system running IPv6 will be using link local addresses to some extent. > In how much hosts we think when mentioning "link local": tens or thousands? > Are they changing frequently? Do the users know them each other? What will > be the future situation and what the common case then? As with any protocol, we need a solution that scales to large networks. While I would not design a network based on a single large LAN link containing thousands of hosts, all of them using link local addressing exclusively, it should not be made impossible or declared invalid by fiat. But you must keep in mind that the situation in which this particular protocol is most desirable is a small LAN with a limited number of hosts and little (if any) infrastructure. > What role the DNS names play (what is a not-"real" DNS name)? Originally I did not want to have any interaction with Domain names, but simply use the simple hostname (e.g. "jessica"). The working group had concerns with this, however, and requested a solution which would permit multiple hosts with the same name (e.g. "www") but configured in separate domains to still be referenced using the linkname mechanism. At that point I felt that the ".link" pseudo-domain was more important; matching a limited scope address with a simple hostname is appropriate, but matching a limited scope address with a FQDN is overloading the name. > To make use of the link local addresses, the link local resolver mechanism > should be applied before any DNS query. Otherwise, only those hosts > on the link can be reached by the new protocol, that don't have any valid > DNS name; those, that aren't registered with any nameserver. Is that your > point of view, too, and your intention?: No, I think that's your opinion. In my view, once DNS is deployed and configured the link local addresses become secondary. Mind you, there may well be times when you want to use them explicitly...again, having a tag associated with the name becomes important. I'd like to leave control in local (i.e. your) hands. > Other systems make use of the various kinds of name resolution having > respective libraries; the methods the system administrator wants to make > available, are listed in a file like /etc/netconfig - controlling by the list > order the setting of the search order, too. Sites may use BIND only for DNS > queries, having other libraries for statical searches. I think we agree here...the linkname mechanism is just another service, separate from BIND/DNS. > With all that, we made the quiet assumption that there aren't any other hosts > with the same FQDN (modulo ".link.notDNS") outside the link, in the Internet > world. If not, it would be difficult to define (or recommend) a "correct" order > of the search methods and to avoid ambiguities. But that's what FQDN means...it *is* unique in the Internet. > Again, we end up with the question of the importance of this protocol > and whether the link local addresses one day will become the common case. > If so, this should not be limited from the beginning on by security shortages > of the protocol for the name resolution. Therefore, I think its worth to > propose (or at least to discuss) some security mechanism; indeed those that > are somewhat more lightweight than a sledgehammer. I'm not sure I agree. If the use of IPsec AH headers is imagined to be appropriate for a protocol like Neighbor Discovery then I suppose the same technique could apply to this protocol, and I could add wording of that sort. If you had another specific mechanism in mind please let me know. Jim Bound wrote (2/14/97): >>The feedback from the group (esp. at Montreal) was that they >>wanted this to work with duplicate names which were configured >>in separate subdomains. The example given was www.[x].foo.com, >>where there might be dozens of hosts responding to a query >>for "www". In my mind, if you've got a situation like that, >>and you're already using DNS, then using this linkname mechanism >>to get Link Local addresses is not vital. But folks wanted to >>see the problem dealt with, so I've tried to solve it. > > Well I would like to readdress it with the group. The names should not > have anything to do with DNS. DNS already has to many records. The only relationship with DNS is that using FQDN's allows uniqueness to be ascertained. www == www, but www.eng.acme.com != www.sales.acme.com > THat is why I proposed the LLname. If the node has a valid www AAAA > record address in the DNS on the link it don't need the LLname. We need > to permit common sense to enter the engineering trade-off discussion for > this and I would like to inject that common sense part to this > discussion and see what the response is. I don't disagree about the preference which should be accorded to DNS if it is deployed. But I think there is something to be said for having an alternate mechanism available. Regarding the idea of implementing linkname as a series of entries in a local file (e.g. /etc/hosts), Jim wrote: > Well I like that model and would like the group to hear it for these > reasons: > > 1. Adding an additional search to the libraries associated with > locating a name (or and address which is an optimization of > gethosbyname2 (if you look at that code check out "isdigit" > function). This puts an entire additional amount of work > to these library routines and should not be decided lightly. > I am in this code daily because of Dyn Upd to DNS and integration > with addr conf and DHCPv6. We need to be careful what we do > here to implementations. FOr what is not a showstopper in the > scheme of things for IPv6. )---> you have key in a LL address. > That is all that is driving this effort. > > 2. It is a discrete service and you did not comment on my suggestion > of the LLname cache. The /etc/host update is not a big deal > it is a simple read and write and for the intensity of the > LL address/naming requirement I think its just fine. So > emphatically disagree with you that this is even a problem or > complex. Its simple actually. It also avoids changing any of > syntax or semantics of addrlib.c, gethnamaddr.c, etc.... Which > again should not be changed lightly. Discussing this offline I realized that you were suggesting that the cache of link local names/addresses be treated as a logical extension to the local file (/etc/hosts), not necessarily as actual entries in this file. That makes sense to me...it would limit the scope of change in the resolver routines, though I never envisioned them as being extensive. re. packet types > Well I disagree with you and I believe that whenever protocol design can > overload the classification of a packet it is superior to discrete > additional components for clarity. I really believe most computer > science problems can be solved by another level of indirection. That is > what I am essentially proposing over your scheme presently. It also > makes writing the code much simpler and reuse of the routines to process > the packet more likely. > > So I guess I would like to get others comments on this too. I'd also like to hear other views. > ALso in your present scheme the length field is not big enough (8 bits) > because a FQDN can be 255 bytes. Good catch...thanks. > I have some other comments I will send to you on editing and > nomenclature on the draft off line. Thanks. > Also not everyone that joined this list may know what the "dentist" > office scenario is and it might be good to put it in an appendix of your > draft. As you use it as an example where this is important too and I > agree it is. But it should be documented for others. Good idea...I'll write something up as an appendix. 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 Feb 25 17:32:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA01972; Tue, 25 Feb 1997 17:27:32 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA01965; Tue, 25 Feb 1997 17:27:24 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA13600; Tue, 25 Feb 1997 17:27:57 -0800 Received: from INET-05-IMC.microsoft.com (mail5.microsoft.com [131.107.3.31]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA02613 for ; Tue, 25 Feb 1997 17:27:59 -0800 Received: by INET-05-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC233B.B6B418B0@INET-05-IMC.microsoft.com>; Tue, 25 Feb 1997 16:48:23 -0800 Message-ID: From: Richard Draves To: "'IPng List'" Subject: (IPng 3091) GSE and NAT Date: Tue, 25 Feb 1997 12:59:05 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1537 I was thinking about section 15 in Mike's new draft, comparing GSE and NAT, and I realized that there's something that I don't understand about GSE. The intractable problem with NAT is dealing with unknown protocols or applications that embed addresses in their data. The NAT box can't translate embedded addresses that it doesn't know about. Why doesn't GSE suffer from the same problem? Section 10.1 says that the initial RG for a source address is "almost always" (when is it not?) the site-local prefix. I assume therefore that when an application does a getsockname() the IPv6 address it gets back uses the site-local prefix. Then when the application embeds its address in payload and sends it to another site, the routing goop does not get translated properly. On the other hand, if getsockname() does return an address with a real RG prefix, then other problems follow. The isolation of the end system from external topology changes breaks down. How does the end system get the RG to return to the application? And if the external topology changes while the application has the address cached, then the application breaks. I think breaking long-running applications is much more serious than breaking long-running TCP connections. Thanks, Rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 25 18:57:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA02100; Tue, 25 Feb 1997 18:51:51 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA02093; Tue, 25 Feb 1997 18:51:37 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA27525; Tue, 25 Feb 1997 18:52: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 SAA20926 for ; Tue, 25 Feb 1997 18:52:07 -0800 From: Masataka Ohta Message-Id: <199702260249.LAA09594@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA09594; Wed, 26 Feb 1997 11:49:25 +0900 Subject: (IPng 3092) 8+8 security To: mo@UU.NET (Mike O'Dell) Date: Wed, 26 Feb 97 11:49:24 JST Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 6579 Mike; At San Jose, steve said we can't produce WG draft unless we cooperated. So, why did you wrote: draft-ietf-ipngwg-gseaddr-00.txt by yourself, even though I send several mails attempting to reach some consensus? Anyway, let's move forward. attached is a draft Internet Draft of my security analysis of locator-ID separation, which is missing from yours. I hope they can be merged to be a real WG draft. See you at Palo Alto. I'm getting late for my plain. Masataka Ohta INTERNET DRAFT M. Ohta draft-ietf-ipngwg-id-security-addr-arch-00.txt Tokyo Institute of Technology February 1997 Identity and Security Implications of IPv6 Addressing Architectures Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo describes the identity and security implications of IPv6 addressing architectures. 1. Configuration In this memo, identity and security implications of IPv6 addressing architectures are considered. The situation considered is that how a host of some organization (home organization) visiting somewhere else (foreign LAN of foreign organization) outside of the organization's LAN (home LAN) can be relied from other hosts of the home organization. If a host reside within LAN of its own organization, the security is obvious by simple firewalling and is not considered by this memo. Finally, most of this memo is dedicated to the establishment of weak security, because real security is secure, regardless of any attempt to break it and the only possible attack is denial of service attack. 2. Stateless Autoconfiguration without Identification is Insecure. M. Ohta Expires on August 31, 1997 [Page 1] INTERNET DRAFT Identity and Security of IPv6 February 1996 Obviously, if a host is autoconfigured its own address and other information from a foreign organization, the information is not useful for the security or, not even to identify the host as is. To let other hosts in the home organization identify the host, there must be some identification recognizable at least by the home organization. But, such identification can easily be forged by anyone and is totally insecure. As discussed in the next section, if the requirement is weak security, A workaround with DNS is possible, as long as the autoconfigured address is registered to DNS forward lookup. But, to do so securely, the host must be relied by dynamic update server(s) of home organization. To let other hosts in the home organization rely the host, there must be some security relationship established in advance. At the same time, we do need some identifier or index of the security relationship, assigned by the home organization. That is, for stateless autoconfiguration be secure (even weakly), we need some some real security, which means some state. We also need some identifier, which must be independent of the location of the foreign LAN. This, naturally, lead to the addressing architecture of Locator+ID. It is obvious that, without some indexing information on security relationship, it is impossible to establish the real security. 3. Establishing Weak Security based on DNS-registered Locator Weak security means that some host does exist at the location designated in DNS. It can be confirmed by, for example, sending some random information to the host with it's DNS-registered location and see it replied back. It is practically assumed that TCP sequence numbers are random enough and that intermediate routers toward the DNS-registered location are reliable. Now, if a packet is sent from some host with some locator, its DNS name can be retrieved through unreliable reverse lookup mechanism. M. Ohta Expires on August 31, 1997 [Page 2] INTERNET DRAFT Identity and Security of IPv6 February 1996 Then, if the forward lookup of locators of the DNS name is successful, one of the locator in the looked up set should be used to reply to the sender of the original packet. If the source locator of the original packet is included in the looked up set, the locator should better be preferred. 4. Rewriting Locators As shown in the previous section, locator information is not necessary for the establishment of weak security. On the other hand, there are a lot of protocols simplied if writing locators by some intermediate entities is allowed. Thus, it is desirable to allow so. As can be seen in the discussion in the previous section, the only requirement is that source DNS name can be looked up without using the source locator part. That is, the requirement is that source ID is location independent, globally unique and have some structure for hierarchical DNS lookup. 5. Security Considerations Everything in this memo is the security considerations. 6. Author's Address Masataka Ohta Computer Center Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku Tokyo 152, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3415 EMail: mohta@necom830.hpcl.titech.ac.jp M. Ohta Expires on August 31, 1997 [Page 3] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 25 21:53:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA02244; Tue, 25 Feb 1997 21:48:10 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA02237; Tue, 25 Feb 1997 21:48:00 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA18271; Tue, 25 Feb 1997 21:48:34 -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 VAA28715 for ; Tue, 25 Feb 1997 21:48:36 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id AAA26673; Wed, 26 Feb 1997 00:42:39 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA15195; Wed, 26 Feb 1997 00:42:38 -0500 Message-Id: <9702260542.AA15195@wasted.zk3.dec.com> To: Richard Draves Cc: "'IPng List'" Subject: (IPng 3093) Re: GSE and NAT In-Reply-To: Your message of "Tue, 25 Feb 97 12:59:05 PST." Date: Wed, 26 Feb 97 00:42:38 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 532 Rich, As your not going to be at the meeting I will bring this up and I see it too. I just wrote it on my copy of the spec I am taking. I agree with you. The entire issue of embedded or any assumptions of addresses has to be reviwed too. /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 Feb 25 23:22:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA02358; Tue, 25 Feb 1997 23:17:29 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA02351; Tue, 25 Feb 1997 23:17:21 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA26548; Tue, 25 Feb 1997 23:17:55 -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 XAA13707 for ; Tue, 25 Feb 1997 23:17:57 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcenl26701; Wed, 26 Feb 1997 02:15:23 -0500 (EST) Message-Id: To: bound@zk3.dec.com cc: Richard Draves , "'IPng List'" Subject: (IPng 3094) Re: GSE and NAT In-reply-to: Your message of "Wed, 26 Feb 1997 00:42:38 EST." <9702260542.AA15195@wasted.zk3.dec.com> Date: Wed, 26 Feb 1997 02:15:22 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 617 it's the same issue for TCP and UDP - if you want to use the addresses for simple identity purposes, use the ESD. if you want to send something that's going to be used to reach you, send a domain name so the other end can get a translation with the right RG. putting the IPv6 equivalent of dotted quads in a packet won't work -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@sunroof.eng.sun.com Wed Feb 26 04:22:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA02668; Wed, 26 Feb 1997 04:16:45 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA02661; Wed, 26 Feb 1997 04:16:38 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA20897; Wed, 26 Feb 1997 04:17:12 -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 EAA13182 for ; Wed, 26 Feb 1997 04:17:14 -0800 Received: from big-dogs.cisco.com ([171.68.53.92]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id EAA01074; Wed, 26 Feb 1997 04:17:06 -0800 (PST) Message-Id: <3.0.32.19970226071705.006da48c@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 26 Feb 1997 07:17:07 -0500 To: "Mike O'Dell" From: Paul Ferguson Subject: (IPng 3096) Re: GSE and NAT Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 782 At 02:15 AM 2/26/97 -0500, Mike O'Dell wrote: > >it's the same issue for TCP and UDP - if you want to use the >addresses for simple identity purposes, use the ESD. if you want >to send something that's going to be used to reach you, >send a domain name so the other end can get a translation >with the right RG. > I can't help but think that such reliance on, and integration of, the DNS into the routing system is a major flaw. When I keep reading things like this, my fears are reborn. - 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@sunroof.eng.sun.com Wed Feb 26 05:47:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA02752; Wed, 26 Feb 1997 05:42:03 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA02745; Wed, 26 Feb 1997 05:41:55 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA27758; Wed, 26 Feb 1997 05:42:28 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA07855 for ; Wed, 26 Feb 1997 05:42:29 -0800 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA60967; Wed, 26 Feb 1997 13:42:26 GMT Date: Wed, 26 Feb 1997 13:42:26 GMT Message-Id: <9702261342.AA60967@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3097) Re: GSE and NAT To: ipng@sunroof.eng.sun.com In-Reply-To: <3.0.32.19970226071705.006da48c@lint.cisco.com> from "Paul Ferguson" at Feb 26, 97 07:17:07 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1813 IPv6-enabled applications must not embed IPv6 addresses in non-dynamically-refreshed state. Legacy IPv4 applications do this, but that is legacy. RFC 1900 explores this issue. GSE addressing doesn't actually change anything here, but provides the ESD which can be safely embedded in dynamically-refreshed state. As for using DNS to look up RG, I fail to see why that differs from using DNS today to look up the network number portion of an IPv4 address. It's true that there are emergency modes of communication where you may type in an IPv4 address, and there may be emergency modes where you need to type in the RG. What's the philosophical difference? Brian Carpenter >- Paul Ferguson said: > > At 02:15 AM 2/26/97 -0500, Mike O'Dell wrote: > > > > >it's the same issue for TCP and UDP - if you want to use the > >addresses for simple identity purposes, use the ESD. if you want > >to send something that's going to be used to reach you, > >send a domain name so the other end can get a translation > >with the right RG. > > > > I can't help but think that such reliance on, and integration of, > the DNS into the routing system is a major flaw. When I keep reading > things like this, my fears are reborn. > > - 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@sunroof.eng.sun.com Wed Feb 26 06:32:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02806; Wed, 26 Feb 1997 06:26:17 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02799; Wed, 26 Feb 1997 06:26:10 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA03306; Wed, 26 Feb 1997 06:26:43 -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 GAA24138 for ; Wed, 26 Feb 1997 06:26:45 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA18209; Wed, 26 Feb 1997 09:17:58 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA02643; Wed, 26 Feb 1997 09:17:55 -0500 Message-Id: <9702261417.AA02643@wasted.zk3.dec.com> To: "Mike O'Dell" Cc: bound@zk3.dec.com, Richard Draves , "'IPng List'" Subject: (IPng 3098) Re: GSE and NAT In-Reply-To: Your message of "Wed, 26 Feb 97 02:15:22 EST." Date: Wed, 26 Feb 97 09:17:55 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 498 the problem is that existing apps don't look at a fqdn.. then the issue is how much of these problems will and do exist... i think that has be part of the effort for gse viability here. or compromises by gse. /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 Wed Feb 26 06:33:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02815; Wed, 26 Feb 1997 06:27:21 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02808; Wed, 26 Feb 1997 06:27:12 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA03528; Wed, 26 Feb 1997 06:27:44 -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 GAA24508 for ; Wed, 26 Feb 1997 06:27:44 -0800 Received: from big-dogs.cisco.com ([171.68.53.92]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id GAA12562; Wed, 26 Feb 1997 06:26:40 -0800 (PST) Message-Id: <3.0.32.19970226092634.006e1120@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 26 Feb 1997 09:26:41 -0500 To: "(Brian E Carpenter)" From: Paul Ferguson Subject: (IPng 3099) Re: GSE and NAT Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1329 At 01:42 PM 2/26/97 GMT, (Brian E Carpenter) wrote: > >As for using DNS to look up RG, I fail to see why that >differs from using DNS today to look up the network number >portion of an IPv4 address. It's true that there are emergency >modes of communication where you may type in an IPv4 address, >and there may be emergency modes where you need to type in >the RG. What's the philosophical difference? > Perhaps I'm misunderstanding something here (wouldn't be the first time), but the way I understand the concept is that there would be a (semi ?) reliance on DNS in the *routing* infrastructure, not just in name<-->address resolution. Or perhaps this is a semantics issue, since the upper portion of the prefix is routing goop, and the lower portion for host bits, what is meant here is that since there are no requirements for the lower bits to be unique, that to resolve the ESD, a resolution to DNS is required to match the appropriate ESD. I dunno. This doesn't seem quite comparable to the relationship between IPv4 and DNS. - 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@sunroof.eng.sun.com Wed Feb 26 06:58:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02839; Wed, 26 Feb 1997 06:52:47 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02832; Wed, 26 Feb 1997 06:52:40 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA11719; Wed, 26 Feb 1997 06:53:13 -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 GAA04128 for ; Wed, 26 Feb 1997 06:53:14 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id GAA29970; Wed, 26 Feb 1997 06:52:14 -0800 Message-Id: <199702261452.GAA29970@puli.cisco.com> To: "(Brian E Carpenter)" cc: ipng@sunroof.eng.sun.com Subject: (IPng 3100) Re: GSE and NAT In-reply-to: Your message of "Wed, 26 Feb 97 13:42:26 GMT." <9702261342.AA60967@hursley.ibm.com> Date: Wed, 26 Feb 97 06:52:14 PST From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 487 Brian, > IPv6-enabled applications must not embed IPv6 addresses > in non-dynamically-refreshed state. Since you used the word "must", can you point me to any IETF document that mandates this ? Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 26 07:15:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA02882; Wed, 26 Feb 1997 07:09:31 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA02871; Wed, 26 Feb 1997 07:09:23 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA16972; Wed, 26 Feb 1997 07:09:55 -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 HAA10982 for ; Wed, 26 Feb 1997 07:09:54 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQceoq13834; Wed, 26 Feb 1997 10:09:45 -0500 (EST) Message-Id: To: Paul Ferguson cc: "Mike O'Dell" , ipng@sunroof.eng.sun.com Subject: (IPng 3101) Re: GSE and NAT In-reply-to: Your message of "Wed, 26 Feb 1997 07:17:07 EST." <3.0.32.19970226071705.006da48c@lint.cisco.com> Date: Wed, 26 Feb 1997 10:09:43 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 740 it does NOT integrate DNS into the routing system any more than current reliance on DNS does. if you want to know how to turn a string into something useful for getting to the destination, you ask DNS this is not a fundamental change to anything actually having DNS get correct information from the routing system would actually be a material operational improvement and will *reduce* the amount of manual information moving (ie, "configuration") -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@sunroof.eng.sun.com Wed Feb 26 07:30:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA02910; Wed, 26 Feb 1997 07:25:22 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA02903; Wed, 26 Feb 1997 07:25:14 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA22024; Wed, 26 Feb 1997 07:25:49 -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 HAA17112 for ; Wed, 26 Feb 1997 07:25:46 -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 QAA13491 for ; Wed, 26 Feb 1997 16:25:44 +0100 (MET) Received: (from durand@localhost) by rama.imag.fr (8.8.0/8.8.Beta.3) id RAA07989 for ipng@sunroof.Eng.Sun.COM; Wed, 26 Feb 1997 17:27:13 +0100 (MET) From: "Alain Durand" Message-Id: <970226172713.ZM7974@rama.imag.fr> Date: Wed, 26 Feb 1997 17:27:13 +0100 X-Mailer: Z-Mail (4.0b.514 14may96) To: ipng@sunroof.eng.sun.com Subject: (IPng 3102) new draft: GSE+ MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.1970226172713.ZM7974.imag.fr" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 6942 -- --PART-BOUNDARY=.1970226172713.ZM7974.imag.fr Content-Type: text/plain; charset=us-ascii Hi, I'm truely sorry to publish this so late before the interim meeting, but I hope this might be of some interest. I have attached a small draft I have writen. It is a proposed modification of draft-ipng-gseaddr-00.txt. The main idea is to introduce a SID, Site IDentifier inside the ESD. This might help solving some issues about as the uniqueness of ESD, security & reverse DNS lookup. - Alain Durand. ps: unfortunatly, I will not be at the interim meeting... :-( --PART-BOUNDARY=.1970226172713.ZM7974.imag.fr X-Zm-Content-Name: draft-durand-gse+-00.txt Content-Type: text/plain ; name="draft-durand-gse+-00.txt" ; charset=us-ascii Content-Disposition: attachment ; filename="draft-durand-gse+-00.txt" Network Working Group Alain Durand Internet-Draft IMAG 1997/02/26 14:32:32MET GSE+ - An Alternate Addressing Architecture to GSE 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa) , nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast ), or ftp.isi.edu (US West Coast). 2. Abstract This document present an alternative addressing architecture to the GSE proposal (draft-ipng-gseaddr-00.txt) of Mike O'dell. The basic change is the introduction of a site identifier in the ESD. 3. Introduction There are several issues in the GSE proposal that remains unsolved in the author mind: A - How to allocate IETF-nodeIDs? B - How to make sure that the ESD is globally unique? C - How to prevent someone from injecting a fake ESD in the public topology.? D - How can a firewall reject packets coming from a particular site? E - How to do reverse DNS lookup for an ESD? The author believe that the source of all those issue is the lack of a Site Identifier in the ESD. 4. Addresses In the GSE proposal, an IPv6 address is split into 3 pieces: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Routing Goop | STP| End System Designator | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6+ bytes ~2 bytes 8 bytes This proposal suggest to split the IPv6 address in 3 other pieces: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Routing Goop | SID | SESD | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 6 bytes | 4 bytes | 6 bytes | | | | | \----------------/ \----------------------------/ 48 bits 80 bits ESD Routing Goop 5. SID, Site IDentifier The SID is a 32 bits token. It identify a site in the global Internet. It is attributed by a regional registry. and belong to this registry. If a site is multi homed, it is allocated only one SID. When a site change provider or change location within the scope of the regional registry, it keeps the same SID. The SID might be split into 2 fields, a Regional Registry ID (RRID) and a Regional Registry SID (RRSID). The exact number of bits for each field is not discussed in this proposal. The allocation of SID is much simpler than the IETF-NodeID one. This greatly simplify issue A. 6. SESD, Site End System Designator The SESD is a 48 bit token. It identify a node within a site. The exact usage of the bits of this field is left to the site policy. Suggested structures are: 1 - 48 bit IEEE mac address (for flat site topologies) 2 - 8 bits local network address + 40 lower bits of IEEE mac address 3 - 16 bits local network address + 32 lower bits of IEEE mac address 4 - 16 bits local network address + 32 bits IPv4 address 5 - 16 bits local network address + 32 bits token assigned by DHCP Using solutions 1, 2 or 3 with stateless auto configuration is possible. Conflicts might happen, but they will be rare and they can be detected with DAD. 7. ESD, END System Designator The ESD is the 80 bits token made of the SID and the SESD. By construction, it is guaranteed globally unique. This solves issue B. 8. Border router security The public topology router should enforce that packets coming from a particular site have the correct SID bits set. This will solve issue C. A border router will do routing goop rewriting in the very same way as in the GSE proposal. It can also filter incoming packets on the SID basis. This will solve issue D. 8. Reverse DNS lookup. The author believes that one should be able to do reverse DNS lookup for an ESD. A reverse top level domain (like esd.ip6.int) could delegate RRID to the regional registries which could then delegate RRSID to the sites. This should solve issue E. 9. Comparison with the GSE proposal The main shift from the GSE proposal is in the introduction of a the SID notion. All other aspects of the GSE model remains identical. 10. Security consideration The SID will help firewalls to filter traffic on a site per site basis. Public topology entry router should enforce that the SID bits of packets coming from a customer are the correct one. This should improve the security of the GSE model. 11. Author address Alain Durand Institut d'Informatique et de Mathematiques Appliquees de Grenoble IMAG BP 53 38041 Grenoble CEDEX 9 France Phone : +33 4 76 63 57 03 Fax : +33 4 76 51 49 64 E-Mail: Alain.Durand@imag.fr --PART-BOUNDARY=.1970226172713.ZM7974.imag.fr-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 26 08:37:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA03064; Wed, 26 Feb 1997 08:32:23 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA03057; Wed, 26 Feb 1997 08:32:16 -0800 Received: from saturn3.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA07573; Wed, 26 Feb 1997 08:32:50 -0800 Received: from mailhub.axion.bt.co.uk (mailhub.axion.bt.co.uk [132.146.5.4]) by saturn3.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA16549 for ; Wed, 26 Feb 1997 08:30:32 -0800 Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 26 Feb 1997 16:28:39 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA03823; Wed, 26 Feb 1997 16:24:27 GMT Date: Wed, 26 Feb 1997 16:24:27 +0000 (GMT) From: George Tsirtsis To: Alan.Durand@imag.fr Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3103) RE:new draft: GSE+ Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1689 Hello, The GSE+ draft tries to solve a problem with Mike's GSE draft which is the the fact that we moved the site prefix to the upper 8 bytes and that looks somewhat strange IMHO. Alan's draft tries to fix that puting a SESD field in the lower 8 bytes and that is fair enough (if we forget that a lot of people said that ESD should be 64bits long and that is probably why Mike changed it in the first place) My problem is that in paragraph 6, SESD can be 0, 8 or 16 bits! That, I find is not very good, because if I start from flat rooting with SESD=0 and in the future deside that is time to create subnetworks in my private network, I will have to renumber all my hosts. Furthermore, if I understand correctly, ESD is an identifier and should not be changed. Regards George George Tsirtsis -------------------------------------------------------------------------- Network Research Tel : 0044-1473-640756 BT Labs Fax : 0044-1473-640709 Ipswich e-mail: george@gideon.bt.co.uk -------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. -------------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 26 10:41:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03335; Wed, 26 Feb 1997 10:35:35 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03328; Wed, 26 Feb 1997 10:35:25 -0800 Received: from saturn3.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA07372; Wed, 26 Feb 1997 10:35:58 -0800 Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by saturn3.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA08594 for ; Wed, 26 Feb 1997 10:33:48 -0800 Received: from ns3.BayNetworks.COM (ns1.corpemea.baynetworks.com [141.251.211.30]) by mailhost3.BayNetworks.COM (8.8.5/BNET-96/12/06-E) with ESMTP id NAA07930 Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17]) by ns3.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with SMTP id TAA24952 Posted-Date: Wed, 26 Feb 1997 19:34:38 +0100 (MET) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0) by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1) id AA17172; Wed, 26 Feb 97 13:34:22 EST Received: from greenfield.engeast.baynetworks.com (greenfield.corpeast.baynetworks.com [192.32.170.19]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA13396; Wed, 26 Feb 1997 13:34:17 -0500 Message-Id: <3.0.32.19970226133440.0069d040@pobox.engeast.baynetworks.com> X-Sender: dhaskin@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 26 Feb 1997 13:34:41 -0500 To: "Alain Durand" , ipng@sunroof.eng.sun.com From: Dimitry Haskin Subject: (IPng 3104) Re: new draft: GSE+ Cc: dhaskin@pobox.engeast.baynetworks.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1240 Alain, The concepts presented in your draft has been discussed on the list. Though I agree with the general approach, I believe the predominant opinion was that 4 bytes is not enough to identify all possible sites (it is below the requirement to support at least 10^9 sites). This is why I proposed to look into 5(RG)+5(SID)+6 or 6(RG)+6(SID)+4 address layout instead of 6(RG)+4(SID)+6 as your suggested. Dimitry At 05:27 PM 2/26/97 +0100, Alain Durand wrote: >Hi, > >I'm truely sorry to publish this so late before the interim >meeting, but I hope this might be of some interest. > >I have attached a small draft I have writen. It is a proposed >modification of draft-ipng-gseaddr-00.txt. > >The main idea is to introduce a SID, Site IDentifier >inside the ESD. This might help solving some issues >about as the uniqueness of ESD, security & reverse DNS lookup. > > - Alain Durand. > >ps: unfortunatly, I will not be at the interim meeting... :-( > > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 26 10:47:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03348; Wed, 26 Feb 1997 10:40:49 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03341; Wed, 26 Feb 1997 10:40:39 -0800 Received: from saturn3.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA09122; Wed, 26 Feb 1997 10:41:12 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by saturn3.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA11056 for ; Wed, 26 Feb 1997 10:39:05 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcepe04830; Wed, 26 Feb 1997 13:41:05 -0500 (EST) Message-Id: To: "Alain Durand" cc: ipng@sunroof.eng.sun.com Subject: (IPng 3105) Re: new draft: GSE+ In-reply-to: Your message of "Wed, 26 Feb 1997 17:27:13 +0100." <970226172713.ZM7974@rama.imag.fr> Date: Wed, 26 Feb 1997 13:41:05 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 572 it's clear that we need 8-byte mac addresses - they are going to happen one way or another. as for IETF-NodeIDs, my draft explicitly specifies allocating them in semantic clusters as we do IPv4 addresses now. and 32-bits for "Site-ID" is nowhere near enough bits cheers, -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@sunroof.eng.sun.com Wed Feb 26 11:42:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA03416; Wed, 26 Feb 1997 11:36:55 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA03409; Wed, 26 Feb 1997 11:36:45 -0800 Received: from saturn3.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA25345; Wed, 26 Feb 1997 11:37:18 -0800 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn3.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA11137 for ; Wed, 26 Feb 1997 11:35:10 -0800 Received: from ns2.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by mailhost2.BayNetworks.COM (8.8.5/BNET-96/12/06-E) with ESMTP id LAA14072 Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17]) by ns2.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with SMTP id LAA06839 Posted-Date: Wed, 26 Feb 1997 11:36:39 -0800 (PST) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0) by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1) id AA22876; Wed, 26 Feb 97 14:36:30 EST Received: from greenfield.engeast.baynetworks.com (greenfield.corpeast.baynetworks.com [192.32.170.19]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA20663; Wed, 26 Feb 1997 14:36:23 -0500 Message-Id: <3.0.32.19970226143647.006943d4@pobox.engeast.baynetworks.com> X-Sender: dhaskin@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 26 Feb 1997 14:36:47 -0500 To: "Mike O'Dell" , "Alain Durand" From: Dimitry Haskin Subject: (IPng 3106) Re: new draft: GSE+ Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1413 At 01:41 PM 2/26/97 -0500, Mike O'Dell wrote: >it's clear that we need 8-byte mac addresses - they are going >to happen one way or another. > No, it is not clear at all if we use SID to identify sites and subnets. >as for IETF-NodeIDs, my draft explicitly specifies allocating >them in semantic clusters as we do IPv4 addresses now. > I believe (unless I misunderstood your draft) that your IETF-NodeIDs do not support stateless autoconfiguration of global scop addresses. This is unnecessary limitation and IMO is a fatal flaw. Another problem is that the use of the IETF-NodeIDs is optional (for those who do not believe that IEEE MAC address is unique enough or would like to do inverse DNS lookups). It is not like choosing what to have for lunch with no consequences to others. We usually do lookups on someone else addresses not own ones (incidently your ftp server refused my connection attempts because it didn't succeeded in mapping my v4 address to a domain name ;). >and 32-bits for "Site-ID" is nowhere near enough bits > I believe it is correctable by increasing the SID size. > cheers, > -mo Regards, Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Feb 26 15:40:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA03782; Wed, 26 Feb 1997 15:34:47 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA03775; Wed, 26 Feb 1997 15:34:39 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA22678; Wed, 26 Feb 1997 15:35:12 -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 PAA05160 for ; Wed, 26 Feb 1997 15:33:01 -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 PAA04549; Wed, 26 Feb 1997 15:35:14 -0800 Message-Id: <3.0.1.32.19970226153353.006b7598@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 26 Feb 1997 15:33:53 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3107) Draft Agenda for Interim IPng 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 content-length: 1436 Attached is the draft agenda for the Thursday/Friday meeting. Bob --------------------------------- Thursday -------- 9:00am Introduction 9:05am Review Agenda 9:15am 8+8 Overview 10:15am Break 10:30am Detailed Review Uniqueness of ESD's DNS forward lookups DNS reverse lookups DNS Structure TCP/UDP Connection Identification Effects on Applications Rewriting of RG (inbound, outbound) 12:00pm Lunch 1:30pm Continuation of Detailed Review Map RG into current Internet Rehoming Site Multihoming Site Rehoming Multihomed Site Rehoming Small Provider Multihoming Small Provider Rehoming Multihomed Small Provider 4:00pm Summary of Discussions Friday -------- 9:00am Review Remaining Agenda 9:10am Review impact on existing specifications Base IPv6 Specification Addressing Architecture Provider Based Addressing Documents Neighbor Discovery Address Autoconfiguration IPoverFoo ICMP .... 12:00pm Lunch 1:30pm New Documents which Need to be Written GRE Specification ESD Guidelines RG Allocation ..... 3:00pm Impact on Implementations 4:00pm Summary and Conclusions ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 26 17:15:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04187; Wed, 26 Feb 1997 17:09:50 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04180; Wed, 26 Feb 1997 17:09:38 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA15707; Wed, 26 Feb 1997 17:10:11 -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 RAA18168 for ; Wed, 26 Feb 1997 17:07:54 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id BA16002; Thu, 27 Feb 1997 12:10:03 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: (IPng 3108) Comments on GSE Date: Thu, 27 Feb 1997 12:10:02 +1100 Message-Id: <882.857005802@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 8096 Let me start by saying that I support the general thrust of the gseaddr draft (and 8+8 before that). None of the comments below should be taken to suggest that I prefer the current addressing architecture. Next I was pleased to see that Mike is now coming to the view that sometime in the future it might be possible to automate address (RG in this case) allocations, and have routers work out between themselves (perhaps with some guidance) what addresses (RG) should be used, and that we won't have to have humans do this forever. Future sure, and who knows how far, but we want to make sure the architecture recognises this as possible, that's great. My biggest problem with the GSE doc is that it spends a lot of time solving a problem that does not (or should not) exist in IPv6. That is, there's a lot of effort there to attempt to hide from a node the fact that its RG has altered. This seems to be driven by the difficulties of renumbering an IPv4 host, which in many cases requires a reboot to accomplish successfully. IPv6 isn't supposed to suffer from that kind of nonsense - renumbering is supposed to simply happen - there's no need at all to attempt to isolate from a host the fact that the RG has changed. In fact, it is worse than that - more to come. The one place where previously there was a problem was with upper layers using the IP layer addresses as identifiers - that's solved by the RG/ESD split. As long as the (relatively) invariant ESD is used as the identifier, this problem vanishes. In the draft, Mike indicates that though this particular problem goes, connections won't remain alive, as the peer won't know to switch to using new RG to reach the node whose RG has altered, so eventually, once the old RG is no longer supported, all that will be left is one way communications. Mike attributes this problem to the supposed impossible security problem of notifying the peer about the RG change. Though I'm not a security person, I find this hard to believe. I'd have thought we have here one of the easier security problems to solve, as all that's needed is authentication without identity. That is, no key distribution scheme is needed at all. The point being that at the time a connection is established, we have two parties, and all they care about is that the two of them continue communicating. They don't care who the other guy really is (if they do they have to use the authentication header or similar, and once using that the "I have moved' thing is trivial). However, what is important is that once communication is established (which may involve some application level authentication unknown to the IP level) that it be at the least difficult to be "hijacked" - for someone to block communications from one end and substitute himself. If it were possible to send a simple "I am now here" message, and be believed, there would be no protection of that kind at all any more. However, since all that is needed for an "I am here" to be believed is proof that it came from the same node that initially opened the connection, it should be possible to dream up a scheme where during the 3-way SYN handshake (if this connection is of the nature that you want it to be able to survive RG changes - ie: you wouldn't bother for SMTP, HTTP, etc, but might for telnet, X, ...) the two nodes exchange public key info (note: this can be a newly invented key just for this one connection, it need not be in any key registry) in a way that each now knows enough about the other to be able to verify that any packet claiming to be from the other is in fact from them. That would be all it knows - still no knowledge of who is really out there, just "when he connected he knew some secret, if when he tells me he has moved he knows the same secret, then it must really be him". I have a scheme I think might work for this (could be sent as either TCP or IPv6 end-to-end options), but this isn't the place for that. In any case, I don't really believe that security is a big issue here - clearly security is needed for an "I have moved" message to be accepted, but I don't think there's anything difficult about providing sufficient security. However, and now we return to the point above, the real problem with implementing any kind of "I have moved" with the GSE addressing as the draft is now written, is that the host doesn't know it has "moved" (that its RG has altered), because the draft goes to great pains to make sure it never needs to find out, and so hides this information so thoroughly, that even given a secure method to send the "I have moved" message, no-one would (almost) ever know when one should be sent. My other major (technical) problem with the draft is the expectation that a nameserver can have two "faces". While it is indeed possible to set up nameservers that can be coerced to work that way, doing so is going directly against the DNS model. That is, only a subset of reasonable DNS configurations can possibly be made to work this way. That this is done for IPv4 simply means that the IPv4 sites that do this live within this subset - usually because of NAT, and needing addresses fiddled. Two obvious drawbacks of a two-faced DNS server ... one is that it would need to be the one magic host that knows what the actual RG's are for local hosts. That is, in order to return the site-local address when a request arrives from a site-local address, it must be able to see from what is in the DNS that the address sought is one that is at this site. It's no use returning the site-local address of some node at some different site just because a node at my local site happened to ask using its site local address, is it? The only information from which one can deduce whether a node is at this site or some other is the RG in its global address, and that requires the DNS server to know which RG is "local". But worse, the two-faced DNS server implementation assumes that the DNS server being used is at the same site as the addresses being obtained, when an address is for a node at the same site as the node enquiring. While it is possible, with enough effort, to force this to work, it simply is not the way the DNS is supposed to work, and prevents some fairly common implemenattions. Eg: it is not uncommon for a site to contract to its ISP to run its DNS. The ISP provides the DNS servers (which would also typically be running the ISP's own domain(s) and those of other customers, and friends), the customer tells the ISP when data needs to be changed. While it is probably a misconception, managing the DNS is seen as being difficult, and not something that "ordinary mortals" want to bother with. In this sitiation, there may be no DNS server at all inside the site to do the two faced fiddling. I think it is mandatory that the DNS server return all known addresses, then the host can work out that the global addresses returned are at the same site as it is, and choose to use the site local address returned, or are at a different site and choose to avoid using site local addresses. Or that is, they could if they knew the RG that was associated with the local site (all of it) so the node would know which global addresses were using local RG, and then select a site local address for better long term stability. Some of the other comments I have on the draft are almost in the nature of editorial (not quite, they're not spelling etc) and I won't bother with right now. Others have to some extent been addressed in Alain Durand's GSE+ draft - that is, at least the issues are in the open, even if the GSE+ suggested solutions are not the best way. These involve filtering, number->name mappings, etc. But this is enough for one message. kre ps: I will also not be at the interim meeting ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 26 17:39:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04225; Wed, 26 Feb 1997 17:33:45 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04218; Wed, 26 Feb 1997 17:33:36 -0800 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA06307; Wed, 26 Feb 1997 17:34:11 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04495; Wed, 26 Feb 1997 17:34:12 -0800 Date: Wed, 26 Feb 1997 17:34:12 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199702270134.RAA04495@bobo.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3109) Re: GSE and NAT MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 757 > putting the IPv6 equivalent of dotted quads in a packet won't work I assume nobody is suggesting replacing the addresses in the MIBs with domain names. Thus we would end up with snmp returning addresses that might be unreachable - for instance a site interior router would return addresses the have the site local RG so nobody outside the site can reach these addresses unless they can guess the RG. I don't know how much of a real-world concern this would be. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Feb 26 18:51:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA04373; Wed, 26 Feb 1997 18:45:58 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA04366; Wed, 26 Feb 1997 18:45:45 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA05517; Wed, 26 Feb 1997 18:46:13 -0800 Received: from mail.ocs.com.au ([203.34.97.3]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA24033 for ; Wed, 26 Feb 1997 18:43:54 -0800 Received: (qmail 11886 invoked by uid 502); 27 Feb 1997 02:46:50 -0000 Message-ID: <19970227024649.11884.qmail@mail.ocs.com.au> Received: (qmail 11874 invoked from network); 27 Feb 1997 02:46:47 -0000 Received: from ocs3.ocs?net (root@192.168.255.3) by mail.ocs.com.au with SMTP; 27 Feb 1997 02:46:47 -0000 From: Keith Owens To: Robert Elz cc: ipng@sunroof.eng.sun.com Subject: (IPng 3110) Re: Comments on GSE In-reply-to: Your message of "Thu, 27 Feb 1997 12:10:02 +1100." <882.857005802@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Feb 1997 13:47:45 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1908 On Thu, 27 Feb 1997 12:10:02 +1100, Robert Elz wrote: >[Comments about authentication without identity snipped] >However, since all that is needed for an "I am here" to be believed >is proof that it came from the same node that initially opened the >connection, it should be possible to dream up a scheme where during >the 3-way SYN handshake [snip] the two >nodes exchange public key info (note: this can be a newly invented >key just for this one connection, it need not be in any key >registry) [snip]. >That would be all it knows - still no knowledge >of who is really out there, just "when he connected he knew some >secret, if when he tells me he has moved he knows the same secret, >then it must really be him". How do you protect against "man in the middle" attacks? Mallory sniffs the link between Alice and Bob. If the "secret" is just random plain text then at any time Mallory can send a redirect message to Alice containing Bob's "secret" and highjack the connection. Even if the secrets are true public keys, if Mallory is on a router between Alice and Bob, he can still intercept the initial handshake and substitute his public key in both directions. Without a key registry, neither Alice nor Bob can tell that they are talking to Mallory instead of each other. Once again Mallory can send redirect messages and highjack the session. There is also the overhead of generating a true private/public key set for each connection. Obviously authentication *with* identity fixes the above problem. It is not obvious that authentication *without* identity is safe against highjacking. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 26 19:31:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA04394; Wed, 26 Feb 1997 19:26:39 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA04387; Wed, 26 Feb 1997 19:26:32 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA11610; Wed, 26 Feb 1997 19:27:03 -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 TAA04578 for ; Wed, 26 Feb 1997 19:24:41 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id DA32007; Thu, 27 Feb 1997 14:25:24 +1100 (from kre@munnari.OZ.AU) To: Keith Owens Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3111) Re: Comments on GSE In-Reply-To: Your message of "Thu, 27 Feb 1997 13:47:45 +1100." <19970227024649.11883.qmail@mail.ocs.com.au> Date: Thu, 27 Feb 1997 14:25:21 +1100 Message-Id: <931.857013921@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3299 Date: Thu, 27 Feb 1997 13:47:45 +1100 From: Keith Owens Message-ID: <19970227024649.11883.qmail@mail.ocs.com.au> If the "secret" is just random plain text Of course not, however we have to keep in mind the aim here, and that is that IPv6 be no worse than IPv4. If genuine security is wanted, then the authentication (AH), and ESP headers are available, and they can be used. Beyond that, the aim would be simply to avoid IPv6 being less secure than IPv4. All the ways you posed where security could be compromised using the sketch of a scheme I gave could also be used to hijack connections in IPv4, so none of those are really important, we wouldn't be getting worse. The problem with a simplistic "I have moved" (no authentication) message to indicate that RG has changed, is that the existance of such a thing would make it so much easier to hijack connections in IPv6 than IPv4 that everyone would immediately disable it. That is, if we were silly enough to invent it in the first place. All we need here is something that connections that are happy enough with the IPv4 level of insecurity can use to get about the same level of insecurity. When more is wanted, it is available. Even if the secrets are true public keys, The scheme I didn't detail (and still won't, as none of this is really relevant here - please everyone, no security arguments, that would be just a path down the rat hole) planned use of true public/private key pairs, I believe, and I'm certainly no expert, that is all that is necessary (for the level of security that is desired). The public/private pair wouldn't need to be regenerated for each new connection, it could be used over & over, but it could be regenerated as often as desired. if Mallory is on a router between Alice and Bob, he can still intercept the initial handshake and substitute his public key in both directions. Sure, but why bother? If mallory is on the router that's in the path, he can simply monitor &/or change the data anyway, no problem (except keeping the tcp sequence numbering right, but that's not difficult). Remember that we're assuming no other encryption/authentication is being used. Without a key registry, neither Alice nor Bob can tell that they are talking to Mallory instead of each other. Of course not, but nor can people using IPv4, really know that they're talking to the other end. The authentication header provides authentication - all that's needed here is to avoid opening a real huge security hole for the people who don't care about authentication. But please, this isn't a current issue - all that is important here is that it is possible (one way or another) to secure "I have moved" type messages so they can be trusted. How that should be done, and how much overhead is needed (even if it were to mean that only AH authenticated connections could be moved) is not important for any present purpose. Don't let's get side tracked. 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 Thu Feb 27 05:11:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA04765; Thu, 27 Feb 1997 05:05:44 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA04750; Thu, 27 Feb 1997 05:05:28 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA08453; Thu, 27 Feb 1997 05:06:03 -0800 Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id FAA03783 for ; Thu, 27 Feb 1997 05:03:21 -0800 Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id OAA09794 for ; Thu, 27 Feb 1997 14:05:57 +0100 Received: from unknown(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma009530; Thu Feb 27 14:04:50 1997 Received: from hades.mpn.cp.philips.com (hades.mpn.cp.philips.com [130.139.64.31]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-970214) with ESMTP id OAA20071 for ; Thu, 27 Feb 1997 14:04:49 +0100 Received: from pc239.nwm.wan.philips.com (pc239.nwm.wan.philips.com [161.89.1.239]) by hades.mpn.cp.philips.com (8.6.10/8.6.10-1.2a-960910) with SMTP id OAA28914 for ; Thu, 27 Feb 1997 14:03:50 +0100 Message-Id: <1.5.4.32.19970227130348.00754950@hades.mpn.cp.philips.com> X-Sender: rhunter@hades.mpn.cp.philips.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Feb 1997 14:03:48 +0100 To: ipng@sunroof.eng.sun.com From: Ray Hunter Subject: (IPng 3112) re: GSE+ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5145 After having read the proposal and the comments I'd like to add my 1 Guilder's worth to the meeting by email. I am convinced that the approach shown in GSE can be made to work today, and provides a great opportunity for the future. I am not convinced that GSE as it stands today is ready for rubber stamping. Equally, GSE+ attempts to be a long term solution. I do think that _temporarily_ encoding AS numbers in the ESD will solve a number of problems, and enable early deployment without significant hardship later. AS numbers are after all only 0-4095 at the moment, which is only 12 bits ;-) I present a summary of the issues with GSE as I see them, and how using AS numbers would be a _quick_fix_in_the_interim_. I make no claims about encoding AS numbers in the ESD as a long term solution. There is nothing fundamentally new in this proposal (unless you haven't read GSE+ ;-). Meanwhile, we can debate long term solutions over a longer term. I'd hate for nothing to come out of this IETF meeting. Routing Goop Determination at Start-up -------------------------------------- problem raised several times on the list. There is no specific protocol to tie location to ESD. Many other protocols have similar items as an explicit service (e.g. Novell SAP's for virtual server LAN's, Apple ZIP+NBP) The proposed solution is to use DNS to redistribute a routing goop. Paul Ferguson raises the question of whether this is a change in use of DNS, and whether we are now confusing name resolution and routing. I tend to agree that it is confusing (see next section below). AS number change very infrequently, and could be made in to DNS records with a minimum of fuss. They can have a very long TTL. They can be linked to both an inverse tree, in the style of in-addr.arpa, and linked to forward resolution domain names, such as company.com. Routing Goop Variance at Site Re-homing may break routing ---------------------------------------------------------- problem raised by Paul Ferguson. I am presuming that a routing goop is assigned per _entry_point_ of an AS. If this is wrong, then flame me. Routing changes at AS boundaries may break TCP sessions, because this will also change the routing goop seen by the remote host in the source address of packets. This implies that goop records can only have a short TTL, and that load on DNS will increase. Otherwise a goop may change when BGP moves, and the application won't know. Either the application has to time out the TCP session, and start a new session, or the back-up routers have change their re-writing to take over the old goop. This only covers the case where an AS has multi-homing for pure long term back up purposes. To me, this now implies DNS also has to be dynamically updated when a routing goop changes. Otherwise new sessions to a site cannot be started. In my view this _is_ a significant change on the routing/DNS relationship. AS numbers do not change when a site re-routes via another provider, so sessions will survive. Today's routing policies are written in terms of AS numbers. They will be equally valid for IPV6 during initial roll out. ESD not long enough to be globally unique ----------------------------------------- Mike himself raised this issue. Mike believes he has fixed this in the move from 8+8 to GSE. I do not see any reason to disagree. AS numbers today are unique, so any scheme based on a pre-fix AS number together with ANY address scheme that guarantees site uniqueness will provide globally unique addresses. Routing Goop Variance at site re-homing may Break Weak Security --------------------------------------------------------------- comment by Robert Elz Weak security is weak security. Many of these problems stem from the lack of an explicit session layer in the IP view of the world. The fixes all talk in terms of session type activies, but it is still a change to TCP or the application. AS numbers are invariant, so there is no issue with them changing. Furthermore ISP's can implement today's packet based security filters based on an a simple prefix filter of the remote AS. There is no need to get all excited about 10000 ESD's on the other end of the link. Routing Goop Variance Breaks Applications that use Embedded Address ------------------------------------------------------------------- raised by Richard Draves Embedded address application exist. Remember the first FDDI to Ethernet or Ethernet to Token Ring bridges. yuk! AS numbers are invariant and so can be embedded. hope this can be taken on board. best regards, Ray Hunter on contract to Origin Building VA-130, Postbus 218, 5600MD Eindhoven, The Netherlands. email: Ray.Hunter@mpn.cp.philips.com email: Ray.Hunter@globis.net www: http://www.globis.net/~rhunter phone: +31 40 2787988 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Feb 27 08:47:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04935; Thu, 27 Feb 1997 08:42:30 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04928; Thu, 27 Feb 1997 08:42:23 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA21756; Thu, 27 Feb 1997 08:42:59 -0800 Received: from universe.digex.net (universe.digex.net [205.197.248.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA03006 for ; Thu, 27 Feb 1997 08:40:17 -0800 Received: (from boots@localhost) by universe.digex.net (8.6.12/8.6.12) id LAA11298 for ipng@sunroof.eng.sun.com; Thu, 27 Feb 1997 11:42:53 -0500 From: Art Boots Coleman Message-Id: <199702271642.LAA11298@universe.digex.net> Subject: (IPng 3113) mail addressing To: ipng@sunroof.eng.sun.com (IPng List) Date: Thu, 27 Feb 1997 11:42:53 -0500 (EST) Reply-To: boots@universe.digex.net X-Mailer: ELM [version 2.4ME+ PL15 (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 content-length: 434 Pardon me please, Would folks please send mail (and replies) to the list, instead of CC'ing the list. advTHANKSance -Boots ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 28 02:44:09 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA05995; Fri, 28 Feb 1997 02:38:43 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA05988; Fri, 28 Feb 1997 02:38:35 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA01061; Fri, 28 Feb 1997 02:39:11 -0800 Received: from glacier.wise.edt.ericsson.se (glacier-ext.wise.edt.ericsson.se [193.180.251.38]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA13679 for ; Fri, 28 Feb 1997 02:36:42 -0800 Received: from era-t.ericsson.se (anchor.ericsson.se [147.214.173.10]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with SMTP id LAA18511 for ; Fri, 28 Feb 1997 11:39:07 +0100 (MET) Received: from preppens.ericsson.se by era-t.ericsson.se (4.1/SMI-4.0-LME1.4) id AA17594; Fri, 28 Feb 97 11:38:58 +0100 Message-Id: <3316B627.5073@era-t.ericsson.se> Date: Fri, 28 Feb 1997 11:40:39 +0100 From: Thomas Eklund Reply-To: thomas.eklund@era-t.ericsson.se Organization: Ericsson Radio Systems X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 3114) IPv6 performance Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1201 Hi all IPv6 folks, I have recently done a lot of performance measurements in different environments (WAN,LAN etc.). All the results have been what we have expected - with one exception. When you do a ftp data transfer over a 802.3 LAN, it shows that the performance for IPv6 is better than over IPv4. The throughput are a little bit higher and the RTT for each packet are shorter. And there are no retransmissions. Does anyone have a comment on this funny behaviour and is there anyone out there who had noticed the same behaviour? -- Regards / Thomas :-) -------------------------------------------------------------------- | Thomas Eklund ERA/T/N | | Mobile Network and Systems Research | | E-mail:thomas.eklund@era-t.ericsson.se | -------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 28 05:52:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA06243; Fri, 28 Feb 1997 05:47:12 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA06236; Fri, 28 Feb 1997 05:47:04 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA14922; Fri, 28 Feb 1997 05:47:39 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA25165 for ; Fri, 28 Feb 1997 05:45:13 -0800 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA75244; Fri, 28 Feb 1997 13:47:38 GMT Date: Fri, 28 Feb 1997 13:47:38 GMT Message-Id: <9702281347.AA75244@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3115) Re: GSE and NAT To: ipng@sunroof.eng.sun.com In-Reply-To: <199702261452.GAA29970@puli.cisco.com> from "Yakov Rekhter" at Feb 26, 97 06:52:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 989 Yakov, As far as I know this is not written in any standards track or BCP document. It is of course a recommendation in RFC 1900 (which was written with IPv4 in mind, but the arguments are similar for v6). As a matter of fact I hesitated for a long time between "must" and "should" but decided that I was entitled to say "must" in a personal message. The text in RFC 1900 is carefully wordsmithed to avoid being too categorical on this point. Brian >- Yakov Rekhter said: > > Brian, > > > IPv6-enabled applications must not embed IPv6 addresses > > in non-dynamically-refreshed state. > > Since you used the word "must", can you point me to any IETF document that mandates this ? > > Yakov. > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Feb 28 06:08:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06262; Fri, 28 Feb 1997 06:02:58 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06255; Fri, 28 Feb 1997 06:02:50 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA16400; Fri, 28 Feb 1997 06:03:25 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA00246 for ; Fri, 28 Feb 1997 06:00:59 -0800 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18005; Fri, 28 Feb 1997 14:03:24 GMT Date: Fri, 28 Feb 1997 14:03:24 GMT Message-Id: <9702281403.AA18005@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3116) 2 faced DNS is here to stay To: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 763 I'd like to take issue with kre's objections to two-faced DNS being required by GSE (or whatever it's called at the end of the interim meeting). I think it's a fact of life that wherever you have firewalls (with or without NAT) you already have a 2 faced DNS. I don't expect this to change, because sites (and even ISPs) will always want to hide some of their hosts from the world. GSE may add a twist to two-facedness but it is going to become normal anyway. 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@sunroof.eng.sun.com Fri Feb 28 14:58:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA06932; Fri, 28 Feb 1997 14:52:44 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA06925; Fri, 28 Feb 1997 14:52:37 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA04846; Fri, 28 Feb 1997 14:53:14 -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 OAA29182 for ; Fri, 28 Feb 1997 14:50:51 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id WA04690; Sat, 1 Mar 1997 09:53:04 +1100 (from kre@munnari.OZ.AU) To: "(Brian E Carpenter)" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3117) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Fri, 28 Feb 1997 14:03:24 GMT." <9702281403.AA18005@hursley.ibm.com> Date: Sat, 01 Mar 1997 09:53:01 +1100 Message-Id: <1690.857170381@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1128 Date: Fri, 28 Feb 1997 14:03:24 GMT From: "(Brian E Carpenter)" Message-ID: <9702281403.AA18005@hursley.ibm.com> I think it's a fact of life that wherever you have firewalls (with or without NAT) you already have a 2 faced DNS. You didn't read what I said. The difference is that as currently planned in the GSE draft, this two faced DNS is going to be mandatory for everyone. That's an unacceptable change to make (imo), and certainly not one that the ipngwg should be making without talking to DNS people. I didn't ever say that such DNS setups didn't exist now, or wouldn't continue to exist. But in any case, firewalls, of themselves, don't require messing about with the DNS (other than that one way or another you have to make data available both inside and out). 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 Fri Feb 28 15:33:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA07034; Fri, 28 Feb 1997 15:27:42 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA07027; Fri, 28 Feb 1997 15:27:35 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA12748; Fri, 28 Feb 1997 15:28:12 -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 PAA11666 for ; Fri, 28 Feb 1997 15:25:50 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id XA08040; Sat, 1 Mar 1997 10:28:09 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.eng.sun.com Subject: (IPng 3118) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Sat, 01 Mar 1997 09:53:01 +1100." <1690.857170381@munnari.OZ.AU> Date: Sat, 01 Mar 1997 10:28:07 +1100 Message-Id: <1705.857172487@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2852 And to give another example I hadn't thought of the other day. If I have my laptop configured to use my standard (home) DNS server, and I want to continue using that (either so I can continue to find addresses for some "hidden to the rest of the world" hosts, or because I trust it, and not others, or whatever), and I come and visit you, and plug my laptop into the same ethernet as you are connected to - then I want to make a connection to your host. I go to my DNS, which (however this new two faced DNS is going to do this) sees my request comes from a global address (since I'm not at the DNS's local site), does the lookup for me - either from its secondary of your zone, or from its cache, or by going and asking your server, gets back your host's address, which will be the global address, according to the current draft, as the request certainly didn't come from inside the site. Then I have to establish a connection, to this global address, which is on the same cable. But I don't know that, as I have no idea (according to the draft) what RG belongs to the local site, or cable, so I have to send my packet off via the default route (or whatever) to the site border router, which does know that the RG belongs internally, translates the dest RG into site local, and sends the packets back again. Now, at the very least we have packets between two hosts on the same ethernet transitting the whole campus to the site border router and back again. That's silly. There can't even be a redirect, as the site border router isn't on the same cable (I assert). There could be other problems if we investigate this kind of oddity in detail. Note that all this is solved by simply allowing the RG to flow throughout the site, so all nodes know all there is to know. Then rational decisions can be made, two faced DNS's aren't required (but nor are they prohibited), and lots of things become much easier - at the cost of the host having to keep track of perhaps a dozen or two RG's that might be applying at any one time (even if it stretched to hundreds, it would still be manageable, and by the time IPv6 is deployed, we'll probably not be phased by tens of thousands, not that I can see any possible need for so many to co-exist). Then the DNS can return to me all the addresses your host owns, even link-local. I can determine from the global addresses returned that I must be on the same cable as you are, and so pick the link local address if I prefer. Further, my resolver could do all that - applications need not necessarily be bothered. 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