From owner-ipng Thu Feb 1 06:17:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24546; Thu, 1 Feb 96 06:17:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24540; Thu, 1 Feb 96 06:17:00 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04627; Thu, 1 Feb 1996 06:16:10 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id GAA21994; Thu, 1 Feb 1996 06:16:09 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA04634; Thu, 1 Feb 1996 09:05:43 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18674; Thu, 1 Feb 1996 09:05:42 -0500 Message-Id: <9602011405.AA18674@fwasted.zk3.dec.com> To: Scott Bradner Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1338) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: Your message of "Tue, 30 Jan 96 20:28:01 EST." <199601310128.UAA13399@newdev.harvard.edu> Date: Thu, 01 Feb 96 09:05:42 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott, This was too easy. As far as processing the option this adds about 6 lines of code when parsing the IPv6 header. At most 20 lines of code to add the binding to dst cache (a few more if you implement as user space daemon). At most 30 lines of code for the ICMPv6 messages. It is simply another type in the dst cache per ND. The authentication will already exist via IPSEC so thats not an issue (or encryption). Not to be confused with the general issue of firewalls discussion on the list just a lines of code issue. NUD type features would add some more logic but I can't imagine more than 50 lines of code at the high end. As far as state maintained its not an issue (other than the issue of maintaining any state for dst caches its another type). The bottom line is we are talking less than 1K and no where near MBs of code for an IPv6 BSD 4.4 type implementation as a "model". /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 1 06:28:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24558; Thu, 1 Feb 96 06:28:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24552; Thu, 1 Feb 96 06:28:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05549; Thu, 1 Feb 1996 06:27:16 -0800 Received: from watson.ibm.com by mercury.Sun.COM (Sun.COM) id GAA24179; Thu, 1 Feb 1996 06:27:15 -0800 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2487; Thu, 01 Feb 96 09:26:42 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.02 on VAGENT2" id 0205; Thu, 1 Feb 1996 09:26:41 EST Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Thu, 01 Feb 96 09:26:41 EST Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/950830) id AA17939; Thu, 1 Feb 1996 09:26:25 -0500 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9602011426.AA17939@hawpub1.watson.ibm.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1339) Re: (mobile-ip) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: (Your message of Tue, 30 Jan 96 09:45:11 PST.) <199601301745.JAA06973@puli.cisco.com> Date: Thu, 01 Feb 96 09:26:25 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> == me (Charles Perkins) > == Ran Atkinson >> In draft-teraoka-ipv6-mobility-sup-02.txt, there is a proposal >> for a Source Address option. ....... >> ...... Dave and I decided that it wouldn't be >> realistic to propose such an option as a solution to the firewall >> problem, because then firewalls would just start filtering out >> packets that contained Source Address Options. > Why couldn't the IP Authentication Header be used by the firewall to > authenticate the validity of the Source Address Option in the packet ? I'm interested in your proposal, but I'm not familiar enough with all the issues to see exactly how to apply the Authentication Header to make things work out. Could you offer more details? > It seems to me that Teraoka-san's comments are correct here. > The ability to traverse firewalls seems to be operationally valuable. We point out exactly this fact in our draft, but I still don't see how Teraoka-san's solution will solve the problem. > I'd still prefer use of something more like JI's original Mobile IP > technology (from his PhD thesis) More like JI's approach than Teraoka's approach, or more like JI's approach than our approach, or ?? > or the Stanford MosquitoNet approach The MosquitoNet approach is a subset of the IPv4 mobility approach, and explicitly excludes consideration of route optimization techniques. > because only the mobile node needed to be modified for mobility to work > sufficiently. As far as I can tell, any approach that allows route optimization either requires correspondent nodes to route packets directly to care-of addresses or requires big modifications to routers. In the former case, the modifications are pretty small. Any approach that requires packets to go through home agents all the time is going to suffer from a number of problems, many of them carefully detailed in our draft. > It has been a source of some mystery to me (and some others > judging from recent private email) why the IETF didn't take JI's work on > Mobile IP and just move it to Proposed Standard years ago. It's not mysterious to me. I suppose you don't place much value on the recent years' work done by the mobile-IP working group. I claim that the original Columbia approach is not easily scalable. To fully analyze all the tradeoffs has been done, would take a lot of time here, and would probably bore everyone to tears on the mailing list. I also don't understand how trashing years of work by lots of people is going to help us find an acceptable solution for IPv6 mobility. > As an aside, > the issue with reuse of JI's (and Phil Karn's and Matt Blaze's) SWIPE > encryption approach was mainly the desire for crypto > algorithm-independence. Since you brought it up, I also want to add my words of praise for JI's groundbreaking work in the area you mention. His work on the Columbia mobile-IP solution certainly opened a lot of people's eyes to the issues, provided a workable campus-wide solution, and became the basis for other research work by Ramon Caceres, the Dataman project at Rutgers, and others also. I am sure that many people recognize the valuable contributions made by JI. > Ran > rja@cisco.com Charles Perkins ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 1 07:05:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24586; Thu, 1 Feb 96 07:05:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24580; Thu, 1 Feb 96 07:05:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09644; Thu, 1 Feb 1996 07:04:38 -0800 Received: from tera.csl.sony.co.jp by mercury.Sun.COM (Sun.COM) id HAA02133; Thu, 1 Feb 1996 07:04:37 -0800 Received: (from tera@localhost) by tera.csl.sony.co.jp (8.6.12+2.4W/3.3W3) id AAA12293; Fri, 2 Feb 1996 00:03:58 +0900 Message-Id: <199602011504.AAA12293@tera.csl.sony.co.jp> To: perk@watson.ibm.com (Charlie Perkins) Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com Subject: (IPng 1340) Re: (mobile-ip) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: Your message of "Tue, 30 Jan 96 09:43:30 EST." <9601301443.AA56977@hawpub1.watson.ibm.com> Date: Fri, 02 Feb 96 00:03:58 +0900 From: TERAOKA Fumio Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In draft-teraoka-ipv6-mobility-sup-02.txt, there is a proposal > for a Source Address option. ... The option is "Source ID" option. It can also be called "Source Home Address" option. > However, it seems unlikely to me that such an approach can be > relied on. If a Source Address option were used, I don't see > what value could be placed on source address filtering by > firewalls. In other words, the firewalls wouldn't be protecting > against anything. In my approach, the source address field in the basic IPv6 header always indicates the current address of the source node. Since firewalls can know the place from where a received packet comes, filtering works correctly. ------------------------------------------------------------------- TERAOKA, Fumio e-mail: tera@csl.sony.co.jp Sony Computer Science Laboratory Inc. phone: +81-3-5448-4380 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 1 07:34:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24610; Thu, 1 Feb 96 07:34:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24604; Thu, 1 Feb 96 07:33:57 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12879; Thu, 1 Feb 1996 07:33:06 -0800 Received: from tera.csl.sony.co.jp by mercury.Sun.COM (Sun.COM) id HAA08429; Thu, 1 Feb 1996 07:33:03 -0800 Received: (from tera@localhost) by tera.csl.sony.co.jp (8.6.12+2.4W/3.3W3) id AAA12349; Fri, 2 Feb 1996 00:32:42 +0900 Message-Id: <199602011532.AAA12349@tera.csl.sony.co.jp> To: "Thomas Narten" Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com Subject: (IPng 1341) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: Your message of "Wed, 31 Jan 96 16:21:01 -0400." <9601312121.AA15381@cichlid.raleigh.ibm.com> Date: Fri, 02 Feb 96 00:32:42 +0900 From: TERAOKA Fumio Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It took me some time to figure out what the source address spoofing > problem was. The problem is at the mobile's *home* firewall, not the > firewall at the site where the mobile node happens to be at the > moment. Right? That is, the firewall at the mobile's home site sees a > packet with a source address corresponding to an internal node > arriving on an interface outside the site. Could be an intruder, so it > it tosses the packet. Fair enough. In draft-ietf-mobileip-ipv6-00.txt, when a packet from a mobile node traverses the firewall at the visited site, the firewall might discard the packet, since the source address of the packet indicates the outside of the site. (The source adddress field indicates the home address of the source mobile node.) In my approach, the source address field indicates the current point of attachment to the internet. > What is not entirely clear to me is how much Teraoka's option helps > here. At first glance, if a packet from the mobile node were sent back > to a Home Agent with its Source Address set to the mobile's COA > address, the mobile's home firewall could let the packet through. But > this also now means that anyone else could get through the firewall > using the same option. So it's not immediately clear that a firewall > would allow such packets through either. If it did, it would have to > rely on individual nodes within the site "doing the right thing" > (e.g., requiring that any packet containing the option also include an > AH). But one of the main points of a firewall is to *not* defer to > internal nodes on such matters, since internal nodes can't be trusted > in that regard. In my approach, the Authentication Header can authenticate the Home Address and the Current Address of the source node. Since it can be assumed that a mobile node and the firewall at the mobile's home site share a key for authentication, the firewall can authenticate the mobile node. ------------------------------------------------------------------- TERAOKA, Fumio e-mail: tera@csl.sony.co.jp Sony Computer Science Laboratory Inc. phone: +81-3-5448-4380 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 1 08:51:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24700; Thu, 1 Feb 96 08:51:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24694; Thu, 1 Feb 96 08:51:22 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23889; Thu, 1 Feb 1996 08:50:29 -0800 Received: from CHIMAY.MACH.CS.CMU.EDU by mercury.Sun.COM (Sun.COM) id IAB27556; Thu, 1 Feb 1996 08:50:26 -0800 Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa28369; 1 Feb 96 11:49:47 EST To: TERAOKA Fumio Cc: Charlie Perkins , mobile-ip@SMALLWORKS.COM, ipng@sunroof.eng.sun.com In-Reply-To: Your message of "Fri, 02 Feb 96 00:03:58 +0900" <199602011504.AAA12293@tera.csl.sony.co.jp> From: Dave Johnson Subject: (IPng 1342) Re: (mobile-ip) Re: draft-ietf-mobileip-ipv6-00.txt Date: Thu, 01 Feb 96 11:49:43 EST Message-Id: <28367.823193383@CHIMAY.MACH.CS.CMU.EDU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> In draft-teraoka-ipv6-mobility-sup-02.txt, there is a proposal >> for a Source Address option. ... > >The option is "Source ID" option. It can also be called "Source >Home Address" option. > >> However, it seems unlikely to me that such an approach can be >> relied on. If a Source Address option were used, I don't see >> what value could be placed on source address filtering by >> firewalls. In other words, the firewalls wouldn't be protecting >> against anything. > >In my approach, the source address field in the basic IPv6 header >always indicates the current address of the source node. Since >firewalls can know the place from where a received packet comes, >filtering works correctly. This almost certainly won't work as intended, though. People who think that firewalls should filter on source addresses won't be fooled by such an option "hiding" the real source address. These people think they are doing this filtering for a reason. If we define a standard way to "defeat" this filtering, they will just change their firewalls to filter also based on the "hidden" real source address in the option. Dave ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 1 10:16:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24779; Thu, 1 Feb 96 10:16:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24773; Thu, 1 Feb 96 10:16:36 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08016; Thu, 1 Feb 1996 10:15:44 -0800 Received: from timbuk.cray.com by mercury.Sun.COM (Sun.COM) id KAA18864; Thu, 1 Feb 1996 10:15:45 -0800 Received: from ironwood.cray.com (root@ironwood-fddi.cray.com [128.162.21.36]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with ESMTP id MAA02020 for ; Thu, 1 Feb 1996 12:15:43 -0600 Received: from poplar029 (dab@poplar029 [128.162.139.29]) by ironwood.cray.com (8.6.12/CRI-ccm_serv-8-2.8) with SMTP id MAA19864 for ; Thu, 1 Feb 1996 12:15:41 -0600 From: David Borman Received: by poplar029 (5.x/btd-b3) id AA22949; Thu, 1 Feb 1996 12:15:38 -0600 Message-Id: <9602011815.AA22949@poplar029> Date: Thu, 1 Feb 1996 12:15:38 -0600 To: ipng@sunroof.eng.sun.com Subject: (IPng 1343) UDP/IPv6 question Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In looking through the IPv6 RFC, I didn't see anything about using jumbograms with UDP. I assume from this that either 1) I missed something in the spec, or 2) The 16 bit UDP length field continues to limit UDP to < 64K, even though IPv6 can go larger. A simple solution to allow >64K UDP datagrams would be to add to the spec that if the UDP length field is zero (or some other value less than 8, since 8 is the smallest legal value), then the UDP length should be ignored, and the length should be taken from the pseudo-header (just like TCP does). Are there any problems with this proposal that I've missed? Related to this, TCP/IPv6 can take advantage of >64K packets, as long as the MSS option is *not* exchanged, since MSS is limited to 64K, and TCP is not allowed to send more than the MSS. The MTU discovery code should find the real MTU, which might be >64K (say, for example, over a local HIPPI link). Am I interpretating this correctly? -David Borman, dab@cray.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 1 10:37:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24825; Thu, 1 Feb 96 10:37:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24819; Thu, 1 Feb 96 10:37:36 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11645; Thu, 1 Feb 1996 10:36:44 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id KAA25649; Thu, 1 Feb 1996 10:36:44 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id KAA21781; Thu, 1 Feb 1996 10:36:37 -0800 Date: Thu, 1 Feb 1996 10:36:37 -0800 From: Ran Atkinson Message-Id: <199602011836.KAA21781@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1344) Re: (mobile-ip) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: <28367.823193383@CHIMAY.MACH.CS.CMU.EDU> References: <199602011504.AAA12293@tera.csl.sony.co.jp> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This almost certainly won't work as intended, though. People who >think that firewalls should filter on source addresses won't be >fooled by such an option "hiding" the real source address. These >people think they are doing this filtering for a reason. If we >define a standard way to "defeat" this filtering, they will just >change their firewalls to filter also based on the "hidden" real >source address in the option. The author of the above was confused. I'll try to clarify. Firewalls are generally trying to filter out traffic from untrustworthy parties. A trustworthy node that is currently outside the firewall perimeter is often still viewed as trustworthy. Many existing sites using firewalls desire a good way to distinguish between a trustworthy remote node (whose remote address possibly changes from time to time) and an untrustworthy remote node. Fumio-san's proposal provides a way that this finer granularity of access control decision could be made more easily. In the presence of IPsec AH, spoofing of the proposed option could be cryptographically precluded. No one here has "defined" how firewalls must handle packets with the proposed option. It has merely been observed that this option can provide firewalls with additional, probably very useful, data that could be part of the access control decision made by the firewall. In virtually all cases, firewalls will be tuned differently by different sites. However, permitting a finer grain of access control decision by the firewall is clearly a win operationally. Ran rja@cisco.com PS: I'm not a big fan of firewalls, but they aren't going away. I will project that firewalls implementing IPsec will become commonplace in the near future (say next 18 months) and that IPv6-capable firewalls will generally be using IPsec to validate the data used for the access control decisions. I'm aware of a number of firewall vendors who are already putting the NRL IPsec implementation into their BSD kernels for their commercial products. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 1 13:21:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24926; Thu, 1 Feb 96 13:21:20 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24920; Thu, 1 Feb 96 13:21:03 PST Received: from kandinsky.eng.sun.com (kandinsky [129.146.86.117]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id NAA02877; Thu, 1 Feb 1996 13:19:28 -0800 (PST) Received: by kandinsky.eng.sun.com (5.x/SMI-SVR4) id AA12821; Thu, 1 Feb 1996 13:25:32 -0800 Date: Thu, 1 Feb 1996 13:25:32 -0800 From: gilligan@caribe.eng.sun.com (Bob Gilligan) Message-Id: <9602012125.AA12821@kandinsky.eng.sun.com> To: ipng@sunroof.eng.sun.com, ipv6imp@munnari.OZ.AU, sun-ipv6-users@sunroof.eng.sun.com Subject: (IPng 1345) New IPv6 for Solaris prototype available Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The third prototype release of IPv6 for Solaris is now available for testing. This release adds new IP layer features along with more applications, including web browser and server programs! For more information, see our web page at: http://playground.sun.com/pub/solaris2-ipv6/html/solaris2-ipv6.html Our IPv6 test machine is up and running the new release at IPv6 address ::192.9.5.6 (no DNS entry yet). This machine is operating as an IPv6 anonymous FTP server, and is perhaps the Internet's first IPv6 web server! Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 1 19:42:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25450; Thu, 1 Feb 96 19:42:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25444; Thu, 1 Feb 96 19:42:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01896; Thu, 1 Feb 1996 19:41:32 -0800 Received: from explorer.netserv.chula.ac.th by mercury.Sun.COM (Sun.COM) id TAA26872; Thu, 1 Feb 1996 19:41:04 -0800 Received: from pioneer.netserv.chula.ac.th (pioneer.netserv.chula.ac.th [161.200.192.12]) by explorer.netserv.chula.ac.th (8.7.3/8.7.3) with ESMTP id KAA00988 for ; Fri, 2 Feb 1996 10:48:28 GMT Received: by pioneer.netserv.chula.ac.th (8.7.1) id KAA17608; Fri, 2 Feb 1996 10:31:49 GMT Date: Fri, 2 Feb 1996 10:31:48 +0000 (TST) From: Cherdwong Hongsrichinda To: ipng@sunroof.eng.sun.com Subject: (IPng 1346) IP assignment Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Who know if IPv6 is used, What kind of it will be assigned? Similar IPv4 Class B or Class C? And What's program that can read .ps format I want to read IPv6 Implement Thank you Cherd ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 2 06:38:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25822; Fri, 2 Feb 96 06:38:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25816; Fri, 2 Feb 96 06:38:37 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09488; Fri, 2 Feb 1996 06:37:46 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id GAA11600; Fri, 2 Feb 1996 06:37:45 -0800 Received: from muggsy.lkg.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA32746; Fri, 2 Feb 1996 09:33:30 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA27463; Fri, 2 Feb 1996 09:33:28 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id OAA25703; Fri, 2 Feb 1996 14:47:30 GMT Message-Id: <199602021447.OAA25703@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: ipng@sunroof.eng.sun.com Cc: nordmark@Eng, narten@vnet.ibm.com Subject: (IPng 1347) Yet more ND questions/issues X-Mailer: exmh version 1.5omega 10/6/94 Date: Fri, 02 Feb 1996 14:47:21 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In doing some in-house testing before the UNH bakeoff, I've run into a few things in Neighbor Discovery that probably should be clarified or fixed. 1) A query is on the Is Router bit on Neighbor Advertisements. The stipulation: The designated address for routers is their link local address (which is used RAs and Redirects) and that hosts only use the designated address when using the router as a forwarding agent. The question: If that's true, when a host receives a neighbor advertisement for a global address of a router, should that advertisement have the IsRouter bit set? If so, what good will it accomplish? 2) What use is the redirected header option in the redirect? You don't need it to process the redirect. If you are worried about security, you will be using authenication so it isn't for that. So why include it? (IPv4 included it but that's no reason for IPv6 to do so). 3) As an implementor, I would like for ND to state that in a Redirect that the Target Link Address option, if present, must be the first option. Especially with the existance of the Redirected Header option, I don't really want to have skip over option to get the Target Link Address especially when I'll be ignoring them. [Note that the above has been written before my normal morning infusion of caffeine.] Comments? Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 2 13:26:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26254; Fri, 2 Feb 96 13:26:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26248; Fri, 2 Feb 96 13:26:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16378; Fri, 2 Feb 1996 13:25:39 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id NAA10460; Fri, 2 Feb 1996 13:25:37 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4053; Fri, 02 Feb 96 16:25:17 EST Received: by RTP (XAGENTA 4.0) id 6196; Fri, 2 Feb 1996 16:24:57 -0500 Received: from hygro.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA15523; Fri, 2 Feb 1996 16:25:15 -0500 Received: from hygro.raleigh.ibm.com (narten@localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id PAA00370; Fri, 2 Feb 1996 15:58:03 -0500 Message-Id: <199602022058.PAA00370@hygro.raleigh.ibm.com> To: TERAOKA Fumio Cc: mobile-ip@SmallWorks.COM, ipng@sunroof.eng.sun.com Subject: (IPng 1348) Re: (mobile-ip) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: Your message of "Fri, 02 Feb 1996 00:32:42 +0900." <199602011532.AAA12349@tera.csl.sony.co.jp> Date: Fri, 02 Feb 1996 15:58:03 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk TERAOKA Fumio writes: >In draft-ietf-mobileip-ipv6-00.txt, when a packet from a mobile node >traverses the firewall at the visited site, the firewall might discard >the packet, since the source address of the packet indicates the outside >of the site. (The source adddress field indicates the home address of >the source mobile node.) I agree that this is theoretically possible, but I have to question whether this is a valid concern in practice. People running firewalls are concerned about stopping bogus traffic originating outside the site from getting in. They care a lot less about preventing traffic from flowing out**. Or stated another way, it's not the site's problem if it lets out packets that have addresses that don't originate from within the site, it's the receiver's problem to deal with. ** It may be the case that a site is worried about keeping its internal traffic from leaking out (to prevent anyone from examining packets containing top secret data), in which case it would probably either filter out all packets having a source address corresponding to nodes within the site, or even more likely, filter out *all* outgoing packets. In either of these scenarios, the "source ID" option doesn't help (and using the Home Address as a source address helps only in the first case). I don't claim to be a firewall expert, so if the above analysis is wrong, please correct me (gently of course!). >In my approach, the Authentication Header can authenticate the Home >Address and the Current Address of the source node. Since it can be >assumed that a mobile node and the firewall at the mobile's home site >share a key for authentication, the firewall can authenticate the mobile >node. If the the packet contains an Authentication Header, and the mobile and firewall share a key, I don't think one can make a strong case that the source address should be the packet's "home address" or its COA. In both cases, the AH verification ensures that the packet was created by the mobile node holding the key. It is *that* *knowledge* -- proving that it knows the key -- that the firewall is looking for in deciding whether or not to allow the packet through. The actual values of various fields within the authenticated packet aren't of interest to the firewall. So if an AH header is present that the firewall can verify, I don't see how it makes any difference which address is being used as the source address. If there is no AH present, the "source ID" option can be spoofed just as easily as the source address. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 2 13:31:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26269; Fri, 2 Feb 96 13:31:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26263; Fri, 2 Feb 96 13:31:39 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17195; Fri, 2 Feb 1996 13:30:47 -0800 Received: from VNET.IBM.COM by venus.Sun.COM (Sun.COM) id NAA01809; Fri, 2 Feb 1996 13:30:46 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4159; Fri, 02 Feb 96 16:30:39 EST Received: by RTP (XAGENTA 4.0) id 6206; Fri, 2 Feb 1996 16:30:20 -0500 Received: from hygro.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18686; Fri, 2 Feb 1996 16:30:30 -0500 Received: from hygro.raleigh.ibm.com (narten@localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id QAA00387; Fri, 2 Feb 1996 16:03:19 -0500 Message-Id: <199602022103.QAA00387@hygro.raleigh.ibm.com> To: Matt Thomas Cc: ipng@sunroof.eng.sun.com, nordmark@Eng Subject: (IPng 1349) Re: Yet more ND questions/issues In-Reply-To: Your message of "Fri, 02 Feb 1996 14:47:21 GMT." <199602021447.OAA25703@whydos.lkg.dec.com> Date: Fri, 02 Feb 1996 16:03:19 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, >1) A query is on the Is Router bit on Neighbor Advertisements. >The stipulation: > The designated address for routers is their link local address > (which is used RAs and Redirects) and that hosts only use the > designated address when using the router as a forwarding agent. >The question: > If that's true, when a host receives a neighbor advertisement > for a global address of a router, should that advertisement have > the IsRouter bit set? If so, what good will it accomplish? As you point out, the client should never be using that address as a router. But there is no harm in having the router set it, and if for some reason the host was using a global address for a router, it would be better to have the bit set than not. So I'd say that the router should always set the IsRouter bit, and clients should process it as normal. Are you proposing that the behavior be different? >2) What use is the redirected header option in the redirect? You don't > need it to process the redirect. If you are worried about security, you > will be using authenication so it isn't for that. So why include it? > (IPv4 included it but that's no reason for IPv6 to do so). This was discussed a number of times by the WG and even though no one felt there was a need for including the header, there seemed a sort of rough consensus to leave it in anyway. So we left it in. >3) As an implementor, I would like for ND to state that in a Redirect > that the Target Link Address option, if present, must be the first > option. Especially with the existance of the Redirected Header option, > I don't really want to have skip over option to get the Target Link > Address especially when I'll be ignoring them. Given that the option could be large in practice, you are right that skipping over it in some implementations could be inefficient. I think it would be reasonable to add text to the spec suggesting that the link-layer option should appear first. But I don't think it should be a MUST. This may also be a good argument for doing away with the Redirected Header completely. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 2 14:03:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26317; Fri, 2 Feb 96 14:03:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26311; Fri, 2 Feb 96 14:03:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23549; Fri, 2 Feb 1996 14:02:53 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id OAA18907; Fri, 2 Feb 1996 14:02:52 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16291(5)>; Fri, 2 Feb 1996 14:02:42 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Fri, 2 Feb 1996 14:02:29 -0800 To: David Borman Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1350) Re: UDP/IPv6 question In-Reply-To: dab's message of Thu, 01 Feb 96 10:15:38 -0800. <9602011815.AA22949@poplar029> Date: Fri, 2 Feb 1996 14:02:16 PST From: Steve Deering Message-Id: <96Feb2.140229pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave, > A simple solution to allow >64K UDP datagrams would be to add to > the spec that if the UDP length field is zero (or some other value > less than 8, since 8 is the smallest legal value), then the UDP > length should be ignored, and the length should be taken from the > pseudo-header (just like TCP does). Are there any problems with > this proposal that I've missed? This suggestion did come up before, and I don't recall any problems being identified. I can't remember why we didn't include it in the IPv6 spec -- maybe it just fell through the cracks. We could handle this either as an update to the IPv6 spec (hopefully not one that would restart the Proposed Standard timer), or someone could write a one-page UDP-over-Jumbograms ID and submit it as a PS. Do you care which way it's done? > Related to this, TCP/IPv6 can take advantage of >64K packets, > as long as the MSS option is *not* exchanged, since MSS is > limited to 64K, and TCP is not allowed to send more than the > MSS. The MTU discovery code should find the real MTU, which > might be >64K (say, for example, over a local HIPPI link). > Am I interpretating this correctly? We (or at least I) forgot about the MSS limitation. Isn't it the case that, if an MSS option is not received, a sending TCP must limit itself to 576-byte packets? If so, your solution of not sending MSS will not work, and we will need to specify expicitly that TCP over IPv6 can send packets as large as the path MTU if no MSS option is received. Alternatively, we could define a new Jumbo-MSS option for TCP. Again, we have to decide whether to do either of those as an update to the IPv6 spec or as a one-page, standalone RFC. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 5 07:00:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27577; Mon, 5 Feb 96 07:00:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27571; Mon, 5 Feb 96 07:00:20 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23916; Mon, 5 Feb 1996 06:59:25 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id GAA11194; Mon, 5 Feb 1996 06:59:24 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1429; Mon, 05 Feb 96 09:59:14 EST Received: by RTP (XAGENTA 4.0) id 6339; Mon, 5 Feb 1996 09:58:53 -0500 Received: from rsal3p26.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18628; Mon, 5 Feb 1996 09:59:03 -0500 Received: from hygro.raleigh.ibm.com (narten@localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id JAA00292; Mon, 5 Feb 1996 09:55:15 -0500 Message-Id: <199602051455.JAA00292@hygro.raleigh.ibm.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1351) Re: (mobile-ip) Re: draft-ietf-mobileip-ipv6-00.txt In-Reply-To: Your message of "Thu, 01 Feb 1996 10:36:37 PST." <199602011836.KAA21781@puli.cisco.com> Date: Mon, 05 Feb 1996 09:55:15 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, >>This almost certainly won't work as intended, though. People who >>think that firewalls should filter on source addresses won't be >>fooled by such an option "hiding" the real source address. These >>people think they are doing this filtering for a reason. If we >>define a standard way to "defeat" this filtering, they will just >>change their firewalls to filter also based on the "hidden" real >>source address in the option. >The author of the above was confused. I'll try to clarify. >Firewalls are generally trying to filter out traffic from untrustworthy >parties. A trustworthy node that is currently outside the firewall >perimeter is often still viewed as trustworthy. Many existing sites >using firewalls desire a good way to distinguish between a trustworthy >remote node (whose remote address possibly changes from time to time) and >an untrustworthy remote node. Fumio-san's proposal provides a way that >this finer granularity of access control decision could be made more >easily. In the presence of IPsec AH, spoofing of the proposed option could >be cryptographically precluded. I still don't get it. It seems to me that if the mobile and the firewall share a key, the mobile (via an AH) can prove to the firewall that it has a key and that its packets are authorized to pass through the firewall. The actual contents of various fields (besides the AH) in the packet are *completely* irrelevent to the firewall. This is what confuses me when you say that Fumio-san's option provides improved access controls. >No one here has "defined" how firewalls must handle packets with the >proposed option. It has merely been observed that this option can provide >firewalls with additional, probably very useful, data that could be part of >the access control decision made by the firewall. Could you please provide a concrete example? I can't seem to get past the catch 22. If the packet contains no AH, it can be spoofed, any option can be forged, and the benefits get lost. If an AH is present, it is the AH's presence (and verifiability) that is of importance. Any policy or special processing could be part of the security association. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 5 07:58:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27653; Mon, 5 Feb 96 07:58:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27647; Mon, 5 Feb 96 07:57:53 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29316; Mon, 5 Feb 1996 07:56:57 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id HAA24795; Mon, 5 Feb 1996 07:56:56 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3289; Mon, 05 Feb 96 10:56:46 EST Received: by RTP (XAGENTA 4.0) id 6356; Mon, 5 Feb 1996 10:56:28 -0500 Received: from rsal3p26.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA21973; Mon, 5 Feb 1996 10:56:40 -0500 Received: from hygro.raleigh.ibm.com (narten@localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id KAA00377; Mon, 5 Feb 1996 10:52:52 -0500 Message-Id: <199602051552.KAA00377@hygro.raleigh.ibm.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1352) Re: The on-link flag. In-Reply-To: Your message of "Wed, 31 Jan 1996 16:09:44 PST." <9602010009.AA03352@feller.mentat.com> Date: Mon, 05 Feb 1996 10:52:52 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The proxy-er should take on DAD duties for any address for which it >is proxying. In general this would not include the link-local address >since the link-local address is not intended to be globally unique. But the link-local address is intended to be unique on a link. If a node is temporarily away, it's probably not a good idea to allow another node to use that address in the meantime, especially if the node will return in the future, and it is using global addresses derived from the token. Addrconf (and DHCP) assume interface tokens are unique on a link. Knowingly violating that assumption seems like a dangerous thing. For the example you've cited, where a node is temporarily off-link, and a node on the home link is still proxying for it, I would think it a bad idea for another node to use the same link-local address since that implies the presence of a duplicate token. >My suggestion of not configuring an address for an "off-link" prefix >but merely adding a route to the prefix directed through the nodes >own interface will solve the uniqueness problem. That is the way >the ARP hack works today so why mess with tradition. Sorry, but I don't follow what the above does or is supposed to achieve. If you don't assign an address (that someone else is using) to an interface, then the address remains unique by definition. But what is the purpose of adding a route for the prefix? The example you cited earlier called for the prefix not being on-link (note that I didn't say "off-link"), which simply means packets under that prefix should be forwarded to a router under the normal default route. One wouldn't have an explicit route for that prefix. The router can still send a redirect saying the destination is on-link. >Actually, my first preference is to disallow proxying entirely. At the time we were writing the spec, we didn't have a use in mind for proxying. However, if someone later decided they wanted to do proxying, there is nothing we could do to stop them. What technical mechanism is there that prevents proxying? So we opted to put some rules into ND that at least insures some uniformity in the way things are done in the presence of mulitple proxiers. More recently (to me anyway), it's become clear that mobility relies on proxying at the home site. The current mobility model has the Home Agent (on the mobile's home link) proxying for the mobile node while it is away from home. If there is a way to do mobility without proxying (that doesn't result in other negative consequences), I'm sure a lot of folks would be interested in hearing about it. >So what does it mean for a prefix to be "off-link" when the only scope >under which my token can be guaranteed unique (via DAD) is "on-link"? There is no such thing as a prefix being "off-link" in ND. Rather, there is a notion that a prefix is on-link, meaning that all addresses under that prefix are on-link. The opposite of on-link is not off-link. It is simply that a host cannot assume that *all* addresses under that prefix are on-link. I can't think of a good example right off for why a site would say "do stateless address autoconfig" on a prefix that is off-link. However, that doesn't preclude some future use. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 5 08:15:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27697; Mon, 5 Feb 96 08:15:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27691; Mon, 5 Feb 96 08:15:27 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01413; Mon, 5 Feb 1996 08:14:31 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id IAA29207; Mon, 5 Feb 1996 08:14:30 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3971; Mon, 05 Feb 96 11:14:21 EST Received: by RTP (XAGENTA 4.0) id 6369; Mon, 5 Feb 1996 11:14:03 -0500 Received: from rsal3p26.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA21403; Mon, 5 Feb 1996 11:14:09 -0500 Received: from hygro.raleigh.ibm.com (narten@localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id LAA00405; Mon, 5 Feb 1996 11:10:20 -0500 Message-Id: <199602051610.LAA00405@hygro.raleigh.ibm.com> To: bound@zk3.dec.com Cc: thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com Subject: (IPng 1353) Re: Implementation? on Addr Conf Section 5.5.3 Prefix Info - d) In-Reply-To: Your message of "Wed, 31 Jan 1996 23:46:27 EST." <9602010446.AA09595@fwasted.zk3.dec.com> Date: Mon, 05 Feb 1996 11:10:20 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >I see your deliema architecturally clearly. But please also see mine as >I just implemented the spec. The bottom line is if it happens I will >overlay the timers for a DHCPv6 address at a minimum which alters the >lease parameters of the server and in the worst case deprecate an >address that has a ratified preferred timer (the stateless RA prefix >sends me a preferred of all zeroes). And the worst case the RA prefix >is killing the address by sending a valid_timer of all zeroes (which I >will note is permited if the prefix previously was provided by the >router). I think I understand where you are coming from. My point is simply that your proposed solution solves the problem in the example you cite, but the same solution does the wrong thing in a different scenario. The one that comes to mind is a site that is phasing out the use of DHCP, and a host refuses to update a Lifetime in a received RA prefix anouncement because it already obtained a Lifetime for the address via DHCP. Eventually the DHCP-learned prefix/address becomes invalid (the DHCP server is no longer responding), and the host doesn't have an address, even though stateless addroconf has been telling it for some time to form such an address with a new Lifetime. It may be up to 30 minutes before a host gets another RA. The scenario you are worried about seems unlikely to me anyway. If a site is sending out RAs containing a zero Lifetime for a prefix, you propose to continue using it because DHCP had a longer timer. However, if RAs say the lifetime is 0, that implies that the prefix as a whole isn't appropriate anymore. So even if you continued using the DHCP-learned address/prefix, its not clear that it would even work anymore. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 5 09:23:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27772; Mon, 5 Feb 96 09:23:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27766; Mon, 5 Feb 96 09:23:24 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11308; Mon, 5 Feb 1996 09:22:28 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id JAA18537; Mon, 5 Feb 1996 09:22:28 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA21675; Mon, 5 Feb 1996 09:22:24 -0800 Date: Mon, 5 Feb 1996 09:22:24 -0800 From: Ran Atkinson Message-Id: <199602051722.JAA21675@puli.cisco.com> To: rja@cisco.com, narten@VNET.IBM.COM Subject: (IPng 1354) Re: (mobile-ip) Re: draft-ietf-mobileip-ipv6-00.txt Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % I still don't get it. It seems to me that if the mobile and the % firewall share a key, the mobile (via an AH) can prove to the firewall % that it has a key and that its packets are authorized to pass through % the firewall. If the mobile uses its "temporary" source address, the packet would normally be rejected by the firewall as coming from a node that is not a legitimate sender for that Security Association (unless the SA was configured to accept packets from INADDR_ANY, in which case there is a well known tunnel-mode spoofing attack possible). Knowledge of the Security Association (which is a SUPERSET of the key) is necessary but not generally sufficient because other sanity checks between the packet header and the Security Association are normally needed. The other sanity checks tend not to be needed on traffic between a pair of _single-user_ systems such as one's Mac PowerBook computer at the IETF and one's PowerMac at home IFF no firewall is involved. Part of the communication problem might be that you appear to assume that the firewall policy is "If has AH, then can traverse the firewall regardless of other data" while I'm not assuming any particular policy and am allowing for the possibility (likely, IMHO) that the firewall might also look at other packet data (in addition to AH validation) before deciding whether to let the packet traverse the firewall. % The actual contents of various fields (besides the AH) % in the packet are *completely* irrelevent to the firewall. This is % what confuses me when you say that Fumio-san's option provides % improved access controls. With IPsec, the node authenticating the AH _does_ generally look at least at the Source Addr and Dest Addr and Auth Header. A firewall will generally look at other stuff (e.g. ULP and port) as well because it is trying to apply various kinds of access control criteria. Firewalls do not behave in the manner typical for either a host or a router but instead can have very different behaviours because they usually examine lots of things in each packet before making the access control decision. Even in the presence of AH, most firewalls will still be applying other kinds of access controls (or at least most firewall admins will still prefer to be able to apply other kinds of access controls in addition to AH). % >No one here has "defined" how firewalls must handle packets with the % >proposed option. It has merely been observed that this option can provide % >firewalls with additional, probably very useful, data that could be part of % >the access control decision made by the firewall. % % Could you please provide a concrete example? I can't seem to get past % the catch 22. If the packet contains no AH, it can be spoofed, any % option can be forged, and the benefits get lost. If an AH is present, % it is the AH's presence (and verifiability) that is of importance. Knowledge of the sender's permanent source address is important to (i.e. is part of) the normal AH input processing in most cases. See the discussion above. % Any policy or special processing could be part of the security % association. No. A Security Association is defined in RFC-1825 and intentionally excludes policy. Special firewall processing is determined by the firewall administrator (and to some extent limited by the firewall implementor/vendor). Ran rja@cisco.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 5 10:03:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27926; Mon, 5 Feb 96 10:03:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27920; Mon, 5 Feb 96 10:03:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17910; Mon, 5 Feb 1996 10:02:04 -0800 Received: from pax.inria.fr by mercury.Sun.COM (Sun.COM) id KAA01249; Mon, 5 Feb 1996 10:02:01 -0800 Received: from [138.96.24.178] by pax.inria.fr (8.6.12/8.6.12) with SMTP id TAA09464; Mon, 5 Feb 1996 19:01:07 +0100 Date: Mon, 5 Feb 1996 19:01:07 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Thomas Narten" From: huitema@pax.inria.fr (Christian Huitema) Subject: (IPng 1355) Re: (mobile-ip) Re: draft-ietf-mobileip-ipv6-00.txt Cc: Ran Atkinson , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:55 AM 5/2/96, Thomas Narten wrote: >I still don't get it. It seems to me that if the mobile and the >firewall share a key, the mobile (via an AH) can prove to the firewall >that it has a key and that its packets are authorized to pass through >the firewall. The actual contents of various fields (besides the AH) >in the packet are *completely* irrelevent to the firewall. This is >what confuses me when you say that Fumio-san's option provides >improved access controls. Placing the home agent in the firewall actually makes a lot of sense. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 5 11:05:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28039; Mon, 5 Feb 96 11:05:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28033; Mon, 5 Feb 96 11:05:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29942; Mon, 5 Feb 1996 11:04:34 -0800 Received: from CORALS.nhn.navair.navy.mil by mercury.Sun.COM (Sun.COM) id LAA26725; Mon, 5 Feb 1996 11:04:33 -0800 Received: from mr.navair.navy.mil by corals.nhn.navair.navy.mil (PMDF V5.0-4 #5358) id <01I0UURL6G2O8WWFXP@corals.nhn.navair.navy.mil> for ipng@sunroof.eng.sun.com; Mon, 05 Feb 1996 14:03:01 -0400 (EDT) Received: with PMDF-MR; Mon, 05 Feb 1996 14:01:10 -0400 (EDT) Mr-Received: by mta JFK.MUAS; Relayed; Mon, 05 Feb 1996 14:01:10 -0400 Mr-Received: by mta KTYHWK; Relayed; Mon, 05 Feb 1996 14:01:10 -0400 Mr-Received: by mta CORALS; Relayed; Mon, 05 Feb 1996 14:02:39 -0400 Disclose-Recipients: prohibited Date: Mon, 05 Feb 1996 14:01:10 -0400 (EDT) From: BUCHTERR Subject: (IPng 1356) IPng e-mailing list To: ipng%sunroof.eng.sun.com%internet@mr.navair.navy.mil Message-Id: <8710011405021996/A17163/KTYHWK/11A22B810A00*@MHS> Autoforwarded: false Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Importance: normal Priority: normal Sensitivity: Company-Confidential Ua-Content-Id: 11A22B810A00 X400-Mts-Identifier: [;8710011405021996/A17163/KTYHWK] Hop-Count: 2 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk unsuscribe buchterr.jfk@navair.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 5 11:49:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28091; Mon, 5 Feb 96 11:49:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28075; Mon, 5 Feb 96 11:44:37 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06787; Mon, 5 Feb 1996 11:43:41 -0800 Received: from ar.com by mercury.Sun.COM (Sun.COM) id LAA11240; Mon, 5 Feb 1996 11:43:40 -0800 Received: (wessorh@localhost) by ar.com (8.6.11/8.6.5) id LAA26974 for ipng@sunroof.eng.sun.com; Mon, 5 Feb 1996 11:41:05 -0800 Date: Mon, 5 Feb 1996 11:41:05 -0800 From: "Rick H. Wesson" Message-Id: <199602051941.LAA26974@ar.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1357) IPv6 on Linux X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anyone know the status of a IPv6 implementation on linux? thanks, -Rick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 5 13:17:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28211; Mon, 5 Feb 96 13:17:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28205; Mon, 5 Feb 96 13:16:49 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22718; Mon, 5 Feb 1996 13:15:53 -0800 Received: from garnet.berkeley.edu by mercury.Sun.COM (Sun.COM) id NAA07200; Mon, 5 Feb 1996 13:15:52 -0800 Received: from Console by garnet.berkeley.edu (8.7.1/1.33r) id NAA25617; Mon, 5 Feb 1996 13:15:50 -0800 Date: Mon, 5 Feb 1996 13:15:50 -0800 Message-Id: <199602052115.NAA25617@garnet.berkeley.edu> X-Sender: mendes@garnet.berkeley.edu X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: Jerry Mendes Subject: (IPng 1358) Auto Configuration & ND Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I know it's the 11th hour, but I have a suggestion to make Auto Configuration more useful. I want to strongly suggest that fields for Primary & Secondary DNS servers be included in the Router Advertisement so that a host can truly auto configure. IMHO, without including DNS server addresses in the auto configuration, the stateless model will buy the end user very little. Administrators will still have to configure every host (with at least DNS addresses) or use DHCPv6. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 5 13:23:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28226; Mon, 5 Feb 96 13:23:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28220; Mon, 5 Feb 96 13:22:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23727; Mon, 5 Feb 1996 13:21:47 -0800 Received: from saturn.hrz.tu-chemnitz.de by mercury.Sun.COM (Sun.COM) id NAA08970; Mon, 5 Feb 1996 13:21:44 -0800 Received: from sunnyboy.informatik.tu-chemnitz.de by saturn.hrz.tu-chemnitz.de with Local SMTP (PP) id <13703-0@saturn.hrz.tu-chemnitz.de>; Mon, 5 Feb 1996 22:21:17 +0100 Received: from rac2 (rac2.informatik.tu-chemnitz.de) by sunnyboy.informatik.tu-chemnitz.de (4.1/SMI-4.1) id AA17420; Mon, 5 Feb 96 22:21:17 +0100 Received: by rac2 (5.x/client-1.5) id AA01421; Mon, 5 Feb 1996 22:21:07 +0100 Date: Mon, 5 Feb 1996 22:20:58 +0100 (MET) From: Bjoern Brandl To: "Rick H. Wesson" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1359) Re: IPv6 on Linux In-Reply-To: <199602051941.LAA26974@ar.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 5 Feb 1996, Rick H. Wesson wrote: > > > Does anyone know the status of a IPv6 implementation > on linux? > > thanks, > > -Rick > Hello Rick, In my oppinion there is no Linux-Implementation of IPv6 for Linux yet. But I still working on it. Bjoern. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 5 20:27:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28725; Mon, 5 Feb 96 20:27:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28719; Mon, 5 Feb 96 20:26:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26718; Mon, 5 Feb 1996 20:25:46 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id UAA08280; Mon, 5 Feb 1996 20:25:46 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA03364; Mon, 5 Feb 1996 23:18:03 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA26615; Mon, 5 Feb 1996 23:18:02 -0500 Message-Id: <9602060418.AA26615@fwasted.zk3.dec.com> To: "Thomas Narten" Cc: bound@zk3.dec.com, thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com Subject: (IPng 1360) Re: Implementation? on Addr Conf Section 5.5.3 Prefix Info - d) In-Reply-To: Your message of "Mon, 05 Feb 96 11:10:20 EST." <199602051610.LAA00405@hygro.raleigh.ibm.com> Date: Mon, 05 Feb 96 23:18:01 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >I see your deliema architecturally clearly. But please also see mine as >I just implemented the spec. The bottom line is if it happens I will >overlay the timers for a DHCPv6 address at a minimum which alters the >lease parameters of the server and in the worst case deprecate an >address that has a ratified preferred timer (the stateless RA prefix >sends me a preferred of all zeroes). And the worst case the RA prefix >is killing the address by sending a valid_timer of all zeroes (which I >will note is permited if the prefix previously was provided by the >router). >I think I understand where you are coming from. My point is simply >that your proposed solution solves the problem in the example you What I found was a "faliure-mode" in the spec. I have not really proposed a solution yet nor has Tim, what we stated was an engineering work around for that failure-mode. This is typically what is done when a failure-mode is found in a standard. Fortuneately for Addr Conf we have time to discuss any failure-modes found in the spec, even when in Proposed Standard Status. >cite, but the same solution does the wrong thing in a different >scenario. The one that comes to mind is a site that is phasing out the >use of DHCP, and a host refuses to update a Lifetime in a received RA >prefix anouncement because it already obtained a Lifetime for the >address via DHCP. Eventually the DHCP-learned prefix/address becomes >invalid (the DHCP server is no longer responding), and the host >doesn't have an address, even though stateless addroconf has been >telling it for some time to form such an address with a new >Lifetime. It may be up to 30 minutes before a host gets another RA. Not in DHCPv6 this won't happen. You will see in the next DHCPv6 spec a major change to DHCPv4 suggested. Servers will be able to advertise that the lease MUST be expired and revoked. Clients will in DHCPv6 have to listen on the DHCPv6 Client Port for these messages. So what you stated will not happen because if DHCPv6 is phased out so will all the clients addresses. Now if the client is not listening I will call that a poor implementation of a DHCPv6 client. >The scenario you are worried about seems unlikely to me anyway. If a This is where I have to put on my implementors hat! If I have a code sequence that will fail and cause an error to the users environment I have to write code to address that situation. I can't just say well it won't happen often. The engineering and product manager will have my head on a stake if I write code like that in a product. >site is sending out RAs containing a zero Lifetime for a prefix, you >propose to continue using it because DHCP had a longer timer. However, No you missed what Tim Hartrick and I suggested. We will keep flags for addresses if they came from stateful or stateless. When I process the ND RA prefix options for addrconf I will only deal with addresses "marked" as stateless. >if RAs say the lifetime is 0, that implies that the prefix as a whole >isn't appropriate anymore. So even if you continued using the >DHCP-learned address/prefix, its not clear that it would even work >anymore. This is true but still an error for the coexistence of stateless and stateful which you and Sue (stateless) and Charlie and I (stateful) have all agreed must be done for IPv6 Address Autoconfiguration. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 5 20:50:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28786; Mon, 5 Feb 96 20:50:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28780; Mon, 5 Feb 96 20:50:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28207; Mon, 5 Feb 1996 20:49:16 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id UAA11190; Mon, 5 Feb 1996 20:49:16 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA24089; Mon, 5 Feb 1996 23:43:34 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27097; Mon, 5 Feb 1996 23:43:33 -0500 Message-Id: <9602060443.AA27097@fwasted.zk3.dec.com> To: Jerry Mendes Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1361) Re: Auto Configuration & ND In-Reply-To: Your message of "Mon, 05 Feb 96 13:15:50 PST." <199602052115.NAA25617@garnet.berkeley.edu> Date: Mon, 05 Feb 96 23:43:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jerry, Please use a Wrap-Margin in mail at least of 72 columns it makes it hard to use the standard ">" to annotate your mail as it wraps and causes extra work for all. Thanks... ****************** I know it's the 11th hour, but I have a suggestion to make Auto Configuration more useful. I want to strongly suggest that fields for Primary & Secondary DNS servers be included in the Router Advertisement so that a host can truly auto configure. IMHO, without including DNS server addresses in the auto configuration, the stateless model will buy the end user very little. Administrators will still have to configure every host (with at least DNS addresses) or use DHCPv6. ******************* I wanted this and a few others but we decided to let service location do it. The reason we did not do it is (and this should go in an IPv6 FAQ List somewhere) is that we moved the processing of ND (address resolution) to ICMPv6 Packets and hence the Internet Layer. The data passed in this model is network context specific data and prefixes not entire addresses. It was also felt that UDP should continue to be the method to determine application service needs and that best also be done via service location protocol (not all agree on the last point but I do). As one of the co-authors of Dyn DNS Updates let me see if I can make you feel OK as I have been thinking on this problem for several years and keep bugging Sue about this every now and then but I think I have an answer finally. Nothing in Dyn DNS Updates REQUIRES that DHCPv6 be used to update the DNS. It can be done by the client directly (if the proper permissions/security is done) or by a DHCPv6 server. So lets take a stateless case: Client locates the DNS server via Service Location Protocol. Code processes RAs and gets prefix option for addrconf. Updates the timers, interfaces, et al. Node then Dynamically Updates DNS or asks DHCPv6 to do it. If the address expires the node or DHCPv6 deletes it via DNS. In fact I can see the above model as one module to do stateless addrconf. The Service Location can be implemented similar as to how one locates a "port" via getservname() lib call in the inline code. If DHCPv6 is used and the "O" bit is set or the "M" bit for that manner I can get to the DNS via DHCPv6 in the same module. Clearly a user interface setup GUI would be provided by the more robust and capable vendors. Does this help you? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 5 23:14:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28844; Mon, 5 Feb 96 23:14:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28838; Mon, 5 Feb 96 23:14:22 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06436; Mon, 5 Feb 1996 23:13:27 -0800 Received: from southstation.mvp.com by venus.Sun.COM (Sun.COM) id XAA20947; Mon, 5 Feb 1996 23:13:25 -0800 Received: (from george@localhost) by southstation.mvp.com (8.6.11/8.6.6) id XAA26781; Mon, 5 Feb 1996 23:01:11 -0800 Date: Mon, 5 Feb 1996 23:01:11 -0800 From: George Mitchell Message-Id: <199602060701.XAA26781@southstation.mvp.com> To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 1362) Re: Auto Configuration & ND Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Clearly a user interface setup GUI would be provided by the more robust > and capable vendors. I had the misfortune to read this message just before going to bed and immediately started having nightmares about -- SMITv6. -- George Mitchell (george@mvp.com) (AIX in joke -- sorry about the distraction!) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 6 00:35:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28884; Tue, 6 Feb 96 00:35:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28878; Tue, 6 Feb 96 00:35:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12063; Tue, 6 Feb 1996 00:34:48 -0800 Received: from ibp.ibp.fr by mercury.Sun.COM (Sun.COM) id AAA03144; Tue, 6 Feb 1996 00:34:46 -0800 Received: from matisse (matisse.ibp.fr [132.227.61.26]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with SMTP id JAA09074 for ; Tue, 6 Feb 1996 09:34:42 +0100 Date: Tue, 6 Feb 1996 09:34:42 +0100 Message-Id: <199602060834.JAA09074@ibp.ibp.fr> X-Sender: eh@hera.ibp.fr X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: "Eric HORLAIT (MASI-CNRS)" Subject: (IPng 1363) IPv6 and Linux Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As far as I know, there is no such available software yet. We are currently beginning the development of an IPv6 stack for Linux. Target availability: beta version July 1996 E. Horlait ---------------------- Professeur Eric HORLAIT ------------------------ Universite Pierre et Marie Curie Tel: 33-1-44-27-73-83 Institut Blaise Pascal - Labo MASI Fax: 33-1-44-27-62-86 4, place Jussieu e-mail: Eric.Horlait@masi.ibp.fr 75252 PARIS Cedex 05 Telex: UPMCSIX 200-145 F ----------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 6 02:19:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28967; Tue, 6 Feb 96 02:19:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28961; Tue, 6 Feb 96 02:18:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17990; Tue, 6 Feb 1996 02:17:48 -0800 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id CAA13602; Tue, 6 Feb 1996 02:17:45 -0800 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 1364) Re: IPv6 on Linux To: wessorh@ar.com (Rick H. Wesson) Date: Tue, 6 Feb 1996 07:53:48 +0000 (GMT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199602051941.LAA26974@ar.com> from "Rick H. Wesson" at Feb 5, 96 11:41:05 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does anyone know the status of a IPv6 implementation > on linux? Sitting watching everyone else at the moment and dismantling the various free code sets. Two people have mailed me this week both doing projects of IPv6 on Linux and I hope to have time to get dug into it properly after Linux 1.4 is released. It would be nice to be further ahead but days are only 24 hours long. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 6 08:08:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29066; Tue, 6 Feb 96 08:08:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29060; Tue, 6 Feb 96 08:07:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11017; Tue, 6 Feb 1996 08:06:56 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id IAA01660; Tue, 6 Feb 1996 08:06:56 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13189; 6 Feb 96 10:12 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1365) I-D ACTION:draft-ietf-ipngwg-discovery-04.txt Date: Tue, 06 Feb 96 10:12:26 -0500 Message-Id: <9602061012.aa13189@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Neighbor Discovery for IP Version 6 (IPv6) Author(s) : T. Narten, E. Nordmark, W. Simpson Filename : draft-ietf-ipngwg-discovery-04.txt Pages : 82 Date : 02/01/1996 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-discovery-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-discovery-04.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-discovery-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960205161357.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-discovery-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-discovery-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960205161357.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 7 15:32:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00518; Wed, 7 Feb 96 15:32:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00512; Wed, 7 Feb 96 15:31:52 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28292; Wed, 7 Feb 1996 15:30:53 -0800 Received: from borg.mindspring.com by mercury.Sun.COM (Sun.COM) id PAA11826; Wed, 7 Feb 1996 15:30:53 -0800 Received: from sthomas.mindspring.com [168.121.37.118] by borg.mindspring.com with SMTP id SAA05950 for ; Wed, 7 Feb 1996 18:30:47 -0500 Date: Wed, 7 Feb 1996 18:30:47 -0500 Message-Id: <199602072330.SAA05950@borg.mindspring.com> X-Sender: sthomas@mindspring.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: Stephen Thomas Subject: (IPng 1366) IPng FAQ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gentle Readers: Since I've seen it mentioned several times in the past few days, is it time to put together an IPng FAQ? I was going to work on an IPv6-over-Frame draft, but since Frame is the same sort of NBMA network as ATM, it seems prudent to wait until after the ATM/ROLC/NHRP/IPng discussions in LA. In the meantime, I'd be happy to volunteer to assemble the FAQ. (I guess I just did.) So, unless there's an objection from the group, start sending me questions (and answers, if you've got them ;^) I'd suggest not copying the ipng mailing list in order to conserve bandwidth. Around the middle of next week I'll summarize to the list. BTW, if you send me answers, expect to be attributed via an email address in the FAQ. If you'd prefer otherwise (anonymous or no email), just indicate that in your contribution. Thanks in advance. --Stephen ________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: s.thomas@acm.org ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 8 15:25:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01423; Thu, 8 Feb 96 15:25:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01417; Thu, 8 Feb 96 15:24:51 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29924; Thu, 8 Feb 1996 15:23:50 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id PAA15872; Thu, 8 Feb 1996 15:23:51 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA27397; Thu, 8 Feb 1996 15:23:55 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Feb 1996 15:25:54 -0800 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1367) WG last call: IPv6 over Token Ring Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is an ipng working group last call for comments on advancing the following document to Proposed Standard: Title : A Method for the Transmission of IPv6 Packets over Token Ring Networks Author(s) : S. Thomas Filename : draft-ietf-ipngwg-token-ring-01.txt Pages : 7 Date : 01/24/1996 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end two weeks from today, on Thursday February 22. Bob Hinden / Steve Deering ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 8 16:28:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01493; Thu, 8 Feb 96 16:28:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01487; Thu, 8 Feb 96 16:28:36 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10949; Thu, 8 Feb 1996 16:27:36 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id QAA01113; Thu, 8 Feb 1996 16:27:36 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id QAA28907; Thu, 8 Feb 1996 16:26:52 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Feb 1996 16:28:51 -0800 To: sob@harvard.edu, mankin@isi.edu From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1368) Re-Request for Advancement of IPng IPv6overEthernet Document Cc: ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us, deering@parc.xerox.com, hinden@Ipsilon.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a RFC with Proposed Standard status: Title : A Method for the Transmission of IPv6 Packets over Ethernet Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-ethernet-ntwrks-01.txt Pages : 4 Date : 10/10/1995 The was a lengthy discussion during the IETF last call which ended on 12/26/95. We believe that the issues raised (regarding the structure of link local addresses) during this discussion were resolved without requiring any changes to this draft. Bob Hinden / Steve Deering >To: IETF-Announce:; >Cc: ipng@sunroof.Eng.Sun.COM >From: IESG Secretary >Subject: (IPng 895) Last Call: A Method for the Transmission of IPv6 >Packets over > Ethernet Networks to Proposed Standard >Date: Wed, 13 Dec 95 07:39:17 -0500 >Sender: owner-ipng@sunroof.Eng.Sun.COM >Precedence: bulk > > >The IESG has received a request from the IPNG Working Group to consider >"A Method for the Transmission of IPv6 Packets over Ethernet Networks" > for the status of Proposed >Standard. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by >December 26, 1995. > >------------------------------------------------------------------------------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html >Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 8 16:43:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01529; Thu, 8 Feb 96 16:43:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01523; Thu, 8 Feb 96 16:43:17 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13265; Thu, 8 Feb 1996 16:41:43 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id QAA04279; Thu, 8 Feb 1996 16:41:36 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id QAA29076; Thu, 8 Feb 1996 16:34:46 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Feb 1996 16:36:45 -0800 To: sob@harvard.edu, mankin@isi.edu From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1369) Request for Advancement of IPng IPv6overFDDI Document Cc: ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us, deering@parc.xerox.com, hinden@Ipsilon.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a RFC with Proposed Standard status: Title : A Method for the Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-fddi-ntwrks-02.txt Pages : 6 Date : 12/13/1995 The was a lengthy discussion during the working last call which ended on 12/22/95. The initial issues raised during the last call we resolved in this version (-02) of the document. We believe that the remaining issues raised (regarding the structure of link local addresses) during this discussion were resolved on the mailing list without requiring any changes to this version of document. Bob Hinden / Steve Deering >Date: Sun, 10 Dec 1995 14:33:36 -0800 >To: ipng@sunroof.Eng.Sun.COM >From: hinden@Ipsilon.COM (Bob Hinden) >Subject: (IPng 892) WG last call: IPv6 over FDDI >Cc: hinden@Ipsilon.COM >Sender: owner-ipng@sunroof.Eng.Sun.COM >Precedence: bulk > >This is an ipng working group last call for comments on advancing the >following document to Proposed Standard: > > Title : A Method for the Transmission of IPv6 Packets > over FDDI Networks > > Author(s) : M. Crawford > Filename : draft-ietf-ipngwg-fddi-ntwrks-01.txt > Pages : 6 > Date : 11/06/1995 > >Please send substantive comments to the ipng mailing list, and minor >editorial comments to the author. This last call period will end two >weeks from today, on Saturday December 22. > >Bob > > >------------------------------------------------------------------------------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html >Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 9 07:55:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02074; Fri, 9 Feb 96 07:55:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02068; Fri, 9 Feb 96 07:54:48 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22714; Fri, 9 Feb 1996 07:53:47 -0800 Received: from isis.imag.fr by mercury.Sun.COM (Sun.COM) id HAA14113; Fri, 9 Feb 1996 07:53:45 -0800 Received: (from richier@localhost) by isis.imag.fr (8.6.11/8.6.9) id QAA23537; Fri, 9 Feb 1996 16:39:47 +0100 Date: Fri, 9 Feb 1996 16:39:47 +0100 From: Jean-Luc Richier Message-Id: <199602091539.QAA23537@isis.imag.fr> In-Reply-To: Bob Hinden's message as of Feb 8, 16:28. Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hinden@Ipsilon.COM (Bob Hinden), sob@harvard.edu, mankin@isi.edu Subject: (IPng 1370) Re: Re-Request for Advancement of IPng IPv6overEthernet Document Cc: ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us, deering@parc.xerox.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The chairs of the IP Next Generation working group, on behalf of the >working group, request that the following document be published as a RFC >with Proposed Standard status: > > Title : A Method for the Transmission of IPv6 Packets > over Ethernet Networks > Author(s) : M. Crawford > Filename : draft-ietf-ipngwg-ethernet-ntwrks-01.txt > Pages : 4 > Date : 10/10/1995 > >The was a lengthy discussion during the IETF last call which ended on >12/26/95. We believe that the issues raised (regarding the structure of >link local addresses) during this discussion were resolved without >requiring any changes to this draft. > >Bob Hinden / Steve Deering Can somebody please summarizes the conclusion of the discussion. I am not sure that I know what was this conclusion. If I am correct, the discussion was about unicity of Link Layer address in a multi-homed node : inside a node, can we use a LL address to implicitely specify a interface ? Three solutions were proposed : - Modify the draft to add a interface information in the LL address It seems that this solution is abandonned, according to the message. - Make sure that the interface token is unique on ALL the interfaces of a node. I think that this solution : - either modifies the SUN ether implementation, where all the interface have the same token. - or contradicts the text of the draft, which says that the token must be the manufacter token, with no modification allowed - Define an explicit method to specify the interface in the read and write of packets with Link layer addresses. The bsdi API draft draft-ietf-ipngwg-bsd-api proposes a method, which allow to specify the interface with an IPV6 address : ++ The last address in the array is an IPv6 address of the receiving ++ interface. Since interfaces in IPv6 may have more than one address, and ++ some addresses (e.g. link-local addresses) may be used on more than one ++ interface, the system should select an address that uniquely identifies ++ the interface. (PS : I think the ``should'' should be a ``must'', otherwise the constrution has no interest) This supposes that the interfaces have a address unique at the node level. But a node must be able to work without any global address configured, and in that case the only addresses are Link Local addresses. Therefore it seems that the bsd-api draft asks for unique LL adresses, in contradiction with the ipng-over-ethernet draft. Or is there some special "node level" address proposal ? -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) LGI, IMAG-CAMPUS, BP 53, F-38041 GRENOBLE Cedex 9 Tel : (33) 76 82 72 32 Fax : (33) 76 44 66 75 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 9 09:19:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02141; Fri, 9 Feb 96 09:19:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02135; Fri, 9 Feb 96 09:18:46 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03673; Fri, 9 Feb 1996 09:17:45 -0800 Received: from guelah.nexen.com by mercury.Sun.COM (Sun.COM) id JAA07876; Fri, 9 Feb 1996 09:17:42 -0800 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.6.12) with ESMTP id MAA06555; Fri, 9 Feb 1996 12:15:21 -0500 (EST) Received: from phish.nexen.com (phish.nexen.com [204.249.99.14]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id MAA15152; Fri, 9 Feb 1996 12:14:40 -0500 Received: from localhost (malis@localhost) by phish.nexen.com (8.7.3/8.6.12) with SMTP id MAA13099; Fri, 9 Feb 1996 12:15:38 -0500 (EST) Message-Id: <199602091715.MAA13099@phish.nexen.com> To: rolc@nexen.com, ip-atm@matmos.hpl.hp.com, rsvp@isi.edu, int-serv@isi.edu, ipng@sunroof.eng.sun.com Cc: malis@nexen.com Subject: (IPng 1371) ipatm, rolc, and joint LA session agendas Date: Fri, 09 Feb 1996 12:15:38 -0500 From: "Andrew G. Malis" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's coming time to put together the working group agendas for the upcoming IETF meeting. In addition to the regular ipatm and rolc sessions, there will also be two additional joint sessions which have been added to compensate for the lack of time we had in Dallas to discuss some specific multidisciplinary issues, and to allow people with the appropriate interest and expertise to attend. rolc will be meeting in two sessions, on Monday 3/4 at 1300-1500 and 1530-1730. ipatm will also be meeting in two sessions, on Tuesday 3/5 at 1300-1500 and Wednesday 3/6 at 1300-1500. There will be a joint ipatm/rsvp/intserv meeting on Wednesday 3/6 at 1530-1730 to discuss how best to carry IP traffic with particular Quality of Service requirements (other than the usual best effort) through an ATM network. We expect to discuss such topics as how (or whether) to use RSVP, how to map to ATM signaling, etc. There will be a joint ipatm/rolc/ipng joint session on Thursday 3/7 at 1300-1500 to discuss how to best carry IPv6 over ATM and other NBMA (non-broadcast, multiple access) networks. The major issues include how to best provide IPv6 functionality such as neighbor discovery and address resolution. Please respond, either publicly or privately, if you have specific topics and/or internet drafts you would like to put on any of the above agendas. I will forward all mail I receive to the appropriate WG chairs. I've included the internet draft deadline notice below as a gentle reminder. I will be on vacation from 2/16 - 2/26, but I will try to get out (at the very least) a draft rolc agenda to the list by 2/15. Regards, Andy ------- Forwarded Message To: IETF-Announce:; cc: cclark@CNRI.Reston.VA.US Subject: Internet-Draft CUTOFF Date Date: Tue, 30 Jan 96 09:58:59 -0500 From: Cynthia Clark The cut-off for Internet-Draft submissions prior to the Los Angeles IETF meeting is Thursday, February 22, 1996 at 5pm ET. Internet-Drafts received after this time will not be announced nor made available in the Internet-drafts Directories. We will begin processing Internet-Draft submissions the week following the IETF meeting. Thank you for your understanding and cooperation. Please do not hesitate to contact me if you have any questions or concerns. Kind Regards, Cynthia Clark Internet-Drafts Administrator ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 9 12:32:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02339; Fri, 9 Feb 96 12:32:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02333; Fri, 9 Feb 96 12:32:19 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10209; Fri, 9 Feb 1996 12:31:18 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id MAA08783; Fri, 9 Feb 1996 12:31:17 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa24358; 9 Feb 96 15:27 EST To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 1372) Last Call: A Method for the Transmission of IPv6 Packets over FDDI Networks to Proposed Standard Reply-To: iesg@IETF.CNRI.Reston.VA.US Date: Fri, 09 Feb 96 15:27:48 -0500 Message-Id: <9602091527.aa24358@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider "A Method for the Transmission of IPv6 Packets over FDDI Networks" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by February 23, 1996. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 9 13:55:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02411; Fri, 9 Feb 96 13:55:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02247; Fri, 9 Feb 96 10:25:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17922; Fri, 9 Feb 1996 10:24:48 -0800 Received: from thumper.bellcore.com by mercury.Sun.COM (Sun.COM) id KAA27810; Fri, 9 Feb 1996 10:24:45 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id NAA20467; Fri, 9 Feb 1996 13:20:57 -0500 Message-Id: <199602091820.NAA20467@thumper.bellcore.com> To: bound@zk3.dec.com Cc: ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com, gja@thumper.bellcore.com Subject: (IPng 1373) Re: IPv6 over NBMA In-Reply-To: Your message of Fri, 26 Jan 1996 14:33:17 -0500. <9601261933.AA09537@fwasted.zk3.dec.com> Date: Fri, 09 Feb 1996 13:20:42 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just back from vacation, and I'm still catching up on the threads, but something from Jim caught my eye.... [..] >>It is a paradox. This is a benefit of the Schulter/Jork/Armitage >>model that address resolution in fact can be done using IPv6 ND, Just for precision's sake, there is no 'Schulter/Jork/Armitage' model per se. There is an I-D that I wrote from the perspective of seeing what hoops need to be jumped through to get the existing ND protocol to run over ATM. My I-D outlined a simple approach that did not allow 'cut through', and left open the broader question of how the concepts of 'cut through' and ND (as currently defined) could be married. There is a 'Schulter/Jork' model - which takes up this challenge from the perspective that ND as a service and a protocol needs to be retained. Then there is the NHRP based approach, which is believed to provide a ND _service_ while not using the ND _protocol_ (a distinction I think I saw Joel make a few days ago). cheers, gja _________________________________________________________________________ Grenville Armitage gja@thumper.bellcore.com Bellcore, 445 South St. http://gump.bellcore.com:8000/~gja/home.html Morristown, NJ 07960 USA (voice) +1 201 829 2635 {.. 2504 (fax)} ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 9 15:53:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02528; Fri, 9 Feb 96 15:53:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02522; Fri, 9 Feb 96 15:53:27 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13461; Fri, 9 Feb 1996 15:52:24 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id PAA00238; Fri, 9 Feb 1996 15:52:17 -0800 From: schulter@zk3.dec.com Received: from bwasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA24428; Fri, 9 Feb 1996 18:40:17 -0500 Received: from dogfish.zk3.dec.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14022; Fri, 9 Feb 1996 18:40:16 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA30321; Fri, 9 Feb 1996 18:40:47 -0500 Message-Id: <9602092340.AA30321@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: Grenville Armitage Cc: bound@zk3.dec.com, ip-atm@matmos.hpl.hp.com, ipng@sunroof.eng.sun.com, gja@thumper.bellcore.com Subject: (IPng 1374) Re: IPv6 over NBMA In-Reply-To: Your message of "Fri, 09 Feb 96 13:20:42 EST." <199602091820.NAA20467@thumper.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Feb 96 18:40:47 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 09 Feb 96 13:20:42 EST Grenville Armitage wrote: > Just for precision's sake, there is no 'Schulter/Jork/Armitage' model > per se. No, there isn't. However, in Jim's defense, I think what he was saying was that you and I started from the same basic assumptions (trying to find a way to make ND work over ATM) and independently came up with two approaches for doing ND over ATM. This would seem to show that it is quite possible to apply ND to ATM. > Then there is the NHRP based approach, which is believed to provide > a ND _service_ while not using the ND _protocol_ (a distinction I > think I saw Joel make a few days ago). Well, this has been bothering me a little as I've been working on my update and answering mail here. There is really no NHRP approach other than some people saying NHRP should be used. What we don't have for an NHRP approach is an I-D which everyone can read to evaluate how NHRP would solve the problems of IPv6 address resolution, address configuration, router discovery, etc. I think an I-D for an NHRP approach would be helpful in the discussions that have been going on around this topic. This would give everyone here some idea of how an NHRP approach would provide the services currently provided by ND and maintain IPv6 link semantics. Maybe one or more of the folks suggesting an NHRP solution should submit a draft so at least everyone is discussing the same thing when discussing an NHRP approach. Just a thought. --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 10 23:44:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03173; Sat, 10 Feb 96 23:44:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03167; Sat, 10 Feb 96 23:44:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03687; Sat, 10 Feb 1996 23:43:02 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id XAA06068; Sat, 10 Feb 1996 23:43:01 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05558 Sun, 11 Feb 1996 18:42:55 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: (IPng 1375) link local address modification draft Date: Sun, 11 Feb 1996 18:43:12 +1100 Message-Id: <13847.824024592@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have just sent the draft proposing modifying link local addresses so they can be (if an implementation desires) intra-node unique as well as intra-link unique. It should appear in the I-D directories sometime in the first half of the coming week. For those who would prefer to get it quicker than that, you can now find it on munnari.oz.au in the big-internet directory, as draft-ietf-ipngwg-iid-00.txt (which should be how it appears in the I-D directories). That is, it can now be found in: ftp://munnari.oz.au/big-internet/draft-ietf-ipngwg-iid-00.txt Obviously the group is free to say anything about it that you like, but I would rather prefer to attempt to get the draft as complete, accurate, and convincing, as possible first, then once it expresses te arguments in favour of the change as best it can, then to discuss whether doing the thing at all is worth the bother. That is - it would be kind of nice to avoid a series of "it fails because of ... so don't do it", followed by "that can be fixed by ... so we can do it" exchanges, at the end of which we probably won't have much idea just where we are. Instead, messages of the form "There's a problem ... which can be fixed by ..." (or even without the fix) would be appreciated. After that's done, we can get into the "that is unimplementable" or "the extra effort isn't worth the gain" ... type discussion - preferably after the next draft appears, which should still be before the LA ietf if we get some of the first kind of comment sometime this week. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 11 15:42:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03456; Sun, 11 Feb 96 15:42:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03450; Sun, 11 Feb 96 15:42:29 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28563; Sun, 11 Feb 1996 15:41:24 -0800 Received: from bingsun2.cc.binghamton.edu by mercury.Sun.COM (Sun.COM) id PAA22593; Sun, 11 Feb 1996 15:41:25 -0800 From: be26804@bingsuns.cc.binghamton.edu Received: (from be26804@localhost) by bingsun2.cc.binghamton.edu (8.6.12/8.6.9) id SAA14144; Sun, 11 Feb 1996 18:42:01 -0500 Date: Sun, 11 Feb 1996 18:41:59 -0500 (EST) X-Sender: be26804@bingsun2 To: ipng Subject: (IPng 1376) IPv6 implementation for Linux Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I plan to do some implementation for Linux as my Master thesis. Does any body has suggestion? Thans for your reply. Tim Hung ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 11 17:33:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03523; Sun, 11 Feb 96 17:33:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03517; Sun, 11 Feb 96 17:33:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02875; Sun, 11 Feb 1996 17:32:00 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id RAA29294; Sun, 11 Feb 1996 17:32:00 -0800 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id RAA10590; Sun, 11 Feb 1996 17:31:28 -0800 Message-Id: <199602120131.RAA10590@mailhost.Ipsilon.COM> To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1377) Re: link local address modification draft In-Reply-To: Your message of "Sun, 11 Feb 1996 18:43:12 +1100." <13847.824024592@munnari.OZ.AU> Date: Sun, 11 Feb 1996 17:31:28 -0800 From: Dennis Ferguson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, I really wish you hadn't laid out a set of rules for commenting on this since I have no idea of where my objection fits into your rules. I am going to assume that you didn't intend the rules to stifle the expression of contrary views (please correct me if I am assuming wrong), particularly since I think the functionality you want needs to exist. It is only the reason you seem to want it which I think is wrong. Here's the first line of the note you sent: > I have just sent the draft proposing modifying link local > addresses so they can be (if an implementation desires) > intra-node unique as well as intra-link unique. Here is a paragraph from your draft which I think summarizes the only justification you provide for wanting to do this at all: > If this is adopted, link local addresses could become the standard > method for interface identification for IPv6, eliminating the various > methods used for IPv4, none of them very satisfactory. I would first point out the apparent inconsistency between the two statements. You suggest that this change will permit an implementation to make link-local addresses intra-node unique _if an implementation desires_, but your sole justification for doing this is stated to be so "link local addresses could become the standard method for interface identification for IPv6". If this becomes the standard method of identifying IPv6 interfaces internal to an implementation it seems to me an implementation which needs to conform to the standard (and if implementations didn't need to conform to the standard then what would be the use of the standard?) won't have any choice but to number each and every interface uniquely, whether it desires this or not. So, based on the only justification you have in the draft, it appears to me that your sole intention is to force implementations to standardize on address-identification of IPv6 interfaces. There are a number of reasons I think it would be a bad idea to standardize the use of IPv6 addresses for the identification of interfaces (and this is coming from someone who has some experience writing software which depends critically on incoming interface identification). (1) IPv4 won't go away, i.e. support for IPv4 will be as important as support for IPv6 for a long time (support for IPv4 is certainly much, much more important now), and there is no lesser (or greater) need to identify incoming interfaces to applications in IPv4 than in IPv6. This means that if you are running IPv4 applications which are sensitive to incoming interface you will already have a non-address method of identifying incoming interfaces, and the same mechanism will work equally well for IPv6. In this case using addresses for IPv6 just adds code for no apparent functional benefit. Of course, if you have no way to identify incoming interfaces in your IPv4 code I would question the need for this in IPv6. Aren't the applications supposed to be the same? In either case there seems to be no need for an IPv6-specific standard anything. (2) You make the entirely unsupported (and apparently very subjective) assertion that, of the "methods used for IPv4, none of them [are] very satisfactory". Please support this. I have experience with at least one method of doing this for IPv4, which I found to be quite satisfactory and which would work equally well for IPv6. How does your experience differ, and why is this compelling enough to standardize on a whole new method? (3) I wish to retain the option of not generating unique interface addresses in the case where the number of interfaces (of either the physical or logical variety) is very large, and where the amount of state one would have to keep in one's address lookup data structure to accomodate this would be relatively (and unjustifiably) large. And, while I wouldn't mind generating unique addresses if the number of interfaces were smaller (i.e. the normal case) I don't want anything to rely on this being so as this breaks the corner case. A non-address mechanism of identifying interfaces works fine in all cases, and for all protocols. I don't think your justification works. I think there is sufficient experience with non-address interface identification to show that it works just fine, and that the proposal is simply unnecessary if the ability to identify interfaces by address internal to an implementation is the only justification you can offer. The reason I think the ability to form intra-node unique link-local addresses needs to exist in any case is to address an issue that caused related problems when trying to figure out how OSPF for IPv6 should work. That is, how do you handle the case where you have two interfaces on the same physical link? There are actually two ways this could occur. The first, common case is that the physical link is actually an ethernet or a FDDI switch, and you want two (or more) interfaces to it for load sharing, to get more bandwidth to the subnet. The second case, which is probably rare but which I think needs to be handled, is what you do when two formerly separate subnets which you have interfaces on get bridged together somehow. It isn't clear to me how it was intended that this should work (and there is the issue, of course, that if your implementation uses the same MAC address on different interfaces you're probably not going to deal well with the latter occurance no matter what) but, certainly from the point of view of the routing protocol, it wasn't clear that anything would ever work if you didn't have unique link-local addresses on each interface that could conceivable be bridged onto the same link as another interface. So I think `The method' section of your draft addresses a problem which I think needs to be addressed. I think, however, that your justification for doing this is a non-issue, and should be replaced with something which is an issue. And I have no idea how this comment fits in with your rules, so I'll save it for later if it is inappropriate now. Dennis Ferguson ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 11 17:56:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03603; Sun, 11 Feb 96 17:56:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03597; Sun, 11 Feb 96 17:56:20 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03638; Sun, 11 Feb 1996 17:55:17 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id RAA01001; Sun, 11 Feb 1996 17:55:16 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06102 Mon, 12 Feb 1996 12:55:00 +1100 (from kre@munnari.OZ.AU) To: Dennis Ferguson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1378) Re: link local address modification draft In-Reply-To: Your message of "Sun, 11 Feb 1996 17:31:28 -0800." <199602120131.RAA10590@mailhost.Ipsilon.COM> Date: Mon, 12 Feb 1996 12:55:17 +1100 Message-Id: <14302.824090117@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 11 Feb 1996 17:31:28 -0800 From: Dennis Ferguson Message-ID: <199602120131.RAA10590@mailhost.Ipsilon.COM> I really wish you hadn't laid out a set of rules for commenting on this since I have no idea of where my objection fits into your rules. Hmm, sorry. Maybe I can make my intent simpler. Basically I want(ed) to avoid the situation where we indulge in a series of "object this part" "I can fix that" "object to that part" "I can fix that too" - ie: backwards and forwards arguments that result from the draft not really being as convincing an argument for the position than it could be. I think we will reach a conclusion faster if we concentrate on getting the draft to the best possible state that we can first, so all the people who favour the proposal basically agree that it is as good an argument as it can be in the time available. Then those who disagree get a crack of tearing down the complete thing, rather than an argument that is incomplete. This to me seems fairer to both sites, the proponents don't have to keep fixing things in response to arguments, and the opponents don't have to attempt to figure out what tomorrows argument will be. I am going to assume that you didn't intend the rules to stifle the expression of contrary views No - even if I did, my "rules" would do no good, people would object anyway... I am just trying to streamline the process a little (if people think that won't work, or is a waste of time, then I can't imagine anything I have said will prevent most on this list from speaking their minds!) I think your comment is totally relevant for right now. If my justification for the concept isn't the right one, then now is when it should be fixed, so those who don't want the things at all can argue against the best argument, rather than a weak one. Having said that, now I will go read your comments carefully. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 12 09:12:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03819; Mon, 12 Feb 96 09:12:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03813; Mon, 12 Feb 96 09:11:58 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20231; Mon, 12 Feb 1996 09:10:52 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id JAA14101; Mon, 12 Feb 1996 09:10:53 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA20611; Mon, 12 Feb 1996 09:08:29 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 Feb 1996 09:10:51 -0800 To: Jean-Luc Richier From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1379) Re: Re-Request for Advancement of IPng IPv6overEthernet Document Cc: hinden@Ipsilon.COM (Bob Hinden), sob@harvard.edu, mankin@isi.edu, ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us, deering@parc.xerox.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jean-Luc, >Can somebody please summarizes the conclusion of the discussion. >I am not sure that I know what was this conclusion. > >If I am correct, the discussion was about unicity of Link Layer address >in a multi-homed node : inside a node, can we use a LL address to implicitely >specify a interface ? The conclusion is that inside of a node a LL address can not be used exclusively to identify an interface if the node has multiple interfaces which use the same interface identifier. >Three solutions were proposed : > >- Modify the draft to add a interface information in the LL address > It seems that this solution is abandonned, according to the message. Correct. >- Make sure that the interface token is unique on ALL the interfaces of a > node. I think that this solution : > - either modifies the SUN ether implementation, where all the > interface have the same token. > - or contradicts the text of the draft, which says that the token must > be the manufacter token, with no modification allowed Note that the only requirement is for a LL address to be unique on a specific link (e.g., on the wire), not inside of a node. There are a numbers of ways for an implementation to identify it's interfaces other than using addresses. Implementations which choose to use the same MAC address for interfaces on different links will need to associate some other information with the address to identify the interface within the node. >- Define an explicit method to specify the interface in the read and write of > packets with Link layer addresses. The bsdi API draft > draft-ietf-ipngwg-bsd-api proposes a method, which allow to specify the > interface with an IPV6 address : > >++ The last address in the array is an IPv6 address of the receiving >++ interface. Since interfaces in IPv6 may have more than one address, and >++ some addresses (e.g. link-local addresses) may be used on more than one >++ interface, the system should select an address that uniquely identifies >++ the interface. > (PS : I think the ``should'' should be a ``must'', otherwise the > constrution has no interest) > > This supposes that the interfaces have a address unique at the node level. > But a node must be able to work without any global address configured, > and in that case the only addresses are Link Local addresses. Therefore > it seems that the bsd-api draft asks for unique LL adresses, in > contradiction with the ipng-over-ethernet draft. > Or is there some special "node level" address proposal ? I agree that the API document need to be clearer on this issue. Perhaps to add ", if possible" to the end of the text you cite. I discussed this with Bob Gilligan and he is aware of the issue. I do not think that IPv6 addresses are a great way to identify interfaces inside of a node, though they would certainly allow for a lot of interfaces :-) Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 12 13:44:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04066; Mon, 12 Feb 96 13:44:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03757; Mon, 12 Feb 96 06:16:02 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02093; Mon, 12 Feb 1996 06:14:58 -0800 Received: from ec-mail.bellsouth.net by mercury.Sun.COM (Sun.COM) id GAA04185; Mon, 12 Feb 1996 06:14:57 -0800 Received: (from root@localhost) by ec-mail.bellsouth.net (8.6.12/8.6.12) id JAA04927 for ipng@sunroof.Eng.Sun.COM; Mon, 12 Feb 1996 09:15:16 -0500 Date: Mon, 12 Feb 1996 09:15:16 -0500 From: tgardner@bellsouth.NET (Terry Gardner) Message-Id: <199602121415.JAA04927@ec-mail.bellsouth.net> Content-Type: text Apparently-To: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From owner-ipng@sunroof.Eng.Sun.COM Sun Feb 11 19:00 EST 1996 Return-Path: owner-ipng@sunroof.Eng.Sun.COM Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ec-mail.bellsouth.net (8.6.12/8.6.12) with ESMTP id TAA00699 for ; Sun, 11 Feb 1996 19:00:13 -0500 Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id XAA06236; Sat, 10 Feb 1996 23:45:24 -0800 Received: from sunroof.eng.sun.com by Eng.Sun.COM (5.x/SMI-5.3) id AA16661; Sat, 10 Feb 1996 23:45:18 -0800 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03173; Sat, 10 Feb 96 23:44:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03167; Sat, 10 Feb 96 23:44:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03687; Sat, 10 Feb 1996 23:43:02 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id XAA06068; Sat, 10 Feb 1996 23:43:01 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05558 Sun, 11 Feb 1996 18:42:55 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 1375) link local address modification draft Date: Sun, 11 Feb 1996 18:43:12 +1100 Message-Id: <13847.824024592@munnari.OZ.AU> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Content-Type: Content-Length: I have just sent the draft proposing modifying link local addresses so they can be (if an implementation desires) intra-node unique as well as intra-link unique. It should appear in the I-D directories sometime in the first half of the coming week. For those who would prefer to get it quicker than that, you can now find it on munnari.oz.au in the big-internet directory, as draft-ietf-ipngwg-iid-00.txt (which should be how it appears in the I-D directories). That is, it can now be found in: ftp://munnari.oz.au/big-internet/draft-ietf-ipngwg-iid-00.txt Obviously the group is free to say anything about it that you like, but I would rather prefer to attempt to get the draft as complete, accurate, and convincing, as possible first, then once it expresses te arguments in favour of the change as best it can, then to discuss whether doing the thing at all is worth the bother. That is - it would be kind of nice to avoid a series of "it fails because of ... so don't do it", followed by "that can be fixed by ... so we can do it" exchanges, at the end of which we probably won't have much idea just where we are. Instead, messages of the form "There's a problem ... which can be fixed by ..." (or even without the fix) would be appreciated. After that's done, we can get into the "that is unimplementable" or "the extra effort isn't worth the gain" ... type discussion - preferably after the next draft appears, which should still be before the LA ietf if we get some of the first kind of comment sometime this week. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 13 10:09:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04536; Tue, 13 Feb 96 10:09:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04366; Tue, 13 Feb 96 02:18:17 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18292; Tue, 13 Feb 1996 02:17:11 -0800 Received: from basil.cdt.luth.se by mercury.Sun.COM (Sun.COM) id CAA05877; Tue, 13 Feb 1996 02:17:11 -0800 Received: from my8.sm.luth.se (my8.sm.luth.se [130.240.3.38]) by basil.cdt.luth.se (8.6.12/8.6.12) with ESMTP id LAA18665; Tue, 13 Feb 1996 11:16:41 +0100 Received: from my8 (localhost [127.0.0.1]) by my8.sm.luth.se (8.6.12/8.6.12) with ESMTP id LAA14381; Tue, 13 Feb 1996 11:18:22 +0100 Message-Id: <199602131018.LAA14381@my8.sm.luth.se> X-Mailer: exmh version 1.6.2 7/18/95 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: ipng@sunroof.eng.sun.com Cc: steve@sics.se, bcn@cdt.luth.se, micke@sm.luth.se Subject: (IPng 1380) Header Compression for IPv6 Date: Tue, 13 Feb 1996 11:18:21 +0100 From: Mikael Degermark Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi folks, I have just submitted an internet draft on header compression for IPv6. It should appear in a few days. Meanwhile, you may fetch it at ftp://ftp.sm.luth.se/pub/micke/draft-degermark-ipv6-hc-00.txt A typical IPv6 header is compressed down to 3-5 octets, including a 2 octet transport layer (UDP or TCP) checksum. Compression state is maintained with soft-state mechanisms, and since there are no exchanges of messages between compressor and decompressor, except for the packets whose headers are compressed, the protocol works over simplex links. We'll appreciate any comments you might have, either on this list or at the LA IETF. Enjoy! Mikael Degermark ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 13 11:21:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04652; Tue, 13 Feb 96 11:21:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04646; Tue, 13 Feb 96 11:20:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11556; Tue, 13 Feb 1996 11:19:43 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id LAA24598; Tue, 13 Feb 1996 11:19:41 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa16048; 13 Feb 96 10:39 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1381) I-D ACTION:draft-ietf-ipngwg-iid-00.txt Date: Tue, 13 Feb 96 10:39:17 -0500 Message-Id: <9602131039.aa16048@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Identifying Interfaces in IPv6 link-local addresses Author(s) : R. Elz Filename : draft-ietf-ipngwg-iid-00.txt Pages : 6 Date : 02/12/1996 This draft proposes a change to the way that IPv6 link local addresses are constructed, so that a node can guarantee that all of its link local addresses are unique within the node. The current definition of a link local address, a well known prefix, some number of zero bits, and a link specific unique token, ensures that it will be unique on the link, which is what is required for communications using those addresses over the link, but does not require uniqueness of the addresses within a node. In some cases all of a nodes interfaces may share the same link local address. Even the possibility of this means that link local addresses, which may in some situations be the only addresses that exist, cannot be used for internal definition of interfaces, or other purposes within the node. This draft suggests a method by which nodes may overcome this problem, by redefining the bits between the prefix and the token to be available to be used by the node to cause the addresses to be unique. 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-iid-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-iid-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-iid-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960212121630.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-iid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-iid-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960212121630.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 14 08:46:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05346; Wed, 14 Feb 96 08:46:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05340; Wed, 14 Feb 96 08:46:34 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21292; Wed, 14 Feb 1996 08:45:26 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id IAA05447; Wed, 14 Feb 1996 08:45:25 -0800 Received: from muggsy.lkg.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA11331; Wed, 14 Feb 1996 11:38:57 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA15571; Wed, 14 Feb 1996 11:38:56 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id QAA17259; Wed, 14 Feb 1996 16:57:57 GMT Message-Id: <199602141657.QAA17259@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: stephen.thomas@tridom.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1382) IPv6 over Token Ring (draft-ietf-ipngwg-token-ring-01.txt) X-Mailer: exmh version 1.5omega 10/6/94 Date: Wed, 14 Feb 1996 16:57:31 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 1042 discusses how to do Token Ring source route discovery using ARP. I don't see any comparable mention of source routing in the IPv6 over Token Ring draft. How link layer source routing interacts with Neighbor Solicitations, Neighbor Advertisements, and with other unicast and multicast packets needs to be specified. Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 14 09:14:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05388; Wed, 14 Feb 96 09:14:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05382; Wed, 14 Feb 96 09:14:37 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26532; Wed, 14 Feb 1996 09:13:29 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id JAA14594; Wed, 14 Feb 1996 09:13:26 -0800 Received: from muggsy.lkg.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA22079; Wed, 14 Feb 1996 11:56:25 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA15748; Wed, 14 Feb 1996 11:56:24 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id RAA17341 for ; Wed, 14 Feb 1996 17:15:30 GMT Message-Id: <199602141715.RAA17341@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 1383) Neighbor advertisements and the override bit (again). X-Mailer: exmh version 1.5omega 10/6/94 Date: Wed, 14 Feb 1996 17:15:21 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In section 7.2.4, Sending Solicited Neighbor Advertisements, of draft-ietf-ipngwg-discovery-04.txt: ... If the solicitation's IP Destination Address is a unicast or anycast address, the Target Link-Layer Address option SHOULD NOT be included; the neighboring node's cached value must already be current in order for the solicitation to have been received. ... If the Target Address is either an anycast address or a unicast address for which the node is providing proxy service, the Override flag SHOULD be set to zero. Otherwise, it SHOULD be set to one. In section 7.2.5, Receipt of Neighbor Advertisements: If the target's Neighbor Cache entry is in any state other than INCOMPLETE when the advertisement is received, the advertisement's Override flag's setting determines whether the Target Link-Layer Address option (if present) replaces the cached address. If the Override flag is set, the receiving node MUST install the link-layer address in its cache; if the flag is zero, the receiving node MUST NOT install the link-layer address in its cache. An advertisement's sender sets the Override flag when it wants its Target Link-Layer Address option to replace the cached value in Neighbor Cache entries, regardless of their current contents. While the "(if present)" helps, the section is still ambiguous. I'd like for Section 7.2.4 to replace the If the Target Link-Layer Address option is not included in the advertisement, the Override flag MUST be set to zero. before: If the Target Address is either an anycast address or a unicast address for which the node is providing proxy service, the Override flag SHOULD be set to zero. Otherwise, it SHOULD be set to one. What meaning does the Override flag have if the Target Link option is not present? Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 15 02:22:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06272; Thu, 15 Feb 96 02:22:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06266; Thu, 15 Feb 96 02:21:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00458; Thu, 15 Feb 1996 02:20:45 -0800 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id CAA12531; Thu, 15 Feb 1996 02:20:43 -0800 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Thu, 15 Feb 1996 19:01:55 +0859 From: Masataka Ohta Message-Id: <199602151002.TAA11727@necom830.cc.titech.ac.jp> Subject: (IPng 1384) Re: ipatm, rolc, and joint LA session agendas To: malis@nexen.com (Andrew G. Malis) Date: Thu, 15 Feb 96 19:01:54 JST Cc: rolc@nexen.com, ip-atm@matmos.hpl.hp.com, rsvp@isi.edu, int-serv@isi.edu, ipng@sunroof.eng.sun.com, malis@nexen.com In-Reply-To: <199602091715.MAA13099@phish.nexen.com>; from "Andrew G. Malis" at Feb 9, 96 12:15 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andy; > Please respond, either publicly or privately, if you have specific > topics and/or internet drafts you would like to put on any of the > above agendas. I'd like to discuss lose of multicast scalability caused by NHRP. It could be discussed in ipatm, ipatm/rsvp/intserv or ipatm/rolc/ipng meeting, I think. I'll prepare an ID (2 or 3 pages long, I think) before 2/22 deadline. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 15 05:59:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06383; Thu, 15 Feb 96 05:59:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06377; Thu, 15 Feb 96 05:59:17 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10574; Thu, 15 Feb 1996 05:58:07 -0800 Received: from guelah.nexen.com by mercury.Sun.COM (Sun.COM) id FAA07028; Thu, 15 Feb 1996 05:58:08 -0800 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.6.12) with ESMTP id IAA09411; Thu, 15 Feb 1996 08:55:30 -0500 (EST) Received: from phish.nexen.com (phish.nexen.com [204.249.99.14]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id IAA28668; Thu, 15 Feb 1996 08:50:31 -0500 (EST) Received: from localhost (malis@localhost) by phish.nexen.com (8.7.3/8.7.3) with SMTP id IAA17991; Thu, 15 Feb 1996 08:53:04 -0500 (EST) Message-Id: <199602151353.IAA17991@phish.nexen.com> To: Yukinori Goto Cc: "Andrew G. Malis" , rolc@nexen.com, ip-atm@matmos.hpl.hp.com, rsvp@ISI.EDU, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com, malis@nexen.com Subject: (IPng 1385) Re: ipatm, rolc, and joint LA session agendas In-Reply-To: Your message of "Thu, 15 Feb 1996 13:55:16 +0900." <9602150455.AA11162@alpha523.aist-nara.ac.jp> Date: Thu, 15 Feb 1996 08:53:03 -0500 From: "Andrew G. Malis" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yuri, > If there is enough time in ipatm session on Tuesday 3/5, I would > like to present SINP (Session Identity Ntification Protocol). Thanks for your request. This probably fits in best for the joint ipatm/rsvp/intserv meeting on Wednesday 3/6. Regards, 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 Thu Feb 15 08:51:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06467; Thu, 15 Feb 96 08:51:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06129; Wed, 14 Feb 96 20:57:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB14133; Wed, 14 Feb 1996 20:56:34 -0800 Received: from mailgate.aist-nara.ac.jp by mercury.Sun.COM (Sun.COM) id UAA10846; Wed, 14 Feb 1996 20:56:00 -0800 Received: from alpha523.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id NAA06040; Thu, 15 Feb 1996 13:55:42 +0900 Received: from localhost by alpha523.aist-nara.ac.jp (5.67+1.6W[kuis-17]/2.8Wb/NAIST-1.3[is]) id AA11162; Thu, 15 Feb 96 13:55:16 GMT+0900 Message-Id: <9602150455.AA11162@alpha523.aist-nara.ac.jp> To: "Andrew G. Malis" Cc: rolc@nexen.com, ip-atm@matmos.hpl.hp.com, rsvp@ISI.EDU, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Subject: (IPng 1386) Re: ipatm, rolc, and joint LA session agendas In-Reply-To: Your message of "Fri, 09 Feb 1996 12:15:38 EST." <199602091715.MAA13099@phish.nexen.com> Date: Thu, 15 Feb 1996 13:55:16 +0900 From: Yukinori Goto Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear ip-atm menbers, If there is enough time in ipatm session on Tuesday 3/5, I would like to present SINP (Session Identity Ntification Protocol). SINP has been published Internet-Draft draft-goto-sinp-01.txt. I think that, when we reserve network resources to guarantee of QoS using RSVP, we must correspond VC and QoSed flow, and this matter occurs in not only Conventional IP over ATM but also Classical IP over ATM with NHRP. Therefore we need SINP to correspond VC and QoSed flow. Best regards, ===================================================== Yukinori Goto Graduate School of Information Science, Nara Institute of Science and Technology, Japan ===================================================== ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 15 09:02:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06529; Thu, 15 Feb 96 09:02:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06401; Thu, 15 Feb 96 06:41:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13724; Thu, 15 Feb 1996 06:40:02 -0800 Received: from lab1.kuis.kyoto-u.ac.jp by mercury.Sun.COM (Sun.COM) id GAA14599; Thu, 15 Feb 1996 06:40:01 -0800 Received: from cherokee.kuis.kyoto-u.ac.jp (cherokee.kuis.kyoto-u.ac.jp [130.54.22.105]) by lab1.kuis.kyoto-u.ac.jp (8.6.9+2.4W/3.3W-cefiro) with ESMTP id XAA05334; Thu, 15 Feb 1996 23:33:36 +0900 Received: from localhost by cherokee.kuis.kyoto-u.ac.jp (8.6.12+2.5Wb7/KUCS2.5) id OAA14936; Thu, 15 Feb 1996 14:33:49 GMT Message-Id: <199602151433.OAA14936@cherokee.kuis.kyoto-u.ac.jp> To: malis@nexen.com Cc: rolc@nexen.com, ip-atm@matmos.hpl.hp.com, rsvp@isi.edu, int-serv@isi.edu, ipng@sunroof.eng.sun.com Subject: (IPng 1387) IP-SVC Re: ipatm, rolc, and joint LA session agendas In-Reply-To: Your message of "Fri, 09 Feb 1996 12:15:38 -0500" References: <199602091715.MAA13099@phish.nexen.com> X-Mailer: Mew beta version 0.91 on Emacs 19.28.4, Mule 2.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 15 Feb 1996 23:33:47 +0900 From: FUJIKAWA Kenji Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear ip-atm members, I'm a newcomer in this ML, but I would like to join the IETF meeting and to present ``IP-SVC'', which establishes VCs dynamically in an ATM network with IP signaling packets. IP-SVC is effective, 1) where various vendors' ATM switchs and NICs are used and SVC is not available. 2) when SVC is needed through public ATM networks. 3) even if SVC is available. Because SVC can only be used for The Classical Model or LANE. IP-SVC enables you to carry out various experiments. I'm developing IP-SVC in cooperation with OHTA Masataka and GOTO Yukinori. The Conventional Model using SINP is now being developed on an IP-SVC system. If there remains available time in ipatm session on Tuesday 3/5, I woud like you to add my IP-SVC presentation just before GOTO's SINP presentation. Best regards, --------------------------------------------------------- FUJIKAWA Kenji @ Dept. of Info. Sci., Kyoto Univ., Japan TEL +81 075-753-5387 FAX +81 075-751-0482 e-mail magician@kuis.kyoto-u.ac.jp ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 15 10:44:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06683; Thu, 15 Feb 96 10:44:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06677; Thu, 15 Feb 96 10:44:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17744; Thu, 15 Feb 1996 10:42:56 -0800 Received: from mailgate.aist-nara.ac.jp by mercury.Sun.COM (Sun.COM) id KAA26076; Thu, 15 Feb 1996 10:42:54 -0800 Received: from alpha523.aist-nara.ac.jp by mailgate.aist-nara.ac.jp (8.6.10+2.5Wb1/2.8Wb/NAIST-1.6[gate]) id DAA24192; Fri, 16 Feb 1996 03:42:46 +0900 Received: from localhost by alpha523.aist-nara.ac.jp (5.67+1.6W[kuis-17]/2.8Wb/NAIST-1.3[is]) id AA11446; Fri, 16 Feb 96 03:42:52 GMT+0900 Message-Id: <9602151842.AA11446@alpha523.aist-nara.ac.jp> To: "Andrew G. Malis" Cc: Yukinori Goto , rolc@nexen.com, ip-atm@matmos.hpl.hp.com, rsvp@ISI.EDU, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Subject: (IPng 1388) Re: ipatm, rolc, and joint LA session agendas In-Reply-To: Your message of "Thu, 15 Feb 1996 08:53:03 EST." <199602151353.IAA17991@phish.nexen.com> Date: Fri, 16 Feb 1996 03:42:51 +0900 From: Yukinori Goto Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Andy, > Thanks for your request. This probably fits in best for the joint > ipatm/rsvp/intserv meeting on Wednesday 3/6. I agree to your comment. I will discuss on Wednesday. Regards, ===================================================== Yukinori Goto Graduate School of Information Science, Nara Institute of Science and Technology, Japan ===================================================== ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 15 11:41:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06754; Thu, 15 Feb 96 11:41:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06738; Thu, 15 Feb 96 11:38:26 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28775; Thu, 15 Feb 1996 11:37:16 -0800 Received: from sam.SyzygyComm.COM by mercury.Sun.COM (Sun.COM) id LAA12718; Thu, 15 Feb 1996 11:37:15 -0800 Received: from isis.SyzygyComm.COM by sam.SyzygyComm.COM (5.0/SMI-SVR4) id AA09463; Thu, 15 Feb 1996 11:40:03 +0800 Received: from Rockys.SyzygyComm.COM by isis.SyzygyComm.COM (4.1/SMI-4.1) id AA22571; Thu, 15 Feb 96 11:35:20 PST Date: Thu, 15 Feb 96 11:24:19 PST From: Steve Jackowski Subject: (IPng 1389) Re: ipatm, rolc, and joint LA session agendas To: "Andrew G. Malis" Cc: rolc@nexen.com, ip-atm@matmos.hpl.hp.com, rsvp@ISI.EDU, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com, malis@nexen.com X-Mailer: Chameleon V0.05, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andy, I'd like to do a presentation in the ipatm/joint rsvp/ipatm/intsrv meeting on a proposed informational RFC I've submitted entitled Native ATM in the Internet. In it I examine the use of reservation protocols and why they are necessary for ATM, then describe the implementation that we did for a major PTT using ST-2 as the reservation protocol. I give examples of signalling mapping, mapping of multicast in a scalable fashion, and mapping of QoS parameters. Much of what we learned in developing this commercial product would be of benefit to the implementation of any reservation protocol in an ATM environment. However, I must point out that the connection-oriented, origin-oriented, hard state nature of ST makes it much easier to implement than rsvp (work is in process here as well). Ideally I'd like 20 minutes, but could summarize it in ten. Let me know. Steve ------------------------------------- Name: Steve Jackowski E-mail: stevej@netmanage.com (Steve Jackowski) Phone: (408) 439-6834 Date: 02/15/96 Time: 11:24:19 This message was sent by Chameleon ------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 15 12:56:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06799; Thu, 15 Feb 96 12:56:58 PST Received: from caribe.eng.sun.com (caribe-86) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06793; Thu, 15 Feb 96 12:56:42 PST Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id MAA22562 for ; Thu, 15 Feb 1996 12:54:42 -0800 (PST) Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA02539; Thu, 15 Feb 1996 12:55:29 -0800 Date: Thu, 15 Feb 1996 12:55:29 -0800 From: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Message-Id: <199602152055.MAA02539@bobo.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1390) Re: Request for Advancement of IPng IPv6overFDDI Document Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Filename : draft-ietf-ipngwg-fddi-ntwrks-02.txt One question/problem with the "Interaction with Bridges": The spec states that this applies only to received valid Router Advertisement or Neighbor Advertisement messages. If A sends a Neighbor Solicitation to B (and B sends an Advertisement back) this would allow A to use the larger MTU when sending to B. However, it does not allow B to use the larger MTU when sending to A. (Assuming A and B are not separated by a bridge.) This could be fixed by at least adding Neighbor Solicitation to the list of packets that trigger the FDDI adjacency detection. Or alternatively the spec could say that the reception of any valid neighbor discovery packet should trigger the FDDI adjacency detection check for the *source* of the packet (applying it to the source is critical in order to handle redirects correctly.) I don't see any technical benefit in the "all ND packets" language. Also, for clarity I think the spec should point out that the FDDI adjacency detection can never make IP multicast be sent with the larger MTU. 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 Thu Feb 15 15:39:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06930; Thu, 15 Feb 96 15:39:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06904; Thu, 15 Feb 96 15:26:59 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10285; Thu, 15 Feb 1996 15:25:48 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id PAA17219; Thu, 15 Feb 1996 15:25:49 -0800 Received: from alpha.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA31526; Thu, 15 Feb 1996 18:23:55 -0500 Received: from brigit.zk3.dec.com by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM) id AA07946; Thu, 15 Feb 1996 18:23:44 -0500 Received: by brigit.zk3.dec.com; (5.65v3.2/1.1.8.2/24Apr95-0109PM) id AA03732; Thu, 15 Feb 1996 18:26:00 -0500 Date: Thu, 15 Feb 1996 18:26:00 -0500 From: alex conta Message-Id: <9602152326.AA03732@brigit.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1391) N&RD draft V4 - comments Cc: conta@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, and Hi Thomas, I recently read version 4 of your neighbor discovery document. Here is my feedback: 1. Bottom line ---------------- I think the document is extremely good. The work done is extremelly valuable. Started and based at a certain degree on the previous work done by Bill Simpson and the working group, you have designed practically from scratch the mechanisms, gathered and documented all the details, variants, and possible facets of the neighbor and router discovery mechanisms, like never before. This is excellent work. It is definiteley an example to follow. 2. Size of the document ----------------------- I bring to your attention a personal opinion, that became stronger most recently before the UNH bake-off during updating my neighbor discovery implementation to the latest version of the specs. The document is long. It has almost 90 pages. It is excellent through the details that it provides, as I said above. I felt and feel that it would be so great, if the same amount of information could be delivered in fewer words, with no less accuracy, or amount of information. Could it be done in 60-70% of the current size, perhaps even 50%? I think a document of not more than 50 pages would be absolutely excellent from all angles. As a matter of fact, I identified a couple of sections were compacting the document is feasable and with more effort other sections can be identified. I send you this through direct Email to not aglomerate the mailing list. To compact the document is a lot of work indeed. But I think that if shortening it with no loss of information content is not possible, then it should be seriously considered to get to 50 page range by splitting it in two: - neighbor discovery - router discovery Regards, Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 15 15:50:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06962; Thu, 15 Feb 96 15:50:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06956; Thu, 15 Feb 96 15:50:16 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13955; Thu, 15 Feb 1996 15:49:05 -0800 Received: from guelah.nexen.com by mercury.Sun.COM (Sun.COM) id PAA22960; Thu, 15 Feb 1996 15:49:05 -0800 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.6.12) with ESMTP id SAA17216; Thu, 15 Feb 1996 18:47:42 -0500 (EST) Received: from phish.nexen.com (phish.nexen.com [204.249.99.14]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id SAA07833; Thu, 15 Feb 1996 18:38:17 -0500 (EST) Received: from localhost (malis@localhost) by phish.nexen.com (8.7.3/8.7.3) with SMTP id RAA05740; Thu, 15 Feb 1996 17:29:58 -0500 (EST) Message-Id: <199602152229.RAA05740@phish.nexen.com> To: rolc@nexen.com, ip-atm@nexen.com, rsvp@isi.edu, int-serv@isi.edu, ipng@sunroof.eng.sun.com Cc: malis@nexen.com, laubach@terra.com21.com Subject: (IPng 1392) Agendas for rolc, ipatm, ipatm/rsvp/intserv, and ipatm/rolc/ipng Date: Thu, 15 Feb 1996 17:29:58 -0500 From: "Andrew G. Malis" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here are the current agendas for rolc, ipatm, ipatm/rsvp/intserv, and ipatm/rolc/ipng. These are very fluid and subject to change. As I will be on vacation, please send updates, corrections, and additional requests to both me and Mark Laubach (laubach@terra.com21.com). Mark will take care of keeping these agendas up to date while I'm out incommunicado. Also, PLEASE NOTE: As of now, the ip-atm list has moved to ip-atm@nexen.com. To join or leave the list, use ip-atm-request@nexen.com or majordomo@nexen.com, using the normal majordomo subscribe and unsubscribe requests. Mail to the hp address will be automatically forwarded to the new list. If you have a problem with the list, send email to to postmaster@nexen.com. Thanks much, Andy ------- rolc, Monday 3/4 at 1300-1500 and 1530-1730 First session: - ATM Forum report and liaison from LANE and MPOA (Swallow & Halpern) - Current (we hope final :-) NHRPv1 draft (Luciani) - NHRP MIB (Luciani and Greene) - Router-to-Router NHRP (Rehkter) - NHRP/ATMARP/MARS Server Cache Synchronization Protocol (Luciani) Second session: - PIM over ATM (Rehkter) draft-rekhter-pim-atm-00.txt - NHRP Multicast routing (Ohta) ipatm, Tuesday 3/5 at 1300-1500 and Wednesday 3/6 at 1300-1500 - ATM Forum report and liaison from LANE and MPOA (Swallow & Halpern) - NHRP/ATMARP/MARS Server Cache Synchronization Protocol (Luciani) - Classical IP/ATM MIB (Luciani, Greene, White, Kuo) - IP-SVC (Kenji) - Session Identity Ntification Protocol (Goto) draft-goto-sinp-01.txt Joint ipatm/rsvp/intserv meeting on Wednesday 3/6 at 1530-1730 - RSVP over IP over ATM (Berson) - Intserv services layered over ATM signaling (Partridge) - RFC 1755 (IP/ATM signaling) update - Native ATM Support in the Internet (Jackowski) Joint ipatm/rolc/ipng joint session on Thursday 3/7 at 1300-1500 - IPv6 over ATM (Schulter) draft-schulter-ipatm-ipv6frmwrk-01.txt - IPv6 over ATM (Armitage) - IPv6 over NBMA Networks (Atkinson, Haskin, and Luciani) draft-ahl-ipv6-nbma-00.txt - Neighbor Discovery for NBMA (Nordmark) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 15 16:02:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06988; Thu, 15 Feb 96 16:02:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06972; Thu, 15 Feb 96 15:57:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15452; Thu, 15 Feb 1996 15:56:24 -0800 Received: from terra.com21.com by mercury.Sun.COM (Sun.COM) id PAA24991; Thu, 15 Feb 1996 15:56:20 -0800 Received: from [140.174.223.64] (matmos.com21.com [140.174.223.64]) by terra.com21.com (8.6.10/8.6.5) with SMTP id QAA19262; Thu, 15 Feb 1996 16:04:55 -0800 X-Sender: laubach@terra.com21.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Feb 1996 15:51:59 -0800 To: "Andrew G. Malis" , rolc@nexen.com, ip-atm@nexen.com, rsvp@isi.edu, int-serv@isi.edu, ipng@sunroof.eng.sun.com From: laubach@terra.com21.com (Mark Laubach) Subject: (IPng 1393) Re: Agendas for rolc, ipatm, ipatm/rsvp/intserv, and ipatm/rolc/ipng Cc: malis@nexen.com, laubach@terra.com21.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Also, PLEASE NOTE: As of now, the ip-atm list has moved to >ip-atm@nexen.com. To join or leave the list, use >ip-atm-request@nexen.com or majordomo@nexen.com, using the normal >majordomo subscribe and unsubscribe requests. Mail to the hp address >will be automatically forwarded to the new list. If you have a >problem with the list, send email to to postmaster@nexen.com. Andy, hp hasn't been informed of the roll over yet. It will happen in the next few days after I get a hold of them. mark ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 15 16:26:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07013; Thu, 15 Feb 96 16:26:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07007; Thu, 15 Feb 96 16:25:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20493; Thu, 15 Feb 1996 16:24:35 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id QAA01709; Thu, 15 Feb 1996 16:24:35 -0800 Received: from alpha.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA02875; Thu, 15 Feb 1996 19:18:56 -0500 Received: from brigit.zk3.dec.com by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM) id AA14960; Thu, 15 Feb 1996 19:18:55 -0500 Received: by brigit.zk3.dec.com; (5.65v3.2/1.1.8.2/24Apr95-0109PM) id AA03797; Thu, 15 Feb 1996 19:21:11 -0500 Date: Thu, 15 Feb 1996 19:21:11 -0500 From: alex conta Message-Id: <9602160021.AA03797@brigit.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1394) Link Local, or Global Address in Router advertisments? Cc: conta@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk During the recent UNH IPv6 bake-off I noticed some interesting side effects of the router discovery mechanism, which after some thinking I concluded is a mechanism problem that should/must be corrected. The current IPv6 Neighbor and Router Discovery draft specifies that a router advertisment message identifies the source of the message through the IPv6 source address which is supposed to be an IPv6 link local address. The link local address is to be used as a router id. Options in the message specify the router's interface link address, and prefixes advertized. The link address is stored in a Neighbor Discovery cache entry. A link address is not specified if some load balancing is done on multiple router interfaces on the same link. What is the problem with that? 1.1 Redundancy ----------------- Specifying the IPv6 link local address as source of the router advertisment message and the link layer address as option in the message provides redundant information. 1.2. Route Ident size - over-kill ----------------------------------- Using the IPv6 link local address as an internal or external router identifier - 16 bytes - is by far an over-kill. The link local address - 6 bytes - provides a unique on the link identifier, (we hope in fact universally unique) which is by far sufficient - and still an over-kill. Note that if the link local address would not be sufficient, as far as unicity, the link local IPv6 address would not be of any help anyways. 1.3. Router interface load balancing. -------------------------------------- The load balancing of routed messages on several interfaces on the same link, seems to me naturally tightly coupled with the routing mechanism, and thus with the routing advertising mechanism. As such, neighbor discovery is not naturally coupled at all with the router load balancing, but it is just used as the mechanism of conveying the address information to the hosts, address information that in non-load balancing cases is conveyed through the router advertisment. Therefore, it is apparent to me that it makes much more sense to have the router decide at the time of sending the advertisment which is the best link interface, and thus which is the best link layer address for balancing the load for the prefixes advertised, and pass the link address information directly in the router advertisment, as done in normal, non-load balancing cases. 1.4 Host lacks knowledge of default routers global addresses --------------------------------------------------------------- Currently after receiving a router advertisment, a host has no knowledge of any of the routers global addresses. As I concluded at the UNH bake-off, this is in my view unacceptable. To not have the router advertisment specify any of the router's global addresses - at least one of the addresses that has its prefix advertised - is detrimental. For at least two reasons: 1.4.1 Reachability of router ----------------------------- The first action that one may do when defining, or autoconfiguring an address is to test the reachability with the most important node on that interface's link, that has an identical prefix. That node is the default router, which advertised that prefix. A host receiving prefix information for a certain subnet - let's use this term for lack of a better one - builds an interface global address based on the prefix, but lacks a very important piece of information which is the router's address on that same subnet. Consequently a user or system manager cannot do the most natural thing which is to 'ping', and thus test reachability or connectivity with its router on the same subnet. 1.4.2 Use of the router global address lookup key for best route, as ---------------------------------------------------------------------- key for packet source address selection, or as key for local address --------------------------------------------------------------------- selection for a socket. --------------------------------------- Furthermore, the default router's global address is important because it can be used in organizing the default routers list as part of the routing table, and have the router's global address be used as a (or one of the) key(s) for the best route lookup mechanism, or for choosing the global address to be filled in the IPv6 source field of an outgoing packet, or in the local IPv6 address field of a protocol control block. 2. Conclusion - link local address ----------------------------------- Using the link local address as source of the router advertisments is a reminiscence of an over-stretched use of the link local address, present in a previous document version, which I very much - and other members of the WG - disagreed with. That over-stretched use of the local link address was eliminated after the Washington D.C., fall 1995, interim working group meeting, and was replaced with a clever mechanism - should we call it Gilligan's mechanism ? - the hop limit = 255. The use of the link local address in router discovery as specified today, is in my view of no real value, and could be removed. In fact not only that does not have a use, but it creates more problems than it resolves. The link local address was defined for use as the default address in the "dentist office" type of networks where there are no routers or configuration servers to provide global address or address prefix information, and it should in my view remain that way, and with that scope. 3. Suggestions --------------- 3.1. Mandate link addresses ---------------------------- The link address could/should be made a mandatory field in a neighbor or router discovery advertisment. On links that do not have link addresses, the link address length should be specified as a zero value. Link address based load balancing is controlled or employed by the advertising mechanism, and thus link addresses used for load balancing are specified with router advertisment messages. If a neighbor discovery cache entry is created for the router as consequence of a router advertisment, the entry should be marked Reachable for symmetric reachability type links, or Stale for asymmetric reachability type links. 3.2. Shorter Router Id. -------------------------- Use the router's link address as router ID, at least internally. As a usually 6 byte field, it is 10 bytes shorter, and as good as a 16 byte long IPv6 link local address based ID. 3.3. Hosts can infer a router's IPv6 link local address -------------------------------------------------------- A host can build an IPv6 link local address of a node that is on the same link with any of its own interfaces, if it knows the link address. Use the router link address to have the host build the router's IPv6 link local address, although that IPv6 address once the router is on the net, is of no practical use, and in my view should not be given in the discovery mechanism any specific (or special) role. 3.4. IPv6 source address of the Advertisment -------------------------------------------- Specify as IPv6 source address of the router advertisment message the global address corresponding to the prefix being advertised. If more than one prefix is advertised in one advertisment message, then the global address corresponds to one of the prefixes advertised. The router global address can be used as a primary or secondary, or simply additional key in best route table entry lookup to identify the best default router, or best source address selection mechanisms, or best local address selection at socket bind time. Thanks, and regards, Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 15 16:54:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07043; Thu, 15 Feb 96 16:54:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07037; Thu, 15 Feb 96 16:54:20 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24628; Thu, 15 Feb 1996 16:53:11 -0800 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id QAA07907; Thu, 15 Feb 1996 16:53:09 -0800 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Fri, 16 Feb 1996 09:38:03 +0900 From: Masataka Ohta Message-Id: <199602160038.JAA14052@necom830.cc.titech.ac.jp> Subject: (IPng 1395) Re: Agendas for rolc, ipatm, ipatm/rsvp/intserv, and ipatm/rolc/ipng To: malis@nexen.com (Andrew G. Malis) Date: Fri, 16 Feb 96 9:38:02 JST Cc: rolc@nexen.com, ip-atm@nexen.com, rsvp@isi.edu, int-serv@isi.edu, ipng@sunroof.eng.sun.com, malis@nexen.com, laubach@terra.com21.com In-Reply-To: <199602152229.RAA05740@phish.nexen.com>; from "Andrew G. Malis" at Feb 15, 96 5:29 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andy; Thank you. > - NHRP Multicast routing (Ohta) Could you rename it - Multicast Inscalability of NHRP (Ohta) Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 16 05:42:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07436; Fri, 16 Feb 96 05:42:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07430; Fri, 16 Feb 96 05:41:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19997; Fri, 16 Feb 1996 05:40:43 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id FAA14753; Fri, 16 Feb 1996 05:40:44 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA07992; Fri, 16 Feb 1996 08:38:53 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA07981; Fri, 16 Feb 1996 08:38:37 -0500 Message-Id: <9602161338.AA07981@fwasted.zk3.dec.com> To: ipv6imp@munnari.oz.au, ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 1396) Netexpo IPv6 Implementation Presentation Pointer Date: Fri, 16 Feb 96 08:38:37 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, On gatekeeper.dec.com via anon ftp you can get my talk from Networks EXPO in Boston this past week: netexpo.ps I did this with Scott Bradner as a panel. Scott gave the history of IPng and layout of current core specs. My slides had to be done way in advance. There were two corrections I did with Grease Pen: 1) UNH event was 1996 not 1995, 2) Added FTP Software and WIDE Members (from Japan) to our list of implementors. I did this as Industry person NOT as Digital person. Also UNH sent me a nice .ps of how our lab looked for the IPv6 interoperability event which I also presented. You can get that .ps too. v6_test_network.ps p.s. Bob H. can we add these to our IPng WWW Home Page as pointer. thx /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 16 05:55:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07449; Fri, 16 Feb 96 05:55:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07443; Fri, 16 Feb 96 05:55:48 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20988; Fri, 16 Feb 1996 05:54:37 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id FAA17077; Fri, 16 Feb 1996 05:54:37 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA04358; Fri, 16 Feb 1996 08:49:14 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23278; Fri, 16 Feb 1996 08:49:07 -0500 Message-Id: <9602161349.AA23278@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 1397) Dynamic Reassignment of IPv6 Addrs for TCP/UDP Date: Fri, 16 Feb 96 08:49:07 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, A draft was submitted yesterday from Pedro Roque and I that will be an agenda item for IPng at L.A. The purpose is to begin some data gathering and review of our proposal to dynamically reassign an IP address being used by a TCP/UDP communications path without altering TCP/UPD RFCs, using a Destination option. We spent a lot of time on this initial spec and look forward to discussion, review, and added input for this work. It also states how it can be used for anycast addresses for a host and some of the problems we encountered for anycast addresses and how we approach solving them. We also have applicability sections on Dynamic Renumbering, Mobile, and Multihoming; as we feel this work can be used by those efforts too. You can get it from gatekeeper.dec.com anon ftp: draft-ietf-ipv6-dyn-ip-addrs-00.txt thanks /jim and pedro ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 16 07:21:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07504; Fri, 16 Feb 96 07:21:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07498; Fri, 16 Feb 96 07:21:33 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29201; Fri, 16 Feb 1996 07:20:23 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id HAA03421; Fri, 16 Feb 1996 07:20:22 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA30937; Fri, 16 Feb 1996 10:08:23 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16495; Fri, 16 Feb 1996 10:08:16 -0500 Message-Id: <9602161508.AA16495@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Subject: (IPng 1398) IPv6 Pointers to the Area (Sorry) Date: Fri, 16 Feb 96 10:08:15 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry... gatekeeper.dec.com /pub/DEC/IPv6 netexpo.ps v6_test_network.ps For IPng Pedro and my draft on dyn reassign of IP addrs draft-ietf-ipv6-dyn-addrs-00.txt too many hours at work..... /jim ------- Forwarded Message Return-Path: daemon Received: from mail11.digital.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14717; Fri, 16 Feb 1996 10:03:52 -0500 Received: from gatekeeper.open.ch by mail11.digital.com (5.65v3.2/1.0/WV) id AA09389; Fri, 16 Feb 1996 09:53:28 -0500 Received: by gatekeeper.open.ch; id PAA11905; Fri, 16 Feb 1996 15:36:14 +0100 Received: from tap.open.ch(193.72.201.41) by gatekeeper.open.ch via smap (V3.1) id xma011898; Fri, 16 Feb 96 15:35:46 +0100 Received: from fanatic.open.ch (fanatic.open.ch [192.168.100.10]) by tap.open.ch (8.6.12+phmap-1.2/8.6.9) with ESMTP id PAA03759 for ; Fri, 16 Feb 1996 15:44:09 +0100 Received: from trillian.open.ch (trillian [192.168.100.11]) by fanatic.open.ch (8.6.12/8.6.12) with ESMTP id PAA00667 for ; Fri, 16 Feb 1996 15:42:39 +0100 Received: (dan@localhost) by trillian.open.ch (8.6.12/8.6.12) id PAA01104 for bound@zk3.dec.com; Fri, 16 Feb 1996 15:44:55 +0100 Message-Id: <199602161444.PAA01104@trillian.open.ch> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Received: by NeXT.Mailer (1.118.3) From: "Daniel S. Decasper" Date: Fri, 16 Feb 96 15:44:50 +0100 To: bound@zk3.dec.com Subject: Re: (IPng 1396) Netexpo IPv6 Implementation Presentation Pointer Reply-To: dan@pointbreak.com (Daniel S. Decasper) References: <9602161338.AA07981@fwasted.zk3.dec.com> Jim, could you please give me a pointer to the directory. I'm very interested in the paper. Thanks - -Dan > > >On gatekeeper.dec.com via anon ftp you can get my talk from Networks >EXPO in Boston this past week: > > netexpo.ps > ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 16 07:48:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07523; Fri, 16 Feb 96 07:48:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07517; Fri, 16 Feb 96 07:48:25 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02458; Fri, 16 Feb 1996 07:47:15 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id HAA09307; Fri, 16 Feb 1996 07:47:15 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3466; Fri, 16 Feb 96 10:46:56 EST Received: by RTP (XAGENTA 4.0) id 9247; Fri, 16 Feb 1996 10:46:31 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA22019; Fri, 16 Feb 1996 10:46:48 -0500 Message-Id: <9602161546.AA22019@cichlid.raleigh.ibm.com> To: Matt Thomas Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1399) Re: Neighbor advertisements and the override bit (again). In-Reply-To: Your message of "Wed, 14 Feb 1996 17:15:21 GMT." <199602141715.RAA17341@whydos.lkg.dec.com> Date: Fri, 16 Feb 1996 10:46:47 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, >While the "(if present)" helps, the section is still ambiguous. I'd like >for Section 7.2.4 to replace the > If the Target Link-Layer Address option is not included in the > advertisement, the Override flag MUST be set to zero. I changed the text to say SHOULD be set to zero for this case. It now reads: If the Target Address is either an anycast address or a unicast address for which the node is providing proxy service, or the Target Link-Layer Address option is not included in the outgoing advertisement, the Override flag SHOULD be set to zero. Otherwise, it SHOULD be set to one. Proper setting of the Override flag insures that nodes give preference to non-proxy advertisements, even when received after proxy advertisements, but that the first advertisement for an anycast address "wins". > What meaning does the Override flag have if the Target Link-Layer > option is not present? None whatsoever. But I also don't see why an implementation processing a received advertisement would even look at this flag unless it was processing the Target Link-Layer Address option. So I don't see a strong argument for saying the bit MUST NOT be set if the option isn't there. Thanks for catching this one! Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 16 08:06:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07543; Fri, 16 Feb 96 08:06:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07537; Fri, 16 Feb 96 08:06:13 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04817; Fri, 16 Feb 1996 08:05:04 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id IAA13864; Fri, 16 Feb 1996 08:05:00 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA07682; Fri, 16 Feb 1996 10:57:27 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA02261; Fri, 16 Feb 1996 10:57:20 -0500 Message-Id: <9602161557.AA02261@fwasted.zk3.dec.com> To: alex conta Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 1400) Re: Link Local, or Global Address in Router advertisments? In-Reply-To: Your message of "Thu, 15 Feb 96 19:21:11 EST." <9602160021.AA03797@brigit.zk3.dec.com> Date: Fri, 16 Feb 96 10:57:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, I see your points but this is revisiting some very basic decisions whether I agree or not, and effects what is going to Proposed Standard. I think we have had these discussions and input from many and I even believe the wrong approach was taken, but consensus has lead us down this path. I will also note that at the UNH bake-off many of us did not experience any negative side affects from the way the spec is written presently, for this particular topic. The core reason for the routers link local address to be used is so if renumbering must take place the router is not dependent on the host listening to global addresses or using them. It was for many more reasons than the Dentist Office scenario. I am concerned about the load balancing and would like to see some router implementations test this and tell us if in fact it works. The core reason I got out of our Cambridge IPv6 meeting is routers want to use multiple interfaces that are not defined to the host via link-layer addresses. >Furthermore, the default router's global address is important because >it can be used in organizing the default routers list as part of the routing >table, and have the router's global address be used as a (or one of the) key(s) >for the best route lookup mechanism, or for choosing the global address to be >filled in the IPv6 source field of an outgoing packet, or in the local IPv6 >address field of a protocol control block. But it can also work fine with the link local address. As far as a key for the best lookup in Wash D.C. that was killed as something a host should do, and why Francis Dupont and I proposed preferences. This is when Steve Deering convinced all of us the redirect would accomplish the same thing. >2. Conclusion - link local address >----------------------------------- > >Using the link local address as source of the router advertisments is a >reminiscence of an over-stretched use of the link local address, present in >a previous document version, which I very much - and other members of the WG - >disagreed with. That over-stretched use of the local link address was >eliminated after the Washington D.C., fall 1995, interim working group >meeting, and was replaced with a clever mechanism - should we call it >Gilligan's mechanism ? - the hop limit = 255. Bob's idea was to make sure that ND packets were not forwarded off link or to an onlink destination, not for the case you state. The link-local address is valuable and not overstretched in ND at all. What was accepted at Wash D.C. is that hosts could use global addresses for ND solicits/advertisements and a good idea (that you actually proposed). >The use of the link local address in router discovery as specified today, is >in my view of no real value, and could be removed. In fact not only that >does not have a use, but it creates more problems than it resolves. Its good for renumbering as stated in the ND spec today. Renumbering is essential to the architecture for all IPv6 specs. We have to live with it or none of our specs will reach standard status via the IESG. >The link local address was defined for use as the default address in the >"dentist office" type of networks where there are no routers or configuration >servers to provide global address or address prefix information, and it should >in my view remain that way, and with that scope. In addition to renumbering it was defined so any node will have an IP address at boot time and this has proved very valuable to ND, Addr Conf, and DHCPv6. >3. Suggestions >--------------- > >3.1. Mandate link addresses >---------------------------- > >The link address could/should be made a mandatory field in a neighbor or router >discovery advertisment. On links that do not have link addresses, the link >address length should be specified as a zero value. This needs much discussion. The mechanism now does permit load balancing in "theory". NOTE- We did not test this at UNH. >Link address based load balancing is controlled or employed by the >advertising mechanism, and thus link addresses used for load balancing are >specified with router advertisment messages. This needs much discussion. The issue is that router vendors want the ability to not send out the link-layer address with an advertisement. >If a neighbor discovery cache entry is created for the router as consequence >of a router advertisment, the entry should be marked Reachable for symmetric >reachability type links, or Stale for asymmetric reachability type links. This can be done in the default router list? If the link-layer address were present? >3.2. Shorter Router Id. >-------------------------- > >Use the router's link address as router ID, at least internally. > >As a usually 6 byte field, it is 10 bytes shorter, and as good as a 16 byte >long IPv6 link local address based ID. We do not have consensus 6 bytes are enough. I am hearing some want 8? >3.3. Hosts can infer a router's IPv6 link local address >-------------------------------------------------------- > >A host can build an IPv6 link local address of a node that is on the same >link with any of its own interfaces, if it knows the link address. > >Use the router link address to have the host build the router's IPv6 link local >address, although that IPv6 address once the router is on the net, is of no >practical use, and in my view should not be given in the discovery >mechanism any specific (or special) role. I don't think Hosts should be building others link-local addresses for two reasons: 1) Its a bad principle for robustness, because we have not decided yet that nodes will not create interface IDs for the bits between the token and high order prefix length. This is for intra-node unqiueness for the link-local address. A foreign neighbor cannot possibly know that uniqueness for another node. In addition for added value in implementations assuming all bits in the link-local addresses for others is not a good idea IMHO. 2) We permit in ND for a router to advertise a prefix with the LINK flag not set. This means the admin is stating the topology is that hosts must go to the router to communicate with another neighbor first. The IPv6 ND host does not really know or can be guranteed that the prefix is onlink in this case (this is how we permit a psuedo ES-IS model in IPv6). My fear is if we relax our architecture to build link-local addresses for another node, hosts will also try to build a global address too. Not good. >3.4. IPv6 source address of the Advertisment >-------------------------------------------- > >Specify as IPv6 source address of the router advertisment message the global >address corresponding to the prefix being advertised. If more than one >prefix is advertised in one advertisment message, then the global address >corresponds to one of the prefixes advertised. Well before we discuss this we need to discuss the effect of your suggestions early on in the list. How it would work is another discussion, but this is one idea, another would be to simply add another field or use the source address in the header. >The router global address can be used as a primary or secondary, or simply >additional key in best route table entry lookup to identify the best default >router, or best source address selection mechanisms, or best local address >selection at socket bind time. But presently for a neighbor or not-a-neighbor that can be determined by the onlink prefixes in the neighbor or destination cache. If its offlink the default router entry can be cloned (in BSD 4.4) to build the route and per host or network routes in this case are not needed as one implementation scenario. But I still like preferences for implementation reasons but I can't seem to win that battle. This is really testing out the specs for sure and a really good discussion. If in fact we do thru consensus determine we want the routers link-layer address another approach is to permit as an option NS for the routers link-layer but that still breaks the goal of the router IPv6 ND architecture. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 16 08:21:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07559; Fri, 16 Feb 96 08:21:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07553; Fri, 16 Feb 96 08:21:10 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06697; Fri, 16 Feb 1996 08:19:59 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id IAA17424; Fri, 16 Feb 1996 08:19:54 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA10855; Fri, 16 Feb 1996 11:11:02 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24010; Fri, 16 Feb 1996 11:10:53 -0500 Message-Id: <9602161610.AA24010@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 1401) Hosts processing IPv6 Source Routes Date: Fri, 16 Feb 96 11:10:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, At the UNH bake-off Steve Deering and Jack McCann while working on PMTU spec told me that its assumed a host forwards packets to the next hop in a source route. Rather than wait for them to bring it up. I thought I would post the issue and see what it generates as a discussion. I have no problem with this behavior 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 Fri Feb 16 08:44:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07575; Fri, 16 Feb 96 08:44:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07569; Fri, 16 Feb 96 08:44:32 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10520; Fri, 16 Feb 1996 08:43:22 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id IAA01479; Fri, 16 Feb 1996 08:43:21 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA12243; Fri, 16 Feb 1996 08:40:44 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 08:43:02 -0800 To: alex conta From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1402) Re: N&RD draft V4 - comments Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, >2. Size of the document >----------------------- > >I bring to your attention a personal opinion, that became stronger >most recently before the UNH bake-off during updating my neighbor >discovery implementation to the latest version of the specs. > >The document is long. It has almost 90 pages. It is excellent through I have head this from some other folks and agree that the current document is on the large size. I do not think we should do anything now (e.g., let the current draft proceed to proposed standard, the IESG is looking at it now, etc.) to restructure it. I think the time to look at splitting into two (or maybe three pieces) is when it goes to Draft standard. I would suspect that based on implementation experience in the next six months there will be a number of clarifications needed. We could look at splitting the document at that time. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 16 10:47:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07793; Fri, 16 Feb 96 10:47:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07787; Fri, 16 Feb 96 10:47:16 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03857; Fri, 16 Feb 1996 10:45:57 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id KAA14812; Fri, 16 Feb 1996 10:45:43 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8265; Fri, 16 Feb 96 13:45:24 EST Received: by RTP (XAGENTA 4.0) id 9384; Fri, 16 Feb 1996 13:44:07 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17987; Fri, 16 Feb 1996 13:44:20 -0500 Message-Id: <9602161844.AA17987@cichlid.raleigh.ibm.com> To: alex conta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1403) Re: Link Local, or Global Address in Router advertisments? In-Reply-To: Your message of "Thu, 15 Feb 1996 19:21:11 EST." <9602160021.AA03797@brigit.zk3.dec.com> Date: Fri, 16 Feb 1996 13:44:20 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, Whoa! I didn't quite expect to see these kinds of comments so late in the process. Hopefully I can convince you that these changes aren't necessary. :-) >1.1 Redundancy >----------------- > Specifying the IPv6 link local address as source of the router > advertisment message and the link layer address as option in the > message provides redundant information. I'm not sure I follow. The link-local address appears only once in an RA message. It is the Source Address of the IP packet, but doesn't appear in the ND part of the packet at all. So it is not redundant information. It is true that the Link-Layer option includes the actual link-layer address, which one could presumably also get from looking at the link-layer packet headers. Are you suggesting we do that? Is this what you mean by redundant information? Or are you observing that in many cases, the link-local address could be derived/constructed from a link-layer address (i.e., assuming addresses are always generated using stateless addrconf)? While this may be true in 99.xxx% of the cases, there will be exceptions. DHCP will surely create many of them. >1.2. Route Ident size - over-kill >----------------------------------- > Using the IPv6 link local address as an internal or external router > identifier - 16 bytes - is by far an over-kill. > The link local address - 6 bytes - provides a unique on the link > identifier, (we hope in fact universally unique) which is by far > sufficient - and still an over-kill. Note that if the link local > address would not be sufficient, as far as unicity, the link local > IPv6 address would not be of any help anyways. I wouldn't think the number of bytes used for storage is a big issue here. Rather, I would think most implementations would prefer have the same type of identifier (i.e., format) used to identify both host and router interfaces. If you only used 6 bytes for routers, but 16 for hosts, an implementation would need need to treat the two cases differently. Sounds like more work for an implementor. Note that an implementation *can* choose to use a shorter identifier internally if it wanted. There is nothing in the spec that prevents that. >1.3. Router interface load balancing. >-------------------------------------- > The load balancing of routed messages on several interfaces on the > same link, seems to me naturally tightly coupled with the routing > mechanism, and thus with the routing advertising mechanism. There are many kinds of load balancing. The type ND supports is where a single IP logical interface actually consists of two or more physical interfaces underneath, but with that level of detail generally hidden from IP (and IP routing). Nodes on the same link as the (replicated) interface in question aren't aware that there is more than one path to the logical interface and will send out NS messages to get its link-layer address. The load-balancing capability in ND simply allows a node with a replicated interface to better control which link-layer address(es) get placed in neighboring node's caches. Specifically, a node could arrange to have 1/2 of its neighbors use one (link-layer) address, the other nodes use another. Note that in IPv4, ARP doesn't provide such a mechanism, and in practice all nodes end up using the same link-layer address. ND is NOT trying to solve the general load-balancing problem. >Therefore, it is apparent to me that it makes much more sense to have the >router decide at the time of sending the advertisment which is the best link >interface, ND provides a mechanism that allows a router to set things up so that the *router* decides which link-layer address (replicated interface) each of its neighboring nodes will use to reach it. In theory, a router could arrange things so that the incoming packets are distributed roughly 50-50 over the replicated interfaces, even if 10% of the hosts generate 90% of the traffic. There is no easy way for a single RA multicast to all nodes to be able to communicate equivalent information. Note also that this is an *option*, and no one is required to take advantage of it. and thus which is the best link layer address for balancing the >load for the prefixes advertised, and pass the link address information >directly in the router advertisment, as done in normal, non-load balancing >cases. I'm confused by your mention of prefixes above. Advertised prefixes indicate on-link destinations, and packet sent to addresses covered by those prefixes don't get sent to the router. Getting further into your note, is it maybe the case that you want a host to be able to send traffic with one Source Address to one of the replicated interfaces, while traffic using one of the other Source Addresses goes to one of the router's other replicated interfaces? ND doesn't currently allow that. Are you saying that this is a type of load balancing ND should support? >1.4 Host lacks knowledge of default routers global addresses >--------------------------------------------------------------- > Currently after receiving a router advertisment, a host has no > knowledge of any of the routers global addresses. >As I concluded at the UNH bake-off, this is in my view unacceptable. I'd be interested in comments from others on this point. Is this really a problem? >1.4.1 Reachability of router >----------------------------- > The first action that one may do when defining, or autoconfiguring > an address is to test the reachability with the most important node > on that interface's link, that has an identical prefix. That node is > the default router, which advertised that prefix. I don't see why when pinging a neighboring router, using an address of one particular prefix as opposed to another is inherently superior. Please elaborate. Keep in mind also that a router may have *several* global addresses (it may connect to the Internet via multiple ISPs, and have a prefix for each ISP). Which of these global address is "inherently superior"? >1.4.2 Use of the router global address lookup key for best route, as >---------------------------------------------------------------------- >key for packet source address selection, or as key for local address >--------------------------------------------------------------------- >selection for a socket. >--------------------------------------- >Furthermore, the default router's global address is important because >it can be used in organizing the default routers list as part of the routing >table,and have the router's global address be used as a (or one of the) key(s) >for the best route lookup mechanism, I don't understand this point at all. When routers appear in routing tables, they are the *target* of the search (i.e., find a router to use to reach a particular destination). They are not the *key*. Isn't the natural routing table organization determined by the *keys* that are used for lookups? >or for choosing the global address to be >filled in the IPv6 source field of an outgoing packet, ND made it a point *not* to get into the issue of how to select the best Source Address on outgoing packets. It sounds like you are proposing something counter to that. >2. Conclusion - link local address >----------------------------------- >Using the link local address as source of the router advertisments is a >reminiscence of an over-stretched use of the link local address, present in >a previous document version, which I very much - and other members of the WG - >disagreed with. That over-stretched use of the local link address was >eliminated after the Washington D.C., fall 1995, interim working group >meeting, and was replaced with a clever mechanism - should we call it >Gilligan's mechanism ? - the hop limit = 255. Just to clarify one point. We originally used the name "designated address" for the unique identifier for a router's interface. The designated address was motivated by the problem of an interface having multiple addresses. If a router has ten addresses, a host could easily conclude that there were ten routers on a link, when in fact there might only have been one. This has some undesirable consequences. Having a router known by a single identifier avoids these problems. Second, IPv4 (and IPv6) have the notion that you only accept redirects if they come from the router currently being used to reach a particular destination. If the router you are using sends back a redirect, but it uses the "wrong" address (which of its ten addresses would it use?), a host will ignore the redirect. This would be a major problem in practice assuming multiple addresses per interface becomes common. My point is that the need for a designated address has nothing to do with link-local addresses. However, we decided that since every interface has a link-local address, and it (presumably) won't change over time (including across renumberings), and a node probably won't have but one link-local address, ND now uses "link-local address" rather than "designated address". I still sometimes think we should have stuck with the original terminology to avoid confusion. >The use of the link local address in router discovery as specified today, is >in my view of no real value, and could be removed. In fact not only that >does not have a use, but it creates more problems than it resolves. I disagree totally. >3. Suggestions >--------------- >3.1. Mandate link addresses >---------------------------- > The link address could/should be made a mandatory field in a > neighbor or router discovery advertisment. On links that do not have > link addresses, the link address length should be specified as a > zero value. I assume you mean "link-layer address" as opposed to "link-local address" above. How is your proposal significantly different than the Link-Layer Option ND currently has? > If a neighbor discovery cache entry is created for the router as > consequence of a router advertisment, the entry should be marked > Reachable for symmetric reachability type links, or Stale for > asymmetric reachability type links. This is something that I don't believe we've discussed (much) before. The idea would be to tag some link types as "SYMMETRIC", meaning you always assume that if you get packets from a node, you can also send packets back. I'm not sure this would really change ND in any fundamental ways, but it might be worth looking into. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 16 12:19:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07914; Fri, 16 Feb 96 12:19:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07908; Fri, 16 Feb 96 12:19:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20928; Fri, 16 Feb 1996 12:18:14 -0800 Received: from stb.info.com by mercury.Sun.COM (Sun.COM) id MAA12279; Fri, 16 Feb 1996 12:18:06 -0800 Received: by stb.info.com (Smail3.1.28.1 #4) id m0tnWbO-000ZB1C; Fri, 16 Feb 96 12:17 PST Message-Id: Date: Fri, 16 Feb 96 12:17 PST From: Michael Gersten Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: ipng@sunroof.eng.sun.com Subject: (IPng 1404) Thoughts on DNS and API Reply-To: michael@stb.info.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm relatively new to this, so forgive me if these were mentioned and rejected 5 months ago. I have two areas of proposals that I'd like to hear from the others on this list. One is in the DNS, and adding a field to support forced source routes. The idea is that you specify in the DNS both your address, and a new field for your gateway/ISP. The name -> address lookup routine would return a source route, which would then be passed to bind, and then used by the TCP/UDP routines. The original idea for this was to deal with a dialup line having other nodes/a LAN, or just being able to be a server machine, even though the ISP provides a dynamic address, and some backbones won't accept routing info provided. This was done in the name of keeping the backbone routing tables reasonably sized. It can still be used for this, but under v6, a provider based address will have a fixed subscriber number, rather than a dynamic address (although the link address may be dynamic), and there's a lot of spare bits in there; you effectivly do have a "stable" address (not permenent; if you change providers, you change addresses and update DNS. Small price). Bottom line is that I can't think of any case where this would be needed in V6; I thought I'd ask and see if anyone else can think of something that can be done with this that couldn't otherwise be done. About the only thing that I can think of it buying is using non-CIDR routing addresses without taking up lots of space in the backbone. The second, and more serious concern, is the API specs. Am I the only one that thinks that duplicating the V4 socket interface for V6 is a really bad idea? Specifically, that the current socket interface is too low-level, and violates every modern concept of device independence and data abstraction? First, the serious problems that I saw while reading the API: 1. Source route address information is not enabled by default. Yet if a packet arrives by source routing, the v6 specs say that you reply by source routing. So this needs to be enabled by default, and some way provided to say how much memory will be needed to retrieve the entire address. 2. Why is there an assumption that a multicast address will only be going out a single link? Why not specify that the kernel will send it out every link that it is valid for? (Think of a central hub machine that bridges several LAN's, and talks out to the ISP as well.) 3. The address to ascii functions specify that the address must be a 16 byte address. Yet if you got this address from an incoming packet, you may have been given a source route, which is longer than 16 bytes. This is "abstract data types" again. 4. The address to ascii functions require you to provide the memory as input; everything else in the proposed api allocates memory as needed and provides a free routine. Additionally, the address to ascii functions make what I consider to be a very bad assumption, namely, saying that X bytes will suffice for an address. What if you're displaying a source route address, and you want a printable form for that? I'd like to see the whole concept of an address treated as an ADT. You get an address -- whatever it is (you see it as a void *) -- either from the kernel when you receive a packet, or from the library routines when you give a name or ascii address string. You can give an address to library routines, and get back an ascii string. Now, the kernel does have a lot of routines that specify an address, and a length; and the API does point out that this works just fine for v6 addresses. Point is, instead of v4: bind (s, &my_saddr, sizeof(my_saddr)) or (proposed v6) bind (s, &my_saddr6, sizeof(my_saddr6)) how about bind(s, as_addr(addr), addr_len(addr)) (works for both of these, and others as well) where as_addr(), and addr_len(), are library routines that know how to do all the conversions between what the library deals with, and what the kernel deals with. How do you get these "addr" cookies? Well, right now, you need to get a string from the user, know ahead of time whether it's a AF_INET, AF_INETV6, AF_NETWARE, or whatever. What if a single library routine could take either "host.name:port", or "128.32.73.128:smpt", or "some.name.thats.v6.net" (note no port -- only specifies part of an address), or "\\machinename\directory\file", and automatically determine that one is a v4 name, one is a v6 name, and the other is a netware name, and hide all that detail from you? What if that same library routine could take "/tmp/file", and deal with files, or "unix:/tmp/X11/whatever", and return a unix domain address? Or even (expanding on that last one just a bit) "http://www.host.com/file.html" or "ftp://etc"? Most of the time, all you are doing with an address string is opening a TCP connection to some port on some machine. A single library routine that does this -- a single "open()" call equivalent, will satisfy 90% (or more) of all network needs, and gain the benefit of working with non-TCP/INET connections, without needing any changes to user code. Other than that, you might be replying to a datagram packet received (such as UDP). In this case, you'll get the address, and address length from the kernel; you give that to the library, and it hands back an addr object. It can then generate a reply address, or whatever else would be done with it. Note that most of the kernel interface (probably all of it) is fine as-is; it just needs to be marked as "Low level support only -- use library routines XXX for general use". (Other than the fact that a single socket is fixed to a single protocol family, and a single address family, as well as a specific protocol, there's no real change needed -- but wouldn't it be nice if a socket could be specified as just a SOCK_DGRAM, so the same socket could receive datagrams of multiple types? Maybe this library should include routines to cover up the low level socket system calls as well. Maybe I'm well beyond the scope of this group by now :-) (One aspect of inet sockets that I think needs to be changed, that does not exist for file based ipc (unix sockets, named pipes, etc) is the lack of renaming ability. You can start a file based server, do a 'mv' on the file, and then start a new process to filter what the server sees/does. In the worst case you can chroot() it. Even root cannot insert a filter on a socket. There's no call to remap a port number or create a "sub-addressing family".) How realistic was that name example? If you have a library that runs all those name queries through a privileged (root) process, and that in turn allows other root processes to register and say "I can decipher some names", then it really can be extended to deal with all of those examples. Michael -- Michael Gersten michael@stb.info.com http://www.stb.info.com/~michael NeXT Registered Developer (NeRD) # 3860 -- Hire me! (Great at design/coding) Without Prejudice, UCC 1-207 (I can't stand fixing other's bugs) Want $$$? Check http://www.stb.info.com/~michael/TrulySpecial.html. Serious. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 17 07:02:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08308; Sat, 17 Feb 96 07:02:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08302; Sat, 17 Feb 96 07:01:52 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10750; Sat, 17 Feb 1996 07:00:41 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id HAA12798; Sat, 17 Feb 1996 07:00:41 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA10544; Sat, 17 Feb 1996 09:58:21 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA30605; Sat, 17 Feb 1996 09:58:14 -0500 Message-Id: <9602171458.AA30605@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1405) DHCPv6 New Drafts available see attached Date: Sat, 17 Feb 96 09:58:13 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------- Forwarded Message Return-Path: daemon Received: from mail11.digital.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19545; Fri, 16 Feb 1996 23:09:12 -0500 Received: from igw2.watson.ibm.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA29208; Fri, 16 Feb 1996 23:04:36 -0500 Received: from np2.watson.ibm.com ([9.2.46.53]) by igw2.watson.ibm.com (8.7.1/8.7.1) with SMTP id XAA10230; Fri, 16 Feb 1996 23:01:58 -0500 Received: by np2.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA22670; Fri, 16 Feb 1996 23:01:31 -0500 From: Charlie Perkins Message-Id: <9602170401.AA22670@np2.watson.ibm.com> To: dhcp-v6@bucknell.edu Cc: bound@zk3.dec.com Subject: DHCPv6 base specification Date: Fri, 16 Feb 96 23:01:31 -0500 We have submitted draft-ietf-dhc-dhcpv6-04.txt to the Internet-drafts directories. It is also available under the same name on software.watson.ibm.com, in directory pub/mobile-ip. Regards, Charles Perkins ------- End of Forwarded Message Return-Path: daemon Received: from mail11.digital.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA20728; Fri, 16 Feb 1996 23:43:58 -0500 Received: from igw2.watson.ibm.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA21079; Fri, 16 Feb 1996 23:37:09 -0500 Received: from np2.watson.ibm.com ([9.2.46.53]) by igw2.watson.ibm.com (8.7.1/8.7.1) with SMTP id XAA09994; Fri, 16 Feb 1996 23:34:40 -0500 Received: by np2.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA23733; Fri, 16 Feb 1996 23:34:26 -0500 From: Charlie Perkins Message-Id: <9602170434.AA23733@np2.watson.ibm.com> To: dhcp-v6@bucknell.edu Cc: bound@zk3.dec.com, droms@bucknell.edu Subject: draft-ietf-dhc-v6exts-01.txt Date: Fri, 16 Feb 96 23:34:21 -0500 I have submitted the Extensions for DHCPv6 draft to the Internet-drafts directories. I've also put it available for anonymous FTP from the pub/mobileip directory on software.watson.ibm.com. Regards, Charles Perkins ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 18 11:09:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08697; Sun, 18 Feb 96 11:09:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08685; Sun, 18 Feb 96 11:09:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26526; Sun, 18 Feb 1996 11:07:56 -0800 Received: from mitsou.inria.fr by mercury.Sun.COM (Sun.COM) id LAA12808; Sun, 18 Feb 1996 11:07:57 -0800 Received: from [138.96.36.34] by mitsou.inria.fr (8.6.12/8.6.12) with SMTP id UAA10059; Sun, 18 Feb 1996 20:07:43 +0100 Date: Sun, 18 Feb 1996 20:07:43 +0100 X-Authentication-Warning: mitsou.inria.fr: Host huitema.inria.fr claimed to be [138.96.36.34] Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Thomas Narten" From: huitema@pax.inria.fr (Christian Huitema) Subject: (IPng 1406) Re: Link Local, or Global Address in Router advertisments? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:44 PM 16/2/96, Thomas Narten wrote: >Note that an implementation *can* choose to use a shorter identifier >internally if it wanted. There is nothing in the spec that prevents >that. It can also do some form of address compression, since the first 10 octets of Link Local addresses are very predictable.. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 18 11:09:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08698; Sun, 18 Feb 96 11:09:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08689; Sun, 18 Feb 96 11:09:13 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26529; Sun, 18 Feb 1996 11:07:58 -0800 Received: from mitsou.inria.fr by mercury.Sun.COM (Sun.COM) id LAA12817; Sun, 18 Feb 1996 11:07:59 -0800 Received: from [138.96.36.34] by mitsou.inria.fr (8.6.12/8.6.12) with SMTP id UAA10061; Sun, 18 Feb 1996 20:07:50 +0100 Date: Sun, 18 Feb 1996 20:07:50 +0100 X-Authentication-Warning: mitsou.inria.fr: Host huitema.inria.fr claimed to be [138.96.36.34] Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: michael@stb.info.com From: huitema@pax.inria.fr (Christian Huitema) Subject: (IPng 1407) Re: Thoughts on DNS and API Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:17 PM 16/2/96, Michael Gersten wrote: >One is in the DNS, and adding a field to support forced source routes. The >idea >is that you specify in the DNS both your address, and a new field for your >gateway/ISP. The name -> address lookup routine would return a source >route, which would then be passed to bind, and then used by the TCP/UDP >routines. You may as well use the mobile-IP approach. The "permanent address" through which you "source route" is really your "home address". Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 19 06:33:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09351; Mon, 19 Feb 96 06:33:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09345; Mon, 19 Feb 96 06:33:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08548; Mon, 19 Feb 1996 06:31:54 -0800 Received: from IMgate.iMach.com by mercury.Sun.COM (Sun.COM) id GAA05397; Mon, 19 Feb 1996 06:31:51 -0800 Received: (from forrestc@localhost) by IMgate.iMach.com (8.6.12/8.6.11) id HAA05216; Mon, 19 Feb 1996 07:31:45 -0700 Date: Mon, 19 Feb 1996 07:31:38 -0700 (MST) From: "Forrest W. Christian" To: ipng@sunroof.eng.sun.com Subject: (IPng 1408) Routing and IPv6 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk With all of the Routing/CIDR Discussions taking place, I decided it was time to look at the IPv6 specs and figure out what, if anything IPv6 was going to do about the inherrent problems with CIDR, such as mandatory renumbering, etc. >From what I can tell, it's not going to change anything, except provide a new number space for us to pollute, and eventually end up with the same problems. Am I missing a draft or something? On a related note, Is there a reason that the address space hasn't been arbitrarily split into DISTINCT fields, to be allocated separately? Let me explain in a little more detail: Assume that you take, say 16 bits off of the top of the address field. Call this the PROVIDER field. The rest, lets call the CUSTOMER field. Set up quite similar to the registry/provider fields in the existing drafts. Allocate PROVIDER addresses to any multihomed organization. I.E. Those who must have an ASN today. These should be unique per provider. Allocate CUSTOMER addresses to any internet customer. No two customers around the globe should have the same set of customer addresses. IGNORE the provider field altogether. Now, If host #1 wants to send a packet to host #2, it would do a lookup through some sort of DNS or DNS-Like mechanism on the CUSTOMER address assigned to host #2, to get the PROVIDER for host #2. It composes a complete destination address and sends it on it's way. (Obviously, the providers for specific addresses would be cashed in some way). Now, in a specific PROVIDER's routers, it only needs: 1) Routes to all of the other PROVIDER's 2) Routes to the CUSTOMER addresses attached to it. Was something like this considered? -forrestc@imach.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 19 06:42:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09363; Mon, 19 Feb 96 06:42:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09357; Mon, 19 Feb 96 06:41:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09516; Mon, 19 Feb 1996 06:40:37 -0800 Received: from IETF.cnri.reston.VA.US by mercury.Sun.COM (Sun.COM) id GAA07040; Mon, 19 Feb 1996 06:40:36 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14712; 19 Feb 96 9:26 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1409) I-D ACTION:draft-ietf-ipngwg-pppext-ipv6cp-01.txt Date: Mon, 19 Feb 96 09:26:37 -0500 Message-Id: <9602190926.aa14712@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-pppext-ipv6cp-01.txt Pages : 11 Date : 02/15/1996 The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-pppext-ipv6cp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-pppext-ipv6cp-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-pppext-ipv6cp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960215162409.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-pppext-ipv6cp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-pppext-ipv6cp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960215162409.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 19 11:56:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09488; Mon, 19 Feb 96 11:56:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09482; Mon, 19 Feb 96 11:56:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01155; Mon, 19 Feb 1996 11:54:57 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id LAA01106; Mon, 19 Feb 1996 11:54:55 -0800 From: conta@zk3.dec.com Received: from alpha.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA14545; Mon, 19 Feb 1996 14:42:23 -0500 Received: from brigit.zk3.dec.com by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM) id AA14161; Mon, 19 Feb 1996 14:42:16 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65v3.2/1.1.8.2/24Apr95-0109PM) id AA05932; Mon, 19 Feb 1996 14:44:35 -0500 Message-Id: <9602191944.AA05932@brigit.zk3.dec.com> To: narten@VNET.IBM.COM Cc: ipng@sunroof.eng.sun.com, conta@zk3.dec.com Subject: (IPng 1410) Re: Link Local, or Global Address in Router advertisments? Date: Mon, 19 Feb 96 14:44:34 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In-reply-to: Message of: "Fri, 16 Feb 96 13:44:20 -0400." Message-Id: <9602161844.AA17987@cichlid.raleigh.ibm.com> Subject: (IPng 1394) Link Local, or Global Address in Router advertisments? Received From: "Thomas Narten" Sent To: alex conta cc: ipng@sunroof.eng.sun.com -------- Delivery-Date: Fri, 16 Feb 96 14:03:34 -0500 In-Reply-To: Your message of "Thu, 15 Feb 1996 19:21:11 EST." <9602160021.AA03797@brigit.zk3.dec.com> Alex, Whoa! I didn't quite expect to see these kinds of comments so late in the process. Hopefully I can convince you that these changes aren't necessary. :-) Thomas, Certainly the UNH bake-off was inspirational (-:... ... I will change a bit the order of things in the message, to put them in the order of what I think is their importance, and to focus on what is essential. In summary, philosophycally, my argumentation is for a model in which, there is no restriction in using a node's global address for any communication, and with any node, on-link, or global, (off-link) - this is a known model, and it served, and serves us well. This applies to communications with the on-link default router as well. Further, I am pointing out the following: A. the current RD specifications identifies a default router ID as an IPv6 address, which has no routability properties, and no other addresses of the default router are given to the host. This has certain implications which are described. Additionally I am pointing out: a. that the router ID does not have to be specified as an IPv6 source address, and does not have to be an IPv6 address. (see 1.) b. that the router ID is unecessarely long, and its length should be optimal. (see 2.) c. reasons a router global address should be known to a host. - less-restrictive implementability. (see 3.) - post-autoconfiguration reacher manageability. (see 4.) d. load balancing through RDA - this was mentioned in the initial message to explain that router interface load balancing could be achieved with the presence of the link-layer address in the RDA, which is counter to the ND based load balancing, which requires the absence of th link-layer address in the RDA. (see 5.) Here it is: 1. >2. Conclusion - link local address >----------------------------------- >Using the link local address as source of the router advertisments is a ... Just to clarify one point. We originally used the name "designated address" for the unique identifier for a router's interface. .... My point is that the need for a designated address has nothing to do with link-local addresses. However, we decided that since every .... >The use of the link local address in router discovery as specified today, is >... My point and necessary clarification is the following: I am NOT argueing against the router ID. I am pointing out the problems with the current choice of a router ID, which as you said resulted only from the requirement of uniqueness on the link. i. The router ID does not have to be the IP source address of the RDA: There seems to be no advantage in identifying a router ID as the RDA IPv6 source address, other than that the RDA message is somewhat shorter: it does not carry a router ID in the message body. A message with a router ID in its body, could have any of the outgoing router's interface addresses as IPv6 source address. ii. The router ID does not have to be an IP address: Like any other IPv6 address or route, autoconfigured IPv6 addresses, and advertised IPv6 routes (prefixes, or default routers) are stored in appropriate internal structures. Unlike for any other IPv6 address or route, a structure for an autoconfigured IPv6 address, or advertised IPv6 route will hold additionally, and distinctively, a router ID. The router ID is stored simply as an additional field in the structure, and it is used to keep track or validate modifications, or cancelation/invalidations of the address or router information by RDA or redirect messages. The router ID has NO addressing or routing role, and therefore, it does not matter whether the router ID is the IPv6 source address of the RDA message, or a value from a field in the RDA message, as long as it uniquely identifies the router on the link. iii. The router ID does not have a direct role in transmitting packets to the router: Since the router ID has only a validation related role, and no role in addressing or routing per see, it has no role in the process of sending a packet to the router. Essentialy the problem I have is that currently RD, superimposing the router ID, and its link unicity requirement with the IPv6 RDA source address, and furthemore with the only router address known to the host, is going beyond the satisfying of the needs for a unique on the link router ID you mentioned eloquently in your previous message. Currently RD is forcing or restricting hosts, directly or not, into a paradigm in which in transmitting packets to the router, hosts must use the router's "IPv6 link local address" as next-hop IPv6 destination for packets forwarded through the router, or as IPv6 header destination address in packets sent to the router as direct communication with the router. Being forced to always use in transmitting packets to a Router Discovery Advertised default router, an address with no-routability properties, RD forces a host implementation to have and use a specific code path for transmitting to a default router, and thus preventing the host from using the same general algorithms/mechanisms, as for transmitting packets to a node of a global address, including nodes that are routers that corespond on the host in routing table entries created on the host through other means than RDA - statically or by other possible means. 2. > Redundancy >----------------- .... > message provides redundant information. Or are you observing that in many cases, the link-local address could be derived/constructed from a link-layer address (i.e., assuming ... Yes. The fixed part of a link local address - its prefix - is always the same and it is known to any node and any host, on a particular link. More than any other node on a link, a router must have a unique link-layer address on a link, before being given the routing function on that link. This creates the conditions to have a router's link-layer addresses always as unique interface IDs, or tokens for building link layer addresses. In fact just to make sure that a router is functioning properly on a link, the requirement could be made that a router link local address MUST contain their link-layer addresses as interface IDs, or tokens. Furthermore, a router will most likely be configured before any other host on a link, and will not depend on autoconfigurion, stateless or statefull. > IPv6 address would not be of any help anyways. I wouldn't think the number of bytes used for storage is a big issue here. Rather, I would think most implementations would prefer have the same type of identifier (i.e., format) used to identify both host and router interfaces. If you only used 6 bytes for routers, but 16 for hosts, an implementation would need to treat the two cases differently. Sounds like more work for an implementor. Note that an implementation *can* choose to use a shorter identifier internally if it wanted. There is nothing in the spec that prevents that. Yes, the size is a big issue. I am not talking about packets, I am talking of storing the router ID in internal structures. As I mentioned above, the router ID has to be stored in several structures. If the structure storing the route ID, is held in a standard size buffer, platform specific, then the size may be a problem. In some implementations a standard buffer has an alignment requirement, bacuase its size is used to mask a pointer to get to its beginning, which may result in the necessity of increasing the size of the buffer to a size equal to the power of 2 of the current size, i.e. doubling the size on each increase. For instance from 128 bytes the next size is 256, then 512, and so on. Keep in mind that this buffers are also used for other structures that certainly do not require any size change, which would use buffer space unefficiently. 3. >1.4.2 Use of the router global address lookup key for best route, as >---------------------------------------------------------------------- ... >Furthermore, the default router's global address is important because ... >for the best route lookup mechanism, I don't understand this point at all. When routers appear in routing tables, they are the *target* of the search (i.e., find a router to use to reach a particular destination). They are not the *key*. Isn't the natural routing table organization determined by the *keys* that are used for lookups? This drives me to get into more implementation details which I would prefer not to, but here it is.... You mentioned (above) only the trivial, or the simplest case of lookup. In case of multiple (duplicate) route table entries for a particular destination address, which are legal, provided prefix lengths are different, one or more additional keys are necessary or at least helpful. Furthermore, the specs suggest multiple default routers, if default routes are part of the routing table, that means multiple route table entries for the same default destination. Furthermore, IPv4 transition through its automatic tunneling comes with an additional default route potentially one for each of the host's IPv4 addresses, and IPv6 tunnelling brings its load as well. Therefore to make the most effective choice, and use or implement the most effective algorithms, the availability of any additional key(s) is important. Is my point more understandable now? >or for choosing the global address to be >filled in the IPv6 source field of an outgoing packet, ND made it a point *not* to get into the issue of how to select the best Source Address on outgoing packets. It sounds like you are proposing something counter to that. It seems to me that ND does unintentionally just exactly what you say it made the point not to. It limits the ways - which is to say it forces certain ways - of selecting the source address, and it stays in the way of more simple and direct mechanisms, in which one can have "two hits from one stroke". And, I am quite positive that if we could look, we saw that distinct implementations do the same thing, to follow or accomodate the current specs. 4. >1.4 Host lacks knowledge of default routers global addresses >--------------------------------------------------------------- > Currently after receiving a router advertisment, a host has no > knowledge of any of the routers global addresses. I'd be interested in comments from others on this point. Is this really a problem? ... I don't see why when pinging a neighboring router, using an address of one particular prefix as opposed to another is inherently superior. Please elaborate. Keep in mind also that a router may have *several* global addresses (it may connect to the Internet via multiple ISPs, and have a prefix for each ISP). Which of these global address is "inherently superior"? I think it does matter which of the router's global addresses you ping the router at - a subset of the router's addresses are on the same link with the host, the others are not. Ping-ing the router at both types of addresses is a good test, but RD scope is on-link addresses, therefore I referred only to on-link addresses. But I perceive a bit of confusion here. Let me try to difuse it: I was discussing an out of the box host address autoconfiguration, when a host does not know anything about the network, and has no apriori knowledge of anything, including who or what the router's global or local link addresses are. There is no host file, or anything to tell the default router's name(s) or address(es). Everything comes to the host through autoconfiguration. After autoconfiguration completion, one finds out how the host was configured by displaying with management tools the route table, the ND cache, the interface addresses, etc. And then the first attempts are made to check connectivity, local, router, and more, based on addresses displayed on the screen... It is absolutely clear that a host after receving current RD advertisments has connectivity and can ping the default router. But currently it has no knowledge of any other address than the router's IPv6 link local address, therefore it cannot ping the router at any of its global addresses. If the router is in another building, or floor, if the network manager is N offices and hallways away, how does one check connectivity to a node that has a global address, i.e. the default router? I am curious to hear your opinion. Do you think this is a problem? 5. >1.3. Router interface load balancing. >-------------------------------------- .... > mechanism, and thus with the routing advertising mechanism. There are many kinds of load balancing.... The entire discussion around load balancing is because ND specifies that the link address option may be ommited for link load balancing purposes, while I am saying that for that very purpose link addresses should not be omitted if the load balancing is RD driven. I think I understood well the type supported by ND, since I have designed and implemented a quite similar one not too many years ago to still remember it. Thanks for the effort and pacience of explaining it. What I am saying is that if an advertisment carries a link (interface) address (not IPv6 link local), and if you change the ND to not force symmetric reachability detection on links that are by their nature symmetrical in reachability, then the link address can be stored directly in an ND cache, marked REACHABLE, and thus no ND messages are needed for that link address for at least another 'reachable' timer interval. >load for the prefixes advertised, and pass the link address information >directly in the router advertisment, as done in normal, non-load balancing >cases. ... Getting further into your note, is it maybe the case that you want a host to be able to send traffic with one Source Address to one of the replicated interfaces, while traffic using one of the other Source Addresses goes to one of the router's other replicated interfaces? ND doesn't currently allow that. Are you saying that this is a type of load balancing ND should support? It could support and certainly it should not exclude. Unicast solicited router advertisments could advertise link addresses, which could be different (distinct) from one or groups of target hosts to another. As I said above, to rely completely only on RD, the SYMMETRIC link concept has to be introduced and thus ND cache entries would have a chance to stay REACHABLE for a long time without any help from ND messages, if the 'reachable timer' is longer or equal to the router's 'advertisment retransmission timer'. Perhaps we should include solicited multicasts addresses as solicited router advertisment destination addresses? Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 19 11:58:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09500; Mon, 19 Feb 96 11:58:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09494; Mon, 19 Feb 96 11:58:27 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01289; Mon, 19 Feb 1996 11:57:13 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id LAA01477; Mon, 19 Feb 1996 11:57:12 -0800 From: conta@zk3.dec.com Received: from alpha.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA12791; Mon, 19 Feb 1996 14:54:15 -0500 Received: from brigit.zk3.dec.com by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM) id AA15461; Mon, 19 Feb 1996 14:54:10 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65v3.2/1.1.8.2/24Apr95-0109PM) id AA05953; Mon, 19 Feb 1996 14:56:26 -0500 Message-Id: <9602191956.AA05953@brigit.zk3.dec.com> To: narten@VNET.IBM.COM Cc: ipng@sunroof.eng.sun.com, conta@zk3.dec.com Subject: (IPng 1411) RDA, and Asymmetric Reachability Detection Date: Mon, 19 Feb 96 14:56:26 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, Another N&RD nit. Apparently the N&RD requires that after receiving an RDA with the source link-layer address option the ND cache entry that is created, be set to a STALE state. This is true for both an URDA, and an SRDA (unsolicited/solicited router discovery advertisment). It makes sense to me to have an SRDA result in a REACHABLE marked ND cache entry, and avoid the minimum two ND messages that a STALE entry requires before it goes to REACHABLE state. Alex P.S. In your responce to my previous message (IPNG 1394), you responded with: > If a neighbor discovery cache entry is created for the router as > consequence of a router advertisment, the entry should be marked > Reachable for symmetric reachability type links, or Stale for > asymmetric reachability type links. This is something that I don't believe we've discussed (much) before. The idea would be to tag some link types as "SYMMETRIC", meaning you always assume that if you get packets from a node, you can also send packets back. I'm not sure this would really change ND in any fundamental ways, but it might be worth looking into. and given my misshappenings with the IPng mailing list, I was not sure if you got my earlier message which I attach bellow. Yes, it suggests marking links that have symmetric reachability characetristics, as "symmetric" and thus eliminating the need for asymmetric reachability testing/confirmation. It can be done it several ways, one mentioned bellow. Another way is to have besides the S and O bit, a third bit, that would tell if ON that the link is asymmetric, in which case the S bit would be taken in consideration. If the bit is OFF, which is the default, the link is symmetric, and therefire the S bit is considered ON on all NDAs. Such a bit should have a place in RDA as well. previous message------------------------------- The N&RD (IPv6 Neighbor and Router Discovery) draft is mandating asymmetric reachability detection. The detection of asymmetric reachability is very useful in some cases, but as I understand, on very common LANs, based on links like Ethernet, or token rings, symmetric reachability is implied in normal conditions - abnormal conditions would be detected by the hardware as fatal. In case of such links, detection of asymmetric reachability is not really needed, and its elimination certainly would reduce the processing and the number of ND packets exchanged. So I would suggest to make the asymmetric reachabillity detection link dependent. If the link is of a type that implies symmetric reachability then force the Solicited bit on Multicasts or Unsolicited Unicasts to a value 1, and thus have the Neighbor Cache of the receiver go to Reachable state, rather than Stale. A Reachable cache entry would still go to Stale state after the 'reachable' timer expiration as before. This eliminates a solicitation/advertisment pair of ND messages, and certainly some processing a pair of nodes must do. Regards, Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 19 13:36:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09562; Mon, 19 Feb 96 13:36:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09556; Mon, 19 Feb 96 13:36:20 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08655; Mon, 19 Feb 1996 13:35:06 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id NAA16010; Mon, 19 Feb 1996 13:35:06 -0800 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA20109; Mon, 19 Feb 1996 16:29:18 -0500 Received: from brigit.zk3.dec.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA05007; Mon, 19 Feb 1996 16:29:01 -0500 Received: by brigit.zk3.dec.com; (5.65v3.2/1.1.8.2/24Apr95-0109PM) id AA06057; Mon, 19 Feb 1996 16:30:57 -0500 Date: Mon, 19 Feb 1996 16:30:57 -0500 From: alex conta Message-Id: <9602192130.AA06057@brigit.zk3.dec.com> To: crawdad@fnal.gov Subject: (IPng 1412) Ethernet address tokens, and Ethernet addresses Cc: conta@zk3.dec.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, In the "A Method for the Transmission of IPv6 Packets over Ethernet Networks" specifications it is mentioned that: The address token [CONF] for an Ethernet interface is the interface's built-in 48-bit IEEE 802 address, .... A different MAC address set manually or by software should not be used as the address token. It is perhaps worth mentioning that on Ethernet cards of adapters, if the physical address is set manually or by software, that physical address must be used as Ethernet unicast destination address, and consequently advertised as the link-layer address to use for transmits to that interface. This means that for such an interface, the IPv6 Neighbor Discovery cache entry will contain a Link-layer Address distinct (different) from the token part - i.e. the built-in (or so called hardware) link-layer address - of the IPv6 link local address or from a Statelss Autoconfigured IPv6 address. Note that the above is not true for FDDI, which allows multiple link-layer addresses in parallel. Alex A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 19 14:40:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09597; Mon, 19 Feb 96 14:40:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09591; Mon, 19 Feb 96 14:40:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13357; Mon, 19 Feb 1996 14:39:13 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id OAA25083; Mon, 19 Feb 1996 14:39:13 -0800 Received: from muggsy.lkg.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA22899; Mon, 19 Feb 1996 17:26:39 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA15308; Mon, 19 Feb 1996 17:26:39 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id WAA06540; Mon, 19 Feb 1996 22:47:56 GMT Message-Id: <199602192247.WAA06540@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: alex conta Cc: crawdad@fnal.gov, ipng@sunroof.eng.sun.com Subject: (IPng 1413) Re: Ethernet address tokens, and Ethernet addresses In-Reply-To: Your message of "Mon, 19 Feb 1996 16:30:57 EST." <9602192130.AA06057@brigit.zk3.dec.com> X-Mailer: exmh version 1.5omega 10/6/94 Date: Mon, 19 Feb 1996 22:47:54 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Matt, [A different Matt responds...] > In the "A Method for the Transmission of IPv6 Packets over Ethernet Networks" > specifications it is mentioned that: > > The address token [CONF] for an Ethernet interface is the interface's > built-in 48-bit IEEE 802 address, > .... > A different MAC address > set manually or by software should not be used as the address token. > > > It is perhaps worth mentioning that on Ethernet cards of adapters, if the > physical address is set manually or by software, that physical address must be > used as Ethernet unicast destination address, and consequently advertised as > the link-layer address to use for transmits to that interface. That is an absurb idea; in fact it is a very dangerous idea. There is no correspondence between link-token and the current link-layer address (they may be the same by coincidence). Anything that's seems to make them more tightly coupled than they are should be shot and killed. > This means that for such an interface, the IPv6 Neighbor Discovery cache entry > will contain a Link-layer Address distinct (different) from the token part - > i.e. the built-in (or so called hardware) link-layer address - of the IPv6 > link local address or from a Statelss Autoconfigured IPv6 address. True. So what? Why is that a problem? If you have a managed address, the token part of the address won't match the link layer address as well. This means that an implementation must already handle the case of (end-of-address != link-layer address). Or proxy/anycast for that matter. > Note that the above is not true for FDDI, which allows multiple link-layer > addresses in parallel. That assumes your O/S can handle multiple physical addresses at one time and not all can. Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 19 15:35:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09630; Mon, 19 Feb 96 15:35:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09624; Mon, 19 Feb 96 15:35:13 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18129; Mon, 19 Feb 1996 15:33:58 -0800 Received: from FNAL.FNAL.Gov by mercury.Sun.COM (Sun.COM) id PAA02770; Mon, 19 Feb 1996 15:33:58 -0800 Received: from munin.fnal.gov ("port 3362"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I1EM81PBHY000JKD@FNAL.FNAL.GOV>; Mon, 19 Feb 1996 17:33:55 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id RAA21529; Mon, 19 Feb 1996 17:33:45 -0600 (CST) Date: Mon, 19 Feb 1996 17:33:44 -0600 From: Matt Crawford Subject: (IPng 1414) Re: Ethernet address tokens, and Ethernet addresses In-Reply-To: "19 Feb 1996 16:30:57 EST." <"9602192130.AA06057"@brigit.zk3.dec.com> To: alex conta Cc: ipng@sunroof.eng.sun.com Message-Id: <199602192333.RAA21529@munin.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{ aa-00-04-00-35-a8 quite often. Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 19 15:37:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09642; Mon, 19 Feb 96 15:37:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09636; Mon, 19 Feb 96 15:37:09 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18251; Mon, 19 Feb 1996 15:35:54 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id PAA03109; Mon, 19 Feb 1996 15:35:55 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA24963; Mon, 19 Feb 1996 18:31:20 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA01655; Mon, 19 Feb 1996 18:31:17 -0500 Message-Id: <9602192331.AA01655@fwasted.zk3.dec.com> To: "Thomas Narten" Cc: alex conta , ipng@sunroof.eng.sun.com Subject: (IPng 1415) Re: Link Local, or Global Address in Router advertisments? In-Reply-To: Your message of "Fri, 16 Feb 96 13:44:20 -0400." <9602161844.AA17987@cichlid.raleigh.ibm.com> Date: Mon, 19 Feb 96 18:31:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, We cannot disclose exact details from UNH bake-off. But I know of no implementors at this point that had a problem with way the link-layer addresses are used in RA/RS or NA/NS in the ND architecture, or its reference/interaction with Addr Conf. The implementation I worked on with Matt Thomas, Jack McCann, and Dan Harrington which is Digital UNIX had no problems with the way things are presently. Locating the source address and dealing with default routes is tricky. In my response to Alex I gave you one method we are experimenting with for the defaul routes ----> BSD 4.4 cloning. I personally think we are heading down the wrong path to permit creating global addresses from link-layer knowledge from a soliticaton or advertisement. So I am opposed to such a strategy, unless it can be shown to add more value to ND. Which I can't parse out of the present 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 Mon Feb 19 16:27:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09690; Mon, 19 Feb 96 16:27:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09684; Mon, 19 Feb 96 16:27:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21626; Mon, 19 Feb 1996 16:25:50 -0800 Received: from borg.mindspring.com by mercury.Sun.COM (Sun.COM) id QAA08952; Mon, 19 Feb 1996 16:25:51 -0800 Received: from sthomas.mindspring.com [168.121.37.118] by borg.mindspring.com with SMTP id TAA18061; Mon, 19 Feb 1996 19:22:14 -0500 Date: Mon, 19 Feb 1996 19:22:14 -0500 Message-Id: <199602200022.TAA18061@borg.mindspring.com> X-Sender: sthomas@mindspring.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Matt Thomas , stephen.thomas@tridom.com From: Stephen Thomas Subject: (IPng 1416) Re: IPv6 over Token Ring (draft-ietf-ipngwg-token-ring-01.txt) Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 04:57 PM 2/14/96 +0000, Matt Thomas wrote: >RFC 1042 discusses how to do Token Ring source route discovery using ARP. >I don't see any comparable mention of source routing in the IPv6 over >Token Ring draft. That was deliberate, but I'm certainly willing to hear other suggestions. >How link layer source routing interacts with Neighbor Solicitations, >Neighbor Advertisements, and with other unicast and multicast packets >needs to be specified. The main reason I'm not comfortable doing so is the layering issue. All these neighbor discovery functions are significantly different in IPv6 (as compared to IPv4) because they now live in a layer above IP. In classic IP, you could view ARP as lying between IP and the link layer. I hope the following example can make the problem a little clearer. IMHO, good behavior for neighbor solitication would go something like: 1) send first NS without any source routing info (i.e. local LAN only) 2) send second NS using all-routes broadcast (possibly multiple copies to all bridged LANs) 3) send subsequent copies to single-route broadcast (one copy only to all bridged LANs) The problem is that the protocol (ICMP) that knows when an NS is first, second, or whatever is one layer removed from the link layer software. If we specify a particular behavior like the above, we would be requiring ICMP to track source-routing information, and for IPv6 to have some sort of mechanism for passing such info from ICMP to the link layer through IP. If I were implementing, I'd probably do just that, but I'm not sure I'm comfortable mandating it. If we want to be more explicit about handling source routing, I can offer at least three options, all of which I'd be happy to add to the draft: a) mandate a behavior like the above (with policies for RA and NA packets as well) and live with the possible uglies it introduces in some implementations b) offer such a policy as a suggested approach rather than a required one c) define two different levels of support for IPv6 over Token Ring, one that doesn't support source routing and one that does Opinions are welcome. BTW, I noticed that the latest IPv6-over-FDDI doesn't say anything about source routing either. The IEEE folks seem to be of the opinion that source routing is just as valid for FDDI as it is for Token Ring, but I don't know if that's real. Anyone know of FDDI chipsets that actually support source routing? BTW2, if we really want to get serious about source routing, we should probably define appropriate behavior for any broadcast or multicast protocol. The IPv6-over-Token Ring draft's probably the place to do that. Are we comfortable making blanket (default) statements that will apply to protocols like OSPF, RIP, RTP, DHCP, ... and letting specific protocols override that behavior as they see fit? BTW3, would it make more sense to have a generic RFC that specificed IPv6's interaction with bridging, independent of the particular LAN type? Many of the complications of bridging arise when different LAN types are mixed. --Stephen ________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: s.thomas@acm.org ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 19 16:56:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09714; Mon, 19 Feb 96 16:56:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09708; Mon, 19 Feb 96 16:55:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23467; Mon, 19 Feb 1996 16:54:42 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id QAA12521; Mon, 19 Feb 1996 16:54:41 -0800 From: conta@zk3.dec.com Received: from alpha.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA26224; Mon, 19 Feb 1996 19:45:31 -0500 Received: from brigit.zk3.dec.com by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM) id AA32742; Mon, 19 Feb 1996 19:45:26 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65v3.2/1.1.8.2/24Apr95-0109PM) id AA06355; Mon, 19 Feb 1996 19:47:45 -0500 Message-Id: <9602200047.AA06355@brigit.zk3.dec.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com, conta@zk3.dec.com Subject: (IPng 1417) Re: Ethernet address tokens, and Ethernet addresses Date: Mon, 19 Feb 96 19:47:45 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In-reply-to: Message of: "Mon, 19 Feb 96 17:33:44 CST." Message-Id: <199602192333.RAA21529@munin.fnal.gov> Subject: Ethernet address tokens, and Ethernet addresses Received From: Matt Crawford Sent To: alex conta cc: ipng@sunroof.eng.sun.com -------- Delivery-Date: Mon, 19 Feb 96 18:42:01 -0500 In-Reply-To: "19 Feb 1996 16:30:57 EST." <"9602192130.AA06057"@brigit.zk3.dec.com> 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{ aa-00-04-00-35-a8 quite often. Matt Matt, >From the combinations: (a) 1::0c12:3456 -> 00-00-0c-12-34-56 ... 17::0c12:3456 -> 00-00-0c-12-34-56 ... fe80::0c12:3456 -> 00-00-0c-12-34-56 or: (b) 1::1 -> 00-00-0c-12-34-56 ... 17::1 -> 00-00-0c-12-34-56 ... fe80::0c12:3456 -> 00-00-0c-12-34-56 or (c) 1::1 -> 00-00-0c-12-34-56 ... 17::1 -> 00-00-0c-12-34-56 ... fe80::1 -> 00-00-0c-12-34-56 or (d) 1::0c12:3456 -> aa-00-04-00-35-a8 ... 17::0c12:3456 -> aa-00-04-00-35-a8 ... fe80::0c12:3456 -> aa-00-04-00-35-a8 or (e) 1::1 -> aa-00-04-00-35-a8 ... 17::1 -> aa-00-04-00-35-a8 ... fe80::0c12:3456 -> aa-00-04-00-35-a8 or (f) 1::1 -> aa-00-04-00-35-a8 ... 17::1 -> aa-00-04-00-35-a8 ... fe80::1 -> aa-00-04-00-35-a8 I think (a) and (d) have a better chance to be the most common case, with (a) outnumbering (d). I thought that adding a short text that would explain it, perhaps with the explanation that this could occur most likely on Ethernet but not necesseraly on FDDI, would reduce the probability of a missinterpretation of the "exception" as a problem or a bug, by people that are not so familiar with the specs or with the intricacies of Ethernet, or FDDI, or etc... physical and hardware addresses, and which from seeing the common case overwhelmingly more often that may conclude that -> is also <-. Since in many cases the specs (RFCs) are also used as a source for products' documentation, the short text in your specs, would increase the probability that the information would get consistently and uniformly into system management manuals of different vendors and different IPv6 products. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 19 17:17:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09746; Mon, 19 Feb 96 17:17:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09740; Mon, 19 Feb 96 17:17:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24760; Mon, 19 Feb 1996 17:16:17 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id RAA15178; Mon, 19 Feb 1996 17:16:16 -0800 From: schulter@zk3.dec.com Received: from flume.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA29847; Mon, 19 Feb 1996 20:05:24 -0500 Received: from dogfish.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA27368; Mon, 19 Feb 1996 20:05:23 -0500 Received: from localhost by dogfish.zk3.dec.com (5.65v3.2/1.1.10.3/27Jun95-1215PM) id AA06161; Mon, 19 Feb 1996 20:06:05 -0500 Message-Id: <9602200106.AA06161@dogfish.zk3.dec.com> X-Mailer: exmh version 1.6.1 5/23/95 To: rolc@nexen.com, ip-atm@nexen.com, ipng@sunroof.eng.sun.com Cc: malis@nexen.com, laubach@terra.com21.com Subject: (IPng 1418) A Framework for IPv6 Over ATM (rev 01) now available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Feb 96 20:06:05 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The I-D draft-schulter-ipv6atm-framework-01.txt (and .ps) is now available from the usual places: ftp://ds.internic.net/internet-drafts/draft-schulter-ipv6atm-framework-01.txt ftp://ds.internic.net/internet-drafts/draft-schulter-ipv6atm-framework-01.ps This draft describes a framework for IPv6 over ATM which maintains full ND and address configuration features and semantics over ATM networks, and a method of using ND to achieve "cut through" connections between subnets. This is only the second rev, so it still has a few missing sections, but presents the main ideas. Discussion of this draft is currently scheduled for the joint IPATM/ROLC/IPNG session on 3/7. --- pete ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 19 23:41:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09914; Mon, 19 Feb 96 23:41:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09908; Mon, 19 Feb 96 23:40:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB13057; Mon, 19 Feb 1996 23:39:35 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id XAA19656; Mon, 19 Feb 1996 23:39:35 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA28299; Tue, 20 Feb 1996 02:33:51 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA06320; Tue, 20 Feb 1996 02:33:47 -0500 Message-Id: <9602200733.AA06320@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Subject: (IPng 1419) FOOBAR for FTP ala RFC 1639 Date: Tue, 20 Feb 96 02:33:47 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, If we are to use this then it needs an update. At UNH some implemented it and some did not. Clearly a change to the port command must happen and the pasv command. The fields for LPRT (long port) need to be reviewed. This spec was done before IPv6 was even decided, hence, codes still exist for TUBA, TPIX, SIP, etc. Also do we want clients to redirect data transfer connections to other clients of a different address family? This is going to make things really complex? Anyway I am implementing it now and am not comfortable with the present RFC. Does someone want to rewrite it? Bob Gilligan had an alternate proposal sometime ago? Bob do you want throw that one on the table too? For now I would like to suggest we treat the address used in the port command in a manner that the data control Address Family determines the data transfer connection. So if control is from IPv4 data transfer is IPv4 if control is IPv6 data transfer is IPv6. PASV should wait until we sort out how we want to do this. This will keep it simple for IPv6 links and IPv4 tunnels in our implementations for right now anyway. All still have to check out and update their port command for IPv6 links though. Comments ???? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 20 08:17:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10125; Tue, 20 Feb 96 08:17:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10119; Tue, 20 Feb 96 08:17:24 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10408; Tue, 20 Feb 1996 08:16:08 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id IAA21218; Tue, 20 Feb 1996 08:16:07 -0800 Received: from shand.reo.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA13681; Tue, 20 Feb 1996 11:12:19 -0500 Received: from localhost by shand.reo.dec.com (5.65/Ultrix3.0-C) id AA00604; Tue, 20 Feb 1996 16:12:03 GMT Message-Id: <9602201612.AA00604@shand.reo.dec.com> To: ipng@sunroof.eng.sun.com Cc: shand@shand.ENET.dec.com Subject: (IPng 1420) Multi-homing support in IPv6 Date: Tue, 20 Feb 96 16:12:02 +0000 From: (Mike Shand REO2 G/C2 DTN:830-4424) X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have today submitted an I-D draft-shand-ipv6-multi-homing-00.txt which explores some of the requirements for multi-homing and the options we have to support them. It is intended as a discussion provoker. Any comments would be gratefully received both prior to and at the LA IETF. Since it may take some time to appear in the drafts repositiory, you may sneak an early preview from gatekeeper.dec.com at /pub/DEC/IPv6/draft-shand-ipv6-multi-homing-00.txt I am reliably informed that it should be available there as of 3 p.m. EST today (20th Feb). Mike ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 20 09:52:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10229; Tue, 20 Feb 96 09:52:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10223; Tue, 20 Feb 96 09:51:51 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24805; Tue, 20 Feb 1996 09:50:31 -0800 Received: from FNAL.FNAL.Gov by mercury.Sun.COM (Sun.COM) id JAA18589; Tue, 20 Feb 1996 09:50:22 -0800 Received: from munin.fnal.gov ("port 3745"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I1FOIARFMC000OGW@FNAL.FNAL.GOV>; Tue, 20 Feb 1996 11:50:15 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id LAA26367; Tue, 20 Feb 1996 11:50:04 -0600 (CST) Date: Tue, 20 Feb 1996 11:50:03 -0600 From: Matt Crawford Subject: (IPng 1421) Re: IPv6 over Token Ring (draft-ietf-ipngwg-token-ring-01.txt) In-Reply-To: "19 Feb 1996 19:22:14 EST." <"199602200022.TAA18061"@borg.mindspring.com> To: Stephen Thomas Cc: Matt Thomas , stephen.thomas@tridom.com, ipng@sunroof.eng.sun.com Message-Id: <199602201750.LAA26367@munin.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{ BTW, I noticed that the latest IPv6-over-FDDI doesn't say anything about > source routing either. My only recognition of source routing was to maintain the MTU at 4352 as IPv4 does, rather than the maximum possible 4470. > BTW3, would it make more sense to have a generic RFC that specificed > IPv6's interaction with bridging, independent of the particular LAN > type? Many of the complications of bridging arise when different LAN > types are mixed. I began my zeroth draft that way, but I decided implementation would be more timely and universal if I put the bridging considerations in the FDDI document itself. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 20 13:32:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10787; Tue, 20 Feb 96 13:32:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10781; Tue, 20 Feb 96 13:31:59 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05488; Tue, 20 Feb 1996 13:30:43 -0800 Received: from IMgate.iMach.com by mercury.Sun.COM (Sun.COM) id NAA29543; Tue, 20 Feb 1996 13:30:41 -0800 Received: (from forrestc@localhost) by IMgate.iMach.com (8.6.12/8.6.11) id OAA10283; Tue, 20 Feb 1996 14:30:12 -0700 Date: Tue, 20 Feb 1996 14:30:03 -0700 (MST) From: "Forrest W. Christian" To: ipng@sunroof.eng.sun.com, Curtis Villamizar Cc: Bryan Byers , "'cidrd@iepg.org'" Subject: (IPng 1422) Re: Routing and IPv6 In-Reply-To: <199602201949.OAA05313@brookfield.ans.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --- cc'd to the ipng list On Tue, 20 Feb 1996, Curtis Villamizar wrote: > What you are describing is an addressing scheme with fixed aggregation > boundaries. We had an addressing scheme with fixed aggregation > boundaries, class A, B, C. It proved inadequate. We are a step > beyond that with arbitrary aggregation boundaries within the > addressing space. No, I'm not describing a scheme with fixed aggregation boundaries, at least in the manner. I'm describing a scheme in which that the upper bits are TOTALLY AND COMPLETELY Separate from the LOWER BITS. Lets jump back to IPv4 here for a minute, and let me use an example, making a couple assumptions. (forget that this will never happen to the IPv4 header) Assume that Everyone KEEPS Their existing numbers. In the IPv4 header, assume that an "ASN" field is added. When the IPv4 packet is originated the ASN of the destination is added to the packet. Now, the backbone routers only need to know how to forward to the specific ASN. Last time I checked that was about 2000 ASN's. If you move ASN's, the ASN which is inserted changes, but your Existing address doesn't. Of course it's slightly more complex than that. There's the necessity for the ASN lookup, some issues over protocols which incorporate IP addresses into them, etc. What I was asking is if there was any disucssion for doing something like this under the ipv6 structure. There is noting like this in the drafts I've read, but I haven't read the current portability draft. I have dropped my original note into the ipng list. So far I haven't heard anything back, other than "you haven't read the drafts". Well Either I'm not reading the same drafts that everyone else is, or this isn't mentioned. > Hope this helps you understand the issues. Now read the draft! :-) If there's a draft I've missed I'd love to. -forrestc@imach.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 20 13:46:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10813; Tue, 20 Feb 96 13:46:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10801; Tue, 20 Feb 96 13:46:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08187; Tue, 20 Feb 1996 13:44:57 -0800 Received: from IMgate.iMach.com by mercury.Sun.COM (Sun.COM) id NAA03783; Tue, 20 Feb 1996 13:44:51 -0800 Received: (from forrestc@localhost) by IMgate.iMach.com (8.6.12/8.6.11) id OAA10283; Tue, 20 Feb 1996 14:30:12 -0700 Date: Tue, 20 Feb 1996 14:30:03 -0700 (MST) From: "Forrest W. Christian" To: ipng@sunroof.eng.sun.com, Curtis Villamizar Cc: Bryan Byers , "'cidrd@iepg.org'" Subject: (IPng 1423) Re: Routing and IPv6 In-Reply-To: <199602201949.OAA05313@brookfield.ans.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --- cc'd to the ipng list On Tue, 20 Feb 1996, Curtis Villamizar wrote: > What you are describing is an addressing scheme with fixed aggregation > boundaries. We had an addressing scheme with fixed aggregation > boundaries, class A, B, C. It proved inadequate. We are a step > beyond that with arbitrary aggregation boundaries within the > addressing space. No, I'm not describing a scheme with fixed aggregation boundaries, at least in the manner. I'm describing a scheme in which that the upper bits are TOTALLY AND COMPLETELY Separate from the LOWER BITS. Lets jump back to IPv4 here for a minute, and let me use an example, making a couple assumptions. (forget that this will never happen to the IPv4 header) Assume that Everyone KEEPS Their existing numbers. In the IPv4 header, assume that an "ASN" field is added. When the IPv4 packet is originated the ASN of the destination is added to the packet. Now, the backbone routers only need to know how to forward to the specific ASN. Last time I checked that was about 2000 ASN's. If you move ASN's, the ASN which is inserted changes, but your Existing address doesn't. Of course it's slightly more complex than that. There's the necessity for the ASN lookup, some issues over protocols which incorporate IP addresses into them, etc. What I was asking is if there was any disucssion for doing something like this under the ipv6 structure. There is noting like this in the drafts I've read, but I haven't read the current portability draft. I have dropped my original note into the ipng list. So far I haven't heard anything back, other than "you haven't read the drafts". Well Either I'm not reading the same drafts that everyone else is, or this isn't mentioned. > Hope this helps you understand the issues. Now read the draft! :-) If there's a draft I've missed I'd love to. -forrestc@imach.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 20 13:46:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10814; Tue, 20 Feb 96 13:46:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10806; Tue, 20 Feb 96 13:46:17 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08201; Tue, 20 Feb 1996 13:45:01 -0800 Received: from po10.andrew.cmu.edu by mercury.Sun.COM (Sun.COM) id NAA03820; Tue, 20 Feb 1996 13:44:59 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.3/8.7.1) id QAA00916 for ipng@sunroof.eng.sun.com; Tue, 20 Feb 1996 16:44:57 -0500 Received: via switchmail; Tue, 20 Feb 1996 16:44:55 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 20 Feb 1996 16:43:48 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 20 Feb 1996 16:43:45 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 20 Feb 1996 16:43:41 -0500 (EST) Message-Id: Date: Tue, 20 Feb 1996 16:43:41 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1424) Re: Thoughts on DNS and API In-Reply-To: References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Gersten writes: > The second, and more serious concern, is the API specs. Am I the > only one that thinks that duplicating the V4 socket interface for V6 > is a really bad idea? You're certainly not the only one who thinks the draft API is seriously defective. My big problem with the API spec is the use of setsockopt() to specify the behavior of such things as accept() and recvfrom() and all the race conditions that fall out from that. Some of the race conditions are extremely non-obvious and inadequately documented in the spec. The IPV6_RECVSRCRT and IPV6_RECVIF options should be arguments to the functions they affect, namely accept(), recvmsg() and the like. (Specifically, there should be new functions, e.g. accept2(), which take an additional flags argument). The options should be considered protocol-independent, not IPv6-specific. When bringing this issue up with the authors of the document, Jim Bound stated that he wanted his implementation to discard the source route information upon receipt of the packet if the IPV6_RECVSRCRT option was not currently set. This means that if a packet arrived, then the application changed the value of IPV6_RECVSRCRT to be set, then the application received the packet, the application would not get the source route. I found this behavior to be completely astonishing and could not see how the current draft could be read to permit it. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 20 14:47:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10933; Tue, 20 Feb 96 14:47:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10927; Tue, 20 Feb 96 14:46:51 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20529; Tue, 20 Feb 1996 14:45:34 -0800 Received: from noao.edu by mercury.Sun.COM (Sun.COM) id OAA21776; Tue, 20 Feb 1996 14:45:33 -0800 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G105) id AA24176; Tue, 20 Feb 96 15:45:31 MST; for ipng@sunroof.eng.sun.com Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA25506; Tue, 20 Feb 96 15:45:29 MST; for ipng@sunroof.eng.sun.com Message-Id: <9602202245.AA25506@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Tue, 20 Feb 1996 15:45:29 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: John Gardiner Myers , ipng@sunroof.eng.sun.com Subject: (IPng 1425) Re: Thoughts on DNS and API Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Feb 20, 4:43pm you write:] > > My big problem with the API spec is the use of setsockopt() to specify > the behavior of such things as accept() and recvfrom() and all the > race conditions that fall out from that. Some of the race conditions > are extremely non-obvious and inadequately documented in the spec. > > When bringing this issue up with the authors of the document, Jim > Bound stated that he wanted his implementation to discard the source > route information upon receipt of the packet if the IPV6_RECVSRCRT > option was not currently set. This means that if a packet arrived, > then the application changed the value of IPV6_RECVSRCRT to be set, > then the application received the packet, the application would not > get the source route. I found this behavior to be completely > astonishing and could not see how the current draft could be read to > permit it. I have no problem with socket options affecting other functions. Look at SO_RCVTIMEO and SO_SNDTIMEO. Should we get rid of these and force a bunch of new I/O functions, all of which require a pointer to a timeval{}? Or get rid of SO_REUSEADDR and invent a new bind_with_reuse()? And just what happens today when someone uses setsockopt() to change the TCP socket receive buffer size after the connection is established (that is decreases the buffer)? And if you turn off the IP_RECVDSTADDR socket option while UDP is receiving a datagram, or if you set the keepalive option 1 hour after the last data or ACK on the connection (is it set for 1 hour in the future or 2?), or setting SO_OOBINLINE while TCP is receiving urgent data, and on and on. I think there are lots of holes in *all* implementations today with regard to changing things like these in the middle of something, and I don't think any are documented. I don't think it was (or should have been) the goal of the IPv6 Sockets API spec to clean up everything in sight. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 20 14:53:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10969; Tue, 20 Feb 96 14:53:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10953; Tue, 20 Feb 96 14:53:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21662; Tue, 20 Feb 1996 14:51:44 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id OAA23597; Tue, 20 Feb 1996 14:51:41 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA13705; Tue, 20 Feb 1996 17:37:25 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA30140; Tue, 20 Feb 1996 17:37:19 -0500 Message-Id: <9602202237.AA30140@fwasted.zk3.dec.com> To: John Gardiner Myers Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 1426) Re: Thoughts on DNS and API In-Reply-To: Your message of "Tue, 20 Feb 96 16:43:41 EST." Date: Tue, 20 Feb 96 17:37:19 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, >Michael Gersten writes: >> The second, and more serious concern, is the API specs. Am I the >> only one that thinks that duplicating the V4 socket interface for V6 >> is a really bad idea? This is like telling the engineers who build cars I don't like trunks in cars. But neglect to provide a solution as to how the passengers hold their stuff in the car. >You're certainly not the only one who thinks the draft API is >seriously defective. John be fair now! I put together a list of folks who had issues and stated those issues. First I tried to foster a discussion amongst a list of folks privately, then my coauthor Bob Gilligan convinced me its best to throw it out to the IPng list. We did this and a whole set of issues. None of the person who have been complaining including you responded to that IPng WG API thread. Everyone is just sitting there and when we try to say Last Call the discussion starts. Please state in detail why the spec is defective if more than what you have stated in this mail. Your throwing stones without giving direction and that really is not fair. I am sure you would not like it if you were on the receiving end of this mail. >My big problem with the API spec is the use of setsockopt() to specify >the behavior of such things as accept() and recvfrom() and all the >race conditions that fall out from that. Some of the race conditions >are extremely non-obvious and inadequately documented in the spec. What race conditions? Please be "technically" specific. If you mean the wait condition to use the setsockopt() that is not the same as a race condition. Please make them obvious to all of us please. >The IPV6_RECVSRCRT and IPV6_RECVIF options should be arguments to the >functions they affect, namely accept(), recvmsg() and the like. >(Specifically, there should be new functions, e.g. accept2(), which >take an additional flags argument). The options should be considered >protocol-independent, not IPv6-specific. I can see this as a way to do v6 functions, but it will break a goal in the spec. Compatibility with the existing functions. This is deemed important to applications most effective portability. If we did head down this path then there are other parts in the spec that need to do that too (e.g. hostname2addr() ---> gethostbyname2()). Why would we make anything for IPv6 protocol un-specific? Please explain your reasoning and motive. >When bringing this issue up with the authors of the document, Jim >Bound stated that he wanted his implementation to discard the source >route information upon receipt of the packet if the IPV6_RECVSRCRT >option was not currently set. This means that if a packet arrived, >then the application changed the value of IPV6_RECVSRCRT to be set, >then the application received the packet, the application would not >get the source route. I found this behavior to be completely >astonishing and could not see how the current draft could be read to >permit it. This is simply a decision that needs to be made if we use setsockopt() as a vehicle to use the source route. If the option is not set the application may not be prepared to use the array to process the incoming source route. Its just a failure mode scientifically not a belief of mine that it is correct behavior. But I agree its bogus. I have tried to fight to have all source routes and options for that matter be part of the msg_control flags for source routes, security notificiaton, flows, etc.. This is an alternative to your redefining each critical function call to process new features in IPv6. In fact all the options can be set by the network layer in a data structure and masked if on or off and passed to the applications via msg_control and iovecs. I lost this battle and have given up. I believe when it gets to POSIX, WINSOCK, and X/Open it will all get revisited to some degree. But right now we are trying to get a minimal stable API for implementations. But if you and others really want to HELP. Then lets get started and get this done. I would appreciate if you would take care if you use my name and private conversations we had, later in public, to make sure you present why I wanted to permit a behavior (that I agree is bogus) in the future as we work together in public. Thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 20 14:53:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10970; Tue, 20 Feb 96 14:53:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10959; Tue, 20 Feb 96 14:53:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21674; Tue, 20 Feb 1996 14:51:47 -0800 Received: from dune.silkroad.com by mercury.Sun.COM (Sun.COM) id OAA23608; Tue, 20 Feb 1996 14:51:41 -0800 Received: (from ipng@localhost) by dune.silkroad.com (8.7.3/8.6.9) id RAA08179; Tue, 20 Feb 1996 17:49:36 -0500 From: Tim Bass (IPNG WG) Message-Id: <199602202249.RAA08179@dune.silkroad.com> Subject: (IPng 1427) Re: Routing and IPv6 To: forrestc@imach.com (Forrest W. Christian) Date: Tue, 20 Feb 1996 17:49:36 -0500 (EST) Cc: ipng@sunroof.eng.sun.com, curtis@ans.net, bbyers@bellsouth.net, cidrd@iepg.org In-Reply-To: from "Forrest W. Christian" at Feb 20, 96 02:30:03 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Forrest replies to a reply to his question: > Lets jump back to IPv4 here for a minute, and let me use an example, > making a couple assumptions. (forget that this will never happen to the > IPv4 header) Assume that Everyone KEEPS Their existing numbers. In the > IPv4 header, assume that an "ASN" field is added. When the IPv4 packet > is originated the ASN of the destination is added to the packet. Now, > the backbone routers only need to know how to forward to the specific > ASN. Last time I checked that was about 2000 ASN's. If you move ASN's, > the ASN which is inserted changes, but your Existing address doesn't. > > Of course it's slightly more complex than that. There's the necessity > for the ASN lookup, some issues over protocols which incorporate IP > addresses into them, etc. There have been many to propose supernetting or aggregation based on ASN numbers via an exterior gateway protocols and the interior routing protocol(s) within the ASN do the rest. (including The Heretic, 1995, cidrd WG ramblings and others even before ) The idea has considerable merit but the details have yet to be worked out ( to my knowledge ). There are plenty of good ideas. Another one is to do aggregation at an intermediate system (like an ISP that defaults to default free ASNs). This involves in-vivo route translation and some major changes to DNS (or similar mapping between end user IP address and the service provider aggregate). I.E. Joe Web has a net that is 197.254.254.0. Instead of advertising 197.254.254.0, his ISP maps 197.254.254.0 into a provider based CIDR block in his network. Also, there must be a mapping between names and both the aggregated mapping and well as the 197.254.254 network. This technique would all portable address space and provide a much greater degree of ISP freedom as well. There are numerous ways to aggregate and to develop a new hierarchical routing paradigm or two......... but ( but I'll stop here before the polarized mind ray is unleashed on The Heretic :-) It seems that ideas are not allowed and are prohibited unless you have the cooperation of a routing vendor whom is willing to make it work and can penetrate the ISP backbone market (need a lottery ticket... the odds are similar :-) 1 24 35 36 40 44 (good luck on Powerball !) Best Regards, Tim +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 20 15:53:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11150; Tue, 20 Feb 96 15:53:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11144; Tue, 20 Feb 96 15:53:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02938; Tue, 20 Feb 1996 15:51:46 -0800 Received: from nsco.network.com by mercury.Sun.COM (Sun.COM) id PAA11063; Tue, 20 Feb 1996 15:51:41 -0800 Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA10547; Tue, 20 Feb 96 17:54:39 CST Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA16017; Tue, 20 Feb 96 17:53:17 CST Date: Tue, 20 Feb 96 17:53:17 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9602202353.AA16017@anubis.network.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1428) Re: Routing and IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that adding a mythical ASN field to the IPv4 header, and doing across-the-core routing by ASN is isomorphic to stamping in a short source route as a packet enters the Land of Default Free Routers, and stripping it back out as it leaves. This is a technical twiddle to aid in one of several possible solutions to the real problem of distributing routing information. The trouble is that no matter how you fiddle it, if you try to do routing based on a endpoint identifier, you're going to have people sobbing and grumbling and whining about how their endpoint identifiers are sacred for various reasons, and just because routing based on them is impossible doesn't mean that someone should not be forced to do it. And do it darn cheap, by golly. IPv6 has some stuff in it for doing flows. I don't know if it's any good, but flows and whatnot are supposed to aid these little issues, being (roughly) dynamically determined routing information which is separate and distict from whatever 'address' widget which identifies the destination host. Andrew ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 20 16:17:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11173; Tue, 20 Feb 96 16:17:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11167; Tue, 20 Feb 96 16:17:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06887; Tue, 20 Feb 1996 16:16:17 -0800 Received: from po10.andrew.cmu.edu by mercury.Sun.COM (Sun.COM) id QAA17118; Tue, 20 Feb 1996 16:16:17 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.3/8.7.1) id TAA01029 for ipng@sunroof.eng.sun.com; Tue, 20 Feb 1996 19:16:15 -0500 Received: via switchmail; Tue, 20 Feb 1996 19:16:14 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 20 Feb 1996 19:14:13 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 20 Feb 1996 19:14:07 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 20 Feb 1996 19:14:02 -0500 (EST) Message-Id: <8l_aD_G00WBw812INw@andrew.cmu.edu> Date: Tue, 20 Feb 1996 19:14:02 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1429) setsockopt() stuff In-Reply-To: <9602202237.AA30140@fwasted.zk3.dec.com> References: <9602202237.AA30140@fwasted.zk3.dec.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I certainly apologize for taking so long to mention the issue on the list, all I can say is that other projects have so far kept it from popping up to the top of my queue. There are two potential race conditions. The less important one is if there are two independent processes (threads, code sections, whatever) sharing a single socket, each of which wants a different value of, say, IPV6_RECVIF, there is no way one can atomically set the option and receive a packet. The two processes would have to agree on some locking mechanism to protect the critical section between the setsockopt() and recvfrom(). The one I'm concerned about is the one where a packet is recieved before setsockopt() is called to set one of these options before receiving a packet. What this effectively means is that the application must either set all of the relevant socket options before calling bind(). The API document does not state that the applications have this requirement. Furthermore, the requirement to call setsockopt() before bind() may not be practical. The bind() call may be performed by some independent subsystem, such as inetd, which hands the application a socket with a packet already queued up to be received. Similar problems exist with accept() and getpeername(). > I can see this as a way to do v6 functions, but it will break a goal in the > spec. Compatibility with the existing functions. This is deemed > important to applications most effective portability. If we did head > down this path then there are other parts in the spec that need to do > that too (e.g. hostname2addr() ---> gethostbyname2()). Defining new functions with expanded functionality has been done numerous times in the past. There's wait(), wait3(), wait4(), and waitpid(). Defining waitpid() does not break compatibility with wait(). Similarly, defining hostname2addr() does not break gethostbyaddr(), and there's no compelling reason to call hostname2addr() gethostbyaddr2(). Defining a function that is like accept() but takes an additional flags argument will not break accept() as long as it is named something other than "accept". For simplicity, accept() could then be written in terms of the new function. Applications are going to need to be changed anyway in order to deal with the new IPv6 address data types. To me, the simplest and most obvious approach to back portability would be to write the application to use the IPv6 data types and functions, then use a compatibility library with stub header files and functions for those systems which only have IPv4. The compatibility functions would only deal with and return IPv4-mapped addresses and so on. As long as the IPv6 API is a functional superset of the IPv4 one and as long as the API can say "no, can't do that" when appropriate, this won't be a problem. > Why would we make anything for IPv6 protocol un-specific? Please > explain your reasoning and motive. Concepts such as source routes and interfaces are not specific to IPv6. It would be reasonable to permit implementations of other protocols, such as IPv4, to give the applications access to this information. Put another way, options such as IPV6_RECVSRCRT affect the behavior of the API, not the behavior of the protocol. They should be made protocol un-specific to permit their movement closer to the API functions that they affect. > But I agree its bogus. I have tried to fight to have all source routes > and options for that matter be part of the msg_control flags for source > routes, security notificiaton, flows, etc. Sounds like a good idea to me. Simple, fairly straightforward, and doesn't require some independent subsystem, such as inetd, to actively cooperate in order for an application to get the data. > I lost this battle and have given up. I > believe when it gets to POSIX, WINSOCK, and X/Open it will all get > revisited to some degree. But right now we are trying to get a minimal > stable API for implementations. Pity. Regardless of what others do, I fear that the minimal API is going to be the lowest common denominator that all of us applications folks will have to write to in order to be portable. On another topic, I'd like to review the proposed security API, but I can't find any such draft. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 20 21:57:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11442; Tue, 20 Feb 96 21:57:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11425; Tue, 20 Feb 96 21:38:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09252; Tue, 20 Feb 1996 21:37:33 -0800 Received: from postoffice.cso.uiuc.edu by mercury.Sun.COM (Sun.COM) id VAA07986; Tue, 20 Feb 1996 21:37:31 -0800 Received: from [192.17.16.74] (mac-ross.isdn.uiuc.edu [192.17.16.74]) by postoffice.cso.uiuc.edu (8.6.12/8.6.12) with SMTP id XAA69768; Tue, 20 Feb 1996 23:36:33 -0600 X-Sender: rrv@tampico.cso.uiuc.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Feb 1996 23:36:36 -0600 To: "Forrest W. Christian" From: rrv@uiuc.edu (Ross Veach) Subject: (IPng 1430) Re: Routing and IPv6 Cc: cidrd@iepg.org, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:30 PM 2/20/96, Forrest W. Christian wrote: >Lets jump back to IPv4 here for a minute, and let me use an example, >making a couple assumptions. (forget that this will never happen to the >IPv4 header) Assume that Everyone KEEPS Their existing numbers. In the >IPv4 header, assume that an "ASN" field is added. When the IPv4 packet >is originated the ASN of the destination is added to the packet. Now, >the backbone routers only need to know how to forward to the specific >ASN. Last time I checked that was about 2000 ASN's. If you move ASN's, >the ASN which is inserted changes, but your Existing address doesn't. How about using a 32 bit number instead of a 16 bit number? >Of course it's slightly more complex than that. There's the necessity >for the ASN lookup, some issues over protocols which incorporate IP >addresses into them, etc. We'd already have the switching engines, routing protocols, and a model for the distributed databases (DNS) that would hold the needed forwarding address. It seems to me like something that could be deployed one routing domain at a time, and be totally transparent to the end user. It seems to me that someone has already done a great deal of work on something that sounds a whole lot like this. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 02:23:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11614; Wed, 21 Feb 96 02:23:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11608; Wed, 21 Feb 96 02:23:34 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25068; Wed, 21 Feb 1996 02:22:17 -0800 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id CAA06822; Wed, 21 Feb 1996 02:22:08 -0800 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 1431) Re: Thoughts on DNS and API To: bound@zk3.dec.com Date: Wed, 21 Feb 1996 08:24:43 +0000 (GMT) Cc: jgm+@CMU.EDU, ipng@sunroof.eng.sun.com In-Reply-To: <9602202237.AA30140@fwasted.zk3.dec.com> from "bound@zk3.dec.com" at Feb 20, 96 05:37:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But I agree its bogus. I have tried to fight to have all source routes > and options for that matter be part of the msg_control flags for source > routes, security notificiaton, flows, etc.. This is an alternative to > your redefining each critical function call to process new features in > IPv6. In fact all the options can be set by the network layer in a data > structure and masked if on or off and passed to the applications via > msg_control and iovecs. I lost this battle and have given up. I > believe when it gets to POSIX, WINSOCK, and X/Open it will all get > revisited to some degree. But right now we are trying to get a minimal > stable API for implementations. Unfortunately as is frequently the case we run the risk of ending up with a single not so good API. Certainly supporting security/flow etc in sendmsg() recvmsg() is a natural place to put many of these things, and also reduces the syscalls/packet overhead doing complex things. > But if you and others really want to HELP. Then lets get started and > get this done. That might not be a bad idea. The existing draft is a very good base and its probably pretty close to fully usable, or a close as can be got until a lot of implementations exist. It also doesn't address a minimal raw socket behaviour specification, which would be a useful move. Forget the funny stuff but enough to do things like a portable IPv6 ping. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 08:40:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11830; Wed, 21 Feb 96 08:40:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11817; Wed, 21 Feb 96 08:39:51 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22275; Wed, 21 Feb 1996 08:38:34 -0800 Received: from po10.andrew.cmu.edu by mercury.Sun.COM (Sun.COM) id IAA05180; Wed, 21 Feb 1996 08:38:34 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.3/8.7.1) id LAA00655 for ipng@sunroof.Eng.Sun.COM; Wed, 21 Feb 1996 11:38:30 -0500 Received: via switchmail; Wed, 21 Feb 1996 11:38:29 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 21 Feb 1996 11:36:57 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 21 Feb 1996 11:36:53 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Wed, 21 Feb 1996 11:36:50 -0500 (EST) Message-Id: <8l_ocWG00WBwQQdHV9@andrew.cmu.edu> Date: Wed, 21 Feb 1996 11:36:50 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1432) Re: Thoughts on DNS and API In-Reply-To: References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If you're going for simple, how about removing the IPV6_RECVSRCRT, IPV6_RECVIF, and IPV6_SENDIF options entirely? Act like they're always set. When receiving an address, if there is room for two or more addresses, make the Nth one the receiving interface address and the second through N-1'th address as much of the source route as will fit. If there's only room for one address, the API would only fill in the endpoint address. When sending an address, if there are two or more addresses supplied, the Nth one is the sending interface and the rest are the source route. A sending interface address of INADDR_ANY would specify that the sender doesn't care which interface it goes out. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 10:42:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11963; Wed, 21 Feb 96 10:42:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11957; Wed, 21 Feb 96 10:41:48 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14592; Wed, 21 Feb 1996 10:40:30 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id KAA16370; Wed, 21 Feb 1996 10:40:31 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id KAA24516; Wed, 21 Feb 1996 10:40:30 -0800 Date: Wed, 21 Feb 1996 10:40:30 -0800 From: Ran Atkinson Message-Id: <199602211840.KAA24516@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1433) Re: Link Local, or Global Address in Router advertisments? In-Reply-To: <9602161557.AA02261@fwasted.zk3.dec.com> References: <9602160021.AA03797@brigit.zk3.dec.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9602161557.AA02261@fwasted.zk3.dec.com> Jim wrote: >I see your points but this is revisiting some very basic decisions >whether I agree or not, and effects what is going to Proposed Standard. >I think we have had these discussions and input from many and I even >believe the wrong approach was taken, but consensus has lead us down this >path. I will also note that at the UNH bake-off many of us did not >experience any negative side affects from the way the spec is written >presently, for this particular topic. Like Jim, I am very uncomfortable with changing these basic decisions this late in the game. I don't see a concrete need for the proposed changes. >This needs much discussion. The issue is that router vendors want the >ability to not send out the link-layer address with an advertisement. Cisco's implementation will probably always include the Source Link-layer Address option in RAs, MTU permitting. Similarly, Cisco's implementation will probably always include the Prefix Information Option with all on-link prefixes (even when the DHCP bit is ON) in RAs, MTU permitting. >>As a usually 6 byte field, it is 10 bytes shorter, and as good as a 16 byte >>long IPv6 link local address based ID. > >We do not have consensus 6 bytes are enough. I am hearing some want 8? Cisco is very strongly opposed to interface tokens larger than 6 bytes (octets) and is extremely unlikely to implement any spec requiring interface tokens to be larger than 6 bytes on any lower layer technology. We need to have as much space as possible reserved for heirarchical addressing. >I don't think Hosts should be building others link-local addresses for >two reasons: > > 1) Its a bad principle for robustness, because we have not decided > yet that nodes will not create interface IDs for the bits > between the token and high order prefix length. This is for > intra-node unqiueness for the link-local address. A foreign > neighbor cannot possibly know that uniqueness for another node. > In addition for added value in implementations assuming > all bits in the link-local addresses for others is not a good > idea IMHO. Yes. > 2) We permit in ND for a router to advertise a prefix with the > LINK flag not set. This means the admin is stating the topology perhaps a typo ? perhaps "topology" should be "local policy" ? > is that hosts must go to the router to communicate with another > neighbor first. The IPv6 ND host does not really know or > can be guranteed that the prefix is onlink in this case (this > is how we permit a psuedo ES-IS model in IPv6). My fear is > if we relax our architecture to build link-local addresses > for another node, hosts will also try to build a global address > too. Not good. OK. Also, the router's link-local address could have been manually configured to be something other than what the host speculates the router's link-local should be. Nodes that try to _guess_ the link-local of other nodes are dangerous and one ought not be building them. >But presently for a neighbor or not-a-neighbor that can be determined by >the onlink prefixes in the neighbor or destination cache. If its >offlink the default router entry can be cloned (in BSD 4.4) to build the >route and per host or network routes in this case are not needed as one >implementation scenario. Yes. Alternately, the existing router entry could be cloned to create a host route (with PMTU information stored in that host route). >But I still like preferences for implementation reasons but I can't seem >to win that battle. Cisco desires to have optional preferences for Router Advertisements because real paying customers want them. I'll note that I used IPv4 RA preferences whilst at NRL to force my FDDI-homed Sun 20/71 to normally select the nearest-to-the-backbone router as the default, while being able to automatically fall back to the secondary (intra-building) router if the primary router should be down for some reason. This eliminated all the redirects for outbound traffic, which was most of my traffic, and conserved bandwidth. Customers like the RA preferences knob. Ran rja@cisco.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 11:05:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11989; Wed, 21 Feb 96 11:05:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11983; Wed, 21 Feb 96 11:04:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18618; Wed, 21 Feb 1996 11:03:27 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id LAA23894; Wed, 21 Feb 1996 11:03:27 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id UAA01211; Wed, 21 Feb 1996 20:58:30 +0200 Date: Wed, 21 Feb 1996 20:58:30 +0200 From: Juha Heinanen Message-Id: <199602211858.UAA01211@lohi.dat.tele.fi> To: rja@cisco.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199602211840.KAA24516@puli.cisco.com> (rja@cisco.com) Subject: (IPng 1434) Re: Link Local, or Global Address in Router advertisments? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Cisco is very strongly opposed to interface tokens larger than 6 bytes (octets) and is extremely unlikely to implement any spec requiring interface tokens to be larger than 6 bytes on any lower layer technology. We need to have as much space as possible reserved for heirarchical addressing. yes, the host part of the address should definitely not be longer than 6 bytes unless you want to increase the ipv6 address from 16 bytes. -- juha ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 11:05:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12001; Wed, 21 Feb 96 11:05:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11995; Wed, 21 Feb 96 11:05:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18731; Wed, 21 Feb 1996 11:04:16 -0800 Received: from puli.cisco.com by mercury.Sun.COM (Sun.COM) id LAA24114; Wed, 21 Feb 1996 11:04:18 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id LAA26106; Wed, 21 Feb 1996 11:04:17 -0800 Date: Wed, 21 Feb 1996 11:04:17 -0800 From: Ran Atkinson Message-Id: <199602211904.LAA26106@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1435) Re: Hosts processing IPv6 Source Routes In-Reply-To: <9602161610.AA24010@fwasted.zk3.dec.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9602161610.AA24010@fwasted.zk3.dec.com> you write: >Hi, > >At the UNH bake-off Steve Deering and Jack McCann while working on PMTU >spec told me that its assumed a host forwards packets to the next hop in >a source route. Rather than wait for them to bring it up. I thought I >would post the issue and see what it generates as a discussion. > >I have no problem with this behavior at all. Definitions: An IPv6 host does not forward packets. An IPv6 router forwards packets. I'd prefer that an "IPv6 host" not forward any packets. This doesn't preclude any box from being configurable as either host or router (e.g. using a knob to switch between the two). Also, I'd like to see language like the below added to the specs if not already present: "Implementations SHOULD permit the administrator to configure the system to not forward unauthenticated source-routed packets." Cisco routers already have such a knob for IPv4, added in response to strong customer demand. Unauthenticated source-routed packets are a serious security problem in practice, even on corporate networks not connected to The Internet. Ran rja@cisco.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 11:43:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12068; Wed, 21 Feb 96 11:43:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12062; Wed, 21 Feb 96 11:43:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25331; Wed, 21 Feb 1996 11:41:47 -0800 Received: from bridge2.NSD.3Com.COM by mercury.Sun.COM (Sun.COM) id LAB05369; Wed, 21 Feb 1996 11:41:46 -0800 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA02150 (5.65c/IDA-1.4.4nsd for ); Wed, 21 Feb 1996 11:41:38 -0800 Received: by jaspar.NSD.3Com.COM id AA14067 (5.65c/IDA-1.4.4-910730); Wed, 21 Feb 1996 11:41:35 -0800 From: "Cyndi M. Jung" Message-Id: <199602211941.AA14067@jaspar.NSD.3Com.COM> Subject: (IPng 1436) Re: Link Local, or Global Address in Router advertisments? To: jh@lohi.dat.tele.fi (Juha Heinanen) Date: Wed, 21 Feb 1996 11:41:34 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199602211858.UAA01211@lohi.dat.tele.fi> from "Juha Heinanen" at Feb 21, 96 08:58:30 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Cisco is very strongly opposed to interface tokens larger than 6 bytes > (octets) and is extremely unlikely to implement any spec requiring > interface tokens to be larger than 6 bytes on any lower layer technology. > > We need to have as much space as possible reserved for heirarchical > addressing. > > yes, the host part of the address should definitely not be longer than 6 > bytes unless you want to increase the ipv6 address from 16 bytes. > > -- juha 6 bytes seems reasonable. The IPv6 over PPP draft has 8 bytes - is there a special logic for the PPP link? Cyndi ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 11:59:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12091; Wed, 21 Feb 96 11:59:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12085; Wed, 21 Feb 96 11:59:24 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28651; Wed, 21 Feb 1996 11:58:07 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id LAA09931; Wed, 21 Feb 1996 11:58:06 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA08597; Wed, 21 Feb 96 14:47:41 EST Received: from karma.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA12761; Wed, 21 Feb 96 14:48:23 EST Date: Wed, 21 Feb 96 14:48:23 EST Message-Id: <9602211948.AA12761@pobox.BayNetworks.com> Received: by karma.engeast (4.1/SMI-4.1) id AA09016; Wed, 21 Feb 96 14:47:46 EST From: Mike Davis To: rja@cisco.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199602211904.LAA26106@puli.cisco.com> (message from Ran Atkinson on Wed, 21 Feb 1996 11:04:17 -0800) Subject: (IPng 1437) Re: Hosts processing IPv6 Source Routes Reply-To: mdavis@BayNetworks.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Ran Atkinson In article <9602161610.AA24010@fwasted.zk3.dec.com> you write: >Hi, > >At the UNH bake-off Steve Deering and Jack McCann while working on PMTU >spec told me that its assumed a host forwards packets to the next hop in >a source route. Rather than wait for them to bring it up. I thought I >would post the issue and see what it generates as a discussion. > >I have no problem with this behavior at all. Definitions: An IPv6 host does not forward packets. An IPv6 router forwards packets. I'd prefer that an "IPv6 host" not forward any packets. I'd like to see no change to what a host may do wrt packets, including source routed packets. They shouldn't have to become routers, and send RAs, etc., just to do so. This doesn't preclude any box from being configurable as either host or router (e.g. using a knob to switch between the two). Or a knob that says don't forward unauthenticated source routes that defaults to allow it. Also, I'd like to see language like the below added to the specs if not already present: "Implementations SHOULD permit the administrator to configure the system to not forward unauthenticated source-routed packets." They certainly should. Cisco routers already have such a knob for IPv4, added in response to strong customer demand. Unauthenticated source-routed packets are a serious security problem in practice, even on corporate networks not connected to The Internet. Ran rja@cisco.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 12:24:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12137; Wed, 21 Feb 96 12:24:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12131; Wed, 21 Feb 96 12:24:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03146; Wed, 21 Feb 1996 12:22:44 -0800 Received: from FNAL.FNAL.Gov by mercury.Sun.COM (Sun.COM) id MAA16255; Wed, 21 Feb 1996 12:22:43 -0800 Received: from munin.fnal.gov ("port 4346"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I1H84N1J7Y000WIC@FNAL.FNAL.GOV>; Wed, 21 Feb 1996 14:22:41 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id OAA04989; Wed, 21 Feb 1996 14:22:30 -0600 (CST) Date: Wed, 21 Feb 1996 14:22:30 -0600 From: Matt Crawford Subject: (IPng 1438) Re: Hosts processing IPv6 Source Routes In-Reply-To: "21 Feb 1996 14:48:23 EST." <"9602211948.AA12761"@pobox.BayNetworks.com> To: mdavis@baynetworks.com Cc: rja@cisco.com, ipng@sunroof.eng.sun.com Message-Id: <199602212022.OAA04989@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12163; Wed, 21 Feb 96 12:35:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12157; Wed, 21 Feb 96 12:34:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04923; Wed, 21 Feb 1996 12:33:28 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id MAA20004; Wed, 21 Feb 1996 12:33:22 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA11061; Wed, 21 Feb 96 15:32:31 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA15623; Wed, 21 Feb 96 15:33:17 EST Date: Wed, 21 Feb 96 15:33:17 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9602212033.AA15623@pobox.BayNetworks.com> To: cmj@NSD.3Com.COM Subject: (IPng 1439) Re: Link Local, or Global Address in Router advertisments? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > 6 bytes seems reasonable. The IPv6 over PPP draft has 8 bytes - is there a > special logic for the PPP link? > > Cyndi In the current revision of the IPv6-over-PPP draft (draft-ietf-ipngwg-pppext-ipv6cp-01.txt), it is 6 bytes. I can make it even shorter if necessary ;). Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 12:49:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12191; Wed, 21 Feb 96 12:49:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12185; Wed, 21 Feb 96 12:49:36 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07033; Wed, 21 Feb 1996 12:48:18 -0800 Received: from bridge2.NSD.3Com.COM by mercury.Sun.COM (Sun.COM) id MAA25430; Wed, 21 Feb 1996 12:48:16 -0800 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA07752 (5.65c/IDA-1.4.4nsd for ); Wed, 21 Feb 1996 12:48:11 -0800 Received: by jaspar.NSD.3Com.COM id AA14304 (5.65c/IDA-1.4.4-910730); Wed, 21 Feb 1996 12:48:09 -0800 From: "Cyndi M. Jung" Message-Id: <199602212048.AA14304@jaspar.NSD.3Com.COM> Subject: (IPng 1440) Re: Link Local, or Global Address in Router advertisments? To: dhaskin@baynetworks.com (Dimitry Haskin) Date: Wed, 21 Feb 1996 12:48:08 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9602212033.AA15623@pobox.BayNetworks.com> from "Dimitry Haskin" at Feb 21, 96 03:33:17 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > > > 6 bytes seems reasonable. The IPv6 over PPP draft has 8 bytes - is there a > > special logic for the PPP link? > > > > Cyndi > > In the current revision of the IPv6-over-PPP draft > (draft-ietf-ipngwg-pppext-ipv6cp-01.txt), it is 6 bytes. > I can make it even shorter if necessary ;). > > Dimitry > I don't know that shorter is better - if the same interface token is to be used in other sorts of addresses (not the link-local), then those 16 bits the IPv6 over PPP just gave up would typically be a subnet-id - at least in many of the addressing schemes I've seen so far. Truly, on a PPP link, only 1 bit is required to distinguish the two ends from each other, and if there were a simple way for the two ends to predictably assign the value of that bit it would be nice. But there is value in keeping the structure of a Prefix the same throughout a domain, so shorter host fields on PPP links doesn't buy anything. Cyndi ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 18:03:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12521; Wed, 21 Feb 96 18:03:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12515; Wed, 21 Feb 96 18:03:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27093; Wed, 21 Feb 1996 18:01:58 -0800 Received: from brookfield.ans.net by mercury.Sun.COM (Sun.COM) id SAA10792; Wed, 21 Feb 1996 18:01:57 -0800 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id UAA12399; Wed, 21 Feb 1996 20:05:42 -0500 Message-Id: <199602220105.UAA12399@brookfield.ans.net> To: "Forrest W. Christian" Cc: ipng@sunroof.eng.sun.com, Curtis Villamizar , Bryan Byers , "'cidrd@iepg.org'" Reply-To: curtis@ans.net Subject: (IPng 1441) Re: Routing and IPv6 In-Reply-To: Your message of "Tue, 20 Feb 1996 14:30:03 MST." Date: Wed, 21 Feb 1996 20:03:00 -0500 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , "Forrest W. Christian" writes: > --- cc'd to the ipng list > > On Tue, 20 Feb 1996, Curtis Villamizar wrote: > > > What you are describing is an addressing scheme with fixed aggregation > > boundaries. We had an addressing scheme with fixed aggregation > > boundaries, class A, B, C. It proved inadequate. We are a step > > beyond that with arbitrary aggregation boundaries within the > > addressing space. > > No, I'm not describing a scheme with fixed aggregation boundaries, at > least in the manner. I'm describing a scheme in which that the upper bits > are TOTALLY AND COMPLETELY Separate from the LOWER BITS. How are the upper and lower bits of a old style class B route not completely separated? > Lets jump back to IPv4 here for a minute, and let me use an example, > making a couple assumptions. (forget that this will never happen to the > IPv4 header) Assume that Everyone KEEPS Their existing numbers. In the > IPv4 header, assume that an "ASN" field is added. When the IPv4 packet > is originated the ASN of the destination is added to the packet. Now, > the backbone routers only need to know how to forward to the specific > ASN. Last time I checked that was about 2000 ASN's. If you move ASN's, > the ASN which is inserted changes, but your Existing address doesn't. Can we call it the network part. And call the rest the host part? > Of course it's slightly more complex than that. There's the necessity > for the ASN lookup, some issues over protocols which incorporate IP > addresses into them, etc. Aren't we just either extending the address space by 16 bits or reinventing IPAE? With this scheme, if I send a packet to 10.0.0.1 how does an AS number get attached? If the ASN is specified, you've extended the address space. If it gets added on at an encapsulating gateway you've reinvented IPAE only using a 16 bit address that can't be aggregated instead of a 32 bit one that can. > What I was asking is if there was any disucssion for doing > something like this under the ipv6 structure. There is noting like this > in the drafts I've read, but I haven't read the current portability draft. > > I have dropped my original note into the ipng list. So far I haven't > heard anything back, other than "you haven't read the drafts". Well > Either I'm not reading the same drafts that everyone else is, or this > isn't mentioned. This looks to me like it is either longer addresses or it is IPAE all over again. > > Hope this helps you understand the issues. Now read the draft! :-) > > If there's a draft I've missed I'd love to. Might be my mistake. I got this thread crossed with the CIDRD last call discussion. If this wasn't in response to that discussion then I appologize as this would have been rude on my part. > -forrestc@imach.com Regards, Curtis ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 20:13:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12596; Wed, 21 Feb 96 20:13:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12590; Wed, 21 Feb 96 20:13:29 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07174; Wed, 21 Feb 1996 20:12:11 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id UAA28763; Wed, 21 Feb 1996 20:12:11 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA32473; Wed, 21 Feb 1996 23:04:38 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA25017; Wed, 21 Feb 1996 23:04:38 -0500 Message-Id: <9602220404.AA25017@fwasted.zk3.dec.com> To: John Gardiner Myers Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1442) Re: setsockopt() stuff In-Reply-To: Your message of "Tue, 20 Feb 96 19:14:02 EST." <8l_aD_G00WBw812INw@andrew.cmu.edu> Date: Wed, 21 Feb 96 23:04:38 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >There are two potential race conditions. The less important one is if >there are two independent processes (threads, code sections, whatever) >sharing a single socket, each of which wants a different value of, >say, IPV6_RECVIF, there is no way one can atomically set the option >and receive a packet. The two processes would have to agree on some >locking mechanism to protect the critical section between the >setsockopt() and recvfrom(). > >The one I'm concerned about is the one where a packet is recieved >before setsockopt() is called to set one of these options before >receiving a packet. What this effectively means is that the >application must either set all of the relevant socket options before >calling bind(). The API document does not state that the applications >have this requirement. > >Furthermore, the requirement to call setsockopt() before bind() may >not be practical. The bind() call may be performed by some >independent subsystem, such as inetd, which hands the application a >socket with a packet already queued up to be received. Thanks John, that was VERY useful. We have to consider this for sure. >> I can see this as a way to do v6 functions, but it will break a goal in the >> spec. Compatibility with the existing functions. This is deemed >> important to applications most effective portability. If we did head >> down this path then there are other parts in the spec that need to do >> that too (e.g. hostname2addr() ---> gethostbyname2()). >Defining new functions with expanded functionality has been done >numerous times in the past. There's wait(), wait3(), wait4(), and >waitpid(). Defining waitpid() does not break compatibility with >wait(). >Similarly, defining hostname2addr() does not break gethostbyaddr(), >and there's no compelling reason to call hostname2addr() >gethostbyaddr2(). We have had input from one person they would like to see it this way for consistency like wait(), wait1(), wait2() ....... >Defining a function that is like accept() but takes an additional >flags argument will not break accept() as long as it is named >something other than "accept". For simplicity, accept() could then be >written in terms of the new function. True. >Applications are going to need to be changed anyway in order to deal >with the new IPv6 address data types. To me, the simplest and most >obvious approach to back portability would be to write the application >to use the IPv6 data types and functions, then use a compatibility >library with stub header files and functions for those systems which >only have IPv4. The compatibility functions would only deal with and >return IPv4-mapped addresses and so on. As long as the IPv6 API is a >functional superset of the IPv4 one and as long as the API can say >"no, can't do that" when appropriate, this won't be a problem. I agree with you. In fact some circles believe we can permit old applications to use IPv6 without porting to the new sockets. I have many concerns about this mostly creating shims that we will live with forever. >> Why would we make anything for IPv6 protocol un-specific? Please >> explain your reasoning and motive. >Concepts such as source routes and interfaces are not specific to >IPv6. It would be reasonable to permit implementations of other >protocols, such as IPv4, to give the applications access to this >information. Not sure at my end if that is really possible or a dream. I see people trying to do this everywhere. We did it successfully I think with IPSEC and DNSIND, but that does not mean it can be done successfully in all cases. I never want to sacrifice IPv6 technology to remain compatible with IPv4. I can't take it. >Put another way, options such as IPV6_RECVSRCRT affect the behavior of >the API, not the behavior of the protocol. They should be made >protocol un-specific to permit their movement closer to the API >functions that they affect. THis is a good "systems" argument. >> But I agree its bogus. I have tried to fight to have all source routes >> and options for that matter be part of the msg_control flags for source >> routes, security notificiaton, flows, etc. >Sounds like a good idea to me. Simple, fairly straightforward, and >doesn't require some independent subsystem, such as inetd, to actively >cooperate in order for an application to get the data. Yes there is a ground swell of implementors I am trying to get to agree with me. >> I lost this battle and have given up. I >> believe when it gets to POSIX, WINSOCK, and X/Open it will all get >> revisited to some degree. But right now we are trying to get a minimal >> stable API for implementations. >Pity. Regardless of what others do, I fear that the minimal API is >going to be the lowest common denominator that all of us applications >folks will have to write to in order to be portable. Like I said people need to chime in here. Anything I work on I want to be useful. We need to hear from people if we want to extend our vision of this API. I would like to for sure. But I am not hearing a lot of folks (who even complained) jumping in here. So if consensus is the minimal then thats what the Info RFC for this iteration of the API. Personally I will go work on this out of the IETF where the group is totally focused on APIs like POSIX .12. But I would like to do it here and give them a working and useful API from within the IETF. >On another topic, I'd like to review the proposed security API, but I >can't find any such draft. There is not one. There is an old one Dan McDonald did out there but it needs a lot of work. I think we need to get the sockets where we want them first as a priority. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 20:22:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12608; Wed, 21 Feb 96 20:22:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12602; Wed, 21 Feb 96 20:22:16 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07825; Wed, 21 Feb 1996 20:20:58 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id UAA29912; Wed, 21 Feb 1996 20:20:58 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA15190; Wed, 21 Feb 1996 23:16:38 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA10186; Wed, 21 Feb 1996 23:16:32 -0500 Message-Id: <9602220416.AA10186@fwasted.zk3.dec.com> To: iialan@iifeak.swan.ac.uk (Alan Cox) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1443) Re: Thoughts on DNS and API In-Reply-To: Your message of "Wed, 21 Feb 96 08:24:43 GMT." Date: Wed, 21 Feb 96 23:16:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alan, I agree with you that we need implementations to exist. We have about 13 right now. But what will really move the API for IPv6 is when the vendors believe that its stable enough to offer Advanced Developer IPv6 Kits to their ISVs and can say go for it people see if you can port to IPv6. So doing it minimally and then changing it is not a good business strategy. So unless all will roll up their sleeves and get the necessary input to the API authors and beat this API to death that will not happen in the IETF. I can't see an API holding up IPv6 in the market so will support the work being moved to POSIX .12 and X/Open and trying to get it "fast tracked", with other folks on this list who are also on this list. Using 4.4 msg_control field is a way to address many of John's (CMU) issues as one example. Like you said we are close. But, close only counts in horse shoes game. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 21:12:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12665; Wed, 21 Feb 96 21:12:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12659; Wed, 21 Feb 96 21:12:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10688; Wed, 21 Feb 1996 21:10:52 -0800 Received: from mail12.digital.com by mercury.Sun.COM (Sun.COM) id VAA06037; Wed, 21 Feb 1996 21:10:52 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA14179; Thu, 22 Feb 1996 00:07:11 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA02795; Thu, 22 Feb 1996 00:07:10 -0500 Message-Id: <9602220507.AA02795@fwasted.zk3.dec.com> To: "Cyndi M. Jung" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1444) Re: Link Local, or Global Address in Router advertisments? In-Reply-To: Your message of "Wed, 21 Feb 96 12:48:08 PST." <199602212048.AA14304@jaspar.NSD.3Com.COM> Date: Thu, 22 Feb 96 00:07:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Cyndi, I am hearing some in the ATM Forum want at least 8 bytes. Other than ATM I could agree to 6 bytes. I can't find any medium that needs more than 6 though other than ATM. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 23:14:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12736; Wed, 21 Feb 96 23:14:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12730; Wed, 21 Feb 96 23:13:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18188; Wed, 21 Feb 1996 23:12:33 -0800 Received: from lohi.dat.tele.fi by mercury.Sun.COM (Sun.COM) id XAA18662; Wed, 21 Feb 1996 23:12:32 -0800 Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id JAA05362; Thu, 22 Feb 1996 09:00:52 +0200 Date: Thu, 22 Feb 1996 09:00:52 +0200 From: Juha Heinanen Message-Id: <199602220700.JAA05362@lohi.dat.tele.fi> To: bound@zk3.dec.com Cc: cmj@NSD.3Com.COM, ipng@sunroof.eng.sun.com In-Reply-To: <9602220507.AA02795@fwasted.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng 1445) Re: Link Local, or Global Address in Router advertisments? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am hearing some in the ATM Forum want at least 8 bytes. Other than ATM I could agree to 6 bytes. I can't find any medium that needs more than 6 though other than ATM. i'm "in the atm forum" as well as anyone else and definitely don't want to have more than 6 bytes. further, as far as i know, the atm forum has never even discussed this matter in any of its working groups. if atm forum wants something, then they will send a liaison to ietf about the matter. these things don't happen via rumors. if someone wants more (and i haven't heard of any) he better come up with very good arguments to do so. there simple isn't so much space in the ipv6 address thanm one could sonsume 8 bytes for the host id. -- juha ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 21 23:42:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12752; Wed, 21 Feb 96 23:42:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12746; Wed, 21 Feb 96 23:42:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19786; Wed, 21 Feb 1996 23:40:58 -0800 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id XAA21279; Wed, 21 Feb 1996 23:40:57 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA07069; Thu, 22 Feb 1996 08:40:55 +0100 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA05409; Thu, 22 Feb 1996 08:40:54 +0100 Message-Id: <9602220740.AA05409@dxcoms.cern.ch> Subject: (IPng 1446) Re: Link Local, or Global Address in Router advertisments? To: ipng@sunroof.eng.sun.com Date: Thu, 22 Feb 1996 08:40:54 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199602220700.JAA05362@lohi.dat.tele.fi> from "Juha Heinanen" at Feb 22, 96 09:00:52 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Surely the only way you can get to need more than 48 bits is by (hold your breath) using a BCD-encoded ISDN number as the token, i.e. an E.164 address, a.k.a. a 16 digit telephone number. In which case we are in a different part of the universe, and all or most bets are off. I really think we should put this aside and make progress based on 6 byte tokens. Brian Carpenter >--------- Text sent by Juha Heinanen follows: > > I am hearing some in the ATM Forum want at least 8 bytes. Other than > ATM I could agree to 6 bytes. I can't find any medium that needs more > than 6 though other than ATM. > > i'm "in the atm forum" as well as anyone else and definitely don't want > to have more than 6 bytes. further, as far as i know, the atm forum has > never even discussed this matter in any of its working groups. if atm > forum wants something, then they will send a liaison to ietf about the > matter. these things don't happen via rumors. if someone wants more > (and i haven't heard of any) he better come up with very good arguments > to do so. there simple isn't so much space in the ipv6 address thanm > one could sonsume 8 bytes for the host id. > > -- juha > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 22 05:21:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12928; Thu, 22 Feb 96 05:21:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12922; Thu, 22 Feb 96 05:21:15 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05528; Thu, 22 Feb 1996 05:19:55 -0800 Received: from basil.cdt.luth.se by mercury.Sun.COM (Sun.COM) id FAA25573; Thu, 22 Feb 1996 05:19:55 -0800 Received: from my8.sm.luth.se (my8.sm.luth.se [130.240.3.38]) by basil.cdt.luth.se (8.6.12/8.6.12) with ESMTP id OAA05992 for ; Thu, 22 Feb 1996 14:19:14 +0100 From: Mikael Degermark Received: from my8 (localhost [127.0.0.1]) by my8.sm.luth.se (8.6.12/8.6.12) with ESMTP id OAA08025 for ; Thu, 22 Feb 1996 14:21:17 +0100 Date: Thu, 22 Feb 1996 14:21:17 +0100 Message-Id: <199602221321.OAA08025@my8.sm.luth.se> Prev-Resent: Wed, 21 Feb 1996 16:34:30 +0100 Prev-Resent: steve@sics.se Apparently-To: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From - Wed Feb 21 12: 04:04 1996 Received: from IETF.cnri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by my28.sm.luth.se (8.7.2/8.7.2) with SMTP id MAA29491; Wed, 21 Feb 1996 12:03:59 +0100 (MET) Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21326; 20 Feb 96 10:57 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa20364; 20 Feb 96 10:45 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-degermark-ipv6-hc-00.txt Date: Tue, 20 Feb 96 10:45:09 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9602201045.aa20364@IETF.CNRI.Reston.VA.US> Resent-To: ipng@sunroof.eng.sun.com Resent-Date: Thu, 22 Feb 1996 14:21:16 +0100 Resent-From: Mikael Degermark --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Header Compression for IPv6 Author(s) : M. Degermark, B. Nordgren, S. Pink Filename : draft-degermark-ipv6-hc-00.txt Pages : 44 Date : 02/19/1996 This document describes how to compress IPv6 headers over point-to-point links. The method can be applied to IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers. A typical IPv6 header can be compressed down to 3-5 octets, including a 2 octet transport layer checksum. 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-degermark-ipv6-hc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-degermark-ipv6-hc-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-degermark-ipv6-hc-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960219100148.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-degermark-ipv6-hc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-degermark-ipv6-hc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960219100148.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 22 06:20:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13002; Thu, 22 Feb 96 06:20:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12996; Thu, 22 Feb 96 06:20:24 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08979; Thu, 22 Feb 1996 06:19:06 -0800 Received: from thumper.bellcore.com by mercury.Sun.COM (Sun.COM) id GAA04080; Thu, 22 Feb 1996 06:19:05 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id JAA15461; Thu, 22 Feb 1996 09:11:09 -0500 Message-Id: <199602221411.JAA15461@thumper.bellcore.com> To: Juha Heinanen Cc: bound@zk3.dec.com, cmj@nsd.3com.com, ipng@sunroof.eng.sun.com, gja@thumper.bellcore.com Subject: (IPng 1447) Re: Link Local, or Global Address in Router advertisments? In-Reply-To: Your message of Thu, 22 Feb 1996 09:00:52 +0200. <199602220700.JAA05362@lohi.dat.tele.fi> Date: Thu, 22 Feb 1996 09:11:02 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I am hearing some in the ATM Forum want at least 8 bytes. Other than >> ATM I could agree to 6 bytes. I can't find any medium that needs more >> than 6 though other than ATM. >> >>i'm "in the atm forum" as well as anyone else and definitely don't want >>to have more than 6 bytes. further, as far as i know, the atm forum has >>never even discussed this matter in any of its working groups. I'd have to agree with juha here - tha ATM Forum per se has not discussed this issue. As far as I can tell the 8 octet token idea was my fault - it originated in the first I-D I wrote to provoke working group activity on IPv6 over ATM (draft-ietf-ipatm-ipv6nd-00.txt). The idea had noted limitations, and newer solutions now exist (notably draft-ahl-ipv6-nbma-00.txt, which I suggest people read before the LA meeting). So, independent of the (de)merits of the 8 octet token, we can't blame the ATM Forum (for once ;-) cheers, gja ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 22 06:28:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13022; Thu, 22 Feb 96 06:28:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13016; Thu, 22 Feb 96 06:28:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09479; Thu, 22 Feb 1996 06:27:12 -0800 Received: from IETF.cnri.reston.VA.US by mercury.Sun.COM (Sun.COM) id GAA05568; Thu, 22 Feb 1996 06:27:09 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa19380; 22 Feb 96 9:22 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1448) I-D ACTION:draft-ietf-ipngwg-pmtuv6-01.txt Date: Thu, 22 Feb 96 09:22:36 -0500 Message-Id: <9602220922.aa19380@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Path MTU Discovery for IP version 6 Author(s) : J. McCann, S. Deering Filename : draft-ietf-ipngwg-pmtuv6-01.txt Pages : 16 Date : 02/21/1996 This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC-1191, which describes Path MTU Discovery for IP version 4. 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-pmtuv6-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-pmtuv6-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-pmtuv6-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960221124915.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-pmtuv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-pmtuv6-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960221124915.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 22 07:06:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13079; Thu, 22 Feb 96 07:06:14 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13073; Thu, 22 Feb 96 07:06:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12263; Thu, 22 Feb 1996 07:04:45 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id HAA13590; Thu, 22 Feb 1996 07:04:44 -0800 Received: from btlaser.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA05643; Thu, 22 Feb 1996 09:56:19 -0500 Received: by tlaser.zk3.dec.com; (5.65v3.2/1.1.8.2/06Mar95-1016AM) id AA08376; Thu, 22 Feb 1996 09:56:18 -0500 Date: Thu, 22 Feb 1996 09:56:18 -0500 From: Jack McCann USG Message-Id: <9602221456.AA08376@tlaser.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1449) updated Path MTU spec is now available Cc: mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk An updated version of the path mtu discovery spec for IPv6 is now available. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-pmtuv6-01.txt This draft incorporates the changes discussed at Dallas IETF as well as comments received via the mailing list and a couple of lessons from the UNH bakeoff. Changes from draft-ietf-ipngwg-pmtuv6-00.txt: - added terminology section - clarified the definition of a path - added discussion about local representation of a path - added paragraph on applicability to multicast - added note about Packet Too Big messages containing MTU values less than the IPv6 minimum link MTU - added note about Packet Too Big messages where the original packet contained a Routing header - removed references to routes, routing tables, and routing table entries - minor edits - added appendix comparison to RFC 1191 - welcome Jeff Mogul (co-author of rfc 1191) as co-author Comments welcome. - Jack ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 22 10:15:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13209; Thu, 22 Feb 96 10:15:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13203; Thu, 22 Feb 96 10:15:34 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08033; Thu, 22 Feb 1996 10:14:13 -0800 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id KAA01900; Thu, 22 Feb 1996 10:14:09 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id TAA08226; Thu, 22 Feb 1996 19:14:02 +0100 (MET) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id TAA26992; Thu, 22 Feb 1996 19:14:00 +0100 Message-Id: <199602221814.TAA26992@givry.inria.fr> From: Francis Dupont To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1450) Re: Link Local, or Global Address in Router advertisments? In-Reply-To: Your message of Wed, 21 Feb 1996 10:40:30 PST. <199602211840.KAA24516@puli.cisco.com> Date: Thu, 22 Feb 1996 19:13:48 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >But I still like preferences for implementation reasons but I can't seem >to win that battle. Cisco desires to have optional preferences for Router Advertisements because real paying customers want them. I'll note that I used IPv4 RA preferences whilst at NRL to force my FDDI-homed Sun 20/71 to normally select the nearest-to-the-backbone router as the default, while being able to automatically fall back to the secondary (intra-building) router if the primary router should be down for some reason. This eliminated all the redirects for outbound traffic, which was most of my traffic, and conserved bandwidth. Customers like the RA preferences knob. => I suppose there are "real paying customers" on the list then I suggest they shout if they want to get optional preferences! (we lost the battle not the war :-) Francis.Dupont@inria.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 Thu Feb 22 10:35:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13238; Thu, 22 Feb 96 10:35:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13232; Thu, 22 Feb 96 10:35:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11850; Thu, 22 Feb 1996 10:34:08 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id KAA08198; Thu, 22 Feb 1996 10:34:09 -0800 Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA18637; Thu, 22 Feb 96 13:32:11 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA01553; Thu, 22 Feb 96 13:32:55 EST Date: Thu, 22 Feb 96 13:32:55 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9602221832.AA01553@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com, rolc@nexen.com, ip-atm@nexen.com Subject: (IPng 1451) Re: I-D ACTION:draft-ahl-ipv6-nbma-00.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Begin Included Message ----- From ietf-announce-request@IETF.CNRI.Reston.VA.US Tue Feb 20 19:20:03 1996 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@IETF.CNRI.Reston.VA.US Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ahl-ipv6-nbma-00.txt Date: Tue, 20 Feb 96 10:45:58 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Content-Length: 3512 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 over NBMA Networks Author(s) : R. Atkinson, D. Haskin, J. Luciani Filename : draft-ahl-ipv6-nbma-00.txt Pages : 14 Date : 02/19/1996 This draft proposes an approach to IPv6 over Non-Broadcast Multiple Access (NBMA) technologies that maximises reuse of existing technology and should work equally well over Frame Relay, ATM, and other NBMA technologies. 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-ahl-ipv6-nbma-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ahl-ipv6-nbma-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ahl-ipv6-nbma-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960219105334.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ahl-ipv6-nbma-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ahl-ipv6-nbma-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960219105334.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ----- End Included Message ----- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 22 11:00:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13273; Thu, 22 Feb 96 11:00:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13267; Thu, 22 Feb 96 11:00:00 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16172; Thu, 22 Feb 1996 10:58:39 -0800 Received: from mail11.digital.com by mercury.Sun.COM (Sun.COM) id KAA22151; Thu, 22 Feb 1996 10:58:41 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA11527; Thu, 22 Feb 1996 13:45:38 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA01528; Thu, 22 Feb 1996 13:45:36 -0500 Message-Id: <9602221845.AA01528@fwasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1452) Re: Link Local, or Global Address in Router advertisments? In-Reply-To: Your message of "Thu, 22 Feb 96 08:40:54 +0100." <9602220740.AA05409@dxcoms.cern.ch> Date: Thu, 22 Feb 96 13:45:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am not wedded to > 6 bytes. But want to make sure we don't have to revisit this again. /jiM ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 22 13:07:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13373; Thu, 22 Feb 96 13:07:33 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13367; Thu, 22 Feb 96 13:07:17 PST Received: from everglade ([192.9.213.1]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id NAA00397; Thu, 22 Feb 1996 13:05:01 -0800 (PST) Date: Thu, 22 Feb 1996 13:08:16 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1453) Re: setsockopt() stuff To: John Gardiner Myers Cc: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There are two potential race conditions. . . . The one I'm concerned > about is the one where a packet is recieved before setsockopt() is > called to set one of these options before receiving a packet. What > this effectively means is that the application must either set all of > the relevant socket options before calling bind(). The API document > does not state that the applications have this requirement. I'm not convinced this is such a serious problem. You have already pointed out that applications can solve the problem themselves by enabling the options they are interested in immediately after the socket() call. i.e. the pattern of function calls looks like this: s = socket(PF_INET6, SOCK_DGRAM, 0); if (setsockopt(s, IPPROTO_IPV6, IPV6_RECVSRCRT, (char *) &on, sizeof(on)) == -1) . . . if (bind(s, . . .) == -1) . . . recvfrom(s, . . .) I don't think this counter-argument is valid: > Furthermore, the requirement to call setsockopt() before bind() may > not be practical. The bind() call may be performed by some > independent subsystem, such as inetd, which hands the application a > socket with a packet already queued up to be received. since it could be addressed by simply adding more configuration information to the inetd.conf config file (e.g. add a field to specify which options to enable per-service). In any case, as Rich Stevens points out, this is a generic problem for the socket interface, so it seems to me any solution should be done generically, for all protocols supported by the socket interface. I think that puts this problem outside the scope of our IPv6 API spec. Perhaps the Posix group should look at this problem? I do agree that system documentation should point out this issue, and that the API spec should point out the problem too. I'll add some discussion of this problem to the next revision of the API spec. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 22 13:39:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13399; Thu, 22 Feb 96 13:39:10 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13393; Thu, 22 Feb 96 13:38:53 PST Received: from everglade ([192.9.213.1]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id NAA01483; Thu, 22 Feb 1996 13:36:39 -0800 (PST) Date: Thu, 22 Feb 1996 13:39:52 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1454) Re: Thoughts on DNS and API To: John Gardiner Myers Cc: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If you're going for simple, how about removing the IPV6_RECVSRCRT, > IPV6_RECVIF, and IPV6_SENDIF options entirely? Act like they're > always set. > > When receiving an address, if there is room for two or more addresses, > make the Nth one the receiving interface address and the second > through N-1'th address as much of the source route as will fit. If > there's only room for one address, the API would only fill in the > endpoint address. I think there is a performance issue here. Presumably, IP must exert some CPU cycles to pull the addresses of the source route out of the received packet and place them into a buffer to pass back to the user. If we design the API so that IP must *always* do that work for every received packet, then every application will pay the performance penalty, even if it does not need the functionality. Certainly lots of IPv6 applications will need to receive the source route and receiving interface information. But other applications will not. Consider "receive-only" applications such as a "stock ticker." It receives stock quotes in UDP packets and displays them on the user's screen. Since it never generates replies, it never needs to know what the source route or receiving interface were. > When sending an address, if there are two or more addresses supplied, > the Nth one is the sending interface and the rest are the source > route. A sending interface address of INADDR_ANY would specify that > the sender doesn't care which interface it goes out. I think this is a reasonable suggestion. Eliminating the IPV6_SENDIF option and implmenting the algorithm you suggest does not have the same performance probmlems as the receiving side, and probably makes the API simpler for the programmer. What do others think? Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 22 14:21:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13424; Thu, 22 Feb 96 14:21:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13418; Thu, 22 Feb 96 14:21:18 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18634; Thu, 22 Feb 1996 14:19:59 -0800 Received: from po10.andrew.cmu.edu by mercury.Sun.COM (Sun.COM) id OAA16751; Thu, 22 Feb 1996 14:19:58 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.3/8.7.1) id RAA00851 for ipng@sunroof.Eng.Sun.COM; Thu, 22 Feb 1996 17:19:56 -0500 Received: via switchmail; Thu, 22 Feb 1996 17:19:54 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 22 Feb 1996 17:19:09 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 22 Feb 1996 17:19:07 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 22 Feb 1996 17:19:05 -0500 (EST) Message-Id: Date: Thu, 22 Feb 1996 17:19:05 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1455) Re: Thoughts on DNS and API In-Reply-To: References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Gilligan writes: > I think there is a performance issue here. Presumably, IP must exert > some CPU cycles to pull the addresses of the source route out of the > received packet and place them into a buffer to pass back to the user. > [...] > Consider "receive-only" applications such as a "stock > ticker." [...] Since it never generates replies, it never needs > to know what the source route or receiving interface were. Such applications don't need the sender endpoint address either. Thus having the IP layer exert cycles to pulling the endpoint address out for passing to the application is similar performance issue. Does that mean we should add an option to suppress the saving of sender endpoint addresses? Is the (likely miniscule) performance gained by having the options worth the additional complexity, including the need to add more information (which is likely to be configured wrong anyway) to such things as inetd.conf. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 22 16:45:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13534; Thu, 22 Feb 96 16:45:19 PST Received: from caribe.eng.sun.com (caribe-86) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13528; Thu, 22 Feb 96 16:45:03 PST Received: from everglade ([192.9.213.1]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id QAA07843; Thu, 22 Feb 1996 16:42:42 -0800 (PST) Date: Thu, 22 Feb 1996 16:45:56 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1456) Re: Thoughts on DNS and API To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > When sending an address, if there are two or more addresses supplied, > > > the Nth one is the sending interface and the rest are the source > > > route. A sending interface address of INADDR_ANY would specify that > > > the sender doesn't care which interface it goes out. > > > > I think this is a reasonable suggestion. Eliminating the IPV6_SENDIF option > > and implmenting the algorithm you suggest does not have the same performance > > probmlems as the receiving side, and probably makes the API simpler for the > > programmer. What do others think? > > I would prefer that if we are going to have options like these that they > remain explicit. Explicit options are bad enough, we don't need implicit > ones as well. Just so I understand what your preference is here, are you saying that you would prefer to keep the IPV6_SENDIF option as currently described in the API spec? Sending a packet with a source route in the current API spec is "implicit" (i.e. you just present an address array with two or more addresses in the "to" field of the sendto() call), but sending a packet with sending interface specified is "explicit" (i.e. you have to enable the option first). What John was suggesting and I was picking up on was that the two could be combined and made both "implicit" (i.e. application does not have to enable any option to send a packet with a source route or sending interface specified; the kernel figures out what you ment based on the number of address structures you provide.). Could you clarify what is "bad" about the implicit approach? Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 22 16:54:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13567; Thu, 22 Feb 96 16:54:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13561; Thu, 22 Feb 96 16:54:30 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11351; Thu, 22 Feb 1996 16:53:08 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id QAA17745; Thu, 22 Feb 1996 16:52:55 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA07916; Thu, 22 Feb 96 14:59:33 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA00996; Thu, 22 Feb 1996 15:00:03 -0800 Date: Thu, 22 Feb 1996 15:00:03 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9602222300.AA00996@feller.mentat.com> To: Bob.Gilligan@Eng Subject: (IPng 1457) Re: Thoughts on DNS and API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > When sending an address, if there are two or more addresses supplied, > > the Nth one is the sending interface and the rest are the source > > route. A sending interface address of INADDR_ANY would specify that > > the sender doesn't care which interface it goes out. > > I think this is a reasonable suggestion. Eliminating the IPV6_SENDIF option > and implmenting the algorithm you suggest does not have the same performance > probmlems as the receiving side, and probably makes the API simpler for the > programmer. What do others think? I would prefer that if we are going to have options like these that they remain explicit. Explicit options are bad enough, we don't need implicit ones as well. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 22 17:48:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13633; Thu, 22 Feb 96 17:48:14 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13627; Thu, 22 Feb 96 17:47:58 PST Received: from everglade ([192.9.213.1]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id RAA10690; Thu, 22 Feb 1996 17:45:44 -0800 (PST) Date: Thu, 22 Feb 1996 17:48:58 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1458) Re: Thoughts on DNS and API To: John Gardiner Myers Cc: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I think there is a performance issue here. Presumably, IP must exert > > some CPU cycles to pull the addresses of the source route out of the > > received packet and place them into a buffer to pass back to the user. > > [...] > > Consider "receive-only" applications such as a "stock > > ticker." [...] Since it never generates replies, it never needs > > to know what the source route or receiving interface were. > > Such applications don't need the sender endpoint address either. Thus > having the IP layer exert cycles to pulling the endpoint address out > for passing to the application is similar performance issue. Does > that mean we should add an option to suppress the saving of sender > endpoint addresses? > > Is the (likely miniscule) performance gained by having the options > worth the additional complexity, including the need to add more > information (which is likely to be configured wrong anyway) to such > things as inetd.conf. Well, I don't think we can just brush off a performance concern that would affect every received UDP packet. We have been spending alot of effort to design IPv6 to allow high-performance implementations. More generally, how we design the API has alot to do with the common case. We design the base API for the common case, and relegate the uncommon cases to options. In IPv4, the vast majority of applications want to know the source IP address of a received UDP packet (even receive-only applications use the source addr for logging), so returning that information is the default and no one ever bothered to implement an option to disable it. I think we are having problems because we don't really have a clear idea what the common case will be for IPv6 applications. If 95 percent of IPv6 applications are going to need to receive source routes, then it should be the default; if only 5 percent will, then it should be an option. I think there are actually three alternative designs here: 1) Source route and receiving interface NOT returned by default; application may ENABLE reception via option. 2) Source route and receiving interface ARE returned by default; application may DISABLE reception via option. 3) Source route and receiving interface ARE returned always; no way to disable it. (With both 2 and 3, I think applications could "ignore" the source route and receiving interface by supplying a single-element address array to the "from" argument.) My sense is that few applications will need to receive source routes, so option (1) is the best approach. But if there is general consensus in the group that receiving source routes and interface will be common in applications, then (2) would be the best choice. What does the rest of the group think? Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 22 19:42:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13678; Thu, 22 Feb 96 19:42:22 PST Received: from caribe.eng.sun.com (caribe-86) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13672; Thu, 22 Feb 96 19:42:06 PST Received: from vallejo.eng.sun.com (vallejo [129.146.86.131]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id TAA12435; Thu, 22 Feb 1996 19:39:54 -0800 (PST) Received: by vallejo.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA24453; Thu, 22 Feb 1996 19:40:41 -0800 Date: Thu, 22 Feb 1996 19:40:41 -0800 From: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Message-Id: <199602230340.TAA24453@vallejo.eng.sun.com> To: rja@cisco.com Subject: (IPng 1459) Re: Hosts processing IPv6 Source Routes 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 > Definitions: > An IPv6 host does not forward packets. > An IPv6 router forwards packets. Your definitions are inconsistent with the text in the IPv6 spec which says: router - a node that forwards IPv6 packets not explicitly addressed to itself. host - any node that is not a router. Thus by definition a host can forward packets that are explicitely addressed to it e.g. by listing the host's address in a source route. 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 Thu Feb 22 19:44:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13690; Thu, 22 Feb 96 19:44:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13684; Thu, 22 Feb 96 19:43:58 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03897; Thu, 22 Feb 1996 19:42:39 -0800 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id TAA20701; Thu, 22 Feb 1996 19:42:39 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA11729; Thu, 22 Feb 96 19:41:35 PST Received: by feller.mentat.com (5.x/SMI-SVR4) id AA01073; Thu, 22 Feb 1996 19:42:04 -0800 Date: Thu, 22 Feb 1996 19:42:04 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9602230342.AA01073@feller.mentat.com> To: Bob.Gilligan@Eng Subject: (IPng 1460) Re: Thoughts on DNS and API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > I would prefer that if we are going to have options like these that they > > remain explicit. Explicit options are bad enough, we don't need implicit > > ones as well. > > Just so I understand what your preference is here, are you saying that you > would prefer to keep the IPV6_SENDIF option as currently described in the API > spec? Sending a packet with a source route in the current API spec is > "implicit" (i.e. you just present an address array with two or more addresses > in the "to" field of the sendto() call), but sending a packet with sending > interface specified is "explicit" (i.e. you have to enable the option first). > What John was suggesting and I was picking up on was that the two could be > combined and made both "implicit" (i.e. application does not have to enable > any option to send a packet with a source route or sending interface > specified; the kernel figures out what you ment based on the number of address > structures you provide.). Yes, it is certainly true that the sending of source routing is implicit in the current draft. If it were my draft I would have an IPV6_SENDSRCRT option or more likely I would use the sendmsg approach for sending source routes which has been mentioned on this list previous- ly. > > Could you clarify what is "bad" about the implicit approach? > It is not really clear that the implicit approach is "bad" in the same way that train wrecks are "bad". I have a general dislike for options and options processing. I believe that if the option (any option) is explicit then it will be easier to make only those applications which use the option pay the cost. Also, maybe I missed something in the previous discussion about this (it would not be the first time), but lets say I have a sendto call which passes an address buffer (buf) of size 5 * sizeof(struct sockaddr_- in6). Without the IPV6_SENDIF option how does the kernel know whether ((struct sockaddr_in6 *)buf)[4] is the sending interface address or the last address of a source route? It seems ambiguous. I may not always want to specify the the sending interface when I am sending source routes. The implicit approach seems to force me to do so. Am I making sense? Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 23 09:24:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13954; Fri, 23 Feb 96 09:24:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12666; Wed, 21 Feb 96 21:12:37 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10725; Wed, 21 Feb 1996 21:11:18 -0800 Received: from necom830.hpcl.titech.ac.jp by mercury.Sun.COM (Sun.COM) id VAA06083; Wed, 21 Feb 1996 21:11:14 -0800 From: Masataka Ohta Message-Id: <199602220402.NAA18147@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA18147; Thu, 22 Feb 1996 13:02:33 +0900 Subject: (IPng 1461) Re: ipatm, rolc, and joint LA session agendas To: mohta@necom830.cc.titech.ac.jp (mohta) Date: Thu, 22 Feb 96 13:02:32 JST Cc: malis@nexen.com, rolc@nexen.com, ip-atm@matmos.hpl.hp.com, rsvp@isi.edu, int-serv@isi.edu, ipng@sunroof.eng.sun.com In-Reply-To: ; from "mohta" at Feb 15, 96 7:01 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Andy; > > > Please respond, either publicly or privately, if you have specific > > topics and/or internet drafts you would like to put on any of the > > above agendas. > > I'd like to discuss lose of multicast scalability caused by NHRP. > > It could be discussed in ipatm, ipatm/rsvp/intserv or ipatm/rolc/ipng > meeting, I think. > > I'll prepare an ID (2 or 3 pages long, I think) before 2/22 deadline. Below is the draft. But, as I forgot to get finename assigned, please don't expect it will be published as an Internet Draft before LA meeting. Masataka Ohta INTERNET DRAFT M. Ohta Tokyo Institute of Technology February 1996 Multicast Inscalability over Large Cloud 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 a scalability issue when multicasting to a large number of recipients over a large cloud. 1. The Problem Multicast algorithms for the Internet are often designed to support a large number of receivers. For the scalability, it is important to not to concentrate lage amount of load to a few locations. To distribute large amount of load caused by a large number of recipients, routers between the sender and the receivers are expected to perform some amount of computation. For example, with RSVP [RSVP], join is receiver initiated and multiple join requests to a single sender are merged on intermediate routers. As a result, each input port of a sender or intermediate routers receives only as many join request as the number of the hosts of the subnet of the input port. The other example of load distribution with RSVP [RSVP] is M. Ohta Expires on Aug 22, 1996 [Page 1] INTERNET DRAFT Multicast Inscalability over Large Cloud February 1996 computation of Adspec, which gives information on available resource between the sender and the receivers. In this case, Adspec received from upstream sender side is modified and distributed to limited number of routers or hosts in the direct downstream subnet. The problem with a large cloud [NHRP], then, is that the cloud does not contain entity to recognize IP specific information. It is impossible to let entities in the cloud perform some operation of IP based protocols. That is, large scale multicast does not scales over a large cloud. 2. A Solution There seems to exists only one solution: to make some of the intermediate link layer entities recognize IP protocols including IP addresses and filter specs [RSVP]. That is, to put IP routers in the large cloud. As a result, the cloud is divided into a collection of small clouds and we don't need a large cloud model [NHRP]. It should be noted that, though the large cloud model was proposed mainly for ATM, when it was not known that IP routers can relay data cell-by-cell, ATM data can be relayed cell-by-cells end-to-end all over the Internet through intermediate IP routers. 3. References [RSVP] [NHRP] 4. Security Considerations (to be provided) 5. 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 M. Ohta Expires on Aug 22, 1996 [Page 2] INTERNET DRAFT Multicast Inscalability over Large Cloud February 1996 Fax: +81-3-5734-3415 EMail: mohta@necom830.hpcl.titech.ac.jp M. Ohta Expires on Aug 22, 1996 [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 Fri Feb 23 09:36:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14000; Fri, 23 Feb 96 09:36:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13994; Fri, 23 Feb 96 09:36:40 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10232; Fri, 23 Feb 1996 09:35:18 -0800 Received: from mail13.digital.com by mercury.Sun.COM (Sun.COM) id JAA20678; Fri, 23 Feb 1996 09:35:13 -0800 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA24512; Fri, 23 Feb 1996 12:22:50 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19531; Fri, 23 Feb 1996 12:22:47 -0500 Message-Id: <9602231722.AA19531@fwasted.zk3.dec.com> To: Bob Gilligan Cc: John Gardiner Myers , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 1462) Re: Thoughts on DNS and API In-Reply-To: Your message of "Thu, 22 Feb 96 17:48:58 PST." Date: Fri, 23 Feb 96 12:22:47 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, I think we need some discussion on core parts of our spec per this recent flurry of mail. Regarding: 1) Source Routes 2) Specifying Interfaces 3) Handling Options Before anymore updates to the spec are released. For source routes I would like to review the option of using msg_cntrl flags to inform an applications source routes are being used and then use the msg_buffer to pass source routes. As opposed to the way we are presently doing it by sending an array of socket addresses. There would be a set of iovec ptrs to the source route in a structure for the source route. I would also like to discuss with the mailing list other options of handling interfaces. I see two other options to doing this: 1) Specifying an interface is present in the msg_cntrl structure to an application. 2) Changing the socket calls affected to pass interfaces as suggested by John G. I would also like to review the processing of options architecturally for IPv6 applications. 1) We need to differentiate those options which just provide a "state" to the Transport or IP layers for processing IPv6, from those that are integral to the communications path of the connection on the node. (e.g. addrform vs specifying an interface). 2) I think we need to define at the IP layer in IPv6 a vector that contains a mask which identifies what options are present and where that data is located in an options structure for the application. If the mask is OFF then then the application does not look for the element in the structure. Assumption: I am proposing a completely different Socket model for the API for IPv6. I do think it important that we have socket structure compatibility with IPv4 but after that its not important. We must evolve. DNS: I think we need to revist what we want from the DNS Library routines and the services routines too. getconninfo(): I think this needs to be in our spec now. POSIX will put it in if we don't. I think it wise our API spec be as close to what POSIX will do as possible. getconninfo() will be used by POSIX IMHO. I don't like the mode we are building this spec in presently. X person on mail list finds a bug or change we add it in. What we are seeing I think is that folks are not happy with the general architecture of our strategy for the more subtle features of IPv6. In my implementation I have still not implemented the source route or interface means specified simply because I don't think we have any consensus on them and in addition they are not the most ideal way to do them. Comments please from 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 Fri Feb 23 10:23:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14125; Fri, 23 Feb 96 10:23:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14119; Fri, 23 Feb 96 10:23:29 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19060; Fri, 23 Feb 1996 10:22:08 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id KAA05891; Fri, 23 Feb 1996 10:22:09 -0800 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id KAA28019; Fri, 23 Feb 1996 10:22:07 -0800 Message-Id: <199602231822.KAA28019@mailhost.Ipsilon.COM> To: Bob Gilligan Cc: John Gardiner Myers , ipng@sunroof.eng.sun.com Subject: (IPng 1463) Re: Thoughts on DNS and API In-Reply-To: Your message of "Thu, 22 Feb 1996 17:48:58 PST." Date: Fri, 23 Feb 1996 10:22:06 -0800 From: Dennis Ferguson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Is the (likely miniscule) performance gained by having the options >> worth the additional complexity, including the need to add more >> information (which is likely to be configured wrong anyway) to such >> things as inetd.conf. > > Well, I don't think we can just brush off a performance concern that > would affect every received UDP packet. We have been spending alot of > effort to design IPv6 to allow high-performance implementations. I think the performance issue is a red herring, it is an implementation choice fairly independent of the API. If it really bothers you to have your implementation pull information from the headers of every packet then don't do it. Just save the raw headers in the socket queue with the packet, only cracking them at the recv*() system call time if it turns out the information is being requested. Since the raw headers are already attached to the packet it doesn't cost any CPU to not get rid of them until later in the process. Not that I would necessarily want to do it this way. I think I'd want to look at what TCP was going to need first. If TCP needs the options from every packet I might rather just unconditionally break them out at the IP layer instead of waiting until the transport protocol finds the socket and determines what might be needed, for the sake of cleanliness. In any case I don't think there are any performance issues here which can't be addressed by appropriate implementation. Dennis Ferguson ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 23 10:25:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14137; Fri, 23 Feb 96 10:25:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14131; Fri, 23 Feb 96 10:25:26 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19379; Fri, 23 Feb 1996 10:24:06 -0800 Received: from IETF.cnri.reston.VA.US by mercury.Sun.COM (Sun.COM) id KAA06453; Fri, 23 Feb 1996 10:24:07 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21762; 23 Feb 96 9:55 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1464) I-D ACTION:draft-ietf-ipngwg-discovery-05.txt Date: Fri, 23 Feb 96 09:55:35 -0500 Message-Id: <9602230955.aa21762@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Neighbor Discovery for IP Version 6 (IPv6) Author(s) : T. Narten, E. Nordmark, W. Simpson Filename : draft-ietf-ipngwg-discovery-05.txt Pages : 84 Date : 02/22/1996 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-discovery-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-discovery-05.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-discovery-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960223095122.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-discovery-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-discovery-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960223095122.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 23 11:21:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14201; Fri, 23 Feb 96 11:21:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14195; Fri, 23 Feb 96 11:21:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB29666; Fri, 23 Feb 1996 11:19:50 -0800 Received: by mercury.Sun.COM (Sun.COM) id LAA29622; Fri, 23 Feb 1996 11:19:50 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.4/8.7.1) id OAA00848 for ipng@sunroof.eng.sun.com; Fri, 23 Feb 1996 14:19:45 -0500 Received: via switchmail; Fri, 23 Feb 1996 14:19:45 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 23 Feb 1996 14:18:23 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 23 Feb 1996 14:18:17 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Fri, 23 Feb 1996 14:18:17 -0500 (EST) Message-Id: <4l=V=t600WBwI12Qgl@andrew.cmu.edu> Date: Fri, 23 Feb 1996 14:18:17 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1465) Re: Thoughts on DNS and API In-Reply-To: <9602230342.AA01073@feller.mentat.com> References: <9602230342.AA01073@feller.mentat.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thartric@mentat.com (Tim Hartrick) writes: > Without the IPV6_SENDIF option how does the kernel know whether > ((struct sockaddr_in6 *)buf)[4] is the sending interface address or the > last address of a source route? With my latest suggestion, it is always the sending interface address. > I may not always > want to specify the the sending interface when I am sending source routes. Then put ipv6addr_any in the last slot. But I have to say Jim Bound's message about revisiting the core parts of the spec rather than constantly making incremental changes makes sense to me. What makes sockets easy to use in applications is the fact that the file-descriptor functions (read(), write(), select()) work with them. The socket-specific functions (bind(), connect(), accept(), etc.) can be replaced with differently-named functions, as long as it is possible to write a compatibility library for running programs written to the IPv6 API on IPv4-only systems. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Feb 23 11:48:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14232; Fri, 23 Feb 96 11:48:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14226; Fri, 23 Feb 96 11:47:48 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04173; Fri, 23 Feb 1996 11:46:30 -0800 Received: by mercury.Sun.COM (Sun.COM) id LAA07155; Fri, 23 Feb 1996 11:46:28 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa22117; 23 Feb 96 9:59 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1466) I-D ACTION:draft-ietf-ipngwg-iid-01.txt Date: Fri, 23 Feb 96 09:58:56 -0500 Message-Id: <9602230959.aa22117@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Identifying Interfaces in IPv6 link-local addresses Author(s) : R. Elz Filename : draft-ietf-ipngwg-iid-01.txt Pages : 8 Date : 02/22/1996 This draft proposes a change to the way that IPv6 link local addresses are constructed, so that a node can guarantee that all of its link local addresses are unique within the node. The current definition of a link local address, a well known prefix, some number of zero bits, and a link specific unique token, ensures that it will be unique on the link, which is what is required for communications using those addresses over the link, but does not require uniqueness of the addresses within a node. In some cases all of a nodes interfaces may share the same link local address. Even the possibility of this means that link local addresses, which may in some situations be the only addresses that exist, cannot be used for internal definition of interfaces, or other purposes within the node. This draft suggests a method by which nodes may overcome this problem, by redefining the bits between the prefix and the token to be available to be used by the node to cause the addresses to be unique. 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-iid-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-iid-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-iid-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960222135210.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-iid-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-iid-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960222135210.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 24 00:39:25 1996 Return-Path: Received: by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA14702; Sat, 24 Feb 96 00:39:25 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14696; Sat, 24 Feb 96 00:39:12 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18480; Sat, 24 Feb 1996 00:37:52 -0800 Received: by mercury.Sun.COM (Sun.COM) id AAA14541; Sat, 24 Feb 1996 00:37:51 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA18712 Sat, 24 Feb 1996 19:34:56 +1100 (from kre@munnari.OZ.AU) To: bound@zk3.dec.com Cc: Bob Gilligan , John Gardiner Myers , ipng@sunroof.eng.sun.com Subject: (IPng 1467) Re: Thoughts on DNS and API In-Reply-To: Your message of "Fri, 23 Feb 1996 12:22:47 CDT." <9602231722.AA19531@fwasted.zk3.dec.com> Date: Sat, 24 Feb 1996 19:35:13 +1100 Message-Id: <18754.825150913@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 23 Feb 96 12:22:47 -0500 From: bound@zk3.dec.com Message-ID: <9602231722.AA19531@fwasted.zk3.dec.com> DNS: I think we need to revist what we want from the DNS Library routines and the services routines too. Oh, yes, yes, before I forget (yet again) - please, in ALL DNS calls, make the returned TTL from the DNS visible to the application - without exception. Applications that make one off use of the address "telnet foo.blah" can simply ignore it, but those which make longer use of addresses really have to know how long the result they have is valid. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 24 15:16:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14970; Sat, 24 Feb 96 15:16:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14964; Sat, 24 Feb 96 15:15:49 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14080; Sat, 24 Feb 1996 15:13:59 -0800 Received: by mercury.Sun.COM (Sun.COM) id PAA09307; Sat, 24 Feb 1996 15:13:54 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa19688; 24 Feb 96 13:30 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1468) I-D ACTION:draft-ietf-ipngwg-ipv6-tunnel-01.txt Date: Sat, 24 Feb 96 13:30:20 -0500 Message-Id: <9602241330.aa19688@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Generic Packet Tunneling in IPv6 Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-ipv6-tunnel-01.txt Pages : 26 Date : 02/23/1996 This document defines the model and mechanisms for IPv6 tunneling of various Internet or lower layer protocol packets, such as IPv6, IPv4, AppleTalk, IPX, etc. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-tunnel-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960224114859.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-tunnel-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960224114859.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Feb 24 17:16:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15011; Sat, 24 Feb 96 17:16:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15005; Sat, 24 Feb 96 17:16:12 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18811; Sat, 24 Feb 1996 17:14:52 -0800 Received: by mercury.Sun.COM (Sun.COM) id RAA17925; Sat, 24 Feb 1996 17:14:51 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa20655; 24 Feb 96 13:59 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1469) I-D ACTION:draft-ietf-ipngwg-ipv6-tunnel-01.txt Date: Sat, 24 Feb 96 13:59:25 -0500 Message-Id: <9602241359.aa20655@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Generic Packet Tunneling in IPv6 Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-ipv6-tunnel-01.txt Pages : 26 Date : 02/23/1996 This document defines the model and mechanisms for IPv6 tunneling of various Internet or lower layer protocol packets, such as IPv6, IPv4, AppleTalk, IPX, etc. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-tunnel-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960224114859.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-tunnel-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960224114859.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Feb 25 09:13:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15168; Sun, 25 Feb 96 09:13:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15162; Sun, 25 Feb 96 09:13:00 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13598; Sun, 25 Feb 1996 09:11:38 -0800 Received: by mercury.Sun.COM (Sun.COM) id JAA27199; Sun, 25 Feb 1996 09:11:38 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13763; 25 Feb 96 11:43 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1470) I-D ACTION:draft-ietf-ipngwg-unicast-addr-fmt-03.txt Date: Sun, 25 Feb 96 11:43:23 -0500 Message-Id: <9602251143.aa13763@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : An IPv6 Provider-Based Unicast Address Format Author(s) : Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel Filename : draft-ietf-ipngwg-unicast-addr-fmt-03.txt Pages : 8 Date : 02/24/1996 This document defines an IPv6 provider-based unicast address format for use in the Internet. The address format defined in this document is consistent with the "IPv6 Addressing Architecture" [ARCH] and the "An Architecture for IPv6 Unicast Address Allocation" [ALLOC], and is intended to facilitate scalable Internet routing. The unicast address format defined in this document doesn't preclude the use of other unicast address formats. 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-unicast-addr-fmt-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicast-addr-fmt-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-unicast-addr-fmt-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960225113722.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-unicast-addr-fmt-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-unicast-addr-fmt-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960225113722.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 26 05:52:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15417; Mon, 26 Feb 96 05:52:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15411; Mon, 26 Feb 96 05:52:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11681; Mon, 26 Feb 1996 05:51:17 -0800 Received: by mercury.Sun.COM (Sun.COM) id FAA14588; Mon, 26 Feb 1996 05:51:06 -0800 Received: from [138.96.24.178] by sophia.inria.fr (8.6.12/8.6.12) with SMTP id OAA18353 for ; Mon, 26 Feb 1996 14:50:59 +0100 Date: Mon, 26 Feb 1996 14:50:59 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: huitema@pax.inria.fr (Christian Huitema) Subject: (IPng 1471) Not so random local tokens Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The current specification of link local addresses mentions that these addresses are composed by the concatenation of a prefix and a unique token. We have almost always assumed that this token will be a 48 bits IEEE-802 address, either that of the CPU board or that of the interface board. I would like to point out another possibility. We could as well use the 48 bits to encode a textual name, the "local name" of the machine in the naming domain. If all machines connected to a given subnet belong to the same naming domain (e.g. *.inria.fr) then the local name constitutes a valid unique token for automatic address configuration. Equating local name and token may facilitate management functions such as reverse address look up. Domain name tokens are case independant and should only comprise letters, digits and hyphen. All these characters are encoded by codes in the range 0x20 to 0x5F of the ASCII alphabet: | 20 sp | 21 ! | 22 " | 23 # | 24 $ | 25 % | 26 & | 27 ' | | 28 ( | 29 ) | 2a * | 2b + | 2c , | 2d - | 2e . | 2f / | | 30 0 | 31 1 | 32 2 | 33 3 | 34 4 | 35 5 | 36 6 | 37 7 | | 38 8 | 39 9 | 3a : | 3b ; | 3c < | 3d = | 3e > | 3f ? | | 40 @ | 41 A | 42 B | 43 C | 44 D | 45 E | 46 F | 47 G | | 48 H | 49 I | 4a J | 4b K | 4c L | 4d M | 4e N | 4f O | | 50 P | 51 Q | 52 R | 53 S | 54 T | 55 U | 56 V | 57 W | | 58 X | 59 Y | 5a Z | 5b [ | 5c \ | 5d ] | 5e ^ | 5f _ | We can thus trivially allocate a 6-bit code to each of these characters, by substracting 0x20 from the ascii code. Hyphen will be coded 0x0d, digits 0x10 to 0x19, letters 0x21 to 0x3a. With a 48 bits, we could encode an 8 character token. However, if we want to not risk collision with a valid IEEE address, we must make sure that the first two bits declare the token as a user assigned unicast address, i.e. setting I/G to 0 and U/L to 1. This is obtained by mandating that the token be at most 7 characters long, and by requiring that the token be right aligned and left padded with the character "?" (coded 0x1F). If we don't have to worry about compatibility, we can use up to 8 characters, but we should keep the same padding rules. For example, if the name of my local station is "pax", I would derive from its name the 8 character string "?????PAX" which will then result in the 48 bit token: 7DF7DF7F0878. Isn't that cool ? Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 26 07:28:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15450; Mon, 26 Feb 96 07:28:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15444; Mon, 26 Feb 96 07:28:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18646; Mon, 26 Feb 1996 07:26:45 -0800 Received: by mercury.Sun.COM (Sun.COM) id HAA01814; Mon, 26 Feb 1996 07:26:43 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01074 Tue, 27 Feb 1996 02:25:41 +1100 (from kre@munnari.OZ.AU) To: huitema@pax.inria.fr (Christian Huitema) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1472) Re: Not so random local tokens In-Reply-To: Your message of "Mon, 26 Feb 1996 14:50:59 BST." Date: Tue, 27 Feb 1996 02:25:58 +1100 Message-Id: <20527.825348358@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 26 Feb 1996 14:50:59 +0100 From: huitema@pax.inria.fr (Christian Huitema) Message-ID: Isn't that cool ? So cool its frozen, rock solid, and will take years (hopefully) to defrost. 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 Mon Feb 26 08:42:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15494; Mon, 26 Feb 96 08:42:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15488; Mon, 26 Feb 96 08:41:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27402; Mon, 26 Feb 1996 08:40:29 -0800 Received: by mercury.Sun.COM (Sun.COM) id IAA20602; Mon, 26 Feb 1996 08:40:29 -0800 Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with SMTP id LAA01491; Mon, 26 Feb 1996 11:36:48 -0500 Received: from apollo13.cascade by casc.com (4.1/SMI-4.1) id AA10555; Mon, 26 Feb 96 11:38:48 EST Received: by apollo13.cascade (5.0/SMI-SVR4) id AA02401; Mon, 26 Feb 1996 11:38:48 +0500 Date: Mon, 26 Feb 1996 11:38:48 +0500 From: jmoy@alpo.casc.com (John Moy) Message-Id: <9602261638.AA02401@apollo13.cascade> To: ospf@gated.cornell.edu Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1473) OSPF for IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi. I've posted the latest OSPF for IPv6 draft as file name . Despite what the abstract in the posting said, there should be three authors: Rib Coltun, Dennis Ferguson and myself. This draft is the result of several weeks of email between Rob, Dennis and me. At this point it is something that we are comfortable with -- which was quite a trick, considering we came at the problem from three very different perspectives. I'll be interested to see how other people react to the draft. To OSPFers: As discussed in the lst WG meeting, we have left the size of the OSPF Router IDs, Area IDs and Link State IDs at 32 bits. This has kept the packet and LSA sizes for IPv6 almost as small as those for IPv4. However, we have removed the Opaque-LSAs, opting instead to increase the size of the LS type field and to encode flooding scope and the way unrecognized LS types are handled in the top few bits of LS type. The only section remaining to be written in the draft is the instructions for implementors. I'll try to finish that in the next couple weeks. It's fairly straightforward if you already have an OSPF for IPv implementation, but there are a couple things that you want to think about (like, for example, how you index your link state database. Most if not all implementation index first on the LSAs' Link State ID, and then on Advertising Router. For IPv6, it's probably better to reverse the order of these indexes). Io IPv6ers: We have appropriated a couple of multicast addresses, and a protocol ID for the next header ID. See Appendix A of the I-D. I hope that's OK. Here's the I-D abstract: This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs a a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload. Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4l, even with the larger IPv6 addresses. Most field- and packet-size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. Please send comments to ospf@gated.cornell.edu. Thanks, John ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 26 10:54:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15570; Mon, 26 Feb 96 10:54:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15564; Mon, 26 Feb 96 10:54:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20501; Mon, 26 Feb 1996 10:52:40 -0800 Received: by mercury.Sun.COM (Sun.COM) id KAA08649; Mon, 26 Feb 1996 10:52:29 -0800 Received: from hpinpcb.cup.hp.com (hpindwx.cup.hp.com) by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA052520735; Mon, 26 Feb 1996 10:52:16 -0800 Received: by hpinpcb.cup.hp.com (1.37.109.16/15.5+IOS 3.20+cup+OMrelay) id AA057170745; Mon, 26 Feb 1996 10:52:25 -0800 From: "Bill Medlin" Message-Id: <9602261052.ZM5715@hpindwx.cup.hp.com> Date: Mon, 26 Feb 1996 10:52:24 -0800 In-Reply-To: bound@zk3.dec.com "(IPng 1462) Re: Thoughts on DNS and API" (Feb 23, 12:22pm) References: <9602231722.AA19531@fwasted.zk3.dec.com> X-Mailer: Z-Mail (3.2.1 10apr95) To: bound@zk3.dec.com, Bob Gilligan Subject: (IPng 1474) Re: Thoughts on DNS and API Cc: John Gardiner Myers , 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 Jim, I wanted to address yours and others' concerns about the IPv6 BSD Sockets API spec. In general, I think the spec is in pretty good shape. Some of these concerns are getting a little overblown. First, let me state that HP's highest priority for this spec is ease of migration for existing IPv4 applications to IPv6. I think the spec does a good job of making this migration as smooth as possible. HP will absolutely oppose any changes to the spec which endanger this ease of migration. This includes anyplace where a particular operation is done one way for IPv4 but would be done a different way for IPv6 (unless absolutely necessary). Second, we would like to see this spec moved to the X/Open forum as soon as possible. My feeling is that the IETF has done a fantastic job of getting the spec as far as it is, but that it is just about time for the logical next step of moving it to a group better equipped to deal with API issues. Third, I hate to see cans of worms being opened up at this late date. Everyone has things about this spec that they would like to change. The spec has arrived at this point through a long, painful process to reach consensus. My concern is that if we start making a lot of changes, we'll have to revisit many of the fundamental decisions made a long time ago. This will threaten to delay deployment of IPv6. As you pointed out, we don't even have a security API yet, a serious problem. Fourth, I notice that with the exception of the authors (Bob and yourself), the other implementors have been very quiet about this whole subject. I would take this to mean lack of support for any serious changes. Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 26 13:25:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15677; Mon, 26 Feb 96 13:25:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15671; Mon, 26 Feb 96 13:24:52 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17032; Mon, 26 Feb 1996 13:23:27 -0800 Received: by mercury.Sun.COM (Sun.COM) id NAA27030; Mon, 26 Feb 1996 13:23:25 -0800 Received: from muggsy.lkg.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA32010; Mon, 26 Feb 1996 16:03:09 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA21569; Mon, 26 Feb 1996 16:03:07 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id VAA05692; Mon, 26 Feb 1996 21:27:16 GMT Message-Id: <199602262127.VAA05692@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: "Bill Medlin" Cc: bound@zk3.dec.com, Bob Gilligan , John Gardiner Myers , ipng@sunroof.eng.sun.com Subject: (IPng 1475) Re: Thoughts on DNS and API In-Reply-To: Your message of "Mon, 26 Feb 1996 10:52:24 PST." <9602261052.ZM5715@hpindwx.cup.hp.com> X-Mailer: exmh version 1.5omega 10/6/94 Date: Mon, 26 Feb 1996 21:27:05 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In <9602261052.ZM5715@hpindwx.cup.hp.com> , Bill Medlin wrote: > Fourth, I notice that with the exception of the authors (Bob and yourself), > the other implementors have been very quiet about this whole subject. Look at IPng 1200-1300 for example. That's not what I call quiet. > I would take this to mean lack of support for any serious changes. I strongly disagree. While most of the BSD API specification is fine as it is, a few places (specifically source routes and "receive/sending" interface) need to be rethought as they "break" the de-facto BSD API model. BSD 4.3 Reno introduced ancillary control data as the means to handle these situations and it's shameful that we seem to be inventing a new wheel when we are already have a perfectly fine wheel. In fact, if you look at the existing BSD 4.4lite UDP code, you will find that ancillary data is already used: if (inp->inp_flags & INP_CONTROLOPTS) { struct mbuf **mp = &opts; if (inp->inp_flags & INP_RECVDSTADDR) { *mp = udp_saveopt((caddr_t) &ip->ip_dst, sizeof(struct in_addr), IP_RECVDSTADDR); if (*mp) mp = &(*mp)->m_next; } #ifdef notyet /* options were tossed above */ if (inp->inp_flags & INP_RECVOPTS) { *mp = udp_saveopt((caddr_t) opts_deleted_above, sizeof(struct in_addr), IP_RECVOPTS); if (*mp) mp = &(*mp)->m_next; } /* ip_srcroute doesn't do what we want here, need to fix */ if (inp->inp_flags & INP_RECVRETOPTS) { *mp = udp_saveopt((caddr_t) ip_srcroute(), sizeof(struct in_addr), IP_RECVRETOPTS); if (*mp) mp = &(*mp)->m_next; } #endif } Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 26 14:36:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15765; Mon, 26 Feb 96 14:36:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15759; Mon, 26 Feb 96 14:35:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00186; Mon, 26 Feb 1996 14:34:32 -0800 Received: by mercury.Sun.COM (Sun.COM) id OAA19165; Mon, 26 Feb 1996 14:34:31 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id XAA02070; Mon, 26 Feb 1996 23:34:21 +0100 (MET) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id XAA07617; Mon, 26 Feb 1996 23:34:14 +0100 Message-Id: <199602262234.XAA07617@givry.inria.fr> From: Francis Dupont To: Matt Thomas Cc: "Bill Medlin" , bound@zk3.dec.com, Bob Gilligan , John Gardiner Myers , ipng@sunroof.eng.sun.com Subject: (IPng 1476) Re: Thoughts on DNS and API In-Reply-To: Your message of Mon, 26 Feb 1996 21:27:05 GMT. <199602262127.VAA05692@whydos.lkg.dec.com> Date: Mon, 26 Feb 1996 23:34:04 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree Matt: I believe the usage of msg_control is far better than the socket array. I have noted a second point where compatibility is not good: it is a good idea to make hostname2addr/addr2hostname MP capable but the way the space is allocated introduces a lot of memory leaks (freehostent() must be called at all the exit points, included hidden ones like in signal processing...). I propose to give the space as an optional argument (another one :-). The size should be a standard define (in /usr/include/netdb.h) with a provision for extension and bad alignment. Regards Francis.Dupont@inria.fr PS: standard defines is a very good thing for portability, I'd like we go far further... ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 26 16:45:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15823; Mon, 26 Feb 96 16:45:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15817; Mon, 26 Feb 96 16:44:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23684; Mon, 26 Feb 1996 16:43:27 -0800 Received: by mercury.Sun.COM (Sun.COM) id QAA24364; Mon, 26 Feb 1996 16:43:26 -0800 Received: from munin.fnal.gov ("port 2287"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I1OGOLZN980003FD@FNAL.FNAL.GOV> for ipng@sunroof.eng.sun.com; Mon, 26 Feb 1996 18:43:24 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id SAA07296; Mon, 26 Feb 1996 18:43:11 -0600 (CST) Date: Mon, 26 Feb 1996 18:43:10 -0600 From: Matt Crawford Subject: (IPng 1477) minor changes to ipv6-over-ether & -fddi To: ipng@sunroof.eng.sun.com Message-Id: <199602270043.SAA07296@munin.fnal.gov> Mime-Version: (is)1(your).(UA)0(compliant?) Content-Type: multipart/mixed; boundary=mimeprimaryboundary 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{ February 26, 1996 A Method for the Transmission of IPv6 Packets over Ethernet Networks 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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 ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. Introduction This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on an Ethernet. Maximum Transmission Unit The default MTU size for IPv6 packets on an Ethernet is 1500 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. If a Router Advertisement is received Crawford Expires August 1996 [Page 1] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over Ethernet 1996-02-26 with an MTU option specifying an MTU larger than 1500, or larger than a manually configured value less than 1500, that MTU option must be ignored. Frame Format IPv6 packets are transmitted in standard Ethernet frames. The ethernet header contains the Destination and Source ethernet addresses and the ethernet type code, which must contain the value 86DD hexadecimal. The data field contains the IPv6 header followed immediately by the payload, and possibly padding octets to meet the minimum frame size for Ethernet. +-------+-------+-------+-------+-------+-------+ ^ | Destination Ethernet address | | +-------+-------+-------+-------+-------+-------+ ethernet | Source Ethernet address | header +-------+-------+-------+-------+-------+-------+ | | 86 DD | v +-------+-------+-------+-------+-------+------+------+ | IPv6 header and payload ... / +-------+-------+-------+-------+-------+------+------+ Stateless Autoconfiguration and Link-Local Addresses The address token [CONF] for an Ethernet interface is the interface's built-in 48-bit IEEE 802 address, in canonical bit order and with the octets in the same order in which they would appear in the header of an ethernet frame. (The individual/group bit is in the first octet and the OUI is in the first three octets.) A different MAC address set manually or by software should not be used as the address token. An IPv6 address prefix used for stateless autoconfiguration of an ethernet interface must be 80 bits in length. The IPv6 Link-local address [AARCH] for an Ethernet interface is formed by appending the interface's IEEE 802 address to the 80-bit prefix FE80::. +-------+-------+-------+-------+-------+-------+------+------+ | FE 80 00 00 00 00 00 00 | +-------+-------+-------+-------+-------+-------+------+------+ | 00 00 | Ethernet Address | +-------+-------+-------+-------+-------+-------+------+------+ Crawford Expires August 1996 [Page 2] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over Ethernet 1996-02-26 Address Mapping -- Unicast The procedure for mapping IPv6 addresses into Ethernet link-layer addresses is described in [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is Ethernet. +-------+-------+-------+-------+-------+-------+-------+-------+ | Type |Length | Ethernet Address | +-------+-------+-------+-------+-------+-------+-------+-------+ Option fields: Type 1 for Source Link-layer address. 2 for Target Link-layer address. Length 1 (in units of 8 octets). Ethernet Address The 48 bit Ethernet IEEE 802 address, in canonical bit order. This is the address the interface currently responds | to, and may be different from the built-in address used as | the address token. | Address Mapping -- Multicast An IPv6 packet with a multicast destination address DST is transmitted to the Ethernet multicast address whose first two octets are the value 3333 hexadecimal and whose last four octets are the last four octets of DST, ordered from more to least significant. +-------+-------+-------+-------+-------+-------+ | 33 | 33 | DST13 | DST14 | DST15 | DST16 | +-------+-------+-------+-------+-------+-------+ Security Considerations Security considerations are not addressed in this memo. Crawford Expires August 1996 [Page 3] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over Ethernet 1996-02-26 References [AARCH] R. Hinden, S. Deering, IP Version 6 Addressing Architecture. RFC1884. | [CONF] S. Thomson, IPv6 Stateless Address Autoconfiguration. Currently draft-ietf-addrconf-ipv6-auto-07.txt. | [DISC] T. Narten, E. Nordmark, W. A. Simpson, Neighbor Discovery for IP Version 6 (IPv6). Currently draft-ietf-ipngwg-discovery-05.txt. | [IPV6] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification. RFC1883. | Author's Address Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA Phone: +1 708 840-3461 EMail: crawdad@fnal.gov Crawford Expires August 1996 [Page 4] --mimeprimaryboundary Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-ipngwg-fddi-ntwrks-03.txt" Content-Description: draft-ietf-ipngwg-fddi-ntwrks-03.txt Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force Matt Crawford INTERNET-DRAFT Fermilab February 26, 1996 A Method for the Transmission of IPv6 Packets over FDDI Networks 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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 ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. Introduction This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. It also specifies the method of forming IPv6 link-local addresses on FDDI networks and the content of the Source/Target Link-layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on an FDDI network. Maximum Transmission Unit FDDI permits a frame length of 4500 octets (9000 symbols), including at least 22 octets (44 symbols) of Data Link encapsulation when long-format addresses are used. Subtracting 8 octets of LLC/SNAP Crawford Expires August 1996 [Page 1] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over FDDI 1996-02-26 header, this would, in principle, allow the IPv6 packet in the Information field to be up to 4470 octets. However, it is desirable to allow for the variable sizes and possible future extensions to the MAC header and frame status fields. The default MTU size for IPv6 packets on an FDDI network is therefore 4352 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of a smaller value on each node. If a Router Advertisement is received with an MTU option specifying an MTU larger than the default or the manually configured value, that MTU option may be logged to system management but must be otherwise ignored. For purposes of this document, information received from DHCP is considered ``manually configured''. Frame Format FDDI provides both synchronous and asynchronous transmission, with the latter class further subdivided by the use of restricted and unrestricted tokens. Only asynchronous transmission with unrestricted tokens is required for FDDI interoperability. Accordingly, IPv6 packets shall be sent in asynchronous frames using unrestricted tokens. The robustness principle dictates that nodes should be able to receive synchronous frames and asynchronous frames sent using restricted tokens. IPv6 packets are transmitted in LLC/SNAP frames, using long-format (48 bit) addresses. The data field contains the IPv6 header and payload and is followed by the FDDI Frame Check Sequence, Ending Delimiter, and Frame Status symbols. +-------+ ^ | FC | | +-------+-------+-------+-------+-------+-------+ | | Destination FDDI address | | +-------+-------+-------+-------+-------+-------+ FDDI | Source FDDI address | header +-------+-------+-------+-------+-------+-------+ | | DSAP | SSAP | CTL | OUI | | +-------+-------+-------+-------+-------+-------+ | | Ethertype | v +-------+-------+-------+-------+-------+------+------+ | IPv6 header and payload ... / +-------+-------+-------+-------+-------+------+------+ Crawford Expires August 1996 [Page 2] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over FDDI 1996-02-26 FDDI Header Fields: FC The Frame Code must be in the range 50 to 57 hexadecimal, inclusive, with the three low order bits indicating the frame priority. The Frame Code should be in the range 51 to 57 hexadecimal, inclusive, for reasons given in the next section. DSAP, SSAP Both the DSAP and SSAP fields shall contain the value AA hexadecimal, indictating SNAP encapsulation. CTL The Control field shall be set to 03 hexadecimal, indicating Unnumbered Information. OUI The Organizationally Unique Identifier shall be set to 000000 hexadecimal. Ethertype The ethernet protocol type ("ethertype") shall be set to the value 86DD hexadecimal. Interaction with Bridges For correct operation when mixed media are bridged together, the smallest MTU of all the media must be manually configured in each node or advertised by routers in an MTU option. Nodes transmitting IPv6 on FDDI should implement the following simple mechanism for ``FDDI adjacency detection''. If a node N1 receives, in an FDDI frame with a non-zero LLC priority, a valid Router Advertisement, Neighbor Advertisement, or Neighbor | Solicitation from a node N2, then N1 may send unicast IPv6 packets to | N2 with sizes up to the default IPv6 FDDI MTU (4352 octets), regardless of any smaller MTU configured manually or received in a Router Advertisement MTU option. N2 may be the IPv6 destination or the next hop router to the destination. Nodes implementing FDDI adjacency detection must provide a configuration option to disable the mechanism. This option may be used when a smaller MTU is desired for reasons other than mixed-media bridging. By default, FDDI adjacency detection should be enabled. The only contemplated use of the LLC priority field of the FC octet is to aid in per-destination MTU determination. It would be sufficient for that purpose to require only that Router Advertisements, Neighbor Advertisements, and Neighbor Solicitations | sent on FDDI always have non-zero priority. However, it may be simpler or more useful to transmit all IPv6 packets on FDDI with Crawford Expires August 1996 [Page 3] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over FDDI 1996-02-26 non-zero priority. Stateless Autoconfiguration and Link-Local Addresses The address token [CONF] for an FDDI interface is the interface's built-in 48-bit IEEE 802 address, in canonical bit order and with the octet in the same order in which they would appear in the header of an ethernet frame. (The individual/group bit is in the first octet and the OUI is in the first three octets.) A different MAC address set manually or by software should not be used as the address token. An IPv6 address prefix used for stateless autoconfiguration of an FDDI interface must be 80 bits in length. The IPv6 Link-local address [AARCH] for an FDDI interface is formed by appending the interface's IEEE 802 address to the 80-bit prefix FE80::. +-------+-------+-------+-------+-------+-------+------+------+ | FE 80 00 00 00 00 00 00 | +-------+-------+-------+-------+-------+-------+------+------+ | 00 00 | FDDI Address | +-------+-------+-------+-------+-------+-------+------+------+ Address Mapping -- Unicast The procedure for mapping IPv6 addresses into FDDI link-layer addresses is described in [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is FDDI. +-------+-------+-------+-------+-------+-------+------+------+ | Type |Length | FDDI Address | +-------+-------+-------+-------+-------+-------+------+------+ Option fields: Type 1 for Source Link-layer address. 2 for Target Link-layer address. Length 1 (in units of 8 octets). FDDI Address The 48 bit FDDI IEEE 802 address, in canonical bit order. This is the address the interface currently responds to, and | may be different from the built-in address used as the | Crawford Expires August 1996 [Page 4] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over FDDI 1996-02-26 address token. | Address Mapping -- Multicast An IPv6 packet with a multicast destination address DST is transmitted to the FDDI multicast address whose first two octets are the value 3333 hexadecimal and whose last four octets are the last four octets of DST, ordered from more to least significant. +-------+-------+-------+-------+-------+-------+ | 33 | 33 | DST13 | DST14 | DST15 | DST16 | +-------+-------+-------+-------+-------+-------+ Security Considerations Security considerations are not addressed in this memo. Acknowledgments | Erik Nordmark contributed to the method for interaction with bridges. | References [AARCH] R. Hinden, S. Deering, IP Version 6 Addressing Architecture. RFC1884. | [CONF] S. Thomson, IPv6 Stateless Address Autoconfiguration. Currently draft-ietf-addrconf-ipv6-auto-07.txt. | [DISC] T. Narten, E. Nordmark, W. A. Simpson, Neighbor Discovery for IP Version 6 (IPv6). Currently draft-ietf-ipngwg-discovery-05.txt. | [IPV6] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification. RFC1883. | Crawford Expires August 1996 [Page 5] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over FDDI 1996-02-26 Author's Address Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA Phone: +1 708 840-3461 EMail: crawdad@fnal.gov Crawford Expires August 1996 [Page 6] --mimeprimaryboundary-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 26 17:12:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15849; Mon, 26 Feb 96 17:12:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15843; Mon, 26 Feb 96 17:12:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28559; Mon, 26 Feb 1996 17:10:50 -0800 Received: by mercury.Sun.COM (Sun.COM) id RAA00787; Mon, 26 Feb 1996 17:10:50 -0800 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id RAA21816; Mon, 26 Feb 1996 17:08:18 -0800 Date: Mon, 26 Feb 1996 17:08:18 -0800 From: Ran Atkinson Message-Id: <199602270108.RAA21816@puli.cisco.com> To: billmd@hpinpcb.cup.hp.com Subject: (IPng 1478) Re: Thoughts on DNS and API In-Reply-To: <9602261052.ZM5715@hpindwx.cup.hp.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, If the Sockets API spec goes anywhere it should be to IEEE POSIX, which is very open and is already writing up a formal standard on Sockets API to be submitted to ISO as part of POSIX. I would hope it would be published as an Informational RFC _first_, as has been planned for a long while now. All IMHO and all my own personal opinion of course. Ran rja@inet.org ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 26 19:10:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15906; Mon, 26 Feb 96 19:10:07 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15900; Mon, 26 Feb 96 19:09:51 PST Received: from kandinsky (kandinsky [129.146.86.117]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id TAA04056; Mon, 26 Feb 1996 19:07:23 -0800 (PST) Date: Mon, 26 Feb 1996 19:13:59 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1479) Re: Thoughts on DNS and API To: Matt Thomas Cc: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I would take this to mean lack of support for any serious changes. > > I strongly disagree. While most of the BSD API specification is fine as > it is, a few places (specifically source routes and "receive/sending" > interface) need to be rethought as they "break" the de-facto BSD API model. I'd like to understand how the current draft of the API spec "breaks" the BSD API model. Could you elaborate? > BSD 4.3 Reno introduced ancillary control data as the means to handle > these situations and it's shameful that we seem to be inventing a new > wheel when we are already have a perfectly fine wheel. We discussed this idea a bit before, but I still have a couple of questions about how it would work: First, how would it work with TCP? The application certainly could use sendmsg() on a TCP socket to specify a source route to use *after* the connection had been established. How would an application specify a source route to be used at connect() time? What about a passively accepted connection? Second, have you given any thought to how would it work on systems that are based on 4.3 BSD Tahoe and earlier releases, which does not have the control message feature? These are two issues that we thought about and addressed in the current API spec. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 26 19:18:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15918; Mon, 26 Feb 96 19:18:48 PST Received: from caribe.eng.sun.com (caribe-86) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15912; Mon, 26 Feb 96 19:18:32 PST Received: from kandinsky (kandinsky [129.146.86.117]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id TAA04293; Mon, 26 Feb 1996 19:16:09 -0800 (PST) Date: Mon, 26 Feb 1996 19:22:46 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1480) Re: Thoughts on DNS and API To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have noted a second point where > compatibility is not good: it is a good idea to make > hostname2addr/addr2hostname MP capable but the way > the space is allocated introduces a lot of memory leaks > (freehostent() must be called at all the exit points, > included hidden ones like in signal processing...). > I propose to give the space as an optional argument > (another one :-). The size should be a standard define > (in /usr/include/netdb.h) with a provision for extension > and bad alignment. I agree it would be simpler to have the application provide the buffer for the function to store the addresses in, but I think that approach has a problem: The application does not know how big to make the buffer. The application doesn't know at the time it calls hostname2addr() whether the function is going to return 1 address, or 400 addresses, or more. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 26 20:41:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15951; Mon, 26 Feb 96 20:41:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15945; Mon, 26 Feb 96 20:41:12 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23194; Mon, 26 Feb 1996 20:39:48 -0800 Received: by mercury.Sun.COM (Sun.COM) id UAA07410; Mon, 26 Feb 1996 20:39:49 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA16612; Mon, 26 Feb 1996 23:30:03 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA30309; Mon, 26 Feb 1996 23:29:56 -0500 Message-Id: <9602270429.AA30309@fwasted.zk3.dec.com> To: "Bill Medlin" Cc: bound@zk3.dec.com, Bob Gilligan , John Gardiner Myers , ipng@sunroof.eng.sun.com Subject: (IPng 1481) Re: Thoughts on DNS and API In-Reply-To: Your message of "Mon, 26 Feb 96 10:52:24 PST." <9602261052.ZM5715@hpindwx.cup.hp.com> Date: Mon, 26 Feb 96 23:29:56 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bill, >I wanted to address yours and others' concerns about the IPv6 BSD Sockets >API spec. In general, I think the spec is in pretty good shape. >Some of these concerns are getting a little overblown. I think any concerns at this point are on a few basic issues: 1) Use of Source Routes 2) Use of Interfaces 3) Use of Options to support 1 and 2 above. I think the issues are valid. >First, let me state that HP's highest priority for this spec is ease >of migration for existing IPv4 applications to IPv6. I think the spec >does a good job of making this migration as smooth as possible. HP >will absolutely oppose any changes to the spec which endanger this >ease of migration. This includes anyplace where a particular >operation is done one way for IPv4 but would be done a different way for IPv6 >(unless absolutely necessary). I would agree with this completely, unless IPv4 was brain dead and in that case I think we should fix it now in IPv6. Source Routes and Interfaces via the API are not part of IPv4, thus, new to the sockets paradigm. So doing it different than IPv4 is an inherent axiom that it must be done different than IPv4, because it does not exist. That part of the spec and the issues brought forth on this list is not overblown and a real issue. >Second, we would like to see this spec moved to the X/Open forum >as soon as possible. My feeling is that the IETF has done a fantastic >job of getting the spec as far as it is, but that it is just about time >for the logical next step of moving it to a group better equipped to >deal with API issues. I would prefer it be sent to POSIX .12 first. >Third, I hate to see cans of worms being opened up at this late date. >Everyone has things about this spec that they would like to change. >The spec has arrived at this point through a long, painful process >to reach consensus. My concern is that if we start making a lot >of changes, we'll have to revisit many of the fundamental decisions >made a long time ago. This will threaten to delay deployment of IPv6. >As you pointed out, we don't even have a security API yet, a serious >problem. I agree we don't want to blow the spec out of the water. But, I don't think we have consensus on Source Routes or Interfaces being specified in the API. It might be a good compromise to leave Interfaces and Source Routes out of the spec and leave it for POSIX and X/Open to enhance the API to support the "new" features of IPv6. Would all support this compromise now so we can get the spec to Info RFC so it will basically do what Bill has suggested above? Provide an API to migrate old IPv4 apps to IPv6? >Fourth, I notice that with the exception of the authors (Bob and yourself), >the other implementors have been very quiet about this whole subject. >I would take this to mean lack of support for any serious changes. Well there has been enough mail by key individuals that has made me wonder if we have consensus as the spec is to go to Info RFC. My concern is we not cast in stone today what may not be the best solution, which will get changed down the road and people have not only port from IPv4 to IPv6 but then again to the new IPv6. I think if we leave source routes and interfaces out of the spec we will be safe. For now let each vendor get some implementation experience with specifying source routes and interfaces in our IPv6 prototypes and then revisit this in the API at a later date. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 26 21:08:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15967; Mon, 26 Feb 96 21:08:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15961; Mon, 26 Feb 96 21:08:29 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25786; Mon, 26 Feb 1996 21:07:05 -0800 Received: by mercury.Sun.COM (Sun.COM) id VAA11968; Mon, 26 Feb 1996 21:07:05 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA23345; Tue, 27 Feb 1996 00:02:55 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA05986; Tue, 27 Feb 1996 00:02:53 -0500 Message-Id: <9602270502.AA05986@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1482) API: Why the IPv4 Arch/Model is not enough for IPv6 Date: Tue, 27 Feb 96 00:02:53 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Gersten gave me permission to forward this to you... /jim ------- Forwarded Message Return-Path: daemon Received: from mail11.digital.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA15558; Mon, 26 Feb 1996 19:04:19 -0500 Received: from user11.term1.ventura.rain.org by mail11.digital.com (5.65v3.2/1.0/WV) id AA27055; Mon, 26 Feb 1996 18:53:36 -0500 Received: by stb.info.com (Smail3.1.28.1 #4) id m0trCh2-000ZB1C; Mon, 26 Feb 96 15:51 PST Message-Id: Date: Mon, 26 Feb 96 15:51 PST From: Michael Gersten Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: bound@zk3.dec.com Subject: Re: (IPng 1426) Re: Thoughts on DNS and API Reply-To: michael@stb.info.com Begin forwarded message: >Michael Gersten writes: >> The second, and more serious concern, is the API specs. Am I the >> only one that thinks that duplicating the V4 socket interface for V6 >> is a really bad idea? This is like telling the engineers who build cars I don't like trunks in cars. But neglect to provide a solution as to how the passengers hold their stuff in the car. - ----- I'm sorry, I thought I did mention a few ideas in that letter I wrote. Briefly, I think that the v4 socket interface destroys all concept of device independence, and is too low level for general application programming, as it hardwires socket ports (imagine hardwiring inode numbers in file open/close calls, or having to write code for hard drives differently from floppies, even if it's just a constant passed to an open call.) I think that the actual interface itself can remain, but be marked as "obsolete -- do not use -- use routines XXX instead". These routines can be library routines, based on the lower level calls. Only one new call, for remapping port numbers, a root only call, needs to be added. The library routines would be responsible for things like taking a string, determining if it's a hostname, and looking it up in whatever name-> address resolver you have (DNS over the internet, who knows what over decnet or IPX/SPX/etc.), or if it's a destination address, opening a connection and returning a socket connection to that host. And, you need the routines to deal with, "Was I given a full address, or just the hostname part, with a port number to come later, or did it actually specify a service name instead of a port number, in which case I probably need to ask the remote machine which port number that server is on" (It may be cached locally, but remember, not every site has things like X windows listed in /etc/services). In general, no program ever needs to be concerned with the details of an address. An address, which is protocol specific, is just a cookie passed either from the "I got a packet for you" kernel call, or from the "give me a name, I'll give you an address" library call. Whether that address is written as "128.32.75.95:25", or "ftp.ucla.edu:ftp", or "\\machine\directory\path\file", makes no difference. You either open it for a datagram, a stream, a reliable sequenced datagram, or whatever; the name will imply the address and protocol, and the protocol and type will imply the specific (ex: a name of "ftp.ucla.edu:ftp" implies an address of ftp.ucla.edu, AF_INET, and a protocol of PF_INET, the PF_INET and stream imply TCP.) The result is a file descriptor that you give read()/write()/lseek()/close()/select()/close() calls on. And, you can then extend that library routine to deal with things like "http://www.whatever.com/path/file.html", and then allow any program to read web pages, etc. Why the root port remapping call? Well, consider the case of a unix domain socket. I have program A listening on /dev/printer (just an example), and a program that wants to write to the printer. But this program is hardwired for a laserjet, and I've got a postscript. I'd like to move that /dev/printer to /dev/raw-printer, and write a new little program that creates a /dev/printer socket, reads from it, calls a translator program, and outputs the result to /dev/raw-printer. In fact, I can do this. ** I can't do this with internet sockets. As far as I know, unix domain sockets are the only ones (aside from real files) that this can be done with, and then only because unix domain sockets live in two worlds. In the worst case, root can use chroot() to force a program to use different files, and have another program do any filtering needed. But even root can't do any filtering with inet sockets right now. Besides, I just use the rear seat instead of the trunk to store things :-) Michael (p.s.: This isn't going to the list; if you think it's needed, please forward this to the list.) - -- Michael Gersten michael@stb.info.com http://www.stb.info.com/~michael NeXT Registered Developer (NeRD) # 3860 -- Hire me! (Great at design/coding) Without Prejudice, UCC 1-207 (I can't stand fixing other's bugs) Want $$$? Check http://www.stb.info.com/~michael/TrulySpecial.html. Serious. ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Feb 26 23:32:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16026; Mon, 26 Feb 96 23:32:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16020; Mon, 26 Feb 96 23:32:09 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04508; Mon, 26 Feb 1996 23:30:46 -0800 Received: by mercury.Sun.COM (Sun.COM) id XAA27421; Mon, 26 Feb 1996 23:30:45 -0800 Received: from ralpha.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA30266; Tue, 27 Feb 1996 02:24:38 -0500 Received: from brigit.zk3.dec.com by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM) id AA08601; Tue, 27 Feb 1996 02:24:10 -0500 Received: by brigit.zk3.dec.com; (5.65v3.2/1.1.8.2/24Apr95-0109PM) id AA13565; Tue, 27 Feb 1996 02:26:18 -0500 Date: Tue, 27 Feb 1996 02:26:18 -0500 From: alex conta Message-Id: <9602270726.AA13565@brigit.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1483) Request for input - IPv6 Tunneling specs Cc: conta@zk3.dec.com, deering@parc.xerox.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The newest IPv6 tunneling draft that was recently submitted to the drafts directory, contains a rationale section of why there are cases in which is good to have a control over the number of recursive encapsulations a packet may be subject to, and two Appendix sections that contain examples of when iand how excessive recursive encapsulation may occur. This information was requested at the previous WG meeting in Dallas. The ratonale section, and the two Appendix sections have the text reproduced below. The authors of the draft would appreciate feedback on this list, or at the WG meeting in LA, regarding these sections. Thanks, Alex Note: free-exit tunnel a tunnel that has an unspecified exit-point address (unspecified IPv6 address). fixed-exit tunnel a tunnel that has a specified exit-point address (not the unspecified IPv6 address). are terms and definitions added to the new draft's terminology section. ------------- 4.1.4 Risk Factors in Recursive Encapsulation The cases which present a high risk of excessive recursive encapsulation are those in which a tunnel entry point node cannot discern between a valid and an invalid recursive encapsulation. Routing loops that cause tunnel packets reach nodes that were already reached before are certainly the major cause of the problem. But since routing loops exist, and happen, it is important to understand and describe, the cases in which the risk for excessive recursive encapsulation is higher. There are two significant elements that determine the risk factor of routing loop excessive recursive encapsulation: (a) the type of tunnel, (b) the type of route to the tunnel exit-point, which determines the packet forwarding through the tunnel, i.e. over the tunnel virtual-link. The type of tunnels which were identified as a high risk factor of excessive recursive encapsulation in routing loops are: "inner tunnels with identical exit-points". These tunnels can be: Conta & Deering Expires in six months [Page 17] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 "fixed-exit inner tunnels with different entry-points", or: "free-exit inner tunnels with different entry-points" Note that free-end inner tunnels fall always into the category of identical exit-point tunnels. Since the source and destination of an original packet is the main information used to decide whether to forward a packet through a tunnel or not, an excessive recursive encapsulation can be avoided in case of a single tunnel (non-inner), by checking that the packet to be encapsulated was not originated by the entry point node. This mechanism is suggested in [IPv4TUN]. However, this type of protection does not seem to work well in case of inner tunnels with different entry-points, and identical exit- points - see Appendix A. Inner tunnels with different entry-points, and identical exit-points introduce ambiguity in deciding whether to encapsulate or not a packet, when a packet encapsulated in an inner tunnel reaches the entry point node of an outer tunnel by means of a routing loop. Because the source of the tunnel packet is the inner tunnel entry point node which is different than the entry point node of the outer tunnel, the source address checking fails to detect an invalid encapsulation, and as consequence the tunnel packet gets encapsulated at the outer tunnel, each time it reaches it through the routing loop. The type of route to a tunnel exit-point node has been also identified as a high risk factor of excessive recursive encapsulation in routing loops. One type of route to a tunnel exit-point node is a route to a specified destination node, i.e. the destination is a valid specified IPv6 address (route to node). Such a route can be selected based on the longest path match of an original packet destination address with the destination address stored in the tunnel entry point node routing table entry for that route. The packet forwarded on such a route is first encapsulated and then forwarded towards the tunnel exit-point node. Another type of route to a tunnel exit-point node is a route to a specified prefix-net, i.e. the destination is a valid specified IPv6 prefix (route to net). Such a route can be selected based on the longest path match of an original packet destination address with the Conta & Deering Expires in six months [Page 18] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 prefix destination stored in the tunnel entry point node routing table entry for that route. The packet forwarded on such a route is first encapsulated and then forwarded towards the tunnel exit-point node. And finally another type of route to a tunnel exit-point is a default route, or a route to an unspecified destination, i.e. the destination is the "unspecified" IPv6 address. This route is selected when no- other match for the destination of the original packet has been found in the routing table. A tunnel that is the virtual-link of a default route, i.e. the link to a default router, is a "default tunnel". If the route to a tunnel exit-point is a route to node, the risk factor for excessive recursive encapsulation is minimum. If the route to a tunnel exit-point is a route to net, the risk factor for excessive recursive encapsulation is medium. There is a range of destination addresses that will match the prefix the route is associated with. If one or more inner tunnels with different tunnel entry-points have exit-point node addresses that match the route to net of an outer tunnel exit-point, then an excessive recursive encapsulation may occur if a tunnel packet gets diverted from inside such an inner tunnel to the entry point of the outer tunnel that has a route to its exit-point that matches the exit-point of an inner tunnel. If the route to a tunnel exit-point is a default route, the risk factor for excessive recursive encapsulation is maximum. Packets are forwarded through a default tunnel for lack of a better route. In many situations, forwarding through a default tunnel can happen for a wide range of destination addresses which at the maximum extent is the entire Internet minus the node's link. As consequence, it is likely that in a routing loop case, if a tunnel packet gets diverted from an inner tunnel to an outer tunnel entry point in which the tunnel is a default tunnel, the packet will be once more encapsulated, because the default routing mechanism will not be able to discern differently, based on the destination - see Appendix B. ... Appendix A Fixed-end Inner tunnels with different entry-points and identical exit-points Conta & Deering Expires in six months [Page 35] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 node node node node node node node a.a.1 b.b.1 c.c.1 ... x ... y ... d.d.1 z.z.1 * ** * ** tunnel I from b.b.1 to z.z.1 tunnel II from c.c.1 to z.z.1 1. node a.a.1: xmt: aa1/zz1 (source=aa1 destination=zz1) to bb1 2. node b.b.1: rcv: aa1/zz1 forwarding: anything that is destined to prefix 'z' => tunnel 'bb1/zz1' and send to cc1 xmt: bb1/zz1 | aa1/zz1 to cc1 3. node cc1: rcv: bb1/zz1 | aa1/zz1 forwarding: anything that is destined to prefix 'z' => tunnel 'cc1/zz1' and send to next router on the way to dd1 xmt: cc1/zz1 | bb1/zz1 | aa1/zz1 to next router on the way to dd1 4. before reaching node dd1, routing loop brings packet to bb1 loop:: node bb1: rcv: cc1/zz1 | bb1/zz1 | aa1/zz1 forwarding: anything that is destined to prefix 'z' => tunnel 'bb1/zz1' and send to cc1 xmt: bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1 to cc1 5. node cc1: Conta & Deering Expires in six months [Page 36] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 rcv: bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1 forwarding: anything that is destined to prefix 'z' => tunnel 'cc1/zz1' xmt: cc1/zz1 | bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1 to next router on the way to dd1 NOTE: check on source address = packet source DOES NOT eliminate the recursive encapsulation Appendix B Default Tunnel - maximum risk for excessive recursive encapsulation in case of routing loops. node node node node node node node a.a.1 b.b.1 c.c.1 d.d.1 e.e.1 f.f.1 z.z.1 * ** ** * tunnel I from b.b.1 to f.f.1 tunnel II from c.c.1 to e.e.1 1. node aa1: xmt: aa1/zz1 (source=aa1 destination=zz1) 2. node bb1: rcv: aa1/zz1 forwarding: anything that does not go to prefix 'a' or 'c' => tunnel 'bb1/ff1' and send to cc1 xmt: bb1/ff1 | aa1/zz1 3. node cc1: rcv: bb1/ff1 | aa1/zz1 forwarding: anything that does not go to prefix 'a', or 'b', or 'd' => tunnel 'cc1/ee1' and send to next router on the way to ee1 Conta & Deering Expires in six months [Page 37] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 xmt: cc1/ee1 | bb1/ff1 | aa1/zz1 to next router on the way to ee1 4. before reaching node ee1, routing loop brings packet to bb1 loop:: node bb1: rcv: cc1/ee1 | bb1/ff1 | aa1/zz1 forwarding: anything that does not go to prefix 'a' or 'c' => tunnel 'bb1/ff1' and send to cc1 xmt: bb1/ff1 | cc1/ee1 | bb1/ff1 | aa1/zz1 to cc1 5. node cc1: rcv: bb1/ff1 | cc1/ee1 | bb1/ff1 | aa1/zz1 forwarding: anything that does not go to prefix 'a', or 'b', or 'd' => tunnel 'cc1/ee1' xmt: cc1/ee1 | bb1/ff1 | cc1/ee1 | bb1/ff1 | aa1/zz1 NOTE: check on source address = packet source DOES NOT eliminate the recursive encapsulation ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 27 00:04:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16072; Tue, 27 Feb 96 00:04:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16066; Tue, 27 Feb 96 00:03:55 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07070; Tue, 27 Feb 1996 00:02:31 -0800 Received: by mercury.Sun.COM (Sun.COM) id AAA00843; Tue, 27 Feb 1996 00:02:30 -0800 From: conta@zk3.dec.com Received: from ralpha.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA21980; Tue, 27 Feb 1996 02:55:57 -0500 Received: from brigit.zk3.dec.com by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM) id AA08824; Tue, 27 Feb 1996 02:54:13 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65v3.2/1.1.8.2/24Apr95-0109PM) id AA13593; Tue, 27 Feb 1996 02:56:24 -0500 Message-Id: <9602270756.AA13593@brigit.zk3.dec.com> To: michael@stb.info.com Cc: ipng@sunroof.eng.sun.com, conta@zk3.dec.com Subject: (IPng 1484) Re: API: Why the IPv4 Arch/Model is not enough for IPv6 Date: Tue, 27 Feb 96 02:56:24 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In-reply-to: Message of: "Tue, 27 Feb 96 00:02:53 EST." Message-Id: <9602270502.AA05986@fwasted.zk3.dec.com> Subject: (IPng 1482) API: Why the IPv4 Arch/Model is not enough for IPv6 Received From: bound@zk3.dec.com Sent To: ipng@sunroof.eng.sun.com -------- Michael Gersten gave me permission to forward this to you... /jim Reply-To: michael@stb.info.com ---- Begin forwarded message: >Michael Gersten writes: >> The second, and more serious concern, is the API specs. Am I the >> only one that thinks that duplicating the V4 socket interface for V6 >> is a really bad idea? This is like telling the engineers who build cars I don't like trunks in cars. But neglect to provide a solution as to how the passengers hold their stuff in the car. - ----- I'm sorry, I thought I did mention a few ideas in that letter I wrote. Briefly, I think that the v4 socket interface destroys all concept of device independence, and is too low level for general application programming, as it hardwires socket ports (imagine hardwiring inode numbers in file open/close calls, or having to write code for hard drives differently from floppies, even if it's just a constant passed to an open call.) This is certainly an interesting point of view. Does the "one does all" call have some ressemblence with DECnet V use of calls related to "towers"? While I am sure that "one does all" call has its merits, I can see also the merits of the current calls, and why one would want to continue using them. Current calls give I think flexibility in relationship with addresses, ports, and transport protocols. A "one does all" call may be built out of extant calls, so one can do it, and use it, for suitable applications, and specifying it may be worth, but I would hesitate to exclude the latter (extant) for the sake of the first, or to recommend one versus the other in the specifications. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 27 08:58:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16272; Tue, 27 Feb 96 08:58:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16266; Tue, 27 Feb 96 08:58:26 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05528; Tue, 27 Feb 1996 08:57:01 -0800 Received: by mercury.Sun.COM (Sun.COM) id IAA15637; Tue, 27 Feb 1996 08:56:59 -0800 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G105) id AA09572; Tue, 27 Feb 96 09:56:55 MST; for ipng@sunroof.eng.sun.com Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA05990; Tue, 27 Feb 96 09:56:57 MST; for ipng@sunroof.eng.sun.com Message-Id: <9602271656.AA05990@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Tue, 27 Feb 1996 09:56:57 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 1485) Re: Thoughts on DNS and API Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Matt Thomas wrote:] > BSD 4.3 Reno introduced ancillary control data as the means to handle > these situations and it's shameful that we seem to be inventing a new > wheel when we are already have a perfectly fine wheel. [Francis Dupont wrote:] > I agree Matt: I believe the usage of msg_control is far better > than the socket array. My reason for preferring the existing spec over the 4.4BSD control message technique is *simplicity*. Using recvmsg() with control information takes a lot more user code. You have to allocate the iovec{} and the msg{} and then fill in both structures with the correct information. This is a pain. As an example, I present the code that receives a UDP datagram and then prints the source and destination IP addresses. 4.4BSD provides a way to do this if the IP_RECVDSTADDR socket option is enabled. With the existing IPv6 sockets API the destination IP address is returned if the datagram is not source routed and if room is provided to return two socket address structures. (Note: this is not working code; the 4.4BSD IPv4 code is from a working program, but I copied it over so there might be missing definitions. The purpose is to show the coding differences.) I count about 8 lines of code for the proposed approach, and about 28 if control information is used (I count the error handling code in both). I think the proposed API method is quite simple and straight forward. Rich Stevens ------------------------------------------------------------------------ /* Receive UDP datagram and then print source and destination IP addresses; uses hypothetical way of returning destination IP address that is similar to what the IPv6 sockets API proposes */ struct sockaddr_in cliaddr[2]; int sockfd, clilen, nread; clilen = sizeof(cliaddr); if ( (nread = recvfrom(sockfd, rbuf, readlen, 0, (struct sockaddr *) &cliaddr, &clilen)) < 0) err_sys("datagram receive error"); if (clilen != sizeof(cliaddr)) err_quit("incorrect length (%d) != %d", clilen, sizeof(cliaddr)); printf("from %s, destination IP address: %s", inet_ntoa(cliaddr[0].sin_addr), inet_ntoa(cliaddr[1].sin_addr)); ------------------------------------------------------------------------ /* Receive UDP datagram and then print source and destination IP addresses; uses 4.4BSD way of returning destination IP address */ struct iovec iov[1]; struct msghdr msg; struct sockaddr_in cliaddr; int sockfd, clilen, nread; struct in_addr dstinaddr; static struct cmsghdr *cmptr = NULL; #define CONTROLLEN (sizeof(struct cmsghdr) + sizeof(struct in_addr)) iov[0].iov_base = rbuf; iov[0].iov_len = readlen; msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_name = &cliaddr; msg.msg_namelen = sizeof(cliaddr); if (cmptr == NULL && (cmptr = malloc(CONTROLLEN)) == NULL) err_sys("malloc error for control buffer"); msg.msg_control = (caddr_t) cmptr; /* for dest address */ msg.msg_controllen = CONTROLLEN; msg.msg_flags = 0; /* flags returned here */ if ( (nread = recvmsg(sockfd, &msg, 0)) < 0) err_sys("datagram receive error"); if (cmptr->cmsg_len != CONTROLLEN) err_quit("control length (%d) != %d", cmptr->cmsg_len, CONTROLLEN); if (cmptr->cmsg_level != IPPROTO_IP) err_quit("control level != IPPROTO_IP"); if (cmptr->cmsg_type != IP_RECVDSTADDR) err_quit("control type != IP_RECVDSTADDR"); bcopy(CMSG_DATA(cmptr), &dstinaddr, sizeof(struct in_addr)); printf("from %s, destination IP address: %s", inet_ntoa(cliaddr.sin_addr), inet_ntoa(dstinaddr)); ------------------------------------------------------------------------ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 27 09:13:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16298; Tue, 27 Feb 96 09:13:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16292; Tue, 27 Feb 96 09:13:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06921; Tue, 27 Feb 1996 09:09:18 -0800 Received: by mercury.Sun.COM (Sun.COM) id JAA19967; Tue, 27 Feb 1996 09:09:11 -0800 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id JAA21424; Tue, 27 Feb 1996 09:09:06 -0800 Message-Id: <199602271709.JAA21424@mailhost.Ipsilon.COM> To: Bob Gilligan Cc: Matt Thomas , ipng@sunroof.eng.sun.com Subject: (IPng 1486) Re: Thoughts on DNS and API In-Reply-To: Your message of "Mon, 26 Feb 1996 19:13:59 PST." Date: Tue, 27 Feb 1996 09:09:05 -0800 From: Dennis Ferguson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I strongly disagree. While most of the BSD API specification is fine as >> it is, a few places (specifically source routes and "receive/sending" >> interface) need to be rethought as they "break" the de-facto BSD API model. > > I'd like to understand how the current draft of the API spec "breaks" > the BSD API model. Could you elaborate? Perhaps because the analogous functionality already existed for IPv4 in later model (i.e. post 1989?) BSD kernels, but the draft chose an entirely different and incompatable method for IPv6? >> BSD 4.3 Reno introduced ancillary control data as the means to handle >> these situations and it's shameful that we seem to be inventing a new >> wheel when we are already have a perfectly fine wheel. > > We discussed this idea a bit before, but I still have a couple of > questions about how it would work: > > First, how would it work with TCP? The application certainly could > use sendmsg() on a TCP socket to specify a source route to use *after* > the connection had been established. How would an application specify > a source route to be used at connect() time? What about a passively > accepted connection? Didn't we have pretty much exactly this discussion before? To: Bob Gilligan Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 1273) Re: New draft of API spec is now available Date: Wed, 24 Jan 1996 21:18:04 -0800 From: Dennis Ferguson >> For Digital UNIX, I'm planning on using the "control data" ability >> which is part of BSD 4.3 Reno or later. >> . . . >> so this can be equally used for TCP. > > Regarding using the "control data" field via recvmsg() for the other > options, I think that's an interesting idea. But I didn't follow > exactly how this would work with TCP sockets. Is the thought that the > application would use recvmsg() on the (AF_INET6, SOCK_STREAM) socket, > and there would be a one-to-one correspondence between received TCP > segments (and their associated IP options) and returns from recvmsg()? Most of this information is often uninteresting to TCP applications since TCP automatically turns source routes around and the like. There is a getsockopt() call to determine the values associated with a connection, if you really want to know them, and a setsockopt() call to (re)set them to something else. This seems sufficient. Why do you think this is insufficient? > Second, have you given any thought to how would it work on systems > that are based on 4.3 BSD Tahoe and earlier releases, which does not > have the control message feature? In /sys/sys/socket.h, mostly s/msg_accrights/msg_control/. The user-visible change from Tahoe to Reno was mostly to rename a couple of very-seldom-used (or never-used?) fields in the struct msghdr. You'll need kernel code to support this, but since Tahoe networking also lacks classless, protocol-independent forwarding table support you'll be doing a lot of work in the kernel anyway. > These are two issues that we thought about and addressed in the > current API spec. It is hard to see how either of these issues is a big enough problem to warrant inventing a whole new thing. Perhaps you could explain this, the current API spec doesn't seem to? Dennis Ferguson ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 27 10:32:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16438; Tue, 27 Feb 96 10:32:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16432; Tue, 27 Feb 96 10:31:46 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19624; Tue, 27 Feb 1996 10:30:21 -0800 Received: by mercury.Sun.COM (Sun.COM) id KAA20480; Tue, 27 Feb 1996 10:30:18 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.4/8.7.1) id NAA00684 for ipng@sunroof.Eng.Sun.COM; Tue, 27 Feb 1996 13:30:16 -0500 Received: via switchmail; Tue, 27 Feb 1996 13:30:15 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 27 Feb 1996 13:29:39 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 27 Feb 1996 13:29:33 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 27 Feb 1996 13:29:27 -0500 (EST) Message-Id: Date: Tue, 27 Feb 1996 13:29:27 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1487) Re: Thoughts on DNS and API In-Reply-To: References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Gilligan writes: > Second, have you given any thought to how would it work on systems > that are based on 4.3 BSD Tahoe and earlier releases, which does not > have the control message feature? I would say the authors of such systems should get with the program and implement whatever features are necessary to support IPv6 and its API. As this list necessarily has a higher concentration of implementors of IPv6 stacks, I suspect it has a natural tendency to make life easier for IPv6 stack implementors. As an applications person, I would like to push the perspective that life be made easier for IPv6 applications implementors. I want to deal with as few API's as possible. Having separate 4.3 and 4.4 APIs for IPv6 (as is the case in the current draft) is a burden for applications developers. In the best possible world, I would write to the one IPv6 API, then include a stock compatibility library for mapping that API onto the IPv4 API for those systems that do not yet support IPv6. At the IPv6 implementors panel last IETF, I was particularly struck by the comment from the implementor (I forget who) that mentioned that picking up the 4.4 stuff at the same time as implementing IPv6 was no big effort. I would like to encourage this approach of forging ahead. There is a difference between providing backwards compatibility and dragging your feet. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 27 12:05:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16607; Tue, 27 Feb 96 12:05:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16601; Tue, 27 Feb 96 12:05:40 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06054; Tue, 27 Feb 1996 12:04:17 -0800 Received: by mercury.Sun.COM (Sun.COM) id MAA00691; Tue, 27 Feb 1996 12:04:14 -0800 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G105) id AA15226; Tue, 27 Feb 96 13:03:45 MST; for ipng@sunroof.eng.sun.com Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA08535; Tue, 27 Feb 96 13:03:30 MST; for ipng@sunroof.eng.sun.com Message-Id: <9602272003.AA08535@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Tue, 27 Feb 1996 13:03:29 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: bound@zk3.dec.com, Bob Gilligan , ipng@sunroof.eng.sun.com Subject: (IPng 1488) Re: Thoughts on DNS and API Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Feb 23, 12:22pm you write:] > > flags to inform an applications source routes are being used and then > use the msg_buffer to pass source routes. As opposed to the way we are > presently doing it by sending an array of socket addresses. There would > be a set of iovec ptrs to the source route in a structure for the source > route. As indicated in my previous email, I like the way the current spec does this. Much simpler for the user. > getconninfo(): > I think this needs to be in our spec now. POSIX will put it in if we > don't. I think it wise our API spec be as close to what POSIX will do > as possible. getconninfo() will be used by POSIX IMHO. I agree with this. When I compared the POSIX getaddrinfo() and getconninfo() they were nearly identical, just different names for the same things. Why not just pick up the POSIX.12 definition and include it in the IPv6 sockets API? (I see Keith Sklower's I-D on getconninfo() has already expired.) Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 27 15:19:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16774; Tue, 27 Feb 96 15:19:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16766; Tue, 27 Feb 96 15:19:32 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14201; Tue, 27 Feb 1996 15:18:07 -0800 Received: by mercury.Sun.COM (Sun.COM) id PAA07766; Tue, 27 Feb 1996 15:18:04 -0800 Received: from muggsy.lkg.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA01522; Tue, 27 Feb 1996 18:10:04 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA27073; Tue, 27 Feb 1996 18:10:02 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id XAA11394; Tue, 27 Feb 1996 23:34:40 GMT Message-Id: <199602272334.XAA11394@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: Bob Gilligan Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1489) Re: Thoughts on DNS and API In-Reply-To: Your message of "Mon, 26 Feb 1996 19:13:59 PST." X-Mailer: exmh version 1.5omega 10/6/94 Date: Tue, 27 Feb 1996 23:34:31 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In , you wrote: > > > > I would take this to mean lack of support for any serious changes. > > > > I strongly disagree. While most of the BSD API specification is fine as > > it is, a few places (specifically source routes and "receive/sending" > > interface) need to be rethought as they "break" the de-facto BSD API model. > > I'd like to understand how the current draft of the API spec "breaks" > the BSD API model. Could you elaborate? The idea of returning multiple sockaddrs instead of just one is a major warping of the API. > > BSD 4.3 Reno introduced ancillary control data as the means to handle > > these situations and it's shameful that we seem to be inventing a new > > wheel when we are already have a perfectly fine wheel. > > We discussed this idea a bit before, but I still have a couple of > questions about how it would work: > > First, how would it work with TCP? The application certainly could > use sendmsg() on a TCP socket to specify a source route to use *after* > the connection had been established. How would an application specify > a source route to be used at connect() time? What about a passively > accepted connection? As Dennis has said, this can be done via setsockopts (and probably should given that is one has to be once per connection). Alternatively, you can do a sendmsg() with only control data before the socket is connected (the current BSD 4.4lite code allows that). For incoming connections, you can do a recvmsg after the accept and then a sendmsg (if you want to use a different source route). > Second, have you given any thought to how would it work on systems > that are based on 4.3 BSD Tahoe and earlier releases, which does not > have the control message feature? No. And, frankly, I don't care. BSD 4.3-Reno (and Net/2 and ...) have been out for long enough that you should be compatible the 4.4BSD socket infrastructure. If you aren't yet compatible, then as part of implementing IPv6 is also upgrading your socket infrastructure. Anyways, it's easier to implement IPv6 on a BSD 4.4lite infrastructure than on BSD 4.3 Tahoe so hopefully one would upgrade for that reason alone. One other (which won't be worth much to those using 4.3 Tahoe sockets) reason for opposing the use of multiple sockaddrs is that it requires significant changes to the protocol-independent socket framework. The addition of the sa_len field in 4.3 Reno (while needed) has resulted in a great of switched between "old" and "new" sockaddr formats. This is currently managable since the len/family are at the start of a sockaddr and there's, at most, only one sockaddr to worry about per call. Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 27 15:37:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16805; Tue, 27 Feb 96 15:37:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16799; Tue, 27 Feb 96 15:37:25 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17325; Tue, 27 Feb 1996 15:35:57 -0800 Received: by mercury.Sun.COM (Sun.COM) id PAA13319; Tue, 27 Feb 1996 15:35:55 -0800 Received: from muggsy.lkg.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA30934; Tue, 27 Feb 1996 18:25:47 -0500 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA27124; Tue, 27 Feb 1996 18:25:45 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id XAA11471; Tue, 27 Feb 1996 23:50:24 GMT Message-Id: <199602272350.XAA11471@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: Richard Stevens Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1490) Re: Thoughts on DNS and API In-Reply-To: Your message of "Tue, 27 Feb 1996 09:56:57 MST." <9602271656.AA05990@gemini.tuc.noao.edu> X-Mailer: exmh version 1.5omega 10/6/94 Date: Tue, 27 Feb 1996 23:50:19 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In <9602271656.AA05990@gemini.tuc.noao.edu> , you wrote: > [Matt Thomas wrote:] > > BSD 4.3 Reno introduced ancillary control data as the means to handle > > these situations and it's shameful that we seem to be inventing a new > > wheel when we are already have a perfectly fine wheel. > > [Francis Dupont wrote:] > > I agree Matt: I believe the usage of msg_control is far better > > than the socket array. > > My reason for preferring the existing spec over the 4.4BSD control message > technique is *simplicity*. Using recvmsg() with control information takes > a lot more user code. You have to allocate the iovec{} and the msg{} and > then fill in both structures with the correct information. This is a pain. Yes it's a pain. Anything that's extensible is going to be more complex than something that isn't. My problem is that you are (probably) changing a system call interface in an incompatible manner. If you want those semantics that are currently in the API spec, write a set of library routines (ipv6_sendto(), ipv6_recvfrom()) to do it and the hide the method of implementation. But don't hack the syscall interface itself. Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 27 16:05:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16830; Tue, 27 Feb 96 16:05:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16824; Tue, 27 Feb 96 16:05:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22909; Tue, 27 Feb 1996 16:03:58 -0800 Received: by mercury.Sun.COM (Sun.COM) id FAA01299; Tue, 27 Feb 1996 05:09:25 -0800 Received: from tlaser.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA11525; Tue, 27 Feb 1996 08:02:55 -0500 Received: by tlaser.zk3.dec.com; (5.65v3.2/1.1.8.2/06Mar95-1016AM) id AA08582; Tue, 27 Feb 1996 08:02:40 -0500 Date: Tue, 27 Feb 1996 08:02:40 -0500 From: Jack McCann USG Message-Id: <9602271302.AA08582@tlaser.zk3.dec.com> To: Bob.Gilligan@Eng, Francis.Dupont@inria.fr Subject: (IPng 1491) Re: Thoughts on DNS and API Cc: ipng@sunroof.eng.sun.com, mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: >> I have noted a second point where >> compatibility is not good: it is a good idea to make >> hostname2addr/addr2hostname MP capable but the way >> the space is allocated introduces a lot of memory leaks >> (freehostent() must be called at all the exit points, >> included hidden ones like in signal processing...). >> I propose to give the space as an optional argument >> (another one :-). The size should be a standard define >> (in /usr/include/netdb.h) with a provision for extension >> and bad alignment. Bob Gilligan responded: >I agree it would be simpler to have the application provide the buffer >for the function to store the addresses in, but I think that approach >has a problem: The application does not know how big to make the >buffer. The application doesn't know at the time it calls >hostname2addr() whether the function is going to return 1 address, or >400 addresses, or more. > >Bob. I agree with Francis, requiring freehostent() where none is required by gethostbyname/addr today increases the likelihood of memory leaks. It also adds a degree of difficulty when porting existing applications. Bob also makes a good point that the app does not know how big to make its buffer. Both concerns can be addressed. Move hostname2addr/addr2hostname back to the model where they allocate static storage and return pointers to it. Let the library deal with the thread-safety issue (e.g. by use of per-thread static areas). This eliminates the need for freehostent(), does not require the app to provide a buffer, and simplifies porting by maintaining the current model. - Jack ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 27 16:19:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16877; Tue, 27 Feb 96 16:19:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16871; Tue, 27 Feb 96 16:19:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26000; Tue, 27 Feb 1996 16:18:13 -0800 Received: by mercury.Sun.COM (Sun.COM) id QAA24994; Tue, 27 Feb 1996 16:18:10 -0800 Received: from as-node.jena.thur.de (uucp@localhost) by jengate.thur.de (8.7.3/8.7.1) with BSMTP id BAA23958 for ipng@sunroof.Eng.Sun.COM; Wed, 28 Feb 1996 01:18:07 +0100 Date: Tue, 27 Feb 1996 12:41:54 +0100 (MET) From: Lutz Donnerhacke To: ipng@sunroof.eng.sun.com Subject: (IPng 1492) Re: Not so random local tokens In-Reply-To: <20527.825348358@munnari.OZ.AU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 27 Feb 1996, Robert Elz wrote: > * huitema@pax.inria.fr (Christian Huitema) wrote: [...allowing 0x21 to 0x5f as valid hostname chars...] > > Isn't that cool ? > So cool its frozen, rock solid, and will take years (hopefully) > to defrost. I have a dream that some gateways between STMP and FTN (or similar) will implement easy tests like bool ishostnamechar(char c) { return !((c - 0x20) & 0xC0); } I have a dream that FTN overlay networks will alloc hostnames like 2:2485/23. I have a dream that RfC 2121 will define 'IP over Fidian carriers'. I have a dream that '*' will be RfCed for mobile communication. I have a dream that '*' will be RfCed as 'everone @ everywhere.spam.com'. I'd like to switch to a new domain name: lutz@as-node.*.th?r.de. Sorry for kidding. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Feb 27 17:07:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16961; Tue, 27 Feb 96 17:07:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16955; Tue, 27 Feb 96 17:07:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04829; Tue, 27 Feb 1996 17:05:50 -0800 Received: by mercury.Sun.COM (Sun.COM) id FAA01124; Tue, 27 Feb 1996 05:07:42 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id OAA29870; Tue, 27 Feb 1996 14:06:58 +0100 (MET) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id OAA08174; Tue, 27 Feb 1996 14:06:56 +0100 Message-Id: <199602271306.OAA08174@givry.inria.fr> From: Francis Dupont To: Bob Gilligan Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1493) Re: Thoughts on DNS and API In-Reply-To: Your message of Mon, 26 Feb 1996 19:22:46 PST. Date: Tue, 27 Feb 1996 14:06:45 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > ... The size should be a standard define > (in /usr/include/netdb.h) with a provision for extension > and bad alignment. I agree it would be simpler to have the application provide the buffer for the function to store the addresses in, but I think that approach has a problem: The application does not know how big to make the buffer. The application doesn't know at the time it calls hostname2addr() whether the function is going to return 1 address, or 400 addresses, or more. => I propose to give enough space and to specify in a standard define what is enough. It is already the case for addr2ascii and the defines are: #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 We can do the same thing or add a space field to the hp structure... If the buffer is allocated in the stack then it will be freed in all cases at return (which is difficult to do with freehostent). Regards Francis.Dupont@inria.fr PS: the problem with addr2ascii was more multiple calls than MP but the same thing can be used here. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 28 06:24:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17363; Wed, 28 Feb 96 06:24:26 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17357; Wed, 28 Feb 96 06:24:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06216; Wed, 28 Feb 1996 06:22:49 -0800 Received: by mercury.Sun.COM (Sun.COM) id GAA01269; Wed, 28 Feb 1996 06:22:49 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9814; Wed, 28 Feb 96 09:22:49 EST Received: by RTP (XAGENTA 4.0) id 0573; Wed, 28 Feb 1996 09:22:44 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA19646; Wed, 28 Feb 1996 09:22:43 -0500 Message-Id: <9602281422.AA19646@cichlid.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1494) BSD API spec/Path MTU Date: Wed, 28 Feb 1996 09:22:43 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The PMTU draft implies that there are times when packets will need to be fragmented, but that in general the upper layer should avoid needing to fragment by adjusting the size of the packets it sends. The exact times when the fragment header should or should not be used are upper-layer and application dependent. It seems that for UDP-type applications, the API will need appropriate hooks that allow an application to specify whether a fragment header should be used, or whether the caller should be notified that the packet is too big, so that it could resend the data using smaller packets. For example, when sending a packet, an appliction might want: a) the system to not send the packet, return an error, and indicate what the proper packet size is. Or b) it does want the packet fragmented. Or, c) go ahead and fragment this packet, but indicate what MTU should be used next time. This sort of control is probably needed on a packet-by-packet basis. Shouldn't this be in the API spec? If it isn't, UDP-based applications will have a difficult time determining an optimal packet size. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Feb 28 18:44:18 1996 Return-Path: Received: by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17936; Wed, 28 Feb 96 18:44:18 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17930; Wed, 28 Feb 96 18:44:02 PST Received: from kandinsky (kandinsky [129.146.86.117]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id SAA05860; Wed, 28 Feb 1996 18:41:33 -0800 (PST) Date: Wed, 28 Feb 1996 18:48:11 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1495) Re: Thoughts on DNS and API To: Dennis Ferguson Cc: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > We discussed this idea a bit before, but I still have a couple of > > questions about how it would work: > > > > First, how would it work with TCP? The application certainly could > > use sendmsg() on a TCP socket to specify a source route to use *after* > > the connection had been established. How would an application specify > > a source route to be used at connect() time? What about a passively > > accepted connection? > > Didn't we have pretty much exactly this discussion before? > . . . > Date: Wed, 24 Jan 1996 21:18:04 -0800 > From: Dennis Ferguson > > . . . > > Regarding using the "control data" field via recvmsg() for the other > > options, I think that's an interesting idea. But I didn't follow > > exactly how this would work with TCP sockets. Is the thought that the > > application would use recvmsg() on the (AF_INET6, SOCK_STREAM) socket, > > and there would be a one-to-one correspondence between received TCP > > segments (and their associated IP options) and returns from recvmsg()? > > Most of this information is often uninteresting to TCP applications > since TCP automatically turns source routes around and the like. There > is a getsockopt() call to determine the values associated with a connection, > if you really want to know them, and a setsockopt() call to (re)set them > to something else. This seems sufficient. > > Why do you think this is insufficient? I did not say that it was insufficient. I was just asking for clarification. In the exchange above, it wasn't clear to me whether you were discussing source routing or IP options in general. The "address array" proposal is documented and worked out in detail in the current draft of the API spec, while the "control message" proposal is only explained in a couple of email messages. I'd like to see the latter proposal flushed out a bit. >From what I understand of the "control message" proposal, TCP and UDP applications would use somewhat different models to specify a source route: TCP applications would specify the route via a setsockopt() call, while the UDP application would specify the route via the control message field of its sendto() call. Say for example that a TCP application wished to specify a source route in order to select a particular service provider. That application would need to make a setsockopt() call specifying the source route before calling connect(). But if the application wished to send a UDP packet via a source route, it would include the source route msg_control field of its sendmsg() call. With the "address array" proposal, TCP and UDP applications use the same model: Applications can pass the same source route address array into a connect() call for a TCP socket as they would pass into a sendto() or sendmsg() call for a UDP socket. My sense is that a single programming model for TCP and UDP is an advantage since it is more understandable by the average programmer. 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 Wed Feb 28 20:48:01 1996 Return-Path: Received: by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17986; Wed, 28 Feb 96 20:48:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17980; Wed, 28 Feb 96 20:47:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08341; Wed, 28 Feb 1996 20:46:17 -0800 Received: by mercury.Sun.COM (Sun.COM) id UAA15529; Wed, 28 Feb 1996 20:46:17 -0800 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id XAA00664; Wed, 28 Feb 1996 23:45:54 -0500 Message-Id: <199602290445.XAA00664@thumper.bellcore.com> To: ip-atm@nexen.com Cc: gja@thumper.bellcore.com, ipng@sunroof.eng.sun.com Subject: (IPng 1496) IPv6 over ATM/NBMA Date: Wed, 28 Feb 1996 23:45:43 -0500 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a question and heads-up combined: Most people are probably aware that the IP-ATM working group's charter now includes IPv6 over ATM. We have a session in LA covering this very topic because it encompasses a number of inter-twined areas. We had some vigorous discussions during late Dec, early January on the issue of generating link-local tokens (interface IDs), and there's an outstanding issue of how to provide Neighbour Discovery (or how _much_ to provide). I was poking around looking for the relevant I-Ds to pre-read before this meeting and came up with: draft-ietf-ipatm-ipv6nd-01.txt draft-schulter-ipv6atm-framework-01.txt and draft-ahl-ipv6-nbma-00.txt My heads-up is to request people interested in this area to pre-read these I-Ds before the meeting. My question is to people interested in this area - is there a relevant I-D I've missed? Could you post additions here? (e.g. I suspect draft-ietf-ipngwg-iid-01.txt may have some impact on any token generation scheme, but I haven't thought it through yet.) cheers, gja _________________________________________________________________________ Grenville Armitage gja@thumper.bellcore.com Bellcore, 445 South St. http://gump.bellcore.com:8000/~gja/home.html Morristown, NJ 07960 USA (voice) +1 201 829 2635 {.. 2504 (fax)} ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 05:47:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18216; Thu, 29 Feb 96 05:47:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18210; Thu, 29 Feb 96 05:47:40 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12913; Thu, 29 Feb 1996 05:46:12 -0800 Received: by mercury.Sun.COM (Sun.COM) id FAA15278; Thu, 29 Feb 1996 05:46:13 -0800 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id IAA14467; Thu, 29 Feb 1996 08:46:03 -0500 (EST) Received: from phish.nexen.com (phish.nexen.com [204.249.99.14]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id IAA16666; Thu, 29 Feb 1996 08:46:02 -0500 (EST) Received: from localhost (malis@localhost) by phish.nexen.com (8.7.3/8.7.3) with SMTP id IAA19382; Thu, 29 Feb 1996 08:45:57 -0500 (EST) Message-Id: <199602291345.IAA19382@phish.nexen.com> To: Grenville Armitage Cc: ip-atm@nexen.com, gja@thumper.bellcore.com, ipng@sunroof.eng.sun.com, malis@nexen.com Subject: (IPng 1497) Re: IPv6 over ATM/NBMA In-Reply-To: Your message of "Wed, 28 Feb 1996 23:45:43 EST." <199602290445.XAA00664@thumper.bellcore.com> Date: Thu, 29 Feb 1996 08:45:57 -0500 From: "Andrew G. Malis" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville, Thanks for posting this. You beat me to it! :-) > Most people are probably aware that the IP-ATM working group's > charter now includes IPv6 over ATM. We have a session in LA > covering this very topic because it encompasses a number of > inter-twined areas. ... > I was poking around looking for the relevant I-Ds to pre-read > before this meeting and came up with: > draft-ietf-ipatm-ipv6nd-01.txt > draft-schulter-ipv6atm-framework-01.txt > and > draft-ahl-ipv6-nbma-00.txt That is the complete list of drafts to be discussed in the joint session. > My heads-up is to request people interested in this area to > pre-read these I-Ds before the meeting. Ditto. It also can't hurt to have also read draft-ietf-ipngwg-discovery-05.txt for background preparation. I plan on posting the agendas for rolc, ipatm, and the two joint sessions later today (they're almost! complete). Cheers, 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 Thu Feb 29 06:49:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18237; Thu, 29 Feb 96 06:49:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18231; Thu, 29 Feb 96 06:48:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17463; Thu, 29 Feb 1996 06:47:23 -0800 Received: by mercury.Sun.COM (Sun.COM) id GAA26538; Thu, 29 Feb 1996 06:47:23 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA16427; Thu, 29 Feb 1996 09:40:23 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24278; Thu, 29 Feb 1996 09:40:22 -0500 Message-Id: <9602291440.AA24278@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1498) Dynamic Reassign IP Addr for TCP/UDP Date: Thu, 29 Feb 96 09:40:22 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I will be presenting our ideas from draft-bound-ipv6-ip-addr-00.txt at some point at one of the ipng meetings in L.A. If you could read the draft before the meeting Pedro and I would really appreciate that as we need to discuss it with the community. The slides I will be using as a dicussion point for the meeting can be copied anon ftp at: gatekeeper.dec.com/pub/DEC/IPv6/dynip.ps We would like to have a working specification model to begin impelementation verification by the next IETF June 24-29 at Montreal. We will get mail list input, but would like to get some in person input at the L.A. meeting. I won't see much mail now until I get to the IETF so all have a safe trip and just because I did not respond to a discussion don't mean I agree. take care and thanks, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 06:49:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18249; Thu, 29 Feb 96 06:49:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18238; Thu, 29 Feb 96 06:49:18 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17481; Thu, 29 Feb 1996 06:47:51 -0800 Received: by mercury.Sun.COM (Sun.COM) id GAA26627; Thu, 29 Feb 1996 06:47:51 -0800 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA01948; Thu, 29 Feb 1996 09:39:06 -0500 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24190; Thu, 29 Feb 1996 09:38:59 -0500 Message-Id: <9602291438.AA24190@fwasted.zk3.dec.com> To: Bob Gilligan Cc: Dennis Ferguson , ipng@sunroof.eng.sun.com Subject: (IPng 1499) Re: Thoughts on DNS and API In-Reply-To: Your message of "Wed, 28 Feb 96 18:48:11 PST." Date: Thu, 29 Feb 96 09:38:59 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk %> if you really want to know them, and a setsockopt() call to (re)set them %> to something else. This seems sufficient. %> %> Why do you think this is insufficient? %I did not say that it was insufficient. I was just asking for %clarification. In the exchange above, it wasn't clear to me whether %you were discussing source routing or IP options in general. Well most of the issues are concerned with source routing. But the options can be processed in ancillary data too in send/recvmsg(). >The "address array" proposal is documented and worked out in detail >in the current draft of the API spec, while the "control message" >proposal is only explained in a couple of email messages. I'd like to >see the latter proposal flushed out a bit. Well right now we are having a discussion. If after the L.A. meeting we still have this dicussion in person then I think documenting the opposing scenario is a worthwhile work effort. >>From what I understand of the "control message" proposal, TCP and UDP >applications would use somewhat different models to specify a source >route: TCP applications would specify the route via a setsockopt() >call, while the UDP application would specify the route via the >control message field of its sendto() call. They would both use the same model. The source router could be expressed via the flags. >Say for example that a TCP application wished to specify a source >route in order to select a particular service provider. That >application would need to make a setsockopt() call specifying the >source route before calling connect(). But if the application wished >to send a UDP packet via a source route, it would include the source >route msg_control field of its sendmsg() call. With ancillary data the flag to specify a source route is present for TCP or UDP. If the app is not using the source route or expects one it does not use the option of setting the flags. >With the "address array" proposal, TCP and UDP applications use the >same model: Applications can pass the same source route address array >into a connect() call for a TCP socket as they would pass into a >sendto() or sendmsg() call for a UDP socket. Your separating TCP an UDP and that is not necessary for transmission of messages. The connect() is an issue. I am not clear a source route on connect() is a valid use of source routes. I can see it on send/recv functions. It could be on connect() the app must do a setsockopt and then put the actual source route into the kernel structures. This way the connect() call remains the same. >My sense is that a single programming model for TCP and UDP is an advantage >since it is more understandable by the average programmer. I don't see it that the use of ancillary data requiring two models. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 07:26:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18270; Thu, 29 Feb 96 07:26:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18264; Thu, 29 Feb 96 07:26:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21014; Thu, 29 Feb 1996 07:25:04 -0800 Received: by mercury.Sun.COM (Sun.COM) id HAA04894; Thu, 29 Feb 1996 07:24:59 -0800 Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA15708; Thu, 29 Feb 96 09:28:04 CST Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA04461; Thu, 29 Feb 96 09:26:35 CST Date: Thu, 29 Feb 96 09:26:35 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9602291526.AA04461@anubis.network.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1500) Re: Thoughts on DNS and API Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk WHen there are several views on how to do something, one should take all the views, and roll them into the standard as various and several ways to do whatever it is you're trying to do. This is how people know it's a Real Standard, and that it should be viewed with suspicion. Andrew ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 07:58:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18290; Thu, 29 Feb 96 07:58:06 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18284; Thu, 29 Feb 96 07:57:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24511; Thu, 29 Feb 1996 07:56:23 -0800 Received: by mercury.Sun.COM (Sun.COM) id HAA12219; Thu, 29 Feb 1996 07:56:22 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.4/8.7.1) id KAA00586 for ipng@sunroof.eng.sun.com; Thu, 29 Feb 1996 10:56:19 -0500 Received: via switchmail; Thu, 29 Feb 1996 10:56:18 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 29 Feb 1996 10:55:26 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 29 Feb 1996 10:55:24 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 29 Feb 1996 10:55:22 -0500 (EST) Message-Id: Date: Thu, 29 Feb 1996 10:55:22 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1501) Re: Thoughts on DNS and API In-Reply-To: References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Gilligan writes: > From what I understand of the "control message" proposal, TCP and UDP > applications would use somewhat different models to specify a source > route: TCP applications would specify the route via a setsockopt() > call, while the UDP application would specify the route via the > control message field of its sendto() call. On one hand, TCP and UDP already use somewhat different models: UDP uses recvfrom()/sendto(), TCP uses connect()/accept(). On the other hand, I get uncomfortable with the idea of specifying addressing information with setsockopt(). A more analogous approach would be to use the msg_control field of connectmsg()/acceptmsg() calls. (or better yet to connect/accept using sendmsg()/recvmsg()) > With the "address array" proposal, TCP and UDP applications use the > same model: Applications can pass the same source route address array > into a connect() call for a TCP socket as they would pass into a > sendto() or sendmsg() call for a UDP socket. Personally, I consider an "address array" an address. It specifies where the data comes from/goes to. The big problem I have with the current API are the three socket options that affect the interpretation of addresses and the fact that if some process (such as inetd) out of your control hands you a socket with the options set wrong, you're screwed and can't get the address information you need. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 08:57:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18349; Thu, 29 Feb 96 08:57:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18318; Thu, 29 Feb 96 08:24:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27658; Thu, 29 Feb 1996 08:22:34 -0800 Received: by mercury.Sun.COM (Sun.COM) id IAA19061; Thu, 29 Feb 1996 08:22:33 -0800 Received: from lotos.gmd.de (actually lotos.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Thu, 29 Feb 1996 17:22:09 +0100 Received: by lotos.gmd.de (5.x/SMI-SVR4) id AA18113; Thu, 29 Feb 1996 17:19:45 +0100 Date: Thu, 29 Feb 1996 17:19:45 +0100 From: smirnow@fokus.gmd.de (Michael Smirnow) Message-Id: <9602291619.AA18113@lotos.gmd.de> To: ip-atm@nexen.com Subject: (IPng 1502) Re: IPv6 over ATM/NBMA Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On G. Armitage's message (Thu Feb 29 06:04:28 1996 - see below): except Armitage's contributions and well known RFCs (from IPATM, IDMR, ROLC,...) I found also useful (at least for me) the following: Endpoint Identifier Destination Option [draft-ietf-nimrod-eid-00]: it treats routing related info (endpoint IDs) separately from topology (locators) - results in scalability; DNS Resource Records for Nimrod Routing Architecture [draft-ietf-nimrod-dns-01]: DNS Resource Records descriptions for the above; IPv6 Stateless Address Autoconfiguration [draft-ietf-addrconf-ipv6-auto-06]: proposes how host can autoconfigure its interfaces in IPv6 An ATMARP Client Autoconfiguration [draft-marcinik-ipatm-auto-arp-00]: cooperation of Classical ATMARP servers (simple cache consistency). Michael > Most people are probably aware that the IP-ATM working group's > charter now includes IPv6 over ATM. We have a session in LA > covering this very topic because it encompasses a number of > inter-twined areas. We had some vigorous discussions during > late Dec, early January on the issue of generating link-local > tokens (interface IDs), and there's an outstanding issue of > how to provide Neighbour Discovery (or how _much_ to provide). > > I was poking around looking for the relevant I-Ds to pre-read > before this meeting and came up with: > > draft-ietf-ipatm-ipv6nd-01.txt > draft-schulter-ipv6atm-framework-01.txt > and > draft-ahl-ipv6-nbma-00.txt > > My heads-up is to request people interested in this area to > pre-read these I-Ds before the meeting. > > My question is to people interested in this area - is there > a relevant I-D I've missed? Could you post additions here? > (e.g. I suspect draft-ietf-ipngwg-iid-01.txt may have some > impact on any token generation scheme, but I haven't thought > it through yet.) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 09:02:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18382; Thu, 29 Feb 96 09:02:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18376; Thu, 29 Feb 96 09:02:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02979; Thu, 29 Feb 1996 09:00:45 -0800 Received: by mercury.Sun.COM (Sun.COM) id JAA01922; Thu, 29 Feb 1996 09:00:42 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.4/8.7.1) id MAA00625 for ipng@sunroof.Eng.Sun.COM; Thu, 29 Feb 1996 12:00:40 -0500 Received: via switchmail; Thu, 29 Feb 1996 12:00:39 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 29 Feb 1996 12:00:21 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 29 Feb 1996 12:00:17 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 29 Feb 1996 12:00:14 -0500 (EST) Message-Id: <0lBRiSu00WBw412TRj@andrew.cmu.edu> Date: Thu, 29 Feb 1996 12:00:14 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1503) Re: Thoughts on DNS and API In-Reply-To: References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk iialan@iifeak.swan.ac.uk (Alan Cox) writes: > > options that affect the interpretation of addresses and the fact that > > if some process (such as inetd) out of your control hands you a socket > > with the options set wrong, you're screwed and can't get the address > > information you need. > > But thats exactly what lets you get the IPv4 stuff unaware of what its doing. > I don't think you can have that both ways. I don't understand the problem you're referring to here. Could you elaborate? -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 09:05:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18402; Thu, 29 Feb 96 09:05:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18393; Thu, 29 Feb 96 09:05:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03611; Thu, 29 Feb 1996 09:04:03 -0800 Received: by mercury.Sun.COM (Sun.COM) id JAA03065; Thu, 29 Feb 1996 09:04:01 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id SAA13493; Thu, 29 Feb 1996 18:03:49 +0100 (MET) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id SAA12365; Thu, 29 Feb 1996 18:03:49 +0100 Message-Id: <199602291703.SAA12365@givry.inria.fr> From: Francis Dupont To: Richard Stevens Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1504) Re: Thoughts on DNS and API In-Reply-To: Your message of Tue, 27 Feb 1996 09:56:57 MST. <9602271656.AA05990@gemini.tuc.noao.edu> Date: Thu, 29 Feb 1996 18:03:42 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: [Francis Dupont wrote:] > I agree Matt: I believe the usage of msg_control is far better > than the socket array. My reason for preferring the existing spec over the 4.4BSD control message technique is *simplicity*. Using recvmsg() with control information takes a lot more user code. You have to allocate the iovec{} and the msg{} and then fill in both structures with the correct information. This is a pain. => it is a matter of taste because the complexity must be somewhere (in the kernel, in the C library or in all the applications which have to deal with source routes). In the current applications only telnet, ping and traceroute manage source routes (it is done by the kernel for the profit of all the TCP servers). I have to add BIND to the list because BIND tries to send answer using the query destination as the source and its current way (SIOCGIFCONF and a socket per address) can't work with IPv6 (because addresses can change). My concern with the socket address array is it is not the standard way to do that, perhaps BSD is wrong but we have the choice between correct it or to keep some kind of compatibility... Regards Francis.Dupont@inria.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 Thu Feb 29 09:13:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18432; Thu, 29 Feb 96 09:13:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18419; Thu, 29 Feb 96 09:13:24 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04947; Thu, 29 Feb 1996 09:11:57 -0800 Received: by mercury.Sun.COM (Sun.COM) id IAA00689; Thu, 29 Feb 1996 08:57:16 -0800 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1505) Re: Thoughts on DNS and API To: jgm+@CMU.EDU (John Gardiner Myers) Date: Thu, 29 Feb 1996 18:37:33 +0000 (GMT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "John Gardiner Myers" at Feb 29, 96 10:55:22 am Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On one hand, TCP and UDP already use somewhat different models: UDP > uses recvfrom()/sendto(), TCP uses connect()/accept(). TCP can use sendto()/recvfrom() connect() UDP can use connect() read() write(). With TTCP these become slightly more of an issue. > addressing information with setsockopt(). A more analogous approach > would be to use the msg_control field of connectmsg()/acceptmsg() > calls. (or better yet to connect/accept using sendmsg()/recvmsg()) That does not seem unreasonable. > options that affect the interpretation of addresses and the fact that > if some process (such as inetd) out of your control hands you a socket > with the options set wrong, you're screwed and can't get the address > information you need. But thats exactly what lets you get the IPv4 stuff unaware of what its doing. I don't think you can have that both ways. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 09:20:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18453; Thu, 29 Feb 96 09:20:22 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18447; Thu, 29 Feb 96 09:20:06 PST Received: from everglade ([192.9.213.1]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id JAA19664; Thu, 29 Feb 1996 09:17:40 -0800 (PST) Date: Thu, 29 Feb 1996 09:21:00 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1506) Re: Thoughts on DNS and API To: Matt Thomas Cc: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > I would take this to mean lack of support for any serious changes. > > > > > > I strongly disagree. While most of the BSD API specification is fine as > > > it is, a few places (specifically source routes and "receive/sending" > > > interface) need to be rethought as they "break" the de-facto BSD API model. > > > > I'd like to understand how the current draft of the API spec "breaks" > > the BSD API model. Could you elaborate? > > The idea of returning multiple sockaddrs instead of just one is a major > warping of the API. Well, I guess I, and at least a few other people on this list, didn't have such a negative architectural reaction to that part of the proposal! Its hard to argue with this point since it is just an opinion! > One other (which won't be worth much to those using 4.3 Tahoe sockets) > reason for opposing the use of multiple sockaddrs is that it requires > significant changes to the protocol-independent socket framework. . . . That is surprising. The only thing the API spec asks of the protocol-independent layer is that it pass the address buffer through to the transport layer protocol unmodified. In fact, it was a design goal that we do not change the protocol-independent parts of the API, and so I'd hope this means that the protocol-independent parts of its implementation have to change little or not at all. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 10:27:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18602; Thu, 29 Feb 96 10:27:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18596; Thu, 29 Feb 96 10:26:57 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17899; Thu, 29 Feb 1996 10:25:28 -0800 Received: by mercury.Sun.COM (Sun.COM) id KAA00537; Thu, 29 Feb 1996 10:25:08 -0800 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1507) Re: Thoughts on DNS and API To: jgm+@CMU.EDU (John Gardiner Myers) Date: Thu, 29 Feb 1996 20:08:26 +0000 (GMT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <0lBRiSu00WBw412TRj@andrew.cmu.edu> from "John Gardiner Myers" at Feb 29, 96 12:00:14 pm Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > if some process (such as inetd) out of your control hands you a socket > > > with the options set wrong, you're screwed and can't get the address > > > information you need. > > But thats exactly what lets you get the IPv4 stuff unaware of what its doing. > > I don't think you can have that both ways. > > I don't understand the problem you're referring to here. Could you > elaborate? As I see it there are two ways things work 1. An init spawned process has to known what is going on. IPV4 stuff gets given an IPv6 socket and goes kersplat trying to analyse it 2. An init spawned process need not know what is up (current model), its blissfully unaware that its functionality is being set up in advance and can work with IPV6 stuff. Aware programs can if they choose 'drive defensively' and set most things up - but as you note not all. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 11:06:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18657; Thu, 29 Feb 96 11:06:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18651; Thu, 29 Feb 96 11:06:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25520; Thu, 29 Feb 1996 11:04:46 -0800 Received: by mercury.Sun.COM (Sun.COM) id LAA19912; Thu, 29 Feb 1996 11:04:46 -0800 Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id OAA18584; Thu, 29 Feb 1996 14:04:42 -0500 (EST) Received: from phish.nexen.com (phish.nexen.com [204.249.99.14]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id NAA21206; Thu, 29 Feb 1996 13:54:36 -0500 (EST) Received: from localhost (malis@localhost) by phish.nexen.com (8.7.3/8.7.3) with SMTP id NAA04905; Thu, 29 Feb 1996 13:54:34 -0500 (EST) Message-Id: <199602291854.NAA04905@phish.nexen.com> To: rolc@nexen.com, ip-atm@nexen.com, rsvp@isi.edu, int-serv@isi.edu, ipng@sunroof.eng.sun.com Cc: malis@nexen.com Subject: (IPng 1508) Agendas for rolc, ipatm, ipatm/rsvp/intserv, and ipatm/rolc/ipng Date: Thu, 29 Feb 1996 13:54:34 -0500 From: "Andrew G. Malis" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please find enclosed the agendas for the rolc, ipatm, joint ipatm/rsvp/intserv, and joint ipatm/rolc/ipng sessions in LA. I'm sending this out as one message, rather than four individual messages, so you can more easily find the meetings that may be of particular interest. Again, note that the ip-atm list has moved to ip-atm@nexen.com. To join or leave the list, use ip-atm-request@nexen.com or majordomo@nexen.com, using the normal majordomo subscribe and unsubscribe requests. Mail to the old hp addresses will be automatically forwarded to the new addresses. See you next week! Andy ------ Routing Over Large Clouds (rolc) WG, Monday 3/4 at 1300-1500 and 1530-1730, chaired by Andy Malis First session: - ATM Forum report and liaison from LANE and MPOA (Swallow & Halpern) - NHRP revision 8 beta (Luciani) draft-ietf-rolc-nhrp-08-beta (distributed via email) - NHRP/ATMARP/MARS Server Cache Synchronization Protocol (SCSP) (Luciani) draft-luciani-rolc-scsp-00 - NHRP MIB (Luciani and Greene) - NHRP Protocol Applicability Statement (Cansever) draft-ietf-rolc-nhrp-appl-02 - NHRP for Destinations off the NBMA Subnetwork (Rehkter) draft-ietf-rolc-r2r-nhrp-00 Second session: - Support for Sparse Mode PIM over ATM (Rehkter, Farinacci) draft-rekhter-pim-atm-00 - Multicast Inscalability over Large Cloud (Ohta) draft-ohta-mcast-large-cloud-00 - OSPF Cut-Thru Advertisments (Coltun) IP Over ATM (ipatm) WG, Tuesday 3/5 at 1300-1500 and Wednesday 3/6 at 1300-1500, chaired by Mark Laubach and Andy Malis First session: - Introduce new chair - ATM Forum report and liaison from LANE and MPOA (Swallow & Halpern) - IPMC status update (Armitage) draft-ietf-ipatm-ipmc-12 - Framework status update (Cole, Shur, Villamizar) draft-ietf-ipatm-framework-doc-07 - RFC1577 Update (Laubach, Halpern) draft-ietf-ipatm-classic2-01 - NHRP/ATMARP/MARS Server Cache Synchronization Protocol (SCSP) (Luciani) draft-luciani-rolc-scsp-00 - Classical IP/ATM MIB (Luciani, Greene, White, Kuo) draft-ietf-ipatm-mib-01 - ATM Signaling Support for IP over ATM - UNI 4.0 Update (Perez) (draft distributed via email) (Maryann will be on hand in the joint ipatm/rsvp/intserv session) Second session: - Multicast Server Architectures for MARS based ATM Multicasting (Talpade) draft-talpade-ipatm-marsmcs-00 - An Extension to the MARS Model (Kandlur) draft-kandlur-ipatm-mars-directvc-00 - Multicast Routing over ATM (Crawley) draft-crawley-mcast-rout-over-atm-00 RSVP and INTSERV over ATM (tspatm) BOF, ipatm/rsvp/intserv joint session on Wednesday 3/6 at 1530-1730, chaired by Andy Malis - Int-Serv ATM interface (Partridge) - Support for RSVP based services over an ATM network (Birman, Guerin, Kandlur) draft-birman-ipatm-rsvpatm-00 - Issues for RSVP and Integrated Services over ATM (Borden, Crawley, Krawczyk, Baker, Berson) draft-crawley-rsvp-over-atm-00 (distributed via email) - Native ATM Support in the Internet (Jackowski) draft at ftp://ftp.netmanage.com/pub/outgoing/nativatm.txt - IP-SVC (Fujikawa) - Session Identity Notification Protocol (Goto) draft-goto-sinp-01 - A Framework for Supporting RSVP Flows Over ATM Networks (Onvural, Srinivasan) draft-onvural-srinivasan-rsvp-atm-00.txt (distributed via email) - Support for Sparse Mode PIM over ATM (Rehkter, Farinacci) draft-rekhter-pim-atm-00 IPv6 over NBMA (nbmav6) BOF, ipatm/rolc/ipng joint session on Thursday 3/7 at 1300-1500, chaired by Allison Mankin - IPv6 and Neighbour Discovery over ATM (Armitage) draft-ietf-ipatm-ipv6nd-01 - A Framework for IPv6 over ATM (Schulter) draft-schulter-ipv6atm-framework-01 - IPv6 over NBMA Networks (Atkinson, Haskin, and Luciani) draft-ahl-ipv6-nbma-00 - Neighbor Discovery for NBMA (Nordmark) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 11:15:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18683; Thu, 29 Feb 96 11:15:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18677; Thu, 29 Feb 96 11:15:02 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27228; Thu, 29 Feb 1996 11:13:34 -0800 Received: by mercury.Sun.COM (Sun.COM) id LAA22780; Thu, 29 Feb 1996 11:13:33 -0800 Received: (from postman@localhost) by po10.andrew.cmu.edu (8.7.4/8.7.1) id OAA00707 for ipng@sunroof.Eng.Sun.COM; Thu, 29 Feb 1996 14:13:30 -0500 Received: via switchmail; Thu, 29 Feb 1996 14:13:30 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 29 Feb 1996 14:13:10 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 29 Feb 1996 14:13:05 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 29 Feb 1996 14:12:58 -0500 (EST) Message-Id: Date: Thu, 29 Feb 1996 14:12:58 -0500 (EST) From: John Gardiner Myers To: ipng@sunroof.eng.sun.com Subject: (IPng 1509) Re: Thoughts on DNS and API In-Reply-To: References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk iialan@iifeak.swan.ac.uk (Alan Cox) writes: > 2. An init spawned process need not know what is up (current model), its > blissfully unaware that its functionality is being set up in advance and can > work with IPV6 stuff. Aware programs can if they choose 'drive defensively' > and set most things up - but as you note not all. IPv6 addresses are much larger than IPv4 addresses. So, if an IPv4-only application tries to look at any (non-IPv4-compatibility) addresses associated with an IPv6 socket, it's going to go kersplat. So you can't give an IPv4-only process an IPv6 socket. But this has nothing to do with IPV6_RECVSRCRT, IPV6_RECVIF, and IPV6_SENDIF. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 11:48:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18744; Thu, 29 Feb 96 11:48:54 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18738; Thu, 29 Feb 96 11:48:34 PST Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id LAA25104; Thu, 29 Feb 1996 11:46:10 -0800 (PST) Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA24684; Thu, 29 Feb 1996 11:46:59 -0800 Date: Thu, 29 Feb 1996 11:46:59 -0800 From: nordmark@caribe-86.eng.sun.com (Erik Nordmark) Message-Id: <199602291946.LAA24684@bobo.eng.sun.com> To: gja@bellcore.com Subject: (IPng 1510) Re: IPv6 over ATM/NBMA Cc: ip-atm@nexen.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My question is to people interested in this area - is there > a relevant I-D I've missed? Could you post additions here? > (e.g. I suspect draft-ietf-ipngwg-iid-01.txt may have some > impact on any token generation scheme, but I haven't thought > it through yet.) This should be obvious but mail over the last few weeks tells me it is needed for folks to read draft-ietf-ipngwg-discovery-05.txt and draft-ietf-addrconf-ipv6-auto-07.txt In particular to understand the relaxed subnet model andel, the extended redirect messages, and which set of ND/addrconf services use multicast and how they use multicast. 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 Thu Feb 29 15:44:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18863; Thu, 29 Feb 96 15:44:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18857; Thu, 29 Feb 96 15:43:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12746; Thu, 29 Feb 1996 15:42:24 -0800 Received: by mercury.Sun.COM (Sun.COM) id PAA10082; Thu, 29 Feb 1996 15:42:21 -0800 Received: by stb.info.com (Smail3.1.28.1 #4) id m0tsHw9-000ZB1C; Thu, 29 Feb 96 15:39 PST Message-Id: Date: Thu, 29 Feb 96 15:39 PST From: Michael Gersten To: ipng@sunroof.eng.sun.com Subject: (IPng 1511) Link versus node router status? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Unless I'm missing something, the v6 specs all imply that you are a router on a per node basis-- either you act as a router for all your links, or for none of them. Consider the case of a dialup node, that also has an ethernet cable on it. The dialup node establishes a connection, finds a router on the other end, gets an address, with (if I remember correctly) 48 bits of local specific addressing. Ideally, it will then be able to advertise itself as a router on the ethernet link (obviously, it must not claim to be a router on the dialup link, but it must be able to forward packets onto the ethernet that come in from the dialup link). And, since it now begins advertising itself as a router over the ethernet link, those nodes can now add any additional addresses, if any, and talk to the rest of the world. Except that, unless I missed something, address configuration only occurs at initialization, and a node does not claim to be a router on a per-link basis. Michael ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 17:49:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19002; Thu, 29 Feb 96 17:49:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18996; Thu, 29 Feb 96 17:49:46 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02320; Thu, 29 Feb 1996 17:48:19 -0800 Received: by mercury.Sun.COM (Sun.COM) id RAA10057; Thu, 29 Feb 1996 17:48:19 -0800 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G105) id AA02701; Thu, 29 Feb 96 18:48:17 MST; for ipng@sunroof.eng.sun.com Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA04124; Thu, 29 Feb 96 18:48:17 MST; for ipng@sunroof.eng.sun.com Message-Id: <9603010148.AA04124@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Thu, 29 Feb 1996 18:48:16 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: John Gardiner Myers , ipng@sunroof.eng.sun.com Subject: (IPng 1512) Re: Thoughts on DNS and API Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On the other hand, I get uncomfortable with the idea of specifying > addressing information with setsockopt(). You're not specifying "addressing information" with a socket option, you're specifying how to interpret the array of addresses that can be passed to other functions. Just like SO_REUSEADDR tells bind() what to do with an IP address; just like fcntl() tells read() and write() whether to block or not; just like SO_BROADCAST tells sendto() whether to accept a broadcast address or not; just like SO_LINGER tells close() what to do if there is still data queued to be sent; just like SO_SNDTIMEO tells write() how long to block; ... I just don't follow this reasoning that control information is the "approved" way to do this with sockets and that an array of addresses somehow violates the sockets API. The only thing control information is used for today with TCP/IP is to return the destination address of a UDP datagram (and even that is broken; it doesn't work for broadcast or multicast datagrams, which is when you really want the information). In the posting of the code from 4.4BSD the other day, notice that two of the three uses have never been implemented. Control information is also used for passing descriptors across a Unix domain socket, and for lots of things that I've never looked at in the OSI code. (Hopefully we won't use the OSI code as the model.) I think the array of addresses is a handy, simple way of doing what the draft API proposes. All the functions that can return an array already have a value-result argument that returns the size of the array. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 17:56:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19019; Thu, 29 Feb 96 17:56:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19013; Thu, 29 Feb 96 17:56:32 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03285; Thu, 29 Feb 1996 17:55:05 -0800 Received: by mercury.Sun.COM (Sun.COM) id RAA11540; Thu, 29 Feb 1996 17:55:03 -0800 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G105) id AA02969; Thu, 29 Feb 96 18:55:00 MST; for ipng@sunroof.eng.sun.com Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA04145; Thu, 29 Feb 96 18:54:52 MST; for ipng@sunroof.eng.sun.com Message-Id: <9603010154.AA04145@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Thu, 29 Feb 1996 18:54:52 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Francis Dupont Subject: (IPng 1513) Re: Thoughts on DNS and API Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Feb 29, 6:03pm you write:] > My concern with the socket address array is it is not the standard > way to do that, perhaps BSD is wrong but we have the choice between > correct it or to keep some kind of compatibility... I will argue that there is no "standard" or "correct" way to do it today. The proposed API is, to me, just as valid as using control information. I am more interested in easy to program and easy to explain, and that's why I like the proposed method more than control information.. But we need only *one* way to do it, or the API becomes a mess. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Feb 29 23:08:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19108; Thu, 29 Feb 96 23:08:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19102; Thu, 29 Feb 96 23:08:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26699; Thu, 29 Feb 1996 23:07:05 -0800 Received: by mercury.Sun.COM (Sun.COM) id XAA24407; Thu, 29 Feb 1996 23:07:03 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20921 Fri, 1 Mar 1996 18:06:34 +1100 (from kre@munnari.OZ.AU) To: Michael Gersten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1514) Re: Link versus node router status? In-Reply-To: Your message of "Thu, 29 Feb 1996 15:39:00 PST." Date: Fri, 01 Mar 1996 18:06:51 +1100 Message-Id: <22502.825664011@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 29 Feb 96 15:39 PST From: Michael Gersten Message-ID: Unless I'm missing something, the v6 specs all imply that you are a router on a per node basis-- either you act as a router for all your links, or for none of them. This is something that has been much discussed before. I think, if I recall correctly, that general consensus is that each interface is independant, (though it makes no sense at all to be a router on only one interface... I don't think). Ideally, it will then be able to advertise itself as a router on the ethernet link Yes. (obviously, it must not claim to be a router on the dialup link, Why not - that's exactly what it is? but it must be able to forward packets onto the ethernet that come in from the dialup link). That is, be a router. Of course, the other end of that link will be a router too (usually), and won't be taking much notice of any router type things that this box is doing. And, since it now begins advertising itself as a router over the ethernet link, those nodes can now add any additional addresses, if any, and talk to the rest of the world. Yes. Except that, unless I missed something, address configuration only occurs at initialization, No, all the time, only link local addresses are init time only. and a node does not claim to be a router on a per-link basis. This is less clear, but irrelevant anyway to your example. 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