From owner-ipng Tue Jun 4 09:58:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03996; Tue, 4 Jun 96 09:58:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03990; Tue, 4 Jun 96 09:58:29 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25255; Tue, 4 Jun 1996 09:55:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA06879; Tue, 4 Jun 1996 09:55:05 -0700 From: bound@zk3.dec.com Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id MAA00944; Tue, 4 Jun 1996 12:41:09 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31619; Tue, 4 Jun 1996 12:40:28 -0400 Message-Id: <9606041640.AA31619@fwasted.zk3.dec.com> To: Steve Deering Cc: Craig Partridge , ipng@sunroof.eng.sun.com Subject: (IPng 1855) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of "Mon, 27 May 96 15:02:18 PDT." <96May27.150226pdt.75270@digit.parc.xerox.com> Date: Tue, 04 Jun 96 12:40:28 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >Fine, but that does not require syntactic indication of anycast-ness. Rather >it requires a change to TCP to enable the responder to say "use this unicast >address for the rest of this conversation". Or do you have some other >mechanism in mind, by which syntactic recognizability of anycast addresses >eliminates the need to change TCP? I agree and also a method for UDP too. At Montreal for the IPng meeting we will have a solution to present how to handle this for TCP and UDP. Clearly there are other issues as brought up for ND and routing. But our proposal will provide a solution to change the address used to speak with the selected anycast host and for the initiating host to use the unicast address of the anycast member responding to the host initiator. We are running tight to make the June 13th deadline for the spec but will be close, but we need time on the agenda for this part of the anycast usage discussion. I perceive the model being presented and the simplified solution to making this work at the virtual transport layer. Getting the change to the API at the virtual application layer is the more tricky problem actually. Pedro Roque will be coming to Montreal to present this with me from Portugal so we would like to make sure we don't get bounced on the IPng agenda. I think there is enough interest on this subject to get the discussion begat in IPng WG. 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 Jun 4 12:37:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04185; Tue, 4 Jun 96 12:37:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04179; Tue, 4 Jun 96 12:37:43 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26129; Tue, 4 Jun 1996 12:34:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA10811; Tue, 4 Jun 1996 12:34:19 -0700 Received: from sunl12.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0uR1re-0004fPC; Tue, 4 Jun 96 14:34 CDT Received: from localhost by sunl12.tellabs.com (4.1/1.9) id AA03961; Tue, 4 Jun 96 14:33:47 CDT Message-Id: <9606041933.AA03961@sunl12.tellabs.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1856) IPng Presentations Date: Tue, 04 Jun 1996 14:33:44 -0500 From: Vijay Gurbani Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello: I am looking for any upcoming IPng Presentations. I have tried (unsucessfully) to find the same information from the 'net. If someone could mail me information about any upcoming presentations, I would be very appreciative. Thanks in advance, -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzEM+a8AAAEEAM9Ka/q0iRM0bp2gP7sYcjSkme1KQv4Ucfqv4XnT74ki5sK4 9UwDTkBOjAseBGj4gIlBBoRJqzWo5qzaWgZfiPRiRfoezHyy31twTEJzg5Kcals+ 9e8tN/U4qud64yHLG0wNkA1y4mEGR0XrDJr69HSxhkoOPhloX+qoXa3gBJ4RAAUT tCdWaWpheSBLLiBHdXJiYW5pIDx2Z3VyYmFuaUB0ZWxsYWJzLmNvbT4= =S5LV -----END PGP PUBLIC KEY BLOCK----- - vijay -- Vijay K. Gurbani vgurbani@tellabs.com 708/512-7490 Software Engineer, TITAN 5500/SONET Development Team Tellabs Operations, Inc. Lisle, Illinois ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 5 12:12:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04750; Wed, 5 Jun 96 12:12:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04744; Wed, 5 Jun 96 12:10:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29160; Wed, 5 Jun 1996 12:06:43 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA28162; Wed, 5 Jun 1996 12:06:40 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2876; Wed, 05 Jun 96 15:06:21 EDT Received: by RTP (XAGENTA 4.0) id 7420; Wed, 5 Jun 1996 15:06:16 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20410; Wed, 5 Jun 1996 15:06:11 -0400 Message-Id: <9606051906.AA20410@cichlid.raleigh.ibm.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1857) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of "Tue, 28 May 1996 15:28:40 PDT." <96May28.152855pdt.75270@digit.parc.xerox.com> Date: Wed, 05 Jun 1996 15:06:11 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >The rejection of anycast packets is a transport- or higher-layer decision, Fair enough. >and it should be signalled by those higher-layer protocols, not ICMP. E.g., >for TCP, perhaps there ought to be defined a new option type, to accompany >FIN and/or RST messages, explaining the reason for the close or reset. Alas, I fear things are more complicated than first appear. The real issue is what is the best way to inform a node that it is attempting communication to an anycast address, in situations where a node needs to be aware that an anycast is in use. Suppose Node A opens a tcp connection to anycast address B_any. How will B's TCP respond? It can't use B_any as a source address, so it sends back a TCP RST, with a TCP option saying that B_any is an anycast address. But the source address of the packet is B_uni. A gets the message and tosses it, since it doesn't have a clue who B_uni is (no PCB for it). Now what? I suppose that the option would have to be defined in such a way as to mean that a receiver has to look up PCBs based on the address in the option, but this differs from standard TCP processing, and seems somewhat inelegant. The RST is not really resetting the connection indicated by the source/destination ports/addrs. The semantics/correct definition of this message get messy too. Suppose that A just happens to also have an open connection to B_uni using the same port numbers as it is using in its attempt to connect to B_any. We want the RST to reset the new connection, not the already open one. It's not entirely clear to me that an ICMP message isn't a better approach here, especially since other protocols/applications besides TCP will need to communicate similar information as well. The problem is even worse for UDP, because now the logic for dealing with all this falls on applications themselves. For example, consider a UDP request from A to B_any and the corresponding reply. When application B responds to a message, it typically sends the reply back specifying that the response packet be sent using the source address that was in the destination of the original packet being responded to (i.e., B_any in this case). But if the original destination is an anycast address, the application now needs to know this and take special action to insure that the reply is sent from B_uni. Not undoable, but somehow more effort than would be ideal. All applications would need to be specially recoded to do the right thing. Ouch. Likewise, A is expecting a response from B_any. Presumably, the response from B_uni will be tossed at the UDP level because there are no listeners on the PCB. Now what? We certainly can't expect A to be listening for responses from *any* source, and then doing the filtering itself. An ICMP "anycast address used" error would at least be a straightforward, standard mechanism for notifying a node (and more specifically the actual sender) that it attempted to make use of an anycast address. How a node/upper layer reacted to such a message would be a transport or higher-layer decision. It would also be a transport or higher-layer decision as to when to send such a message, since they aren't always appropriate. For example, tunneling a packet to a router's anycast address shouldn't prompt such a message. 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 Jun 5 12:56:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04814; Wed, 5 Jun 96 12:56:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04808; Wed, 5 Jun 96 12:55:43 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05688; Wed, 5 Jun 1996 12:52:17 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA11464; Wed, 5 Jun 1996 12:52:16 -0700 Received: (from shaver@localhost) by neon.ingenia.com (8.8.Alpha.2/8.6.9) id PAA05156; Wed, 5 Jun 1996 15:52:11 -0400 From: Mike Shaver Message-Id: <199606051952.PAA05156@neon.ingenia.com> Subject: (IPng 1858) Re: Responses to Comments on Multihoming draft To: narten@VNET.IBM.COM (Thomas Narten) Date: Wed, 5 Jun 1996 15:52:10 -0400 (EDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9606051906.AA20410@cichlid.raleigh.ibm.com> from "Thomas Narten" at Jun 5, 96 03:06:11 pm X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake Thomas Narten: > The problem is even worse for UDP, because now the logic for dealing > with all this falls on applications themselves. For example, consider > a UDP request from A to B_any and the corresponding reply. When > application B responds to a message, it typically sends the reply back > specifying that the response packet be sent using the source address > that was in the destination of the original packet being responded to > (i.e., B_any in this case). But if the original destination is an > anycast address, the application now needs to know this and take > special action to insure that the reply is sent from B_uni. Not > undoable, but somehow more effort than would be ideal. All > applications would need to be specially recoded to do the right > thing. Ouch. (Newbie warning.) Could this not be done in the kernel, like the checks for a source address of IPV6_ADDR_ANY? It would seem to me that the kernel could handle the conversion between the anycast address used for the initial datagram and the address used by the application, long before the application ever gets it. That would prevent applications from having to deal with the anycast issue if appropriate, and a new sockopt would allow an application to find out if the original connection was `mapped' from an anycast address or not if desired. Mike -- #> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation <# #> Chief System Architect -- will tame sendmail(8) for food <# #> <# #> "You are a very perverse individual, and I think I'd like to get to <# #> know you better." --- eric@reference.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 Jun 5 15:09:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04948; Wed, 5 Jun 96 15:09:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04942; Wed, 5 Jun 96 15:07:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28786; Wed, 5 Jun 1996 15:04:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA23072; Wed, 5 Jun 1996 15:04:31 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id SAA08815; Wed, 5 Jun 1996 18:03:14 -0400 Date: Wed, 5 Jun 1996 18:03:14 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9606051803.ZM8813@seawind.bellcore.com> In-Reply-To: "Thomas Narten" "(IPng 1857) Re: Responses to Comments on Multihoming draft" (Jun 5, 3:06pm) References: <9606051906.AA20410@cichlid.raleigh.ibm.com> X-Mailer: Z-Mail (3.2.0 06sep94) To: "Thomas Narten" Subject: (IPng 1859) Re: Responses to Comments on Multihoming draft Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The "anycast response" problem is one of many problems faced by TCP as a result of TCP reliance on addresses to identify connections. We need ways to convince TCP that the packets received from host "Foo" really is a response to a packet sent to address "Bar". Variations of this problem occur when a host roams from one addressing area to another, or when a site is renumbered. I proposed a TCP based solution at the transport area directorate during last winter IETF. The basic idea was to exchange connection identifiers, that could be passed either as parameters of TCP packets or as a new payload code. When we investigated the possible deployment of TTCP during the Los Angeles IETF in March, we observed that TTCP also requires connection identifiers, to prevent phantoms of past transactions from haunting the current contexts. There was at that time a vague request to seriously look at the possibility of using the same mecanism in both cases. Neither Bob Braden nor me, however, are particularly rich in spare cycles... While I believe that the "final solution" does require an update to TCP, we are all fully aware that deploying a new version of TCP may take some time. Jim Bound mentioned that he was working on an IPv6/ICMP alternative, some form of "your partner has moved" message, which will also solve the mobility problem -- to an extent. I have not seen Jim's draft yet, but maybe I did not look hard enough. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jun 5 23:54:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05116; Wed, 5 Jun 96 23:54:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05110; Wed, 5 Jun 96 23:51:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19548; Wed, 5 Jun 1996 23:47:42 -0700 Received: by mercury.Sun.COM (Sun.COM) id XAA07105; Wed, 5 Jun 1996 23:47:42 -0700 Received: from matisse (matisse.ibp.fr [132.227.61.26]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with SMTP id IAA04453 for ; Thu, 6 Jun 1996 08:47:40 +0200 Date: Thu, 6 Jun 1996 08:47:40 +0200 Message-Id: <199606060647.IAA04453@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 1860) Flow ID and BSD sockets interface Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Flow IDs could be used in conjunction with signalling protocols (e.g. RSVP) to maintain a predifined quality of service. For some applications, changing the quality of service definition is necessary. It seems that we need some means to do that through the socket interface. I think that an IOCTL call is the best way to do that. But, this call is to be standardized to ensure the portability of applications using this opportunity. This imply an addition to the draft-ietf-bsd-api document. Any comments? Eric ---------------------- 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 http://www-masi-net.ibp.fr/~eh ----------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 6 00:58:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05192; Thu, 6 Jun 96 00:58:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05186; Thu, 6 Jun 96 00:58:19 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24675; Thu, 6 Jun 1996 00:54:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA15309; Thu, 6 Jun 1996 00:54:50 -0700 From: Masataka Ohta Message-Id: <199606060744.QAA02860@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA02860; Thu, 6 Jun 1996 16:44:27 +0900 Subject: (IPng 1861) Re: Flow ID and BSD sockets interface To: Eric.Horlait@masi.ibp.fr (Eric HORLAIT) Date: Thu, 6 Jun 96 16:44:26 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199606060647.IAA04453@ibp.ibp.fr>; from "Eric HORLAIT" at Jun 6, 96 8:47 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Flow IDs could be used in conjunction with signalling protocols (e.g. RSVP) > to maintain a predifined quality of service. For some applications, changing > the quality of service definition is necessary. > > It seems that we need some means to do that through the socket interface. I > think that an IOCTL call is the best way to do that. Shouldn't it be setsockopt()? 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 Jun 6 01:23:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05224; Thu, 6 Jun 96 01:23:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05218; Thu, 6 Jun 96 01:22:57 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26121; Thu, 6 Jun 1996 01:19:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA19343; Thu, 6 Jun 1996 01:19:31 -0700 Received: from shand.reo.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id EAA31121; Thu, 6 Jun 1996 04:13:40 -0400 (EDT) Received: from localhost by shand.reo.dec.com (5.65/MS-010395) id AA24525; Thu, 6 Jun 1996 09:13:03 +0100 Message-Id: <9606060813.AA24525@shand.reo.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1862) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of "Wed, 05 Jun 96 15:06:11 -0300." <9606051906.AA20410@cichlid.raleigh.ibm.com> Date: Thu, 06 Jun 96 09:13:01 +0100 From: (Mike Shand REO2 G/C2 DTN:830-4424) X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Alas, I fear things are more complicated than first appear. The real > issue is what is the best way to inform a node that it is attempting > communication to an anycast address, in situations where a node needs > to be aware that an anycast is in use. Isn't this problem addressed by Jim and Pedro's draft? draft-bound-ipv6-ip-addr-00.txt As I understand it, the anycast node could return an address set reasign option giving the new address which is to be used for the connection (or does it use an identification option, or both - I'm not sure). Anyway the semantics are " here is a response to the packet which you sent to address FOO. Please consider it as such and pass it up to the higher layers as if had a source address of FOO (including the pseudo header issues), and please add the address BAR to your set of addresses to be used for future communication with this entity". I'm sure Jim or Pedros can explain it much better than I. This provides similar functionality to Christian's TCP proposal, but has the advantage (to my mind) that since it operates within the network layer it will operate with both TCP and UDP (or any other "transport" protocol for that matter), and in particular requires no changes to TCP. 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 Thu Jun 6 05:59:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05302; Thu, 6 Jun 96 05:59:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05296; Thu, 6 Jun 96 05:56:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10694; Thu, 6 Jun 1996 05:53:27 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA20848; Thu, 6 Jun 1996 05:53:28 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with SMTP id FAA05048; Thu, 6 Jun 1996 05:53:27 -0700 (MST) Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA02842; Thu, 6 Jun 96 05:53:27 MST; for ipng@sunroof.eng.sun.com Message-Id: <9606061253.AA02842@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Thu, 6 Jun 1996 05:53:26 -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: Masataka Ohta , Eric.Horlait@masi.ibp.fr (Eric HORLAIT) Subject: (IPng 1863) Re: Flow ID and BSD sockets interface Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Flow IDs are already in the API: the sin6_flowinfo member of the IPv6 socket address structure, along with the various rules on how to set this for TCP connects, TCP passive opens, and UDP. This member contains the 4-bit priority and the 24-bit flow label. 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 Jun 6 07:02:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05370; Thu, 6 Jun 96 07:02:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05357; Thu, 6 Jun 96 06:57:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15688; Thu, 6 Jun 1996 06:54:24 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA04004; Thu, 6 Jun 1996 06:54:23 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15494; 6 Jun 96 9:20 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1864) I-D ACTION:draft-ietf-ipngwg-linkname-00.txt Date: Thu, 06 Jun 96 09:20:19 -0400 Message-Id: <9606060920.aa15494@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 : Link Local Addressing and Name Resolution in IPv6 Author(s) : D. Harrington Filename : draft-ietf-ipngwg-linkname-00.txt Pages : 9 Date : 06/05/1996 This draft proposes an experimental mechanism by which IPv6 link-local addresses and associated system names may be distributed among interconnected hosts, for use by users and applications. It provides an overview of the problem, a proposed solution (including suggested protocol details), and lists various related issues. This work is introduced to the IPng Working Group initially, although it might also have implications or concerns relevant to individuals working on directory services and other areas. 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-linkname-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-linkname-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 (193.205.245.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-linkname-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: <19960605155049.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-linkname-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-linkname-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960605155049.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 Jun 6 07:07:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05378; Thu, 6 Jun 96 07:07:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05372; Thu, 6 Jun 96 07:03:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16169; Thu, 6 Jun 1996 07:00:22 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA05370; Thu, 6 Jun 1996 07:00:19 -0700 Received: from nowhere.london.sco.COM by scol.london.sco.COM id aa18540; 6 Jun 96 13:51 GMT X-Uri: X-Face: "Ht#9&2KEo;v0Jn!m[7V}D}F5>{KUiNw Cc: Masataka Ohta , Eric HORLAIT , ipng@sunroof.eng.sun.com Subject: (IPng 1865) Re: Flow ID and BSD sockets interface In-Reply-To: Your message of "Thu, 06 Jun 1996 05:53:26 PDT." <9606061253.AA02842@gemini.tuc.noao.edu> Date: Thu, 06 Jun 1996 14:51:47 +0100 Message-Id: <9297.834069107@sco.COM> From: Harvey Thompson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Flow IDs are already in the API: the sin6_flowinfo member of the IPv6 > socket address structure, along with the various rules on how to set > this for TCP connects, TCP passive opens, and UDP. This member contains > the 4-bit priority and the 24-bit flow label. Which makes me wonder, is there a standard way to allocate a unique flow id? Somebody once said "just allocate one at random" but surely you have to make sure it's unique? If there isn't a standard way, application code that's trying to be portable will be messy. Perhaps I'm missing something... Another thought-ette; as somebody pointed out earlier, the flow id field is accessed through by doing "sin6.sin6_flowinfo & IPV6_FLOWINFO_FLOWLABEL", am I therefore to assume that the flowlabel part is the 24 least significant bits in sin6_flowinfo (and the 4 bits for IPV6_FLOWINFO_PRIORITY are taken from the remaining bunch with IPV6_PRIORITY_* defines set accordingly)? I suppose depending on how you allocate flow-ids, it doesn't really matter. Gosh, and while I'm waxing philisophically... The discussions on implementing sin6_flowinfo using unions and bit-fields faded away just after somebody said "It's all fine.", which taken with the above may mean I've missed something. Somebody also said this field should be in network byte order -- I think not. The draft doesn't say this, isn't it up to the implementation to stuff the various bits into the IPv6 header in the correct order? --HarveyT ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 6 07:17:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05395; Thu, 6 Jun 96 07:17:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05385; Thu, 6 Jun 96 07:13:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17313; Thu, 6 Jun 1996 07:10:34 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA08244; Thu, 6 Jun 1996 07:10:33 -0700 Received: from matisse (eric@matisse.ibp.fr [132.227.61.26]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with SMTP id QAA01920 ; Thu, 6 Jun 1996 16:10:31 +0200 Message-Id: <31B6E687.49089403@masi.ibp.fr> Date: Thu, 06 Jun 1996 16:09:11 +0200 From: Eric Horlait Organization: CNRS MASI X-Mailer: Mozilla 2.02 (X11; I; Linux 1.3.70 i486) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 1866) Re: Flow ID and BSD sockets interface References: <9297.834069107@sco.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Harvey Thompson wrote: > > > Flow IDs are already in the API: the sin6_flowinfo member of the IPv6 > > socket address structure, along with the various rules on how to set > > this for TCP connects, TCP passive opens, and UDP. This member contains > > the 4-bit priority and the 24-bit flow label. > > Which makes me wonder, is there a standard way to allocate a unique flow > id? Somebody once said "just allocate one at random" but surely you have > to make sure it's unique? If there isn't a standard way, application code > that's trying to be portable will be messy. Perhaps I'm missing > something... > Allocation of flow ids is not yet well defined. One possibility could be "at random"; another one is by using an external mechanism, for example a signalling protocol, which returns a flow idsafter requesting ressources and reserving them (through the flow id) from the routers inside the net. In this case, the flow id must be unique. I think this can be done when using flow id in cunjunction with source address to identify a(n application) flow. -- ---------------------- 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 http://www-masi-net.ibp.fr/~eh ----------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 6 08:09:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05543; Thu, 6 Jun 96 08:09:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05536; Thu, 6 Jun 96 08:03:33 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22761; Thu, 6 Jun 1996 08:00:00 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA22599; Thu, 6 Jun 1996 08:00:00 -0700 Received: from munin.fnal.gov ("port 2473"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I5L1TJRV9E002DMA@FNAL.FNAL.GOV> for ipng@sunroof.eng.sun.com; Thu, 06 Jun 1996 09:59:58 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id JAA05307; Thu, 06 Jun 1996 09:59:03 -0500 (CDT) Date: Thu, 06 Jun 1996 09:59:02 -0500 From: Matt Crawford Subject: (IPng 1867) Re: I-D ACTION:draft-ietf-ipngwg-linkname-00.txt In-Reply-To: "06 Jun 1996 09:20:19 EDT." <"9606060920.aa15494"@IETF.CNRI.Reston.VA.US> To: ipng@sunroof.eng.sun.com Message-Id: <199606061459.JAA05307@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 AA05559; Thu, 6 Jun 96 08:21:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05551; Thu, 6 Jun 96 08:17:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24461; Thu, 6 Jun 1996 08:13:41 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA27028; Thu, 6 Jun 1996 08:13:41 -0700 Received: from munin.fnal.gov ("port 2483"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I5L2BH8OAC002DMA@FNAL.FNAL.GOV>; Thu, 06 Jun 1996 10:13:38 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id KAA05417; Thu, 06 Jun 1996 10:12:43 -0500 (CDT) Date: Thu, 06 Jun 1996 10:12:42 -0500 From: Matt Crawford Subject: (IPng 1868) Re: Flow ID and BSD sockets interface In-Reply-To: "06 Jun 1996 16:09:11 +0200." <"31B6E687.49089403"@masi.ibp.fr> To: Eric Horlait Cc: ipng@sunroof.eng.sun.com Message-Id: <199606061512.KAA05417@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{ Allocation of flow ids is not yet well defined. One possibility > could be "at random"; I don't think the application can have any involvement with selecting the flow ID, except to choose between zero (the default) or non-zero. First of all, the application would be burdened with retrying on a clash, since accidental duplication of a flow ID would be a disaster. Second, allowing free choice by the application layer with some notification of clash would create a covert signalling channel between processes. Sure, there are others, but since IPv6 marks a milestone in IP getting serious about security, let's not add another stone to the burden of multi-level secure system implementors. > another one is by using an external mechanism, for example a > signalling protocol, which returns a flow idsafter requesting > ressources and reserving them (through the flow id) from the > routers inside the net. In this case, the flow id must be unique. This sounds hard, since different first-hop routers to different destinations would have to cooperate in order to keep your flow IDs unique. Routing could change and two flows could come to share part of a path. _________________________________________________________ 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 Thu Jun 6 09:07:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05628; Thu, 6 Jun 96 09:07:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05613; Thu, 6 Jun 96 09:03:33 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01213; Thu, 6 Jun 1996 09:00:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA13299; Thu, 6 Jun 1996 08:59:59 -0700 From: K.Belgaied@frec.bull.fr Received: from egalmc2 (egalmc2.frec.bull.fr) by ecbull.frec.bull.fr; Thu, 6 Jun 1996 17:58:55 +0200 (MET) Received: by egalmc2 (AIX 4.1/UCB 5.64/4.03) id AA139876; Thu, 6 Jun 1996 18:01:06 +0200 Date: Thu, 6 Jun 1996 18:01:06 +0200 Message-Id: <9606061601.AA139876@egalmc2> To: Eric.Horlait@masi.ibp.fr Subject: (IPng 1869) Re: Flow ID and BSD sockets interface Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: t3+l+4r+YMa0u7swvzMOgw== Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the particular case of using RSVP, with a minimum traffic control on the packets forwarding path, the flow-id choice can be simple and does not need to be unique allover the network (which is pretty complex to achieve). The RSVP "Path" messages maintain a "Path state" in each router, along the way of the data. A path state contains at least the unicast IP address of the previous hop node, which is used to route the RSVP "Resv" messages hop-by-hop in the reverse direction. We can add to the per-flow path state 2 fields: "previous-hop-flow-id" and "this-hop-flow-id". On an incomming packet, the former (previous-hop-flow-id) is only used to retreive the latter (this-hop-flow-id) which indicates actually what kind of service this packet will get, and will replace "previous-hop-flow-id" in the outgoing packet. Thus the flow-id is changed hop-by-hop throughout the RSVP-capable nodes, and is unique in each node. One weakness is that we assume that non-capable RSVP nodes do not modify the flow-id. > Allocation of flow ids is not yet well defined. One possibility could be "at random"; > another one is by using an external mechanism, for example a signalling protocol, > which returns a flow idsafter requesting ressources and reserving them (through the > flow id) from the routers inside the net. > In this case, the flow id must be unique. I think this can be done when using flow id > in cunjunction with source address to identify a(n application) flow. > > -- > > ---------------------- Professeur Eric HORLAIT ------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > Kais Belgaied Bull S.A, Echirolles, France Phone: (+33) 76297150 e-mail: K.Belgaied@frec.bull.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 Jun 6 11:12:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06050; Thu, 6 Jun 96 11:12:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06044; Thu, 6 Jun 96 11:09:39 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23121; Thu, 6 Jun 1996 11:06:11 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA05781; Thu, 6 Jun 1996 11:06:12 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <19930(8)>; Thu, 6 Jun 1996 09:36:51 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 6 Jun 1996 09:36:42 -0700 To: Eric Horlait Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1870) Re: Flow ID and BSD sockets interface In-Reply-To: Eric.Horlait's message of Thu, 06 Jun 96 07:09:11 -0800. <31B6E687.49089403@masi.ibp.fr> Date: Thu, 6 Jun 1996 09:36:36 PDT From: Steve Deering Message-Id: <96Jun6.093642pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Allocation of flow ids is not yet well defined. One possibility could be > "at random"; Allocation of IPv6 flow labels *is* well defined. A host *must* allocate them at random. From the IPv6 spec, RFC-1883, section 6: A flow label is assigned to a flow by the flow's source node. New flow labels must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFFF hex. The purpose of the random allocation is to make any set of bits within the Flow Label field suitable for use as a hash key by routers, for looking up the state associated with the flow. A flow is identified by the concatenation of its source address and its flow label. Since source addresses are unique over their scope of use, the combination of source address + flow label is unique over the same scope. *Within* a host, it is necessary to ensure that the labels chosen for different flows are unique. I would expect this to be achieved by using a single host-wide variable (e.g., in the OS kernel) that maintains the intermediate state of the pseudo-random number generator, with approriate mechanisms to prevent concurrent access to that variable (i.e., the use and modification of that variable are within a critical section). > another one is by using an external mechanism, for example a signalling > protocol... It is precisely to avoid the need for a flow-id allocation protocol that the IPv6 flow identification scheme is defined the way it is. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 6 12:16:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06189; Thu, 6 Jun 96 12:16:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06183; Thu, 6 Jun 96 12:11:21 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03575; Thu, 6 Jun 1996 12:07:54 -0700 Received: by venus.Sun.COM (Sun.COM) id MAA26272; Thu, 6 Jun 1996 12:05:26 -0700 From: bound@zk3.dec.com Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id OAA20253; Thu, 6 Jun 1996 14:58:39 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA05350; Thu, 6 Jun 1996 14:58:04 -0400 Message-Id: <9606061858.AA05350@fwasted.zk3.dec.com> To: huitema@bellcore.com (Christian Huitema) Cc: "Thomas Narten" , ipng@sunroof.eng.sun.com Subject: (IPng 1871) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of "Wed, 05 Jun 96 18:03:14 EDT." <9606051803.ZM8813@seawind.bellcore.com> Date: Thu, 06 Jun 96 14:58:03 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian et al, Pedro Roque and I are working on the draft right now. It won't get submitted until late next week. I am not going to respond to any mail at this point in the anycast discussion as it takes away from the specs I have to get done before June 13th. Once thats done I am sure I will have a lot to say but for now I got to go back to work and for this week the mail list discussion for me is a low priority but I am saving all the anycast mail to respond later and want to talk to Pedro too. There is an old draft out there but it was to complex and got into some very research areas what we are doing now is putting work together to just simply update the IP address (IPv6 we are only working on) for a UDP or TCP connection and the relevant application. I am assuming Pedro and I will have time to discuss this proposal as another one to Christian's to see what folks think and if it can move this discussion forward. I cannot ignore UDP my customers won't let me. thanks and sorry, /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 Jun 6 23:37:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06537; Thu, 6 Jun 96 23:37:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06531; Thu, 6 Jun 96 23:37:18 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00279; Thu, 6 Jun 1996 23:33:51 -0700 Received: by mercury.Sun.COM (Sun.COM) id XAA22858; Thu, 6 Jun 1996 23:33:49 -0700 Received: from matisse (matisse.ibp.fr [132.227.61.26]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with SMTP id IAA14606 ; Fri, 7 Jun 1996 08:33:44 +0200 Date: Fri, 7 Jun 1996 08:33:44 +0200 Message-Id: <199606070633.IAA14606@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: Steve Deering From: "Eric HORLAIT (MASI-CNRS)" Subject: (IPng 1872) Re: Flow ID and BSD sockets interface Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:36 06/06/1996 PDT, Steve Deering wrote: >> another one is by using an external mechanism, for example a signalling >> protocol... > >It is precisely to avoid the need for a flow-id allocation protocol that >the IPv6 flow identification scheme is defined the way it is. > But the pseudo random allocation is nothing else that a (local) protocol allocation. I think that the real problem is what is the use of the flow Id. I would like to use it as a marker for resources reservation. So, this algorithm does not violate the statements in IPv6 definition: compute flow id: 1- get a random number, say X, in the range 1 to FFFFFF hex. 2- if (a signalling protocol is in use) call it with the flow id and the specific parameters needed 3- return X My initial purpose was to allow the modification of the flow Id used by a connection during that connection, because I think that *if* there is a signalling protocol in use, it is possible for an application to renegociate some parameters during an established connection. In this case, the algorithm for flow id allocation is called again, and the new obtained flow id is to be transmitted to the networking code, presumably without closing the existing connection and reopening one. I think that this behaviour could be obtained using an ioctl call modifying the flow id initially associated with a socket when it is first created (via struct sockaddr_in6). These considerations are between protocol specification (via the cooperation aspects of two protocols) and implementation issues (specification of the interface using BSD sockets). Eric ---------------------- 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 http://www-masi-net.ibp.fr/~eh ----------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 7 06:04:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06791; Fri, 7 Jun 96 06:04:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06785; Fri, 7 Jun 96 06:04:04 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23160; Fri, 7 Jun 1996 06:00:36 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA11153; Fri, 7 Jun 1996 06:00:37 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id JAA00569; Fri, 7 Jun 1996 09:00:11 -0400 Date: Fri, 7 Jun 1996 09:00:11 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9606070900.ZM567@seawind.bellcore.com> In-Reply-To: "Eric HORLAIT (MASI-CNRS)" "(IPng 1872) Re: Flow ID and BSD sockets interface" (Jun 7, 8:33am) References: <199606070633.IAA14606@ibp.ibp.fr> X-Mailer: Z-Mail (3.2.0 06sep94) To: "Eric HORLAIT (MASI-CNRS)" Subject: (IPng 1873) Re: Flow ID and BSD sockets interface 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 Eric, As Steve said, Flow-ids are allocated locally, not globally. How you organize this allocation within your system is indeed part of the design of the API. Note that there is no relation between a flow-id and a "connection". The following are all possible: * allocate a flow-id to a specific connection, say the transfer of a file over the Internet. * allocate a flow-id to a set of related connections, say the audio, video and white-board streams of a conference, all handled by different processes over different socket, but all using the same flow-id and address parameters. * multiplex the packets sent by one application over several flow-ids, for example one per level of priority within the application. The constraint of the flow id is that it is specific to a source, a destination, and a "routing behaviour" between the source and the destination. It is legitimate to cache routing information such as destination address, source route or hop-by-hop options on per source-address+flow-id pair basis. The implication is that if the application decide to change any of these parameters, e.g. using a different source route, then the flow-id must change. How one get and pass the flow-id is indeed part of the API design. The constraint of the API are: 1) that flow-ids have to be unique for a given source. This implies a system function for allocating the flow ids. That system function deliver pseudo-random numbers, and check for their uniqueness. 2) that application programs should have a way to specify which flow-id they use, for example to coordinate sharing of the same flow between several sources. 3) that systems should be careful to invalidate the use of a flow-id by a given socket if key parameters of the socket change (destination address, source route, hop by hop parameters). The relation with RSVP is obvious. When an application starts transmitting on a given flow-id, that flow-id should also be present as a parameter in the RSVP "PATH" messages. When it starts receiving, the flow-id is a natural component of the reservation messages. This imply communication of the flow-id between the application process and the reservation process. Organization of that reservation channel is indeed system specific. By the way, just a clarification regarding the API. I can specify a flow-id either in a "bind" or in a "sendto" command, as part of the IPv6 socket address parameter. Which flow-id that should actually be transmitted in the packet? Hint: the flow-id that appears in the "recvfrom" parameter is obviously read from the incoming packet, thus the value specified by the source. Go figure... -- 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 Jun 9 07:53:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07815; Sun, 9 Jun 96 07:53:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07809; Sun, 9 Jun 96 07:53:25 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10717; Sun, 9 Jun 1996 07:49:56 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA11510; Sun, 9 Jun 1996 07:49:55 -0700 From: bound@zk3.dec.com Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA24575; Sun, 9 Jun 1996 10:40:17 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA03586; Sun, 9 Jun 1996 10:39:32 -0400 Message-Id: <9606091439.AA03586@fwasted.zk3.dec.com> To: Mike Shaver Cc: narten@VNET.IBM.COM (Thomas Narten), ipng@sunroof.eng.sun.com Subject: (IPng 1874) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of "Wed, 05 Jun 96 15:52:10 EDT." <199606051952.PAA05156@neon.ingenia.com> Date: Sun, 09 Jun 96 10:39:32 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, >Thus spake Thomas Narten: >> The problem is even worse for UDP, because now the logic for dealing >> with all this falls on applications themselves. For example, consider >> a UDP request from A to B_any and the corresponding reply. When >> application B responds to a message, it typically sends the reply back >> specifying that the response packet be sent using the source address >> that was in the destination of the original packet being responded to >> (i.e., B_any in this case). But if the original destination is an >> anycast address, the application now needs to know this and take >> special action to insure that the reply is sent from B_uni. Not >> undoable, but somehow more effort than would be ideal. All >> applications would need to be specially recoded to do the right >> thing. Ouch. >(Newbie warning.) > >Could this not be done in the kernel, like the checks for a source >address of IPV6_ADDR_ANY? >It would seem to me that the kernel could handle the conversion >between the anycast address used for the initial datagram and the >address used by the application, long before the application ever gets >it. That would prevent applications from having to deal with the >anycast issue if appropriate, and a new sockopt would allow an >application to find out if the original connection was `mapped' from >an anycast address or not if desired. Pedro and I just about got our draft complete and will make the deadline. As its only 8 pages once we send it to ID folks we will send to the list. But your totally correct it can be done in the kernel but Steve is right that the application must take responsibility for using an anycast address. That can be done with a socket level option and expecially for UDP. As far a TCP or UDP checking out and doing anything with PCBs or your favorite implementation data structure for verifying what to do with a source address is none of the IETFs business but an implementation discussion for those of us who still actually build networking kernels. I say this so we don't get confused whats the realm of the TCP and UDP RFCs and whats the realm of design of networking kernels. Pedro and my draft causes NO CHANGES to TCP or UDP which is different than Christian's proposal. Based on all the mail I have seen on this discussion I think we bascially came up with an idea that will support Steve's mail to some degree we hope from the mail last week. But I believe putting this in ICMP is not smart and unnecessary. /jim Mike -- #> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation <# #> Chief System Architect -- will tame sendmail(8) for food <# #> <# #> "You are a very perverse individual, and I think I'd like to get to <# #> know you better." --- eric@reference.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 Mon Jun 10 10:31:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08467; Mon, 10 Jun 96 10:31:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08461; Mon, 10 Jun 96 10:30:56 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA22370; Mon, 10 Jun 1996 10:27:23 -0700 From: Victor.DIAS-FERNANDES@dg12.cec.be Received: by mercury.Sun.COM (Sun.COM) id KAA01465; Mon, 10 Jun 1996 10:27:22 -0700 Received: from MX3.CEC.BE (tcbru10x [158.169.10.20]) by tcbru22.cec.be (8.6.12/8.6.12) with SMTP id SAA18778 for ; Mon, 10 Jun 1996 18:59:26 +0200 X400-Received: by mta MX3.CEC.BE in /PRMD=CEC/ADMD=RTT/C=BE/; Relayed; Mon, 10 Jun 1996 18:58:47 +0200 X400-Received: by /PRMD=CEC/ADMD=RTT/C=BE/; Relayed; Mon, 10 Jun 1996 11:31:47 +0200 Date: Mon, 10 Jun 1996 11:31:47 +0200 X400-Originator: Victor.DIAS-FERNANDES@DG12.cec.be X400-Recipients: ipng@sunroof.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=CEC/ADMD=RTT/C=BE/;0011500001105675000002] X400-Content-Type: P2-1988 (22) Content-Identifier: Re: I-D ACTION: Message-Id: To: Subject: (IPng 1875) Re: I-D ACTION:draft-ietf-ipngwg-linkname-00.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe this can be a very useful mechanism, but I have some security concerns; even if this will be restricted to the local physical link (it can be very large). - Suppose that system S2 wants to connect to system S1. S2 sends a Link Local Address and Name Resolution (LANR) request packet on the link to map S1`s name to an address, but system S3 "arranges" for the packet not to be received/processed by S1, and S3 generates a LANR response packet to S2 advertising S1 name and S3 address. As S3 knows the name and address of S1, then communication between S1 and S2 will be through S3: S1 <--> S3 <--> S2 - What will be the action of a system upon reception of a duplicate Name:Address map: 1- for is own name, 2- for a neighbor name I think we could include some other requirements in the implementation: - drop any packet with a TTL=0 that thus not come from the cached link address - allow for a local (system) configuration file with Name:Address maps that will be permanent. These maps will not change with any protocol event. - if a duplicate name is detected a system must: 1- log the event with the Time, Name and Conflicting Addresses 2- if the duplicate name is with the system`s own name, inform the network/system administrator of the duplication (with any available facilities), and re-Advertise is Name:Address (how long?) 3- if the duplicate name is with one of the permanent names locally configured, ignore the packet 4- if the duplicated name is with another map entry created with a LANR protocol event, ignore the advertised name and clear the local cache entry. - at least one case of duplicate Name:Address map can occur and be legal. It will be the case if a system changes it`s IP Address but not it`s name (installation of a new network link interface and using auto-configuration). In this case (or other legal cases), to avoid the described duplicate detection process, a system could (if possible) send some LANR Advertise packets with TTL=0 before disabling the network link interface. Victor Dias Fernandes (victor.dias-fernandes@dg12.cec.be) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 10 11:54:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08618; Mon, 10 Jun 96 11:54:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08612; Mon, 10 Jun 96 11:54:17 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA08918; Mon, 10 Jun 1996 11:50:44 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA09510; Mon, 10 Jun 1996 11:50:37 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id OAA21429; Mon, 10 Jun 1996 14:44:08 -0400 (EDT) Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA02669; Mon, 10 Jun 1996 14:44:07 -0400 Received: by netrix.lkg.dec.com; (5.65v3.2/1.1.8.2/28May95-0415PM) id AA27563; Mon, 10 Jun 1996 14:44:17 -0400 Date: Mon, 10 Jun 1996 14:44:17 -0400 From: Dan Harrington Message-Id: <9606101844.AA27563@netrix.lkg.dec.com> To: Victor.DIAS-FERNANDES@dg12.cec.be Subject: (IPng 1876) Re: I-D ACTION:draft-ietf-ipngwg-linkname-00.txt Cc: dan@netrix.lkg.dec.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Victor, Thanks for the feedback... > I believe this can be a very useful mechanism, but I have some security > concerns; > even if this will be restricted to the local physical link (it can be very > large). Yes, Matt C. made a similar point re. large LANs...I'll have to ponder that point. > - Suppose that system S2 wants to connect to system S1. > S2 sends a Link Local Address and Name Resolution (LANR) request > packet on the link to map S1`s name to an address, but system S3 > "arranges" for the packet not to be received/processed by S1, and > S3 generates a LANR response packet to S2 advertising S1 name and > S3 address. As S3 knows the name and address of S1, then > communication between S1 and S2 will be through S3: > > S1 <--> S3 <--> S2 I'm not terribly clear on how S3 could "arrange" for a packet sent to a multicast destination to be selectively misdelivered. Nor is it obvious to me how S3 would be inserted as a forwarder...in the scenario you described, after receiving the response message S2 would send a unicast packet to S3. How would S3 know enough to think it was meant for S1, and thereby forward it? > - What will be the action of a system upon reception of a duplicate > Name:Address map: > 1- for is own name, Take no action. If it is indeed a duplicate, then what would be the harm of having your own name/address mapping reiterated? You would be looping back such a packet anyhow, wouldn't you? Perhaps there would be a concern if the TTL=0... > 2- for a neighbor name Look at the TTL fields and act accordingly. > I think we could include some other requirements in the implementation: > > - drop any packet with a TTL=0 that thus not come from the cached link > address If the TTL is 0, it indicates that the cached name:address pair should be deleted. If you don't have that mapping, no action need be taken. But I wouldn't construe that as being equivalent to "drop the packet". > - allow for a local (system) configuration file with Name:Address maps that > will be permanent. These maps will not change with any protocol event. That is what /etc/hosts (or equivalent) is there for. > - if a duplicate name is detected a system must: > > 1- log the event with the Time, Name and Conflicting Addresses > 2- if the duplicate name is with the system`s own name, inform the > network/system administrator of the duplication (with any available > facilities), > and re-Advertise is Name:Address (how long?) > 3- if the duplicate name is with one of the permanent names locally > configured, > ignore the packet > 4- if the duplicated name is with another map entry created with a > LANR protocol > event, ignore the advertised name and clear the local cache entry. These sound like implementation details, which I'd be happy to consider as suggestions. I'll have to think about #4, though... Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jun 10 12:49:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08753; Mon, 10 Jun 96 12:49:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08745; Mon, 10 Jun 96 12:49:30 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA18411; Mon, 10 Jun 1996 12:45:59 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA29284; Mon, 10 Jun 1996 12:45:34 -0700 Received: from munin.fnal.gov ("port 1205"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I5QWYONF66002MUY@FNAL.FNAL.GOV>; Mon, 10 Jun 1996 14:45:18 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id OAA01436; Mon, 10 Jun 1996 14:44:21 -0500 (CDT) Date: Mon, 10 Jun 1996 14:44:20 -0500 From: Matt Crawford Subject: (IPng 1877) Re: I-D ACTION:draft-ietf-ipngwg-linkname-00.txt In-Reply-To: "10 Jun 1996 14:44:17 EDT." <"9606101844.AA27563"@netrix.lkg.dec.com> To: Dan Harrington Cc: ipng@sunroof.eng.sun.com Message-Id: <199606101944.OAA01436@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{ I'm not terribly clear on how S3 could "arrange" for a packet sent > to a multicast destination to be selectively misdelivered. A fiendish node on a shared ethernet, for example, could receive most of a packet and then stomp on the FCS, causing all other nodes to ignore it. From this starting point you can do a lot of nasty, including subverting a Diffie-Hellman key exchange. As for subverting LANR by interception, I think the relevant question is, does that make a bigger hole than subversion of ND itself? I don't see how. _________________________________________________________ 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 Mon Jun 10 14:27:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08848; Mon, 10 Jun 96 14:27:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08838; Mon, 10 Jun 96 14:27:07 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA06401; Mon, 10 Jun 1996 14:23:35 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA06793; Mon, 10 Jun 1996 14:23:33 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id RAA08186; Mon, 10 Jun 1996 17:14:19 -0400 (EDT) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA03929; Mon, 10 Jun 1996 17:14:15 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id RAA19402; Mon, 10 Jun 1996 17:18:47 GMT Message-Id: <199606101718.RAA19402@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: ipng@sunroof.eng.sun.com Cc: Matt Crawford Subject: (IPng 1878) Re: I-D ACTION:draft-ietf-ipngwg-linkname-00.txt In-Reply-To: Your message of "Mon, 10 Jun 1996 14:44:20 EST." <199606101944.OAA01436@munin.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jun 1996 17:18:40 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I'm not terribly clear on how S3 could "arrange" for a packet sent > > to a multicast destination to be selectively misdelivered. > > A fiendish node on a shared ethernet, for example, could receive most > of a packet and then stomp on the FCS, causing all other nodes to > ignore it. From this starting point you can do a lot of nasty, > including subverting a Diffie-Hellman key exchange. True. But then in a real secure environment, you wouldn't be using a real shared LAN. You'd use Ethernet switches (or equivalent) and the only person the fiendish node would hurt is himself. Should I even mention physical security in the above scenario? > As for subverting LANR by interception, I think the relevant question > is, does that make a bigger hole than subversion of ND itself? I > don't see how. Neither do I. And while I have the soapbox ... While I concede that security is important, the current zeal that some in the IETF have for it is becoming quite frustrating. If the same zeal for security was applied to computer hardware, I doubt they'd allow anything to ship unless it was fully Tempest compliant (damn the price). [The above is not directed at Matt Crawford but is a personal comment about the IETF in general.] -- 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 Jun 10 17:14:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09095; Mon, 10 Jun 96 17:14:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08734; Mon, 10 Jun 96 12:47:42 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA18194; Mon, 10 Jun 1996 12:44:08 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id MAA28501; Mon, 10 Jun 1996 12:43:57 -0700 Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA32509; Mon, 10 Jun 1996 15:34:04 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA29499; Mon, 10 Jun 1996 15:34:02 -0400 Message-Id: <9606101934.AA29499@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 1879) Jim/Pedro Anycast Usage Draft for Montreal IPng Meeting Date: Mon, 10 Jun 96 15:34:01 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPng WG, Here is the draft we just sent to CNRI. We await your comments. Pedro and I will take comments to help us build the slides to present this work to you at Montreal IETF meeting to foster a good discussion. Input this week would be greatly appreciated as I will be at the IPv6 UNH 2cnd Interoperability Event June 18-21, and would like to build our discussion slides at Montreal with Pedro before June 17. thanks /jim Return-Path: bound Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA10140; Sun, 9 Jun 1996 13:01:02 -0400 Message-Id: <9606091701.AA10140@fwasted.zk3.dec.com> To: internet-drafts@cnri.reston.va.us Cc: roque@di.fc.ul.pt, bound@zk3.dec.com, hinden@ipsilon.com, deering@parc.xerox.com, cclark@cnri.reston.va.us Subject: ID draft-bound-anycast-00.txt Date: Sun, 09 Jun 96 13:01:02 -0400 From: bound X-Mts: smtp Hi, Please submit as ID on behalf of Pedro Roque and I. We will be reviewing this draft at the Montreal IETF IPng WG meetings. thanks /jim - ----------cut here------------------ INTERNET-DRAFT J. Bound IPv6 Work in Progress Digital Equipment Corp P. Roque Universidade de Lisboa IPv6 Anycasting Service: Minimum requirements for end nodes 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 document proposes a minimum set of requirements for IPv6 hosts in order to achieve communication with nodes providing services through IPv6 anycast addresses. We present a mechanism that aims to allow TCP and UDP communication between hosts where the packet exchange is initiated through the usage of an anycast address, without requiring modifications to the general definitions of the transport protocols. Expires January 1997 [Page 1] INTERNET-DRAFT June 1996 Table of Contents: 1. Introduction.................................................3 2. Terminology and Definitions..................................3 3. Anycast address usage........................................4 4. Source Identification Option.................................5 5. Receipt of Source Identification Option......................5 6. Issues for Further Consideration.............................7 Acknowledgements................................................7 References......................................................7 Authors' Address................................................8 Expires January 1997 [Page 2] INTERNET-DRAFT June 1996 1. Introduction IPv6 Anycast addresses [RFC-1883] allow a datagram to be addressed to a group of hosts with delivery to one and preferably only one semantic. This facility can be used to facilitate traffic path selection when a group identifies the set of routers of a particular traffic provider. Other possible uses of anycast addresses are to provide a "Host Anycasting Service" [RFC-1546], where a set of hosts can represent a particular service. While the particular mechanisms hosts can use to provide services via anycast addresses are still to be defined, this document attempts to define a minimum set of requirements that should be implemented in all IPv6 hosts in order to use those services. The authors view a "Host Anycasting Service" as complementary, rather than orthogonal, to Service Discovery mechanisms [SVRLOC] since they can be used to provide lightweight service access without the need for previous configuration. For instance, a well-known site-local address can be used to communicate with a host that provides service discovery services. While it is expected that the particular specifications regarding anycast address usage by application servers and routing are defined as extensions to IPv6 and companion protocols, the authors feel that mechanisms needed in every host should be defined before the massive deployment of IPv6 hosts. The problems pertaining to the usage of anycast addresses for accessing application services can be clearly divided in three distinct components: procedures for hosts providing services via anycast addresses, routing, and procedures in hosts accessing services via anycast. This document focuses solely on the later problem, as the authors consider that it can be solved independently of the previous two. 2. Terminology and Definitions IP Internet Protocol Version 6 (IPv6). The terms IPv4 and IPv6 are used only in contexts where necessary to avoid ambiguity. Anycast Address An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the "nearest" one, according to the routing protocols' measure of distance). Expires January 1997 [Page 3] INTERNET-DRAFT June 1996 Communication Any packet exchange between nodes that requires that the address of each node used in the exchange remain the same for the duration of the packet exchange. Examples are a TCP connection or UDP request/response. 3. Anycast address usage Anycast addresses are restricted to be used as the destination address of a datagram. This requirement is imposed by necessity to determine the originating node of a datagram in error conditions. Current transport protocols [RFC-768] [RFC-793] rely, however, on the source address of the IP datagram to demultiplex incoming packets. Independently of how the network delivers datagrams addressed to an anycast group, it's usage in normal communication depends on the ability of a host to accept a datagram originating from a distinct unicast address as a reply to a packet sent to an anycast address. Also, as anycast addresses are syntacticly indistinguishable from unicast addresses, the client of a service provided via anycast should not need explicit knowledge of whenever a particular address is unicast or anycast, much less the particular group membership for a particular anycast address. To fulfill the above stated goals, the authors propose the definition of a Destination Option, named Source Identification Option, to dynamically inform client hosts that a particular communication initiated through the use of an anycast address should proceed with the use of a unicast address of one of the anycast group members. This option requires no processing from the network layer other than encoding and decoding the respective extension header and MUST be passed transparently from the network layer to the transport layer. The transport layer MAY then take in to account this information when demultiplexing datagrams. Section 5 of this document discusses in more detail the expected behavior of transport protocols when receiving a datagram with this option. Although this document does not pretend to specify the mechanisms to be used by hosts providing a service through anycast addresses, we note that a reply to a datagram received for an anycast address will not be correctly interpreted if a Source Identification Option is not present. Expires January 1997 [Page 4] INTERNET-DRAFT June 1996 4. Source Identification Option The Source Identification Option provides a mechanism hosts can use to inform it's communications peers that datagram demultiplexing by transport protocols should be performed with respect to the identifier present in this option. This option is encoded in the Destination Options Extension Header of IP datagrams as option type TBD. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Identifier | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 8-bit identifier of the type of option. The first three bits of the option are 000, indicating first that a node receiving the option may discard the option and still process the rest of the packet, and second that the option may not be modified enroute. Option Length 8-bit unsigned integer. Length of the Option Data field of this option, in octets. Identifier 128-bit IP address. The anycast address known to the receiver of the datagram as the destination address of a particular communication. 5. Receipt of Source Identification Option As previously stated in section 3 of this document, a transport protocol MAY take in account the identifier received in a Source Identification Option for purposes of datagram demultiplexing. TCP [RFC-793] communication depends on the knowledge of state information by communicating peers, initialized on a synchronization period referred to as the "three way handshake". In terms of access to a service provided via the use of anycast address, procedures must be provided to insure correct synchronization between the client and a member of the anycast group, and to maintain the same communication end- points during the duration of the connection. Expires January 1997 [Page 5] INTERNET-DRAFT June 1996 An IP node performing a TCP active open sends a segment to the network addressed to the destination address of the connection. It then expects to receive a segment from this address confirming or rejecting the connection establishment request. When the destination address of the connection is an anycast address this condition cannot be met since the responding host may not send datagrams using an anycast address as source address in datagrams. In this scenario, the responding node should use the Source Identification Option, with the destination address on the received syn segment as an identifier, in order to inform the node performing the active open that the segment is related to this communication. A TCP performing an active open MAY then use the IP address present on the Source Identification Option to demultiplex the incoming segment. If the segment causes TCP to proceed to SYN-RECEIVED or ESTABLISHED it MUST then consider that the destination address of the connection is the source address present on the received segment. Note that for TCP, the receipt of a Source Identification Option is meaningful only when the segment refers to a connection on the SYN-SENT state. Otherwise, this option should be ignored by TCP. This will cause the received segment to be interpreted as a segment to a connection in the CLOSED state, assuming that no communication is taking place between the same address/port pairs. Datagram exchanges using UDP [RFC-768] constitute a more problematic case. While UDP is itself connectionless, many applications using this transport protocol require state to be maintained. This implies that while some applications desire to communicate with any of the members of the anycast group, others can only tolerate anycast initiated communication requiring subsequent packets to be delivered to the same host. Since the appropriate semantics of anycast address usage on UDP communication are application dependent, a UDP implementation should only take in to account the Source Identification Option when this behavior has been explicitly requested by the application. When such option is selected by the application incoming datagrams containing a Source Identification Option shall be demultiplexed and delivered to the application using the identifier contained in the option as the source address of the datagram. Otherwise, the Source Identification Option should be ignored by a UDP implementation. As UDP already provides a means for determination of the originating node of a received datagram by applications, no further modifications are required to allow the use of this service with the desired semantics. Expires January 1997 [Page 6] INTERNET-DRAFT June 1996 6. Issues for Further Consideration Security considerations. Receipt of a RST segment carried in a datagram containing a Source Identification Option. According to [RFC-793], a segment containing a valid acknowledgement value and the RST bit on for a TCP connection in SYN-SENT state, will cause the connection to enter the CLOSED state. In the specific case of an active open to an anycast address, this abortive termination could be caused by a failure from one of the group members. The appropriate action to take in this case is an issue for further study. Acknowledgements We would like to thank Dan Harrington and Mike Shand who have provided comments and review of an earlier version of this work. References [RFC-768] J. Postel, "User Datagram Protocol", STD-6, August 1980. [RFC-793] J. Postel, "Transmission Control Protocol", STD-7, September 1981. [RFC-1546] C. Partridge, T. Mendez, W. Milliken, "Host Anycasting Service", Informational Request for Comments, November 1993. [RFC-1883] S. Deering and R. Hinden, "Internet Protocol Version 6, (IPv6) Specification" Proposed Standard, December 1995. [SVRLOC] J. Veizades, E. Guttman, C. Perkins and S. Kaplan, "Service Location Protocol", Internet Draft, March 1996, Expires January 1997 [Page 7] INTERNET-DRAFT June 1996 Authors' Address Jim Bound Digital Equipment Corporation 110 Spitbrook Road, ZKO3-3/U14 Nashua, NH 03062 Phone: (603) 881-0400 Email: bound@zk3.dec.com Pedro Roque Departamento de Inform'atica Faculdade de Ciencias da Universidade de Lisboa Campo Grande - Bloco C5 1700 Lisboa, Portugal Email: roque@di.fc.ul.pt Expires January 1997 [Page 8] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 11 10:17:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09559; Tue, 11 Jun 96 10:17:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09553; Tue, 11 Jun 96 10:16:58 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA02774; Tue, 11 Jun 1996 10:13:15 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA20195; Tue, 11 Jun 1996 10:13:10 -0700 Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id NAA18996; Tue, 11 Jun 1996 13:12:11 -0400 Received: from apollo13.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id NAA07059; Tue, 11 Jun 1996 13:12:29 -0400 Received: by apollo13.cascade (5.x/SMI-SVR4) id AA18738; Tue, 11 Jun 1996 13:12:33 -0400 Date: Tue, 11 Jun 1996 13:12:33 -0400 From: jmoy@alpo.casc.com (John Moy) Message-Id: <9606111712.AA18738@apollo13.cascade> To: ospf@gated.cornell.edu Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1880) draft-ietf-ospf-ospfv6-02.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi. The complete OSPF for IPv6 specification has been posted as draft-ietf-ospf-ospfv6-02.txt in the standard I-D repositories. The changes from the previous IPv6 spec are as follows: o Section 3, "Implementation details" has been completed. This section serves as a recipe for turning an OSPF for IPv4 implementation into one for IPv6. o As per discussions at the last IETF, the "external route tag" field has been added back to the AS-external-LSA. o The sense of the LS type's U-bit has been reversed, so that the coding of 0 now represents the common case: if LS type unrecognized, treat the LSA as if it had link-local flooding scope. o LSAs with global scope and/or unknown LS type with U-bit set to 1 (flood even when LS type unrecognized) are excluded from stub areas, as per discussions on the mailing list. o Neighbors are always identified by their Router ID (as opposed to the IPv4 situation, where neighbors on broadcast, NBMA and Point-to-MultiPoint interfaces are identified by IP interface address). o A router advertises its own point-to-point interface addresses in intra-area-prefix-LSAs, rather than advertising the neighbor's address or a prefix for the link (the two IPv4 options). o All section references (previously listed as XX) are now filled in. Note that the document references a yet-to-be-published OSPF for IPv4 update ([Ref1]). I'll be sending that document out in the next couple of days. The OSPF WG will be meeting at the Montreal IETF on Wednesday, 6/26 from 1300-1500. The OSPF for IPv6 document will be on the agenda. The rest of the agenda will be determined this week. 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 Thu Jun 13 09:08:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11156; Thu, 13 Jun 96 09:08:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10966; Thu, 13 Jun 96 03:23:36 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA21629; Thu, 13 Jun 1996 03:19:59 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA09108; Thu, 13 Jun 1996 03:19:59 -0700 Received: from my8.sm.luth.se (my8.sm.luth.se [130.240.3.38]) by my28.sm.luth.se (8.7.5/8.7.2) with ESMTP id MAA26163; Thu, 13 Jun 1996 12:19:26 +0200 Received: from localhost (micke@localhost) by my8.sm.luth.se (8.6.11/8.6.11) with SMTP id MAA23068; Thu, 13 Jun 1996 12:22:44 +0200 Message-Id: <199606131022.MAA23068@my8.sm.luth.se> X-Mailer: exmh version 1.6.6 3/24/96 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 Subject: (IPng 1881) ipng@sunroof.eng.sun.com Date: Thu, 13 Jun 1996 12:22:42 +0200 From: Mikael Degermark Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have a new i-d on ipv6 header compression. It will appear before the IETF. Meanwhile you can fetch it at ftp://cdt.luth.se/micke/draft-degermark-ipv6-hc-01.txt Important changes from the previous version are * link-layer is required to indicate type of compressed headers. This saves a lot of real-estate in the new compressed header formats. * new mechanisms for dealing with links that reorder. These mechanisms also solve a problem caused by the TCP window scale option pointed out by Craig Partridge at the LA IETF * mechanisms for quick repair of the compression state after loss. This can improve TCP performance by up to 30 per cent when header compression is used over lossy links such as wireless. * revised section on grouping of packets into packet streams. We would like to hear any comments you might have... Micke ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 13 12:45:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11356; Thu, 13 Jun 96 12:45:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11350; Thu, 13 Jun 96 12:45:20 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA28635; Thu, 13 Jun 1996 12:41:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA04403; Thu, 13 Jun 1996 12:41:44 -0700 Received: from my8.sm.luth.se (my8.sm.luth.se [130.240.3.38]) by my28.sm.luth.se (8.7.5/8.7.2) with ESMTP id VAA07302; Thu, 13 Jun 1996 21:40:36 +0200 Received: from localhost (micke@localhost) by my8.sm.luth.se (8.6.11/8.6.11) with SMTP id VAA27811; Thu, 13 Jun 1996 21:43:55 +0200 Message-Id: <199606131943.VAA27811@my8.sm.luth.se> X-Mailer: exmh version 1.6.6 3/24/96 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: ipng@sunroof.eng.sun.com, rem-conf@es.net Subject: (IPng 1882) IPv6 Header Compression Date: Thu, 13 Jun 1996 21:43:54 +0200 From: Mikael Degermark Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have a new i-d on IPv6 header compression. It will appear before the IETF. Meanwhile you can fetch it at ftp://cdt.luth.se/micke/draft-degermark-ipv6-hc-01.txt Abstract 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/UDP header can be compressed down to 4 octets including the UDP checksum. A typical IPv6/TCP header can be compressed down to 4-6 octets including the TCP checksum. Important changes from the previous version are * link-layer is required to indicate type of compressed headers. This saves a lot of real-estate in the new compressed header formats. * new mechanisms for dealing with links that reorder. These mechanisms also solve a problem caused by the TCP window scale option pointed out by Craig Partridge at the LA IETF * mechanisms for quick repair of the compression state after loss. This can improve TCP performance by up to 30 per cent when header compression is used over lossy links such as wireless. * revised section on grouping of packets into packet streams. We would like to hear any comments you might have... Micke ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 13 15:25:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11473; Thu, 13 Jun 96 15:25:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11467; Thu, 13 Jun 96 15:25:25 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA25588; Thu, 13 Jun 1996 15:21:47 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA27104; Thu, 13 Jun 1996 15:21:46 -0700 Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa16724; 13 Jun 96 18:21:17 EDT To: mobile-ip@SMALLWORKS.com, ipng@sunroof.eng.sun.com Cc: Charlie Perkins From: Dave Johnson Subject: (IPng 1883) New Mobile IPv6 draft Date: Thu, 13 Jun 96 18:21:06 -0400 Message-Id: <16722.834704466@CHIMAY.MACH.CS.CMU.EDU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie Perkins and I have completed a new version of the draft on "Mobility Support in IPv6" that should be appearing in your favorite internet-drafts directory soon. You can also get a copy now from: ftp://ftp.cs.cmu.edu/user/dbj/mobile-ip/draft-ietf-mobileip-ipv6-01.txt Here is a copy of the Abstract from the draft: This document specifies the operation of mobile computers using IPv6. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send packets destined for the mobile node directly to it at this care-of address. The Mobile IP working group has reached consensus on the approach described in this draft, based on earlier versions of the draft and presentations at IETF meetings. This new version of the draft now contains a more detailed specification of the protocol, and contains specific requirements for all IPv6 nodes. These requirements are quite simple, yet allow dramatic simplifications in the Mobile IPv6 protocol. Given the expected rapid growth in the number of mobile nodes in the Internet, we view these requirements as essential in order to allow efficient, ubiquitous operation of the protocol anywhere. Questions or comments on the draft should be sent to the Mobile IP mailing list at mobile-ip@SmallWorks.COM. Dave -- David B. Johnson E-mail: dbj@cs.cmu.edu Assistant Professor Home page: http://www.cs.cmu.edu/~dbj/ Computer Science Department Phone: (412) 268-7399 Carnegie Mellon University Fax: (412) 268-5576 5000 Forbes Avenue Pittsburgh, PA 15213-3891 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 17 12:45:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13535; Mon, 17 Jun 96 12:45:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13529; Mon, 17 Jun 96 12:45:29 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA05053; Mon, 17 Jun 1996 12:41:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA18120; Mon, 17 Jun 1996 12:41:47 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa28864; 17 Jun 96 15:33 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1884) I-D ACTION:draft-ietf-ipngwg-ipv6-tunnel-02.txt Date: Mon, 17 Jun 96 15:33:29 -0400 Message-Id: <9606171533.aa28864@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-02.txt Pages : 38 Date : 06/14/1996 This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. The model and mechanisms can be applied to other protocol packets as well, such as AppleTalk, IPX, CLNP, or others. 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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-02.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 (193.205.245.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-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960617153301.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-tunnel-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960617153301.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 Jun 17 13:16:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13601; Mon, 17 Jun 96 13:16:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13595; Mon, 17 Jun 96 13:16:17 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA10023; Mon, 17 Jun 1996 13:12:36 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA28871; Mon, 17 Jun 1996 13:12:34 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa24889; 17 Jun 96 14:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1885) I-D ACTION:draft-cisco-ipv6-router-alert-00.txt Date: Mon, 17 Jun 96 14:19:26 -0400 Message-Id: <9606171419.aa24889@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. Title : IPv6 Router Alert Option Author(s) : R. Atkinson, D. Katz Filename : draft-cisco-ipv6-router-alert-00.txt Pages : 4 Date : 06/14/1996 This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for protocols addressed to a destination but also require special processing in routers along the path. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-cisco-ipv6-router-alert-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-cisco-ipv6-router-alert-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 (193.205.245.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-cisco-ipv6-router-alert-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: <19960614153112.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-cisco-ipv6-router-alert-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-cisco-ipv6-router-alert-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960614153112.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 Tue Jun 18 14:52:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14450; Tue, 18 Jun 96 14:52:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14444; Tue, 18 Jun 96 14:51:46 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA04091; Tue, 18 Jun 1996 14:48:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA11790; Tue, 18 Jun 1996 14:47:50 -0700 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 OAA21501; Tue, 18 Jun 1996 14:47:39 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jun 1996 14:49:03 -0700 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1886) Draft IPng Agenda Cc: hinden@Ipsilon.COM, deering@parc.xerox.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the draft agenda for next week's IPng meeting in Montreal. Please: o Send us proposed additions, deletions, changes, time changes, etc. o Don't yell at us if we forgot to include your request. o Do volunteer for one of the unassigned status reports currently labelled "?" We have a lot of topics to cover. Consequentially we are trying to do a better job managing the time for each topic. For example if one of the status reports starts to generate a substantive discussion, we will try to schedule it for a latter time slot. Bob Hinden / Steve Deering ___________________________________________________________________________ Draft IPNG Working Group Agenda Montreal IETF June 24-28, 1996 Monday 1930 - 2200 Introduction - Steve Deering & Bob Hinden 10 min Document Status - Bob Hinden 10 min Status Reports (each 10 min or less) 130 min UNH Testing - Bill Lenharth Header Compression - Micke Degermark IPv6 Tunneling - Alex Conta Interface IDs - Robert Elz UDP & TCP/MSS vs. Jumbograms - Dave Borman Neighbor Discovery - Tom Narten ITU Request for IPv6 Addresses - Bob Hinden IPv6 Auto-Configuration - Sue Thompson DHCPv6 - ? IPv6 Mobility - ? RIPng - ? OSPFng - ? IDRPng - ? IPv6 over NBMA - ? IPv6 over PPP - ? IPv6 Multicast Routing - Steve Deering Tuesday 0900 - 1130 Host Anycast - Jim Bound & Pedro Roque 30 min Multihomed Hosts - Mike Shand & Matt Thomas 30 min BSD API Issues - Bob Gilligan 30 min Naming Link-Local Addresses - Dan Harrington 10 min Router Alert Option - Ran Atkinson 10 min Host Handling of Route Header - Steve Deering 10 min Open 30 min Wednesday 0900 - 1130 Spec Changes/Clarifications - Steve Deering 30 min Advancement of main specs to Draft Standard? 10 min Open for Additional Topics and continuation of 100 min earlier topics Conclusion / Interm Meeting Scheduling 10 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 18 17:02:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14631; Tue, 18 Jun 96 17:02:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14623; Tue, 18 Jun 96 17:01:53 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA25059; Tue, 18 Jun 1996 16:58:11 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA07805; Tue, 18 Jun 1996 16:58:09 -0700 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 QAA26007; Tue, 18 Jun 1996 16:58:07 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jun 1996 16:59:31 -0700 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1887) Update to IPng Web Pages Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I completed an update to the IPng web pages at: http://playground.sun.com/ipng The changes include new implementations (see who is now implementing IPng), pointers to the new internet drafts and RFCs, and a number of small changes/corrections. Changes/corrections/comments to me. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 18 20:17:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14863; Tue, 18 Jun 96 20:17:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14857; Tue, 18 Jun 96 20:16:45 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA14640; Tue, 18 Jun 1996 20:13:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA18423; Tue, 18 Jun 1996 20:13:02 -0700 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.12/8.6.11) with ESMTP id XAA13399; Tue, 18 Jun 1996 23:12:29 -0400 Message-Id: <199606190312.XAA13399@thumper.bellcore.com> To: ipng@sunroof.eng.sun.com Cc: ion@nexen.com, gja@thumper.bellcore.com Subject: (IPng 1888) IPv6 over NBMA - Montreal Date: Tue, 18 Jun 1996 23:12:13 -0400 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is intended as a 'heads up' for the IPNG WG, and an FYI for the ION WG. My apologies that it'll be redundant for those of you tracking both groups closely. I've updated my little web page of pointers to ION I-Ds on the IPv6 over NBMA issue. It is at: http://gump.bellcore.com:8000/~gja/iv6-drafts.html This topic will be discussed in depth in the ION meeting next Tuesday in Montreal. I'd encourage IONic people to read up on IPv6 issues, and IPv6ers to come along to help keep us packet-shredders honest. For newcomers, a brief history: - July 1995, Stockholm, I voluntered to edit an I-D on IPv6 over ATM. Soon afterwards, the IP-ATM WG was formally tasked with working on the IPv6 over ATM problem space, and I released draft-ietf-ipatm-ipv6nd-00.txt to start public debate. - The public didn't really notice until Dec95/Jan96, and much excitment was had at the March 96 IETF in LA, as three proposals hit the newstands. draft-ietf-ipatm-ipv6nd-01/02 tracked the evolving consensus points and tossed out parts that were declared crappy. - ROLC and IP-ATM merged into ION, which now has the task of moving forward with IPv6. The default appears to have been to expand the scope to be generally IPv6 over NBMA. The I-D I've editted to track developments is now draft-ietf-ion-ipv6nd-00. Three additional I-Ds currently exist proposing some divergent approaches to items on which there is no current consensus. These are: draft-ietf-ion-ipv6-nbma-00 draft-ietf-ion-ipv6atm-framework-00 draft-armitage-ion-tn-00 cheers, gja _________________________________________________________________________ Grenville Armitage http://gump.bellcore.com:8000/~gja/home.html On the Internet, I AM a dog. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 20 15:41:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16304; Thu, 20 Jun 96 15:41:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16298; Thu, 20 Jun 96 15:41:28 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA21141; Thu, 20 Jun 1996 15:37:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA23684; Thu, 20 Jun 1996 15:37:23 -0700 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (8.7.3/8.6.10/MOT-3.8) with ESMTP id WAA05543; Thu, 20 Jun 1996 22:35:10 GMT Received: from il02dns1.comm.mot.com (il02dns1.comm.mot.com [145.1.3.2]) by pobox.mot.com (8.7.3/8.6.10/MOT-3.8) with ESMTP id RAA05618; Thu, 20 Jun 1996 17:37:10 -0500 (CDT) Received: from becks.comm.mot.com (becks.comm.mot.com [145.1.80.10]) by il02dns1.comm.mot.com (8.7.5/8.7.3) with SMTP id RAA10082; Thu, 20 Jun 1996 17:38:26 -0500 (CDT) Received: from localhost by becks.comm.mot.com (4.1/SMI-4.1) id AA17859; Thu, 20 Jun 96 17:37:07 CDT Message-Id: <9606202237.AA17859@becks.comm.mot.com> To: mobile-ip@smallworks.com, ietf-secretariat@cnri.reston.va.us, ipng@sunroof.eng.sun.com Cc: solomon@comm.mot.com, nordmark@Eng (Erik Nordmark), jhalpern@newbridge.com (Joel Halpern) Subject: (IPng 1889) Agenda for Mobile IP in Montreal Date: Thu, 20 Jun 1996 17:37:07 -0500 From: "James D. Solomon" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greetings, Here's a pseudo-final agenda for Montreal. Note that the order of primary focus in the meetings (i.e. IPv4 mobility vs. IPv6 mobility) has changed from my last posting. Note also that the first meeting (Wednesday) has been moved to 1300-1500. Both sessions are scheduled for MBONE multicasting. We encourage the active participants of the IPNGWG to attend the first Mobile IP session which will focus on Mobile IPv6. [Note to all presenters: please read and and heed the wisdom contained therein!] Regards, Jim S. MOBILE IP WG AGENDA I) WEDNESDAY, June 26, 1996, 1300-1500, TOPIC: Mobile IPv6 1) WG Draft: draft-ietf-mobileip-ipv6-01.txt (please read it!!) Dave Johnson and/or Charlie Perkins 2) draft-teraoka-ipv6-mobility-sup-03.txt Fumio Teraoka Recommended reading: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-ipv6-01.txt ftp://ds.internic.net/rfc/rfc1883.txt ftp://ds.internic.net/rfc/rfc1885.txt ftp://ds.internic.net/internet-drafts/draft-teraoka-ipv6-mobility-sup-03.txt II) THURSDAY, June 27, 1996, 1300-1500 TOPIC: Mobile IPv4 0) Administravia 1) SKIP firewall support for Mobile IP Gabriel Montenegro 15 min. 2) Authenticated Firewall Traversal Michael Richardson 10 min. 3) Authentic Firewall Traversal and Subnet Mobility in VIPv3 Fumio Teraoka 10 min. 4) Fast and Scalable Handoffs for Wireless Internetworks Ramon Caceres 15 min. 5) "Network Connection Quality" Extension Dave Johnson 15 min. 6) Route Optimization Dave Johnson 7) Route Optimization Kazuhiro Okanoue Recommended Reading: ftp://ds.internic.net/internet-drafts/draft-richardson-ipsec-aft-00.txt ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-optim-04.txt ftp://ds.internic.net/internet-drafts/draft-okanoue-mobileip-R+A-00.txt ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-06.txt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 20 16:52:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16404; Thu, 20 Jun 96 16:52:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16398; Thu, 20 Jun 96 16:51:50 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA03072; Thu, 20 Jun 1996 16:48:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA14000; Thu, 20 Jun 1996 16:48:03 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with SMTP id QAA10498 for ; Thu, 20 Jun 1996 16:47:59 -0700 (MST) Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA00428; Thu, 20 Jun 96 16:48:01 MST; for ipng@sunroof.eng.sun.com Message-Id: <9606202348.AA00428@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Thu, 20 Jun 1996 16:48:00 -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 1890) IPv6 BSD API changes Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (I was going to send this to only the people who attended the ad-hoc meeting in LA on the BSD API changes but realized there are probably more interested parties out there, many of whom participated in the email exchanges on the larger IPng mailing list in March and April.) There are a few items still outstanding from all our previous discussions: 1. Resolver changes required to handle IPv6 addresses [i.e., gethostbyname() and gethostbyaddr()]. 2. Final definitions of the inet_pton() and inet_ntop() functions, that will handle both IPv4 and IPv6 address strings. 3. Whether to include a description of the Posix 1003.1g getaddrinfo() function, and the order and types of arguments to our own complement of this function, getnameinfo(). Paul Vixie incorporated changes into the BIND-4.9.4T4B release to handle items 1 and 2 above. They are the result of the discussions that many of us had on either the smaller mailing list or on the IPng mailing list in March and April. I've gone through Paul's code and written up the changes as modifications to Section 5 of , which I have attached. Comments? With regard to item 3, I went ahead and wrote up a description of both getaddrinfo() and getnameinfo() that are POSIX-free (Bob Gilligan has these), and have coded both functions (however, I have not yet made the changes required to work with Paul's latest BIND). I won't be in Montreal, but wanted to get this out to people, to try and get the ball rolling to get the API spec finished, and to have something to comment on in Montreal. Rich Stevens ------------------------------------------------------------------------ 5. Library Functions 5.1. Hostname to Address Translation The commonly used function gethostbyname() remains unchanged. Existing applications that call this function continue to receive only IPv4 addresses that are the result of a A query in the DNS. (We assume the DNS is being used; some environments may be using a hosts file or some other name resolution system.) Two new changes are made to support IPv6 addresses. First the following function is new: struct hostent *gethostbyname2( const char *name, int af); The af argument specifies the address family. The default operation of this function is simple: - If the af argument is AF_INET, then a query is made for A records. If successful, IPv4 addresses are returned and the h_length member of the hostent structure will be 4, else the function returns a NULL pointer. - If the af argument is AF_INET6, then a query is made for AAAA records. If successful, IPv6 addresses are returned and the h_length member of the hostent structure will be 16, else the function returns a NULL pointer. The second change, that provides additional functionality, is to set the new resolver option RES_USE_INET6. (This option is provided starting with the BIND 4.9.4 release.) The common way to set and use this option would be res_init(); _res.options |= RES_USE_INET6; and then to call either gethostbyname() or gethostbyname2(). This option then affects only the process that is calling the resolver. If this option is set in the resolver configuration file (normally /etc/resolv.conf) then all applications on the host would be affected by the option (which should not be done until all applications on the host are capable of dealing with IPv6 addresses). When the RES_USE_INET6 option is set, two changes occur: - gethostbyname(host) first calls gethostbyname2(host, AF_INET6) looking for AAAA records, and if this fails it then calls gethostbyname2(host, AF_INET) looking for A records. - gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6 addresses with the h_length member of the hostent structure set to 16. An application must not enable the RES_USE_INET6 option until it is prepared to deal with 16-byte addresses in the returned hostent structure. The following table summarizes the the operation of the existing gethostbyname() function, the new function gethostbyname2(), along with the new resolver option RES_USE_INET6. +------------------+---------------------------------------------------+ | | RES_USE_INET6 option | | +-------------------------+-------------------------+ | | off | on | +------------------+-------------------------+-------------------------+ | |Search for A records. |Search for AAAA records. | | gethostbyname | If found, return IPv4 | If found, return IPv6 | | (host) | addresses (h_length=4). | addresses (h_length=16).| | | Else error. | Else search for A | | | | records. If found, | | | | return IPv4-mapped IPv6 | | | | addresses (h_length=16).| | | | Else error. | +------------------+-------------------------+-------------------------+ | |Search for A records. |Search for A records. | | gethostbyname2 | If found, return IPv4 | If found, return | | (host, AF_INET) | addresses (h_length=4). | IPv4-mapped IPv6 | | | Else error. | addresses (h_length=16).| | | | Else error. | +------------------+-------------------------+-------------------------+ | |Search for AAAA records. |Search for AAAA records. | | gethostbyname2 | If found, return IPv6 | If found, return IPv6 | | (host, AF_INET6) | addresses (h_length=16).| addresses (h_length=16).| | | Else error. | Else error. | +------------------+-------------------------+-------------------------+ It is expected that when a typical naive application that calls gethostbyname() today is modified to use IPv6, it simply changes the program to use IPv6 sockets and then enables the RES_USE_INET6 resolver option before calling gethostbyname(). This application will then work with either IPv4 or IPv6 peers. Note that gethostbyname() and gethostbyname2() are not thread-safe, since both return a pointer to a static hostent structure. But several vendors have defined a thread-safe gethostbyname_r() function that requires four additional arguments. We expect these vendors to also define a gethostbyname2_r() function. 5.2. Address To Hostname Translation The existing gethostbyaddr() function already requires an address family argument and can therefore work with IPv6 addresses: struct hostent *gethostbyaddr( const char *src, int len, int af); One possible source of confusion is the handling of IPv4-mapped IPv6 addresses and IPv4-compatible IPv6 addresses. Current thinking involves the following logic: - If af is AF_INET6, and if len equals 16, and if the IPv6 address is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 address, then skip over the first 12 bytes of the IPv6 address, set af to AF_INET, and set len to 4. - If af is AF_INET, then query for a PTR record in the in-addr.arpa domain. - If af is AF_INET6, then query for a PTR record in the ip6.int domain. - If the function is returning success, and if af equals AF_INET, and if the RES_USE_INET6 option was set, then the single address that is returned in the hostent structure (the first argument to the function) is returned as an IPv4-mapped IPv6 address and the h_length member is set to 16. The same caveats regarding a thread-safe version of gethostbyname() that were made at the end of the previous section apply here as well. 5.3. Protocol-Independent Hostname and Service Name Translation 5.4 Socket Address Structure to Hostname and Service Name Translation int getnameinfo( const struct sockaddr *sa, size_t salen, char *host, size_t hostlen, char *serv, size_t servlen); 5.5. Address Conversion Functions BSD Unix provides two functions, inet_addr() and inet_ntoa(), to convert an IPv4 address between binary and text form. IPv6 applications need similar functions. The following two functions convert both IPv6 and IPv4 addresses: int inet_pton( int af, const char *src, void *dst); and const char *inet_ntop( int af, const void *src, char *dst, size_t size); The inet_pton() function converts an address in its standard text presentation form into its numeric binary form. The af argument specifies the family of the address. Currently AF_INET and AF_INET6 address families are supported. The src argument points to the string being passed in. The dst argument points to a buffer into which the function stores the numeric address. The address is returned in network byte order. Inet_pton() returns 1 if the conversion succeeds, 0 if the input is not a valid IPv4 dotted-decimal string or a valid IPv6 address string, or -1 with errno set to EAFNOSUPPORT if the af argument is unknown. The function does not modify the buffer pointed to by dst if the conversion fails. The calling application must ensure that the buffer referred to by dst is large enough to hold the numeric address. If the af argument is AF_INET, the function accepts a string in the standard IPv4 dotted decimal form: ddd.ddd.ddd.ddd where ddd is a one to three digit decimal number between 0 and 255. If the af argument is AF_INET6, then the function accepts a string in one of the standard IPv6 text forms defined in Section 2.2 of the addressing architecture specification [2]. The inet_ntop() function converts a numeric address into a text string suitable for presentation. The af argument specifies the family of the address. This can be AF_INET or AF_INET6. The src argument points to a buffer holding an IPv4 address if the af argument is AF_INET, or an IPv6 address if the af argument is AF_INET6. The dst argument points to a buffer where the function will store the resulting text string. The size argument specifies the size of this buffer. The application must specify a non-NULL dst argument. For IPv6 addresses, the buffer must be at least 46-octets. For IPv4 addresses, the buffer must be at least 16-octets. In order to allow applications to easily declare buffers of the proper size to store IPv4 and IPv6 addresses in string form, implementations should provide the following constants, made available to applications that include : #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 The inet_ntop() function returns a pointer to the buffer containing the text string if the conversion succeeds, and NULL otherwise. Upon failure, errno is set to EAFNOSUPPORT if the af argument is invalid or ENOSPC if the size of the result buffer is inadequate. The function does not modify the storage pointed to by dst if the conversion fails. Applications obtain the prototype declarations for inet_ntop() and inet_pton() by including the header file . 5.6. Embedded IPv4 Addresses ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jun 20 19:35:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16565; Thu, 20 Jun 96 19:35:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16559; Thu, 20 Jun 96 19:35:04 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA22584; Thu, 20 Jun 1996 19:31:18 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA16521; Thu, 20 Jun 1996 19:31:10 -0700 Received: (qmail-queue invoked from smtpd); 21 Jun 1996 02:29:26 -0000 Received: from kandinsky.free-gate.com (192.168.1.104) by free-gate.com with SMTP; 21 Jun 1996 02:29:25 -0000 Message-Id: <31CA097B.15EF@free-gate.com> Date: Thu, 20 Jun 1996 19:31:23 -0700 From: Bob Gilligan Organization: FreeGate Corporation X-Mailer: Mozilla 2.0 (Win95; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 1891) re: IPv6 BSD API changes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard Stevens wrote: > > (I was going to send this to only the people who attended the ad-hoc > meeting in LA on the BSD API changes but realized there are probably > more interested parties out there, many of whom participated in the > email exchanges on the larger IPng mailing list in March and April.) > > There are a few items still outstanding from all our previous discussions: > > 1. Resolver changes required to handle IPv6 addresses [i.e., gethostbyname() > and gethostbyaddr()]. > > 2. Final definitions of the inet_pton() and inet_ntop() functions, that > will handle both IPv4 and IPv6 address strings. > > 3. Whether to include a description of the Posix 1003.1g getaddrinfo() > function, and the order and types of arguments to our own complement > of this function, getnameinfo(). > FYI, I have a 30-minute agenda slot at the Tuesday morning WG meeting for API spec issues. These three items will be on the list of issues to resolve. People who are interested in the IPv6 API should plan on attending this meeting. If we can resolve all of the API issues then, the document can move forward to informational RFC. 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 Jun 21 09:04:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17461; Fri, 21 Jun 96 09:04:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17446; Fri, 21 Jun 96 09:04:28 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA14150; Fri, 21 Jun 1996 09:00:41 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA06126; Fri, 21 Jun 1996 09:00:41 -0700 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 JAA27386; Fri, 21 Jun 1996 09:00:40 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Jun 1996 09:02:08 -0700 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1892) Agenda Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the updated agenda for next weeks meeting. Bob Hinden / Steve Deering ________________________________________________________________________ IPNG Working Group Agenda Montreal IETF June 24-28, 1996 Monday 1930 - 2200 Introduction - Steve Deering & Bob Hinden 10 min Document Status - Bob Hinden 10 min Status Reports (each 10 min or less) 130 min UNH Testing - Bill Lenharth Header Compression - Micke Degermark IPv6 Tunneling - Alex Conta Interface IDs - Robert Elz UDP & TCP/MSS vs. Jumbograms - Dave Borman Neighbor Discovery - Tom Narten ITU Request for IPv6 Addresses - Bob Hinden IPv6 Auto-Configuration - Sue Thompson DHCPv6 - Jim Bound IPv6 Mobility - Dave Johnson RIPng - Bobby Minnear OSPFng - John Moy IDRPng - Yakov Rekhter IPv6 over FDDI - Matt Crawford IPv6 over NBMA - Grenville Armitage IPv6 over PPP - Dimitry Haskin IPv6 Multicast Routing - Steve Deering Routing Table Size Issue - Ran Atkinson Tuesday 0900 - 1130 Host Anycast - Jim Bound & Pedro Roque 30 min Multihomed Hosts - Mike Shand & Matt Thomas 30 min BSD API Issues - Bob Gilligan 30 min Naming Link-Local Addresses - Dan Harrington 10 min Router Alert Option - Ran Atkinson 10 min Host Handling of Route Header - Steve Deering 10 min Open 30 min Wednesday 0900 - 1130 Spec Changes/Clarifications - Steve Deering 30 min Advancement of main specs to Draft Standard? 10 min Open for Additional Topics and continuation of 100 min earlier topics Conclusion / Interm Meeting Scheduling 10 min ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jun 21 09:04:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17462; Fri, 21 Jun 96 09:04:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17447; Fri, 21 Jun 96 09:04:29 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA14153; Fri, 21 Jun 1996 09:00:42 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA06136; Fri, 21 Jun 1996 09:00:42 -0700 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 JAA27389; Fri, 21 Jun 1996 09:00:41 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Jun 1996 09:02:09 -0700 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1893) Updated IPng Web Pages Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I did another update to the IPng web pages. The URL is: http://playground.sun.com/pub/ipng/html/ipng-main.html Check out new host implementations by Novell, IBM, and Pacific Softworks, and a new router implementation by Digital. 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 Tue Jun 25 12:02:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01977; Tue, 25 Jun 96 12:02:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01971; Tue, 25 Jun 96 12:01:55 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA04798; Tue, 25 Jun 1996 11:58:04 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA23757; Tue, 25 Jun 1996 11:58:03 -0700 Received: from [206.167.192.38] (ietf192-38.ietf.risq.qc.ca [206.167.192.38]) by mailrelay.ipsilon.com (8.6.10/8.6.10) with SMTP id MAA23876; Tue, 25 Jun 1996 12:25:10 -0700 X-Sender: hinden@xtester.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Jun 1996 11:59:35 -0700 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1894) WG last call: Generic Packet Tunneling in IPv6 Specification 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 : Generic Packet Tunneling in IPv6 Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-ipv6-tunnel-02.txt Pages : 38 Date : 06/14/1996 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today, on 7/9/96. Bob Hinden / Steve Deering ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 25 12:03:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01989; Tue, 25 Jun 96 12:03:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01983; Tue, 25 Jun 96 12:02:47 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA04927; Tue, 25 Jun 1996 11:58:56 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA24071; Tue, 25 Jun 1996 11:58:55 -0700 Received: from [206.167.192.38] (ietf192-38.ietf.risq.qc.ca [206.167.192.38]) by mailrelay.ipsilon.com (8.6.10/8.6.10) with SMTP id MAA23879; Tue, 25 Jun 1996 12:25:13 -0700 X-Sender: hinden@xtester.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Jun 1996 11:59:41 -0700 To: sob@harvard.edu, mankin@isi.edu From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1895) Request to Advance "OSI NSAPs and IPv6" Cc: jburgan@BayNetworks.com, scoya@cnri.reston.va.us, ipng@sunroof.eng.sun.com, 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 Experimental status: Title : OSI NSAPs and IPv6 Author(s) : J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd Filename : draft-ietf-ipngwg-nsap-ipv6-01.txt Pages : 19 Date : 05/23/1996 This version of this document reflects changes requested by the IANA after the previous version had been forwarded to the IANA from the IESG. The IPng working group discussed this draft at the Montreal IETF and decided to forward this version of the document to the IESG without an additional working group last call. We also believe that an IETF last call is not required as the document was previous approved by the IESG and was sent to the IANA. Bob Hinden / Steve Deering ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jun 25 12:52:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02072; Tue, 25 Jun 96 12:52:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA02066; Tue, 25 Jun 96 12:52:44 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA12436; Tue, 25 Jun 1996 12:48:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA10343; Tue, 25 Jun 1996 12:48:52 -0700 Received: from localhost (day@localhost) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id PAA27699 for ; Tue, 25 Jun 1996 15:52:41 -0400 (EDT) Message-Id: <199606251952.PAA27699@zafu.bbn.com> X-Authentication-Warning: zafu.bbn.com: Host day@localhost didn't use HELO protocol From: "John Day" Subject: (IPng 1896) [ iheavens@fore.com: TCP and RSTs - new draft ] To: ipng@sunroof.eng.sun.com Date: Tue, 25 Jun 96 15:47:02 EST Mail-System-Version: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Since we were all trying to remember how TCP handled refused connections this morning in the IPng meeting and since the anycast solution uses RSTs, this might be something worth looking at. John -------- Beginning of Forwarded Message(s) --------- Received: from BBN.COM (BBN.COM [128.89.0.122]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id UAA00230; Mon, 24 Jun 1996 20:44:09 -0400 (EDT) Received: from zephyr.isi.edu by BBN.COM id aa19125; 24 Jun 96 20:38 EDT Received: by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 24 Jun 1996 16:31:09 -0700 Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 24 Jun 1996 15:20:26 -0700 Received: from fore.co.uk (zander.fore.co.uk) by venera.isi.edu (5.65c/5.61+local-23) id ; Mon, 24 Jun 1996 15:20:24 -0700 Received: by fore.co.uk (4.1/SMI-4.1) id AA27213; Mon, 24 Jun 96 23:18:27 +0100 Received: from fore.com (mailhub.fore.com) by fore.co.uk (4.1/SMI-4.1) id AA27183; Mon, 24 Jun 96 23:02:08 +0100 Received: from dolphin.fore.com ([192.88.243.27]) by fore.com (8.7.3/8.6.11) with ESMTP id SAA21541; Mon, 24 Jun 1996 18:00:36 -0400 (EDT) Received: from marlin-atm.fore.com (marlin-atm.fore.com [169.144.1.249]) by dolphin.fore.com (8.7.3/3.4W4) with SMTP id SAA29517; Mon, 24 Jun 1996 18:03:37 -0400 (EDT) From: Ian Heavens Received: by marlin-atm.fore.com (4.1/SMI-4.1) id AA13743; Mon, 24 Jun 96 18:03:36 EDT Message-Id: <9606242203.AA13743@marlin-atm.fore.com> Subject: TCP and RSTs - new draft To: end2-end-interest@ISI.EDU Date: Mon, 24 Jun 1996 18:03:36 -0400 (EDT) Cc: iheavens@fore.com (Ian Heavens) X-Mailer: ELM [version 2.4 PL24 ME8b] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-end2end-interest@ISI.EDU Precedence: bulk I have put a new draft, "RSTs Considered Harmful", in draft-heavens-problems-rsts-02.txt. It contains the noncontroversial parts (one hopes so) of my previous lengthy opus on the subject, to the effect that TCP RSTs are not protected by TIME-WAIT mechanisms from segment corruption. Once I have found out how to do this, I would like to publish this as an Informational RFC. Ian Ian Heavens, Fore Systems -------- End of Forwarded Message(s) --------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 26 07:24:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02504; Wed, 26 Jun 96 07:24:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA02498; Wed, 26 Jun 96 07:24:15 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA07352; Wed, 26 Jun 1996 07:20:23 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA26841; Wed, 26 Jun 1996 05:44:30 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id MA18375; Wed, 26 Jun 1996 22:43:59 +1000 (from kre@munnari.OZ.AU) To: "John Day" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1897) Re: [ iheavens@fore.com: TCP and RSTs - new draft ] In-Reply-To: Your message of "Tue, 25 Jun 1996 15:47:02 EST." <199606251952.PAA27699@zafu.bbn.com> Date: Wed, 26 Jun 1996 22:43:59 +1000 Message-Id: <14305.835793039@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As I recall the Heavens draft, RST's at SYN time aren't the problem that was found, just resets when there may be outstanding data in the pipes somewhere. Rejecting a SYN attempt with a RST I believe is still safe. That draft is worth reading, but I doubt is specially relevant to IPv6. 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 Fri Jun 28 16:06:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04282; Fri, 28 Jun 96 16:06:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04276; Fri, 28 Jun 96 16:05:43 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA23556; Fri, 28 Jun 1996 16:01:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA01844; Fri, 28 Jun 1996 16:01:46 -0700 Received: from munin.fnal.gov ("port 2225"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I6G92F019U000EW5@FNAL.FNAL.GOV> for ipng@sunroof.eng.sun.com; Fri, 28 Jun 1996 18:01:43 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id SAA18996; Fri, 28 Jun 1996 18:00:28 -0500 (CDT) Date: Fri, 28 Jun 1996 18:00:19 -0500 From: Matt Crawford Subject: (IPng 1898) API issues regarding flow IDs To: ipng@sunroof.eng.sun.com Message-Id: <199606282300.SAA18996@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{>" = bsd-api-05 "!!" = RFC 1883 >> Applications have control over what values for [prio. and flow label] >> are used in packets that they originate, !! A source must not re-use a flow label for a new flow within the !! lifetime of any flow-handling state that might have been !! established for the prior use of that flow label. These are irreconcilable. If an application can set the flow label, it can re-use a recent or a current label. Also, !! A flow label is assigned to a flow by the flow's source node. New !! flow labels must be chosen (pseudo-)randomly and uniformly from the !! range 1 to FFFFFF hex. probably represents an unwelcome burden on the application, even if the kernel somehow rejected duplicate flow labels. Here's another problem: >> And an application may specify the flow label and priority to use in >> transmitted packets of a passively accepted TCP connection, by >> setting the sin6_flowinfo field of the address passed in the bind() >> function. This means that the sequence bind(); listen(); accept(); accept(); can give you two simultaneous streams to unrelated destinations but using a single flow label. My proposed fix for TCP sockets is as follows: A flow label can be set only by a bind() call, and then any non-zero flow label (alternatively, a special non-zero constant) indicates that the kernel should choose a non-zero value. If the application wants to know what value was chosen, it should be obtained with getsockname(). For UDP it's more difficult, since single a UDP socket can sent packets in many different flows, to one destination address or to many. The application must be able to obtain and use a number of flow labels, but use them only in accordance with the RFC 1883. A little more work is needed in this area. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.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 Jun 28 19:37:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04386; Fri, 28 Jun 96 19:37:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04380; Fri, 28 Jun 96 19:37:41 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA15797; Fri, 28 Jun 1996 19:33:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA05667; Fri, 28 Jun 1996 19:33:44 -0700 Received: (qmail-queue invoked from smtpd); 29 Jun 1996 02:34:30 -0000 Received: from kandinsky.free-gate.com (192.168.1.104) by free-gate.com with SMTP; 29 Jun 1996 02:34:30 -0000 Message-Id: <31D495FE.1467@free-gate.com> Date: Fri, 28 Jun 1996 19:33:34 -0700 From: Bob Gilligan Organization: FreeGate Corporation X-Mailer: Mozilla 2.0 (Win95; I) Mime-Version: 1.0 To: Matt Crawford , ipng@sunroof.eng.sun.com Subject: (IPng 1899) Re: API issues regarding flow IDs References: <199606282300.SAA18996@munin.fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford wrote: > > I have a few issues with flow labels which got squeezed of the end of > the agenda at the IPNG session Wednesday. > > ">>" = bsd-api-05 > "!!" = RFC 1883 > > >> Applications have control over what values for [prio. and flow label] > >> are used in packets that they originate, > > !! A source must not re-use a flow label for a new flow within the > !! lifetime of any flow-handling state that might have been > !! established for the prior use of that flow label. > > These are irreconcilable. If an application can set the flow label, > it can re-use a recent or a current label. Also, But keep in mind that an application may wish to use the same flow label for a number of UDP transaction or TCP connections that are going to the same destination. > !! A flow label is assigned to a flow by the flow's source node. New > !! flow labels must be chosen (pseudo-)randomly and uniformly from the > !! range 1 to FFFFFF hex. > > probably represents an unwelcome burden on the application, even if > the kernel somehow rejected duplicate flow labels. We did not really attempt to solve the problem of selecting a flow label label or enforcing the uniqueness requirements in this version of the API spec, and perhaps we should state that more clearly. The intention was to provide enough functionallity that people can start experimenting with flow labels, but that we would need to develop some new mechanism to allocate and free flow labels once flow labeling moves beyond the experimental state. > Here's another problem: > > >> And an application may specify the flow label and priority to use in > >> transmitted packets of a passively accepted TCP connection, by > >> setting the sin6_flowinfo field of the address passed in the bind() > >> function. > > This means that the sequence bind(); listen(); accept(); accept(); > can give you two simultaneous streams to unrelated destinations but > using a single flow label. I agree this is not the result that most applications need, but there are some that do. Consider an FTP client executing an MGET or MPUT to a server. The client may wish to set up a single flow that is used for all of the data connections. Since all of the connections are between the same pair of hosts, this is perfectly legal, and more efficient than setting up a new flow for each connection. > My proposed fix for TCP sockets is as follows: > > A flow label can be set only by a bind() call, and then any non-zero > flow label (alternatively, a special non-zero constant) indicates > that the kernel should choose a non-zero value. If the application > wants to know what value was chosen, it should be obtained with > getsockname(). If we make *any* non-zero flow label in bind() instruct the kernel to select a unique flow label, then we loose the flexability of allowing applications and libraries select their own flow label. I think this would be a reduction in functionallity. We could define one distinguished value to have this meaning, but I'm not sure we want to tie flow label selection in with the bind() system call. Doing so might unnecessarily tie our hands when we design the flow setup protocol. We may not want the kernel to "own" flow label selection. The RSVP daemon might want to be the module that selects flow labels, for example. > For UDP it's more difficult, since single a UDP socket can sent > packets in many different flows, to one destination address or to > many. The application must be able to obtain and use a number of > flow labels, but use them only in accordance with the RFC 1883. A > little more work is needed in this area. Since the flow setup protocol, and use of flows in general, are not well defined yet, we took the philosophy in the API spec of putting responsibility for adhering to the flow label uniqueness requirements on the shoulders of the application. I think this is adequate for now. Those applications that don't care about flows (all of them today) can simply set the sin6_flowinfo field to zero. Those that do wish to use flows can take the effort to adhere to the uniqueness requirements. 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