From owner-ipng Fri Sep 1 08:47:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21434; Fri, 1 Sep 95 08:47:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21422; Fri, 1 Sep 95 08:47:01 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13148; Fri, 1 Sep 1995 08:35:36 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id IAA10601; Fri, 1 Sep 1995 08:35:33 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12988; 1 Sep 95 10:52 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 626) I-D ACTION:draft-ietf-ipngwg-unicast-addr-fmt-02.txt Date: Fri, 01 Sep 95 10:51:58 -0400 Message-Id: <9509011052.aa12988@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 : An IPv6 Provider-Based Unicast Address Format Author(s) : Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel Filename : draft-ietf-ipngwg-unicast-addr-fmt-02.txt Pages : 9 Date : 08/31/1995 This document defines an IPv6 provider-based unicast address format for use in the Internet. The address format defined in this document is consistent with the "IPv6 Addressing Architecture" [ARCH] and the "An Architecture for IPv6 Unicast Address Allocation" [ALLOC], and is intended to facilitate scalable Internet routing. The unicast address format defined in this document doesn't preclude the use of other unicast address formats. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-unicast-addr-fmt-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicast-addr-fmt-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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-unicast-addr-fmt-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: <19950831101853.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-unicast-addr-fmt-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-unicast-addr-fmt-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950831101853.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 1 08:47:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21435; Fri, 1 Sep 95 08:47:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21428; Fri, 1 Sep 95 08:47:07 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13151; Fri, 1 Sep 1995 08:35:42 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id IAA10611; Fri, 1 Sep 1995 08:35:38 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13009; 1 Sep 95 10:52 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 627) I-D ACTION:draft-ietf-ipngwg-test-addr-alloc-00.txt Date: Fri, 01 Sep 95 10:52:08 -0400 Message-Id: <9509011052.aa13009@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 : IPv6 Testing Address Allocation Author(s) : R. Hinden, J. Postel Filename : draft-ietf-ipngwg-test-addr-alloc-00.txt Pages : 5 Date : 08/31/1995 This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. These addresses are temporary and will be reclaimed in the future. Any IPv6 system using these addresses will have to renumber at some time in the future. These addresses will not to be routable in the Internet other than for IPv6 testing. The addresses described in this document are consistent with the IPv6 Addressing Architecture [ARCH]. They may be assigned to nodes manually, with IPv6 Auto Address Allocation [AUTO], or with DHCP for IPv6 [DHCPv6]. 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-test-addr-alloc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-test-addr-alloc-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-test-addr-alloc-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: <19950831104039.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-test-addr-alloc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-test-addr-alloc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950831104039.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 5 06:40:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22783; Tue, 5 Sep 95 06:40:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22777; Tue, 5 Sep 95 06:40:10 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27042; Tue, 5 Sep 1995 06:28:40 -0700 Received: from concorde.inria.fr by venus.Sun.COM (Sun.COM) id GAA27446; Tue, 5 Sep 1995 06:28:30 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id PAA23726 for ; Tue, 5 Sep 1995 15:23:26 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id PAA08296 for ; Tue, 5 Sep 1995 15:23:23 +0200 Message-Id: <199509051323.PAA08296@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 628) for a preference option in Neighbor Discovery Date: Tue, 05 Sep 1995 15:23:09 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk We need a preference in some cases in Neighbor Discovery: - router advertisement (in order to select a "good" router) - anycast neighbor advertisement (today the first answer is used but responders should randomly delay their answers in order to avoid collisions on shared media) - router advertisement with several global prefixes (in order to be able to recognize the best prefix if timelives are not enough). These preferences are optional then I propose to add a new option for any preference notion on the previous header or option. This option needs to be 8 byte aligned then if the preference field itself is 4 byte unsigned there is a two byte field before. I propose to split preference into a 2 byte priority and a 4 byte metric (inside the priority class). A priority value must be reserved for invalid/worst preference and a default must be specified. Francis.Dupont@inria.fr PS: I belive a preference option is the minimal modification to the current draft (and implementations). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 7 09:09:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24316; Thu, 7 Sep 95 09:09:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24310; Thu, 7 Sep 95 09:08:55 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28962; Thu, 7 Sep 1995 08:57:17 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id IAA08242; Thu, 7 Sep 1995 08:57:05 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1768; Thu, 07 Sep 95 11:56:47 EDT Received: by RTP (XAGENTA 4.0) id 9691; Thu, 7 Sep 1995 11:56:16 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17870; Thu, 7 Sep 1995 11:56:23 -0400 Message-Id: <9509071556.AA17870@cichlid.raleigh.ibm.com> To: Francis Dupont Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 629) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of "Tue, 05 Sep 1995 15:23:09 +0200." <199509051323.PAA08296@givry.inria.fr> Date: Thu, 07 Sep 1995 11:56:02 +22305558 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >We need a preference in some cases in Neighbor Discovery: > - router advertisement (in order to select a "good" router) I think this has been hashed out already. My reading of WG consensus is that while it might be useful, it's not clear that it is necessary, and it's not critical enough to try and put it into ND before pushing for proposed standard. If there is disagreement with this assessment, now would be a good time for folks to speak up. > - anycast neighbor advertisement (today the first answer is >used but responders should randomly delay their answers >in order to avoid collisions on shared media) Hmm. Adding a random delay before responding, might be a good thing to do. However, I don't get the impression that there will be "many" servers/routers on a link configured to recognize the same anycast address. That is: - there is no need to insert random delay if only 2 or 3 nodes ever respond. At present, this is probably a reasonable assumption. However, in the long term, how anycast addresses will be used is less clear. So it might be useful to add a small random component just to be safe. - On the other hand, a node only cares about getting a single NA for an anycast address. If 30 get sent, but half get lost, the client doesn't really care. Thus, the real issue is whether we want to "jam" the net with a bunch of transmissions at the same time. Not clear that this is a significant problem in practice. Remember, most NS/NA messages will be unicast. It's only the first one that is multicast (and then responded to by all servers for that anycast address). Adding a "preference" field to allow a client to better select an anycast address goes beyond what ND intends. That is, in the case of preferences for anycast addresses, the preference is used to select the "best" server based on the server's load, speed, etc. One could achieve the same result by having the servers communicate with each other using higher-level protocols to decide which servers are "best" and then having only those servers respond. > - router advertisement with several global prefixes >(in order to be able to recognize the best prefix >if timelives are not enough). I don't understand the point you want to make here. Please clarify. What does it mean for one prefix to be "better" than another? > This option needs to be 8 byte aligned then if the preference >field itself is 4 byte unsigned there is a two byte field before. >I propose to split preference into a 2 byte priority and a 4 byte >metric (inside the priority class). A priority value must be reserved >for invalid/worst preference and a default must be specified. Could you please clarify? You want a priority for "invalid" preference? Does this mean, for example, that the NS you just received should be ignored because it is invalid? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 7 10:58:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24472; Thu, 7 Sep 95 10:58:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24466; Thu, 7 Sep 95 10:58:40 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15258; Thu, 7 Sep 1995 10:47:02 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id KAA11834; Thu, 7 Sep 1995 10:46:41 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15363; 7 Sep 95 13:25 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 630) I-D ACTION:draft-ietf-ipngwg-token-ring-00.txt Date: Thu, 07 Sep 95 13:24:56 -0400 Message-Id: <9509071325.aa15363@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 : A Method for the Transmission of IPv6 Packets over Token Ring Networks Author(s) : S. Thomas Filename : draft-ietf-ipngwg-token-ring-00.txt Pages : 5 Date : 09/06/1995 This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Token Ring networks [8025]. It also specifies the content of the Source/Target Link-layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on a Token Ring. 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-token-ring-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-token-ring-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-token-ring-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: <19950906135937.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-token-ring-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-token-ring-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950906135937.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 7 11:37:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24546; Thu, 7 Sep 95 11:37:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24540; Thu, 7 Sep 95 11:37:50 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22129; Thu, 7 Sep 1995 11:26:10 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id LAA22207; Thu, 7 Sep 1995 11:25:57 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id UAA10119; Thu, 7 Sep 1995 20:25:47 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id UAA11766; Thu, 7 Sep 1995 20:25:46 +0200 Message-Id: <199509071825.UAA11766@givry.inria.fr> From: Francis Dupont To: "Thomas Narten" Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 631) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of Thu, 07 Sep 1995 11:56:02. <9509071556.AA17870@cichlid.raleigh.ibm.com> Date: Thu, 07 Sep 1995 20:25:43 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: >We need a preference in some cases in Neighbor Discovery: > - router advertisement (in order to select a "good" router) I think this has been hashed out already. My reading of WG consensus is that while it might be useful, it's not clear that it is necessary, and it's not critical enough to try and put it into ND before pushing for proposed standard. If there is disagreement with this assessment, now would be a good time for folks to speak up. => It is not my understanding: if the current draft must be modified before to be pushed (for instance for the "sender" address in NS) then we should talk about router preference now. I really believe redirects are not a reasonable way to select a default router on a LAN! I shout it is a *critical* problem to have *no* preference! My proposal is minimal because my purpose is *not* to slow down the draft on its track... > - anycast neighbor advertisement (today the first answer is >used but responders should randomly delay their answers >in order to avoid collisions on shared media) Hmm. Adding a random delay before responding, might be a good thing to do. However, I don't get the impression that there will be "many" servers/routers on a link configured to recognize the same anycast address. That is: - there is no need to insert random delay if only 2 or 3 nodes ever respond. At present, this is probably a reasonable assumption. However, in the long term, how anycast addresses will be used is less clear. So it might be useful to add a small random component just to be safe. - On the other hand, a node only cares about getting a single NA for an anycast address. If 30 get sent, but half get lost, the client doesn't really care. Thus, the real issue is whether we want to "jam" the net with a bunch of transmissions at the same time. Not clear that this is a significant problem in practice. Remember, most NS/NA messages will be unicast. It's only the first one that is multicast (and then responded to by all servers for that anycast address). => preference is better than a race during a "jam". Adding a "preference" field to allow a client to better select an anycast address goes beyond what ND intends. That is, in the case of preferences for anycast addresses, the preference is used to select the "best" server based on the server's load, speed, etc. One could achieve the same result by having the servers communicate with each other using higher-level protocols to decide which servers are "best" and then having only those servers respond. => the standard way is to delay the answer and to cancel it when a "better" responds. It gives no "jam", no race and less packets without higher-level protocols... KISS! > - router advertisement with several global prefixes >(in order to be able to recognize the best prefix >if timelives are not enough). I don't understand the point you want to make here. Please clarify. What does it mean for one prefix to be "better" than another? => addresses should have a clear order. Today we know that global > site-local > link-local but inside the same class only lifetimes can help. I propose to have an explicit optional preference notion (with a default value) in order to help ordering of addresses which is *necessary* for the source address selection default case (use the "best" address). > This option needs to be 8 byte aligned then if the preference >field itself is 4 byte unsigned there is a two byte field before. >I propose to split preference into a 2 byte priority and a 4 byte >metric (inside the priority class). A priority value must be reserved >for invalid/worst preference and a default must be specified. Could you please clarify? You want a priority for "invalid" preference? Does this mean, for example, that the NS you just received should be ignored because it is invalid? => the good word is "worst" (worse than any not worst), in math -infinity. My idea is not to make things invalid but to point out junk/last-resort things (ie I want three (worst << default << good) or more values. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 8 04:28:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25257; Fri, 8 Sep 95 04:28:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25251; Fri, 8 Sep 95 04:28:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20992; Fri, 8 Sep 1995 04:17:01 -0700 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id EAA13768; Fri, 8 Sep 1995 04:17:01 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA02588; Fri, 8 Sep 1995 04:11:58 -0700 Received: by xirtlu.zk3.dec.com; id AA13949; Fri, 8 Sep 1995 07:11:53 -0400 Message-Id: <9509081111.AA13949@xirtlu.zk3.dec.com> To: Francis Dupont Cc: "Thomas Narten" , ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Subject: (IPng 632) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of "Thu, 07 Sep 95 20:25:43 +0200." <199509071825.UAA11766@givry.inria.fr> Date: Fri, 08 Sep 95 07:11:47 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >=> It is not my understanding: if the current draft must be modified >before to be pushed (for instance for the "sender" address in NS) >then we should talk about router preference now. I really believe >redirects are not a reasonable way to select a default router on a LAN! >I shout it is a *critical* problem to have *no* preference! >My proposal is minimal because my purpose is *not* to slow down >the draft on its track... I think we need router preference too. And my belief is WG consensus is that this should be put in the draft going to proposed standard. So I am confused where Tom came up with that we have the opposite consensus. Francis's proposal is reasonable and redirects are not a reasonable way to select default router. Chairs? I think we need your input here. We seem to disagree on what consensus we have and I raise that as an issue now. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 8 07:32:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25323; Fri, 8 Sep 95 07:32:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25317; Fri, 8 Sep 95 07:32:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02427; Fri, 8 Sep 1995 07:20:32 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id HAA07947; Fri, 8 Sep 1995 07:18:34 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7550; Fri, 08 Sep 95 10:18:18 EDT Received: by RTP (XAGENTA 4.0) id 9954; Fri, 8 Sep 1995 10:17:21 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17817; Fri, 8 Sep 1995 10:17:23 -0400 Message-Id: <9509081417.AA17817@cichlid.raleigh.ibm.com> To: Francis Dupont , bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 633) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of "Thu, 07 Sep 1995 20:25:43 +0200." <199509071825.UAA11766@givry.inria.fr> Date: Fri, 08 Sep 1995 10:17:01 +22305558 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Francis Dupont writes: >=> It is not my understanding: if the current draft must be modified >before to be pushed (for instance for the "sender" address in NS) >then we should talk about router preference now. First, let's be sure we are all talking about the same thing. Based on previous email, I assume you are advocating not a "default router preference", but a "router preference". There is a difference. In the former, the preference is used only in selecting a default router when performing "next-hop determination" as described in the ND draft. Once a router has been selected, the preference has no significance. The main argument against "default router preferences" is that they are an incomplete solution; once a host's cache entries all point to the "wrong" router, they will never switch to a "better" router (unless NUD determines that the bad router has become unreachable). Note that these are the semantics of IPv4 router discovery. The definition for what I'm calling "router preferences" is that a node should use the highest preference router at (more or less) all times. In particular, if you are using a low preference router, but a "better", higher-preference one becomes available, you switch to the better router. This also avoids the drawbacks of the IPv4 semantics. Francis, Jim and others: would you please clearly state which semantics you are calling for? Note also that there are some issues that arise when "router preference" semantics are used. In particular, under what conditions do you switch from using a low preference router to a higher preference one? Things get a little bit murky when redirects come into play. For example, if a node receives a redirect telling it to use router X (which may have a lower or unknown preference), when (if ever) does it purge that route? If the semantics of preferences say you should use the highest preference router, this implies that routes learned from redirects need to purged periodically (every minute or two??) in order to start using a "better" router should it become available. The fundamental problem with "router preferences" is that they are preferences only for the "default" case. If you have several routers on your network, the "best" router for a particular destination may be different from the "best" router for another destination. Thus, a single router metric doesn't provide sufficient information, and a redirect telling you of a better first-hop for a specific destination can conflict with advertised router preferences. It's not immediately clear how a host would resolve such conflicts. When does a node believe the redirect (and for how long) given that other routers appear and disappear continually? The "default router preference" model places the onus of resolving such conflicts squarely on the routers. A host continues to use the same router for a destination until it is redirected to different router. Ultimately, routers are the only ones with sufficient information to know which router is best for a particular destination. Having a "router preference" moves some of that onus to hosts, but they don't have sufficient information to know which router is best for a particular destination. Consequently, they must periodically purge all routes learned via redirects so that the "best" default router can send them a new redirect telling them which router is best for a particular destination. >I really believe redirects are not a reasonable way to select a >default router on a LAN! Could you please elaborate on this point? Are you saying that the default router/redirect mechanism *architecture* is fundamentally broken, or are you saying that too many routers are brain dead and don't do redirects correctly, so we need to put more smarts on hosts to make up for deficiencient router implementations? > > - anycast neighbor advertisement (today the first answer is > >used but responders should randomly delay their answers > >in order to avoid collisions on shared media) > Hmm. Adding a random delay before responding, might be a good thing to > do. However, I don't get the impression that there will be "many" > servers/routers on a link configured to recognize the same anycast > address. That is: > - there is no need to insert random delay if only 2 or 3 nodes > ever respond. At present, this is probably a reasonable assumption. > However, in the long term, how anycast addresses will be used is > less clear. So it might be useful to add a small random component > just to be safe. > - On the other hand, a node only cares about getting a single NA for > an anycast address. If 30 get sent, but half get lost, the client > doesn't really care. Thus, the real issue is whether we want to "jam" > the net with a bunch of transmissions at the same time. Not clear > that this is a significant problem in practice. Remember, most NS/NA > messages will be unicast. It's only the first one that is multicast > (and then responded to by all servers for that anycast address). >=> preference is better than a race during a "jam". Note that you are assuming that anycast addresses will be used for *individiual* *services* rather than generic node addresses. Having a metric saying use this *server* rather than another *server* implies that all servers agree to the ranking. This will only be true (in general) if the servers provide equivalent functionality. If an anycast address is used to identify a set of diverse servers, ranking them becomes more difficult. For example, consider an anycast address that identifies all the routers on a subnet. If you are looking for a router as part of doing source routing through "clouds", you might have one way of ranking routers. If you were instead looking for routers for (say) mobility agents (or something else???) the rankings might well be different. [This isn't a particularly realistic example, but given our limited understanding of how anycast addresses will be used, it's useful for making a point.] What I'm getting at is that for the case of anycast addresses, preferences would be used for resource location, a separate problem that needs to be solved for the more general case (e.g., find the "best" DNS or HTTP server I should be using). I'm a little uncomfortable trying to deal with this issue in ND. I don't think ND is the right place. > > - router advertisement with several global prefixes > >(in order to be able to recognize the best prefix > >if timelives are not enough). >=> addresses should have a clear order. Today we know that >global > site-local > link-local but inside the same class >only lifetimes can help. I propose to have an explicit optional >preference notion (with a default value) in order to help >ordering of addresses which is *necessary* for the source address >selection default case (use the "best" address). ND explicitely does not deal with source address selection. IMO, we don't (yet) fully understand the problem of source address selection making it premature to put a simplistic metric into ND to indicate preferences. As an example, if one has multiple addresses for each of the providers a site connects to, the right address to use on outgoing packets depends on (possibly complex) policy considerations that ND probably doesn't (and can't) know about (e.g., all of user XYZ's packets should go via provider foo). Putting preferences in ND won't help here. > > This option needs to be 8 byte aligned then if the preference > >field itself is 4 byte unsigned there is a two byte field before. > >I propose to split preference into a 2 byte priority and a 4 byte > >metric (inside the priority class). A priority value must be reserved > >for invalid/worst preference and a default must be specified. > Could you please clarify? You want a priority for "invalid" > preference? Does this mean, for example, that the NS you just received > should be ignored because it is invalid? >=> the good word is "worst" (worse than any not worst), in math -infinity. >My idea is not to make things invalid but to point out junk/last-resort >things (ie I want three (worst << default << good) or more values. I still don't follow you. My reading is that you want to have a two-level metric. The first level indicates a class of some sort ("worst", "good", "better"), while the metric provides further ranking within a class. How is this different than a flat metric space where (say) the "worst" metric are all less than 100, the good ones are between 100 and 200, etc.? Jim Bound writes: >I think we need router preference too. And my belief is WG consensus is >that this should be put in the draft going to proposed standard. So I >am confused where Tom came up with that we have the opposite consensus. >Francis's proposal is reasonable and redirects are not a reasonable way >to select default router. Ironically, I believed you were not in favor of metrics. Going back and rereading a message of yours from July 27, your stated position was more ambiguous. In any case, it would be nice to hear from others, even it all we get is a "I agree/disagree with X". Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 8 09:28:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25393; Fri, 8 Sep 95 09:28:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25387; Fri, 8 Sep 95 09:28:50 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15466; Fri, 8 Sep 1995 09:15:23 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id JAA02141; Fri, 8 Sep 1995 09:13:32 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id SAA02071; Fri, 8 Sep 1995 18:13:26 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id SAA14258; Fri, 8 Sep 1995 18:13:25 +0200 Message-Id: <199509081613.SAA14258@givry.inria.fr> From: Francis Dupont To: "Thomas Narten" Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng 634) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of Fri, 08 Sep 1995 10:17:01. <9509081417.AA17817@cichlid.raleigh.ibm.com> Date: Fri, 08 Sep 1995 18:13:02 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: Francis, Jim and others: would you please clearly state which semantics you are calling for? => I am advocating (and implementing) your "router preference". I believe the semantics of IPv4 router discovery is not good and must be fixed in IPv6. I always use the link-local router anycast address (fe80::) as the default router and the Router Advertisement receiver sets the Ethernet address of fe80:: to the Ethernet address of the "best" router. This changes all the routes cloned from the default route, ie every indirect routes except manual and from redirect routes (exactly what you name "router preference")! <> => It is clear for me than routes created by redirect must be cleared with a timeout of the same order than ND (some minutes). This has nothing to do with "router preference" but perhaps we need a good way to give a lifetime to redirects (ie do we need a lifetime field/option for redirects ?). The fundamental problem with "router preferences" is that they are preferences only for the "default" case. => the fundamental problem without preference is any router can be the default router without control. In general we have a small set of routers connected to the Internet and we'd like to pick one of them as the default router (using "router preferences" for instance). If you have several routers on your network, the "best" router for a particular destination may be different from the "best" router for another destination. => If you have some small networks with dedicated gateways then redirects give shortest paths (it is the way I believe (router) redirects should be used). You have opened a second can of worms: should redirects be sent for prefixes (ie do we need a prefix length field/option for redirects ?). Thus, a single router metric doesn't provide sufficient information, and a redirect telling you of a better first-hop for a specific destination can conflict with advertised router preferences. It's not immediately clear how a host would resolve such conflicts. => clearly a redirect overrules the default route (because it has a longer prefix destination (128 > 0) for instance). I don't see the problem. >I really believe redirects are not a reasonable way to select a >default router on a LAN! Could you please elaborate on this point? Are you saying that the default router/redirect mechanism *architecture* is fundamentally broken, => yes, I am saying the default router/redirect mechanism *architecture* is fundamentally broken if you have no way to control the choice of the default router! Preferences give a simple way to choice a good router when you have good and bad routers, "router preferences" gives the best default router. No preference at all gives any router, in some cases it doesn't matter, in some cases (I believe they are very common) it can lead to a redirect for nearly every non-local destinations. or are you saying that too many routers are brain dead and don't do redirects correctly, so we need to put more smarts on hosts to make up for deficient router implementations? => I believe it is already the case (with IPv4), I'd like to get a good mechanism in IPv6 without IPv4 known draw backs and without the need for host configurations in common cases. Preferences are the simple way to do that and their management can be restricted to routers. <> => the current proposal is not reasonable for CSMA/CD LAN. In the case of the link-local router anycast address (fe80::) I believe the NS/NA behavior should be the parallel of RS/RA then I propose the same kind of (partial) solution: optional preference. ND explicitly does not deal with source address selection. => ND is the base of Address Autoconfiguration then has a real effect on source address selection. Not dealing with the problem doesn't solve it... IMO, we don't (yet) fully understand the problem of source address selection making it premature to put a simplistic metric into ND to indicate preferences. As an example, if one has multiple addresses for each of the providers a site connects to, the right address to use on outgoing packets depends on (possibly complex) policy considerations that ND probably doesn't (and can't) know about (e.g., all of user XYZ's packets should go via provider foo). Putting preferences in ND won't help here. => I don't believe that preference (simplistic metric) can solve all the problems but it can help for some of them and it is cheap and simple... I still don't follow you. My reading is that you want to have a two-level metric. => we have 6 bytes in the packet, I propose to use a two-level metric with 2+4 bytes. It is not important but I can't see a better usage for all these bytes. Regards Francis.Dupont@inria.fr PS: I have implemented the complete host part (*) of Neighbor Discovery and I am testing it (unfortunately I have no real router nor the ND router part). I have already got some results when I've written the code: - we need to have a better way to recognize our packets during the "Duplicate Address Detection". - nothing really clever can be done if this fails (this can become a real problem with IPv6 only mono-homed hosts) - IPv4-compatible IPv6 (auto) config and routing can be made completely independent of IPv6 native stuff. - LAN interface will have several addresses which must be clearly ordered, the "best" one and a/the link-local one have special usages. - the "router preference" scheme is easier to implement than "default router preference" (because it splits the two important things in the default route: the link-layer address of the default router (ie where to send packets) and the interface address of the default route (aka default source address)). - site-local and global addresses should not be mixed on the same node at the same time (I can't see no problem with this restriction). - multihomed hosts are a real nightmare (not new :-)! ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 8 11:24:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25492; Fri, 8 Sep 95 11:24:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25486; Fri, 8 Sep 95 11:23:55 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04064; Fri, 8 Sep 1995 11:12:06 -0700 Received: from coral.bucknell.edu by mercury.Sun.COM (Sun.COM) id LAA00745; Fri, 8 Sep 1995 11:11:43 -0700 Received: from droms.bucknell.edu by coral.bucknell.edu; (5.65v3.0/1.1.8.2/29Aug94-0956AM) id AA00995; Fri, 8 Sep 1995 14:10:36 -0400 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Sep 1995 14:10:46 -0400 To: host-conf@sol.eg.bucknell.edu, addrconf@cisco.com, ipng@sunroof.Eng.Sun.COM, ipv6imp@munnari.oz.au From: droms@bucknell.edu (Ralph Droms) Subject: (IPng 635) New mailing list for discussion of DHCPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In a conversation with Jim Bound this morning, we thought it might be a good idea to provide a separate mailing list for the discussion of DHCPv6. Noting the lack of participation in discussion of DHCPv6 on the host-conf mailing list, it seemed to us that we might encourage discussion on the part of the IPv6 community by separating DHCPv4 from DHCPv6. So, I've set up a new list called dhcp-v6@bucknell.edu for discussion of the DHCPv6 protocol spec. Note that this list will *not* be gatewayed to the host-conf list; the primary raison d'etre for the new list is to separate mail about DHCPv4 from mail about DHCPv6. Please direct subscription requests to listserv@bucknell.edu. - Ralph ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 8 12:57:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25633; Fri, 8 Sep 95 12:57:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25627; Fri, 8 Sep 95 12:57:34 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18042; Fri, 8 Sep 1995 12:45:57 -0700 Received: from itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id MAA22868; Fri, 8 Sep 1995 12:45:46 -0700 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14269; Fri, 8 Sep 95 15:45:40 EDT Date: Fri, 8 Sep 95 15:45:40 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9509081945.AA14269@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 636) ND Router Preference Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk We at NRL are (and have been) agreeing with Francis Dupont and Jim Bound that Router Preferences need to be in the ND draft before that draft goes to Proposed Standard. Its sometimes hard to measure consensus, but count us as being in favour of preferences. The point about redirects NOT being a really good alternative for preferences is well taken. Also, IPv4 Router Discovery is A Very Good thing operationally. I do NOT want to lose any capabilities that it has. Ran rja@cs.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 8 14:11:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25726; Fri, 8 Sep 95 14:11:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25720; Fri, 8 Sep 95 14:10:52 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27962; Fri, 8 Sep 1995 13:59:05 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id NAA09683; Fri, 8 Sep 1995 13:58:46 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA18212; Fri, 8 Sep 1995 16:58:39 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA32096; Fri, 8 Sep 1995 16:58:38 -0400 Message-Id: <9509082058.AA32096@wasted.zk3.dec.com> To: "Thomas Narten" Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 637) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of "Fri, 08 Sep 95 10:17:01." <9509081417.AA17817@cichlid.raleigh.ibm.com> Date: Fri, 08 Sep 95 16:58:37 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >Ironically, I believed you were not in favor of metrics. Going back >and rereading a message of yours from July 27, your stated position >was more ambiguous. In any case, it would be nice to hear from >others, even it all we get is a "I agree/disagree with X". My position on router preference fields has been clear since Bill Simpson invented them for ND. I can't help we switch authors and now I have to re-explain why I want something but I will. I was ambiguous on metrics in general because I am unclear what they are at this time. I still am. I was willing to let this go for Proposed Std. But once Francis presented his case I changed my mind. Which last time I looked I am allowed to do in the IETF, so as you seem to wanted to inform all I changed my mind I took up space in this mail to tell all why. [Thank You Francis I almost let something go I did not want to]. Blame Tom not me he asked. I believe we need router preferences (not just default router preferences), because its more efficient. On redirects you bring up a very real issue. I suggest that after a redirect the router preference becomes NULL (or void whatever). In this manner the preferences in fact will move towards a default router preference unless the router preferences in fact are updated. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 8 14:52:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25821; Fri, 8 Sep 95 14:52:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25815; Fri, 8 Sep 95 14:52:04 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04569; Fri, 8 Sep 1995 14:40:28 -0700 Received: from CU.NIH.GOV by mercury.Sun.COM (Sun.COM) id OAA19887; Fri, 8 Sep 1995 14:40:20 -0700 Message-Id: <199509082140.OAA19887@mercury.Sun.COM> To: ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Fri, 08 Sep 1995 17:38:28 EDT Subject: (IPng 638) Re: for a preference option in Neighbor Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > >I really believe redirects are not a reasonable way to select a > >default router on a LAN! > > Could you please elaborate on this point? Are you saying that the > default router/redirect mechanism *architecture* is fundamentally > broken, I don't know if they are "broken", but redirects as currently implemented leave a lot to be desired as a way to select the best router for a particular destination. Most routers will only send a redirect if a packet is sent back out the same interface it arrived on. But in many cases the path from the router to the destination will be out some other interface. Often you don't want to run a routing protocol on a LAN that has user hosts on it. If you don't, that guarantees no redirects. If you do, the LAN could end up being used for transit, which might not be desirable. The point to remember is that routers don't generally know that the best path is through some other router. They have a routing table that tells them what the best route to a destination is from that router, not from a host on a LAN connected to the router. The two may be different. With a link state routing protocol, the router theoretically has enough knowledge to determine that the packet should have been sent to another router, but it can't afford to use up cycles making that check on every packet. With a distance vector routing protocol, the router doesn't even theoretically have the information it needs. So the heuristic is to send a redirect when a packet goes out the same interface it came in on. That the router does know. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 8 15:46:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25933; Fri, 8 Sep 95 15:46:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25927; Fri, 8 Sep 95 15:46:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12448; Fri, 8 Sep 1995 15:34:31 -0700 Received: from bridge2.NSD.3Com.COM by mercury.Sun.COM (Sun.COM) id PAA00874; Fri, 8 Sep 1995 15:34:30 -0700 Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA28693 (5.65c/IDA-1.4.4nsd for ); Fri, 8 Sep 1995 15:33:52 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA23480 (5.65c/IDA-1.4.4-910730); Fri, 8 Sep 1995 15:30:02 -0700 Message-Id: <199509082230.AA23480@remmel.NSD.3Com.COM> To: Francis Dupont , bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, tracym@NSD.3Com.COM Subject: (IPng 639) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of "Fri, 08 Sep 1995 10:17:01." <9509081417.AA17817@cichlid.raleigh.ibm.com> Date: Fri, 08 Sep 1995 15:30:02 -0700 From: Tracy Mallory Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk [Disclaimer: I've been lurking, and since my day job involves code other than IPv6 I've probably missed something. (I'm reading more like 2/3 of these messages, a relatively high percentage. However...)] My memory of at least one explanation for why router preferences weren't included is that they don't solve the problem of multiple exit points for different kinds of traffic, destinations, etc. With router preferences you only get to choose a single best router for all your traffic. In large (multi-homed, or perhaps just multi-backboned) organizations it is likely that there are really two or three (or more) "best" routers, based on the destination or (someday) the type of traffic. Even in my building, the best router needs to be chosen based on whether I'm headed for a corporate Notes database server, or the test lab debug station down the hall, or out to the latest hot Web site. Given that the issue above is real, perhaps the 6 bytes potentially available for specifying the preference value could be used to address this issue. (or perhaps a few (8?) more bytes should be considered). 1. I'd prefer to see the number of preference values very small. Three might be too few(might not;-), but no more than an octet should be plenty. 2. A type field (1 octet) specifying the kind of preference, leaving room for extensions: [We're heading toward blue sky ;-] basic (what the list seems to be discussing: a single simple metric) prefix (new suggestion: supply prefix info to allow multiple best routers) 3. Parms(4 octets?), with some form of prefix specification which would either select, or eliminate a router from consideration. Lot's of fun with this one: some flag bits(or use the type field), a mask specification (how many bits, starting where), same value. 3b. Get another 8 octets for the preference field and do the prefix thing right. Back to earth: Bone up on KISS theory and try to do the SIMPLEST thing that enables multiple, sensible, route preferences. Regards, Tracy ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 8 17:41:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26013; Fri, 8 Sep 95 17:41:55 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26007; Fri, 8 Sep 95 17:41:46 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id RAA06502; Fri, 8 Sep 1995 17:30:10 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id RAA11818; Fri, 8 Sep 1995 17:29:42 -0700 Date: Fri, 8 Sep 1995 17:29:42 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199509090029.RAA11818@bobo.Eng.Sun.COM> To: Francis.Dupont@inria.fr Subject: (IPng 640) Re: for a preference option in Neighbor Discovery 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 > => It is not my understanding: if the current draft must be modified > before to be pushed (for instance for the "sender" address in NS) > then we should talk about router preference now. I really believe > redirects are not a reasonable way to select a default router on a LAN! > I shout it is a *critical* problem to have *no* preference! > My proposal is minimal because my purpose is *not* to slow down > the draft on its track... We are still missing a detailed specification of the host processing asociated with your proposed preference field in router advertisements. You've only outlined the packet/option format which is not sufficient for me to understand your proposal. Could you please help me understand your proposal by answering the following questions (the questions are stated using the conceptual model and terminology in the ND specification): 1. When a host has no destination cache entry (i.e. it is doing next-hop determination) and it needs to use a default router which default router should it use? I assume you are proposing to select the highest preference router. Just want to make sure. 2. As in #1 (default router selection algorithm): when multiple default routers have the same preference which one should the host choose? Random?, round-robin?, ... 3. When comparing the preference field how do you use the 2 byte priority and the 4 byte metric? Do you first compare the priority and only look at the metric if the priorities are equal? (i.e. the metric is only used as a tie-breaker) 4. What are the processing rules when a router advertisement is received and it has a higher preference they any other router in the hosts default router list? 4a. Do you change all the destination cache entries that use other default routers to start using the router with the highest preference? 4b. Do you change destination cache entries that have been updated by Redirects to use a different router? 5. Same questions as #4 by when the preference is identical to the currently highest preference in the default router list. Are any destination cache entries effected? 6. What are the processing rules when receiving a router advertisement from a router that is currently recorded in the default router list and the preference in the RA is different then the recorded preference? The preference might have either increased or decreased. An increase might make this router into the highest preference router. A decrease might make another router be the highest preference router. 6a. In which, if any, of the above cases do you change existing destination cache entries to use another router? 6b. In which, if any, of the above cases do you change a destination cache entry that has beed created/modified by a redirect to use a particular router? > Adding a "preference" field to allow a client to better select an > anycast address goes beyond what ND intends. That is, in the case of > preferences for anycast addresses, the preference is used to select > the "best" server based on the server's load, speed, etc. One could > achieve the same result by having the servers communicate with each > other using higher-level protocols to decide which servers are "best" > and then having only those servers respond. > > => the standard way is to delay the answer and to cancel it when > a "better" responds. It gives no "jam", no race and less packets > without higher-level protocols... KISS! The algorithm that cancels delayed answers when a "better" one responds (for example. IGMP reports) assume that all packets are multicast. Are you advocating that all Neighbor Advertisements should be multicast or unicast? Or are you proposing that this should only apply to anycast advertisements? Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 8 18:33:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26070; Fri, 8 Sep 95 18:33:20 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26064; Fri, 8 Sep 95 18:33:10 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id SAA10948; Fri, 8 Sep 1995 18:21:34 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id SAA11839; Fri, 8 Sep 1995 18:21:08 -0700 Date: Fri, 8 Sep 1995 18:21:08 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199509090121.SAA11839@bobo.Eng.Sun.COM> To: Francis.Dupont@inria.fr Subject: (IPng 641) Re: for a preference option in Neighbor Discovery 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 > => It is clear for me than routes created by redirect must be > cleared with a timeout of the same order than ND (some minutes). > This has nothing to do with "router preference" but perhaps > we need a good way to give a lifetime to redirects > (ie do we need a lifetime field/option for redirects ?). The protocol as specified in draft-ietf-ipngwg-discovery-01.txt does not require any lifetimes for information learned from redirect messages. The current first-hop router will send a redirect if a different first-hop router becomes a better choice for a particular destination. And the neighbor unreachability detection mechanism will detect when the router that the host was redirected to has gone dead and reselect a default router. What problem are you proposing to solve by adding a lifetime to redirects? > => yes, I am saying the default router/redirect mechanism > *architecture* is fundamentally broken if you have no way > to control the choice of the default router! Preferences > give a simple way to choice a good router when you have > good and bad routers, "router preferences" gives the best > default router. No preference at all gives any router, > in some cases it doesn't matter, in some cases (I believe > they are very common) it can lead to a redirect for nearly > every non-local destinations. But depending on how you specify the details in your "router preference" proposal you might end up with periodic storms of redirects. If you are proposing that when a new higher-preference router becomes available all destination cache entries should be updated to use the new router then all hosts will send all packets to the new router and many of them are likely to get redirected back to the router they were already using. Once you present the details of your proposal (see my questions in a previous mail) we can discuss this further. Why isn't it sufficient to have a "default router preference"? It seems to work well in IPv4 router discovery. Having a "router preference" is likely IMHO to cause complex interactions with redirects. > => I believe it is already the case (with IPv4), I'd like to get > a good mechanism in IPv6 without IPv4 known draw backs and > without the need for host configurations in common cases. > Preferences are the simple way to do that and their > management can be restricted to routers. Do you have specific examples of where and why the ICMP router discovery doesn't work well? What are the "IPv4 known draw backs" that you are alluding to? > ND explicitly does not deal with source address selection. > > => ND is the base of Address Autoconfiguration then has a real > effect on source address selection. Not dealing with the problem > doesn't solve it... I agree with you that we (the IETF) needs to address source-address selection as well as outgoing interface selection (on multihomed hosts). However, that does not mean that all these pieces have to be specified in the ND document. Quite contrary, in order to make progress it is critical that we partition the work into independent components and solve a piece at a time. I'm sure the ADs will entertain a request to work on source addres selection either in the ipngwg working group or in some other working group. > => I don't believe that preference (simplistic metric) can solve > all the problems but it can help for some of them and it is > cheap and simple... Just because the packet/option format is simple doesn't mean that the protocol mechanisms are simple. Didn't we recently go through this with the system-heard extension which looked very simple initially but nobody could quite understand the details of how it works? I'm patiently awaiting your detailed proposal for "router preferences". Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 8 18:41:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26087; Fri, 8 Sep 95 18:41:37 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26081; Fri, 8 Sep 95 18:41:28 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id SAA11078; Fri, 8 Sep 1995 18:29:52 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id SAA11843; Fri, 8 Sep 1995 18:29:25 -0700 Date: Fri, 8 Sep 1995 18:29:25 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199509090129.SAA11843@bobo.Eng.Sun.COM> To: atkinson@itd.nrl.navy.mil Subject: (IPng 642) Re: ND Router Preference Cc: ipng@sunroof2.Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Also, IPv4 Router Discovery is A Very Good thing operationally. > I do NOT want to lose any capabilities that it has. Note that (using Thomas terminology from (IPng 633)) what IPv4 has in "default router preference" and what Francis is proposing is "router preference" which are very different beasts. The "router preference" has some form of implied redirect semantics (I don't understand the details since Francis hasn't specified them). We understand "default router preference". IMHO we do not understand the implications of "router preference" and, in particular, how it interacts with redirects. Do you want "default router preference" like in RFC 1256 or do you want Francis' "router preference"? Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 9 04:47:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26307; Sat, 9 Sep 95 04:47:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26301; Sat, 9 Sep 95 04:47:46 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17263; Sat, 9 Sep 1995 04:36:10 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id EAA23009; Sat, 9 Sep 1995 04:36:04 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id NAA07903; Sat, 9 Sep 1995 13:36:02 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id NAA15312; Sat, 9 Sep 1995 13:36:00 +0200 Message-Id: <199509091136.NAA15312@givry.inria.fr> From: Francis Dupont To: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 643) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of Fri, 08 Sep 1995 17:29:42 PDT. <199509090029.RAA11818@bobo.Eng.Sun.COM> Date: Sat, 09 Sep 1995 13:35:56 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: > => It is not my understanding: if the current draft must be modified > before to be pushed (for instance for the "sender" address in NS) > then we should talk about router preference now. I really believe > redirects are not a reasonable way to select a default router on a LAN! > I shout it is a *critical* problem to have *no* preference! > My proposal is minimal because my purpose is *not* to slow down > the draft on its track... We are still missing a detailed specification of the host processing associated with your proposed preference field in router advertisements. You've only outlined the packet/option format which is not sufficient for me to understand your proposal. => router advertisements are received by a daemon (user process) which manages: - a notion of the "best" interface (useful only for multihomed, you can forget it) - a list of valid (ie with non expired lifetime > 0) routers per interface ordered by preference. Exactly: * a new router is inserted in the list after the last router with a strictly better preference. * when a router advertisement is received for a known router, its parameters are updated and its preference is compared to the preference of the first (ie best) router. If it is better (ie the preference has grown) then the router is placed at the head of the list (must be fixed, see after). * the kernel can send a message to the daemon if a router state changes: if NUD detects an unreachable router, is_router becomes zero in a NA or a router solicitation is received then the router is made invalid (ie discarded, I need to refine this). The (intented) behavior is: - the best router has always the best preference (ie there is no routers with a strictly better preference). - if several routers have the best preference the "first known" becomes the best one (it is a matter of choice, other strategies can be implemented, for instance use the "last heard" (one character change in the code :-). I have no opinion about the best "selection strategy" nor the draft at the bottom of page 34). Could you please help me understand your proposal by answering the following questions (the questions are stated using the conceptual model and terminology in the ND specification): 1. When a host has no destination cache entry (i.e. it is doing next-hop determination) and it needs to use a default router which default router should it use? => there is only one default router: the best router on the best interface. It is always a valid one. 2. As in #1 (default router selection algorithm): when multiple default routers have the same preference which one should the host choose? Random?, round-robin?, ... => the "first known" but I can implement other strategies (round-robin, "last heard", ...). Perhaps stability and simplicity are the good criterions. More powerful strategies, for instance with a feedback from redirect frequency, seem to be far more difficult to implement and be overkilling ? 3. When comparing the preference field how do you use the 2 byte priority and the 4 byte metric? Do you first compare the priority and only look at the metric if the priorities are equal? (i.e. the metric is only used as a tie-breaker) => yes, it is the idea of a two-level preference. 4. What are the processing rules when a router advertisement is received and it has a higher preference they any other router in the hosts default router list? => if its preference is strictly higher than any other then it becomes the default router (strictly can be remove if an other selection strategy is used). 4a. Do you change all the destination cache entries that use other default routers to start using the router with the highest preference? => yes. 4b. Do you change destination cache entries that have been updated by Redirects to use a different router? => no. 5. Same questions as #4 by when the preference is identical to the currently highest preference in the default router list. Are any destination cache entries effected? => with the current selection strategy no destination cache entries are affected. With an other strategy the best router can change and the answers will be 5a==yes, 5b==no (only the default route and routes cloned from it with the same next-hop will change, no manual routes or routes from redirects will be affected). 6. What are the processing rules when receiving a router advertisement from a router that is currently recorded in the default router list and the preference in the RA is different then the recorded preference? The preference might have either increased or decreased. An increase might make this router into the highest preference router. A decrease might make another router be the highest preference router. => good point, I have forgotten the case where the best router preference have decreased. I'll change for a *stable* sorting of the router list when the best router (ie the head of the list) is involved. (I already do this for the prefix list, I know I need it for the router list but I could not see why :-). 6a. In which, if any, of the above cases do you change existing destination cache entries to use another router? => if the default router changes then existing destination cache entries using the default router will change the default router link-layer address (it is different than what you have described but the effect is the same). 6b. In which, if any, of the above cases do you change a destination cache entry that has beed created/modified by a redirect to use a particular router? => the gateway of a route created/modified by a redirect can be changed only by a manual action or another redirect, *never* by the default router stuff. The kernel timeouts routes from a redirect and the daemon deletes them when it knows the used router has became invalid or unreachable (optimization). The algorithm that cancels delayed answers when a "better" one responds (for example. IGMP reports) assume that all packets are multicast. Are you advocating that all Neighbor Advertisements should be multicast or unicast? Or are you proposing that this should only apply to anycast advertisements? => My proposal should only apply to anycast advertisements (unsolicited or in response to an multicast solicitation) of course. Regards Francis.Dupont@inria.fr PS: here is a short summary (you should know how 4.4BSD routing works, a good reference is TCP/IP Illustrated Volume 2 (whole code with comments)): - the route structure (named rtentry) have five interesting fields: * destination (rt_key) * gateway (rt_gateway) which contents the gateway address for indirect routes and the link-layer address (if any) for direct routes * interface (rt_ifp) * interface address (rt_ifa), one of the addresses of the interface, used by source address selection * route for the gateway (rt_gwroute), used only for indirect routes (rt_gwroute points to the direct route for the gateway). - with the draft words, Destination Cache is the routing table, on-link and off-link destinations give exactly direct and indirect routes. Neighbor Cache is the set of direct routes for interfaces supporting ND. For off-link destinations (== indirect routes) the next-hop neighbor is the rt_gateway pointer and the indirection into the Neighbor Cache is the rt_gwroute pointer. - the daemon (almost finished, not tested) receives Router Advertisements and Redirects, manages: * "Router Discovery" and default router selection * "Prefix Discovery" (ie on-link status of a prefix) * "Parameter Discovery" (not yet but easy to do) * "Address Autoconfiguration" for global or site-local addresses (need to be interfaced with a DHCPv6 client library for stateful mode). * "Redirect" for router redirects (ie change in the used router, not in the link-layer address, Redirect Target != Redirect Destination). ("Address Autoconfiguration" of link-local addresses and their "Duplicate Address Detection" are done at boot time, "Address Resolution", "Next-Hop Determination" (aka routing), "Neighbor Unreachability Detection" and "Redirect" for link-layer addresses are done by the kernel. - the default router address (ie the gateway of the default route) is the link-local router anycast address (fe80::). It is the central idea, the whole thing comes from this. - the daemon sets/changes the link-layer address of fe80:: and sets/changes the interface address associated with the default route. Then default route has: * ::/0 in the destination field * fe80:: in the gateway field. * interface & interface address set by the daemon (to the best interface and its best address), it gives the "default source address" (ie the source address used when none is explicitly given (bound) and there is no better route than the default route for the destination, the kernel initializes it to the link-local address of the interface which it is *not* what we want :-). * rt_gwroute field pointing to the direct route for destination fe80:: with link-layer address (in the gateway field) set by the daemon. - when an Ethernet/FDDI/... interface has to send a packet only the link-layer address of the next-hop is needed (not its IPv6 address when you have reach this stage). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 9 06:29:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26352; Sat, 9 Sep 95 06:29:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26346; Sat, 9 Sep 95 06:29:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20142; Sat, 9 Sep 1995 06:17:32 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id GAA27149; Sat, 9 Sep 1995 06:17:26 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id PAA08169; Sat, 9 Sep 1995 15:17:23 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id PAA15441; Sat, 9 Sep 1995 15:17:22 +0200 Message-Id: <199509091317.PAA15441@givry.inria.fr> From: Francis Dupont To: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Cc: atkinson@itd.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM Subject: (IPng 644) Re: ND Router Preference In-Reply-To: Your message of Fri, 08 Sep 1995 18:29:25 PDT. <199509090129.SAA11843@bobo.Eng.Sun.COM> Date: Sat, 09 Sep 1995 15:16:54 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: Note that (using Thomas terminology from (IPng 633)) what IPv4 has in "default router preference" and what Francis is proposing is "router preference" which are very different beasts. => in fact we have two different questions: - do we need a preference field/option for router discovery ? - do we use "default router preference" or "router preference" ? Short summary of the debate: from EN to all: preferences are not needed because with "default router preference" semantics it doesn't give what you'd like. from FD to EN: the "default router preference" semantics is not the best one, "router preference" is possible with IPv6 (PS: because IPv6 router advertisements include a link-layer address). Arguments are bound but the questions are different and only the first one has immediate effect on the draft (then needs a fast consensus). The "router preference" has some form of implied redirect semantics. => I agree, it is a kind of redirect on routers: redirect can be classified by their object: - host redirects (today IPv6, IPv4 host redirects): Only packets to a particular destination are redirected == only a (indirect) route for an host is created/modified. - prefix redirects (IPv4 network redirects): Only packets to a destination in a particular prefix are redirected == only a (indirect) router for a prefix is created/modified. It is more powerful but impact on routes for more defined prefixes (including host routes) is not clear. Note if the prefix is the default (::/0) this problem is exactly the "default router preference"/"router preference" debate! - router redirects (generalized "router preference"): Only packets with this particular next-hop are redirected == the next-hop dependent fields of the routes using this particular router are modified. It is easy to do if there is an indirection between these routes and the shared values which must be modified. We understand "default router preference". IMHO we do not understand the implications of "router preference" and, in particular, how it interacts with redirects. => there is no more interaction between redirects (as proposed today for IPv6) and "router preference" than between redirects and "default router preference". The "router preference" introduction just shows that the current proposal for IPv6 redirects is the less powerful and the more conservative one (perhaps you have guessed I don't like redirects: I shall not object :-). Do you want "default router preference" like in RFC 1256 or do you want Francis' "router preference"? => the debate is a bit more complicated, we have four possibilities: - "default router preference" with only one possible preference (ie current draft proposal) - "default router preference" with preference (ie IPv4 Router Discovery) - "router preference" with only one possible preference (no advocate :-) - "router preference" with preference (my proposal) and two questions (see above). Regards Francis.Dupont@inria.fr PS: HSRP (Hot Standby Router Protocol), the last backup router by Cisco works (tries to work :-) at the Ethernet level and gives the same kind of behavior than "router preference" then we can experience this kind of scheme. (HSRP adds to a set of IPv4 Cisco routers a "shadow" IPv4 router (with a new address) with a "shadow" Ethernet address and select the best router in the set. If you sends a packet to the "shadow" router (using a default route for instance) then the best router will answer to the ARP request and forward IPv4 packets. PPS: today I know only three cases for exit points (exit: from your network to the Internet or corporate backbone or the huge network where all the good things are): - no exit point (ie not connected network): there is no need for default routing or it can be scaled down into one of the two other cases. - one exit point served by one router or one router with a small set of backup routers (more than 90% of the connected networks ?): we want preference in order to select the exit router or one of its backups (if one of them is always available then "default router preference" and "router preference" differences have no operational important impact) - two or more exit points with three subcases: * almost all the nodes are routers running a good routing protocol: no problem, the routing protocol should do everything! * you can add an interconnection network and fall into the previous case (for the network with the hosts) and the previous subcase (for the interconnection network with the routers): you are saved! * last subcase: nothing can help you (switch to ATM :-) ? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 9 07:03:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26377; Sat, 9 Sep 95 07:03:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26371; Sat, 9 Sep 95 07:03:01 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20768; Sat, 9 Sep 1995 06:51:25 -0700 Received: from bodhi.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id GAA28310; Sat, 9 Sep 1995 06:51:25 -0700 From: Ran Atkinson Message-Id: <9509090949.ZM3029@bodhi> Date: Sat, 9 Sep 1995 09:48:59 -0400 In-Reply-To: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) "Re: (IPng 636) ND Router Preference" (Sep 8, 18:29) References: <199509090129.SAA11843@bobo.Eng.Sun.COM> Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: Erik Nordmark , atkinson@itd.nrl.navy.mil Subject: (IPng 645) Re: ND Router Preference Cc: ipng@sunroof2.Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk We agree with Francis (unless I'm confused lately about what Francis is asking for; it is always possible that I'm confused :-). Ran ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 9 07:48:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26410; Sat, 9 Sep 95 07:48:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26404; Sat, 9 Sep 95 07:47:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21583; Sat, 9 Sep 1995 07:36:18 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id HAA29810; Sat, 9 Sep 1995 07:36:16 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id QAA08544; Sat, 9 Sep 1995 16:36:14 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id QAA15546; Sat, 9 Sep 1995 16:36:13 +0200 Message-Id: <199509091436.QAA15546@givry.inria.fr> From: Francis Dupont To: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 646) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of Fri, 08 Sep 1995 18:21:08 PDT. <199509090121.SAA11839@bobo.Eng.Sun.COM> Date: Sat, 09 Sep 1995 16:36:06 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: > => It is clear for me than routes created by redirect must be > cleared with a timeout of the same order than ND (some minutes). > This has nothing to do with "router preference" but perhaps > we need a good way to give a lifetime to redirects > (ie do we need a lifetime field/option for redirects ?). The protocol as specified in draft-ietf-ipngwg-discovery-01.txt does not require any lifetimes for information learned from redirect messages. The current first-hop router will send a redirect if a different first-hop router becomes a better choice for a particular destination. And the neighbor unreachability detection mechanism will detect when the router that the host was redirected to has gone dead and reselect a default router. => NUD is triggered only when there is some traffic then you can have a lot of unused routes from redirect and Neighbor Cache entries. In my implementation both they have finite lifetimes, I should use the same value... The draft doesn't specify a lifetime of Neighbor Cache entries nor for routes from redirect which it is coherent. Question closed! Why isn't it sufficient to have a "default router preference"? It seems to work well in IPv4 router discovery. => I have two answers: first the thing I *want* is preferences in the RFC. IPv4 router discovery is not perfect but it works and we need something at least as powerful as it is (the draft has less than IPv4 router discovery because preferences have been removed). Having a "router preference" is likely IMHO to cause complex interactions with redirects. => I can't see the problem (other than a clear misunderstanding between us). > => I believe it is already the case (with IPv4), I'd like to get > a good mechanism in IPv6 without IPv4 known draw backs and > without the need for host configurations in common cases. > Preferences are the simple way to do that and their > management can be restricted to routers. Do you have specific examples of where and why the ICMP router discovery doesn't work well? What are the "IPv4 known draw backs" that you are alluding to? => Easy, I've tried every protocols for router discovery and the bests are IDRP and HSRP. IDRP is fine, clearly it is the good way but HSRP has sown some drawbacks of IDRP: - it works only for the default route(r) - you can keep a router when a better one is available (cf your argument against preference). Our main network has one exit point with a dedicated router. We have a spare router, when it is not used for experiments we put it as the backup of the exit router (best place!). We need the spare router for a long time at an other place (common fate of spare devices :-), the config is simpler, easier to manage with only one router then we stop the dedicated router, cleanup its config. No problem because the backup router is still up but some hosts will switch to it during this "critical phase". We restart the dedicated router, stop the backup: dring, a phone call for a network problem: someone was stuck with the backup router on a route cloned from the default route during the "critical phase". You have described the problem: "default router preference" doesn't guarantee that the best router is used. In this case HSRP is transparent then more powerful than IRDP, ie there is a place for improvement in IRDP: I propose to replace "default router preference" by "router preference". > => I don't believe that preference (simplistic metric) can solve > all the problems but it can help for some of them and it is > cheap and simple... Just because the packet/option format is simple doesn't mean that the protocol mechanisms are simple. Didn't we recently go through this with the system-heard extension which looked very simple initially but nobody could quite understand the details of how it works? => We agree. I'm patiently awaiting your detailed proposal for "router preferences". => I propose to study a preference option with two immediate usages: - Router Advertisements - Anycast Neighbor Advertisements (because of the link-local router anycast address). Another detail, I believe preferences can clarify the invalid router issue because invalid (0 or expired lifetime) means only "not suitable as a default router". We can take the same things than in RFC 1256, keep a list of all the routers and use it in order to optimize redirect management (for instance reject a redirect with a junk router). Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 10 12:14:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26670; Sun, 10 Sep 95 12:14:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26664; Sun, 10 Sep 95 12:14:38 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01336; Sun, 10 Sep 1995 12:03:01 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id MAA10744; Sun, 10 Sep 1995 12:03:00 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA13207; Sun, 10 Sep 1995 15:02:57 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA24672; Sun, 10 Sep 1995 15:02:55 -0400 Message-Id: <9509101902.AA24672@wasted.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: (IPng 647) DHCPv6 and Importance Date: Sun, 10 Sep 95 15:02:55 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk IPng WG, Ralph Droms has created a new list for DHCPv6 (dhcp-v6@bucknell.edu). I really hope folks on DHCPv4 will join that list as we enhance DHCPv6. A new draft will be forth coming in the next few weeks. I want to spend the time getting all the input I have received into that draft so we can have a solid foundation to discuss at the Dallas IETF meeting. The objective is to move to Proposed Standard after the Dallas IETF meeting. We will have at least two implementations prototyped for proof of concept too (though not normally required). Hopefully three. IPv6 I believe must begin to be deployed by 1998. Initial deployment IMHO cannot depend on the IPv6 routing structure to be in place at that time. Initial deployment will require DHCPv6 as networks integrate IPv6 into the initial IPv4 network toplogy, and absorb the new paradigms born out of the IETF work on IPv6 (e.g. DNSIND, Addr Conf, Neighbor Discovery). In addition its critical that we determine the "functions" in DHCPv6 we must carry forward from DHCPv4. For example it appears that Service Location can replace the need to locate services with DHCP. Is that OK? These and other questions must be discussed as part of DHCPv6. We are also free to develop new models that do not have to be backwards compatible with DHCPv4 (or bootp). We have a base spec now and we need a solid one by the time we walk away from the Dallas IETF meeting. Your involvment and expertise is needed. To join: send mail to listserve@bucknell.edu in the text somewhere enter: subscribe dhcp-v6 your-email-addr thanks for your support, /jim ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 10 12:19:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26691; Sun, 10 Sep 95 12:19:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26685; Sun, 10 Sep 95 12:19:10 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01473; Sun, 10 Sep 1995 12:07:33 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id MAA11086; Sun, 10 Sep 1995 12:07:33 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA13347; Sun, 10 Sep 1995 15:07:31 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA24531; Sun, 10 Sep 1995 15:07:29 -0400 Message-Id: <9509101907.AA24531@wasted.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 648) Re: DHCPv6 and Importance In-Reply-To: Your message of "Sun, 10 Sep 95 15:02:55 EDT." <9509101902.AA24672@wasted.zk3.dec.com> Date: Sun, 10 Sep 95 15:07:29 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >Ralph Droms has created a new list for DHCPv6 (dhcp-v6@bucknell.edu). I >really hope folks on DHCPv4 will join that list as we enhance DHCPv6. A new Should have said "folks on IPng" above. thanks, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 11 06:52:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27021; Mon, 11 Sep 95 06:52:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27015; Mon, 11 Sep 95 06:52:34 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06018; Mon, 11 Sep 1995 06:40:55 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id GAA20815; Mon, 11 Sep 1995 06:40:55 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7974; Mon, 11 Sep 95 09:40:37 EDT Received: by RTP (XAGENTA 4.0) id 0395; Mon, 11 Sep 1995 09:40:08 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17600; Mon, 11 Sep 1995 09:40:25 -0400 Message-Id: <9509111340.AA17600@cichlid.raleigh.ibm.com> To: Francis Dupont Cc: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark), ipng@sunroof.Eng.Sun.COM Subject: (IPng 649) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of "Sat, 09 Sep 1995 13:35:56 +0200." <199509091136.NAA15312@givry.inria.fr> Date: Mon, 11 Sep 1995 09:40:22 +22305558 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Francis, Your explanations have been helpful. Here are some additional questions. 1) Your implementation appears to have one default router at all times. In particular, if you have (say) three equal priority routers, a host is unable to split the traffic among the three; all traffic must go through one of them. While the current ND draft clearly allows this, it is also not a requirement, nor should it be. How would you split traffic over multiple (equal precedence) routers? 2) I'm a bit unclear as to how you handle the case of all default routers becoming unreachable via NUD. Suppose you have two routers (with different precedences), but both become unreachable. Later, one of the routers (take your pick as to which one) becomes reachable again, but does not send out a new RA (e.g., the router was up the entire time -- a bridge failure was the cause of the outage). What does your implementation do in this case? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 11 10:03:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27193; Mon, 11 Sep 95 10:03:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27187; Mon, 11 Sep 95 10:03:20 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26475; Mon, 11 Sep 1995 09:51:40 -0700 Received: from concorde.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA25688; Mon, 11 Sep 95 09:51:35 PDT Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id SAA05411; Mon, 11 Sep 1995 18:35:56 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id SAA17255; Mon, 11 Sep 1995 18:35:56 +0200 Message-Id: <199509111635.SAA17255@givry.inria.fr> From: Francis Dupont To: "Thomas Narten" Cc: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark), ipng@sunroof.Eng.Sun.COM Subject: (IPng 650) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of Mon, 11 Sep 1995 09:40:22. <9509111340.AA17600@cichlid.raleigh.ibm.com> Date: Mon, 11 Sep 1995 18:34:17 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: Your explanations have been helpful. Here are some additional questions. 1) Your implementation appears to have one default router at all times. In particular, if you have (say) three equal priority routers, a host is unable to split the traffic among the three; all traffic must go through one of them. While the current ND draft clearly allows this, it is also not a requirement, nor should it be. How would you split traffic over multiple (equal precedence) routers? => current 4.4BSD supports only one route for a destination then it is not possible to have several default routes then several default routers: traffic splitting cannot be done by the obvious way. It is possible to change from time to time the default router if there are several default routers with the same preference but I believe it is not a good idea (cf stability criterion). At the network level if you have several possible default routers with the same preference then hosts will take different routers and the traffic will be randomly split, it seems a better way. For instance we can implement a load feedback: a load indicator is put in the metric and hosts can change for a better router with a probability depending on the metric advantage... It makes host implementations for complicated for an optimization without clear advantage. Traffic splitting has been tried by Cisco, even with equivalent links it can give strange results. I believe stability is a better criterion. I believe it is very important to be able to try other routers with the same preference only when all the candidate routers have suspect reachability (then with the same "unreachable" preference"). 2) I'm a bit unclear as to how you handle the case of all default routers becoming unreachable via NUD. Suppose you have two routers (with different precedences), but both become unreachable. Later, one of the routers (take your pick as to which one) becomes reachable again, but does not send out a new RA (e.g., the router was up the entire time -- a bridge failure was the cause of the outage). What does your implementation do in this case? => I have not yet fully implement unreachable case (I work on it) but there is only one difficult case: all default routers are unreachable and all their link-layer addresses are unknown (I'd like to avoid address resolution with anycast). If a bridge failure makes all the routers unreachable then they will get an "unreachable" preference value and will be tried in a round-robin fashion (the next one will be tried when NUD fails). It gives the same kind of behavior than "default router preference". When routers will become reachable again preferences will apply when they will send new RAs (PS: RA makes a router "reachable"). It seems reasonable and close to the draft ? Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 11 10:26:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27259; Mon, 11 Sep 95 10:26:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27253; Mon, 11 Sep 95 10:25:58 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01001; Mon, 11 Sep 1995 10:14:13 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id KAA08951; Mon, 11 Sep 1995 10:13:02 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2788; Mon, 11 Sep 95 13:10:31 EDT Received: by RTP (XAGENTA 4.0) id 0449; Mon, 11 Sep 1995 13:09:00 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18672; Mon, 11 Sep 1995 13:08:58 -0400 Message-Id: <9509111708.AA18672@cichlid.raleigh.ibm.com> To: Francis Dupont Cc: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark), ipng@sunroof.Eng.Sun.COM Subject: (IPng 651) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of "Mon, 11 Sep 1995 18:34:17 +0200." <199509111635.SAA17255@givry.inria.fr> Date: Mon, 11 Sep 1995 13:08:44 +22305558 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Francis Dupont writes: > 1) Your implementation appears to have one default router at all > times. In particular, if you have (say) three equal priority routers, > a host is unable to split the traffic among the three; all traffic > must go through one of them. While the current ND draft clearly > allows this, it is also not a requirement, nor should it be. How would > you split traffic over multiple (equal precedence) routers? >=> current 4.4BSD supports only one route for a destination then >it is not possible to have several default routes then several >default routers: traffic splitting cannot be done by the obvious >way. > It is possible to change from time to time the default >router if there are several default routers with the same preference >but I believe it is not a good idea (cf stability criterion). I agree that splitting traffic for the same destination among multiple routers is not such a good idea. That is not what I'm proposing. What I meant to ask was whether your implementation allows routes for destinations X, Y & Z to go via router R1, while routes for destination to A, B & C go via R2, where R1 & R2 are routers on the default list with the same preference. I believe that there are configurations where this sort of traffic splitting is desirable. What I'm hearing is that your implementation (or indeed any implementation that uses an anycast address for the default router) cannot support this (e.g, there is only one default router, and everyone always uses the same default router, unless they have been explicitly redirected elsewhere). Indeed, without adding some additional rules concerning default router selection, I could see your scheme leading to situations where you have 3 "good" routers (each having the same preference), but all traffic from all nodes is going through one router, with the other two getting nothing. This would not be a good thing. > I believe it is very important to be able to try other routers >with the same preference only when all the candidate routers >have suspect reachability (then with the same "unreachable" preference"). The current spec is not (and shouldn't be) this restrictive. We want implementors to play with load-balancing traffic through multiple routers so that we gain more experience. > 2) I'm a bit unclear as to how you handle the case of all default > routers becoming unreachable via NUD. Suppose you have two routers > (with different precedences), but both become unreachable. Later, one > of the routers (take your pick as to which one) becomes reachable > again, but does not send out a new RA (e.g., the router was up the > entire time -- a bridge failure was the cause of the outage). What > does your implementation do in this case? >=> I have not yet fully implement unreachable case (I work on it) >but there is only one difficult case: all default routers are >unreachable and all their link-layer addresses are unknown A related problem that also needs to be dealt with occurs when any of your higher-priority routers becomes reachable after having been unreachable. By definition, you should be using it. But you have to explicitly probe it to see if its reachable, even if you aren't using it at the moment (e.g., all traffic is going through a lower precedence router just fine). Remember, it may be 30 minutes between RAs, so just waiting for the next RA isn't sufficient. Handling this sort of complicating case was one of the motivations for removing the precedence field in the first place. >(I'd like to avoid address resolution with anycast). In the context of ND, performing address resolution on the anycast address to locate a functioning router would be incorrect. The set of routers willing to act as defaults may not be the same as the set of routers configured to recognize the all-routers anycast address. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 11 12:21:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27487; Mon, 11 Sep 95 12:21:06 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27481; Mon, 11 Sep 95 12:20:57 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id MAA24905; Mon, 11 Sep 1995 12:09:18 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id MAA13474; Mon, 11 Sep 1995 12:08:50 -0700 Date: Mon, 11 Sep 1995 12:08:50 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199509111908.MAA13474@bobo.Eng.Sun.COM> To: Francis.Dupont@inria.fr Subject: (IPng 652) Re: for a preference option in Neighbor Discovery 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 > When routers will become reachable again preferences will apply > when they will send new RAs (PS: RA makes a router "reachable"). > It seems reasonable and close to the draft ? Just to clarify. Receiving a RA does not mean that the router is reachable. Neighbor Discovery has to be able to detect assymetric reachability such as a router that can transmit packets but not receive them. Thus, in order for a router to be considered reachable the host has to get some confirmation that the forward path (host->router) is working. This can be done using transport layer advise or explicit probing using NS/NA. See section 6.3.1 in the draft. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 11 13:17:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27589; Mon, 11 Sep 95 13:17:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27420; Mon, 11 Sep 95 11:33:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15827; Mon, 11 Sep 1995 11:22:14 -0700 Received: from gateway.fedex.com by mercury.Sun.COM (Sun.COM) id LAA07859; Mon, 11 Sep 1995 11:20:57 -0700 Received: by gateway.fedex.com id AA17035 (InterLock SMTP Gateway 3.0 for ipng@sunroof.eng.sun.com); Mon, 11 Sep 1995 13:18:33 -0500 Message-Id: <199509111818.AA17035@gateway.fedex.com> Received: by gateway.fedex.com (Internal Mail Agent-1); Mon, 11 Sep 1995 13:18:33 -0500 Date: Mon, 11 Sep 1995 13:15:36 -0500 (CDT) From: Keith Johnson To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 653) draft-ietf-ipngwg-unicast-addr-fmt-02.txt comments Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Section 3.2 ----------- Should the APNIC regional registry value be 00100 instead of 10100 in keeping with the binary increments from the left side of the field? Section 3.3 ----------- Provider ID should NOT be allowed to grow to the right side of the field into the first 8 bit RES field since the last paragraph of 3.2 mentions that more than one regional registry ID value could be assigned to a given regional registry. What do you think? Section 4.0 ----------- Has there been any discussion on what a good value for n is with respect to the number of bits allocated to the National-Registry ID? Keith Johnson / FedEx / keith.johnson@fedex.com / (901) 375-6609 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 11 13:57:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27671; Mon, 11 Sep 95 13:57:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27665; Mon, 11 Sep 95 13:56:53 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07924; Mon, 11 Sep 1995 13:45:12 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id NAA14042; Mon, 11 Sep 1995 13:45:05 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id NAA22132; Mon, 11 Sep 1995 13:44:36 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Sep 1995 13:47:40 -0700 To: ipng@sunroof.Eng.Sun.COM From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 654) IPng Web Pages Update Soon Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Folks, I am doing an update to the IPng web pages. I am especially interested in new implementations. Also, on the implementations page, I am starting to include small gif files of the logo's of organizations doing IPv6 implementations. If you have a gif you would like to see there, please send it to me so I can include it. Thanks, Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 12 04:29:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28311; Tue, 12 Sep 95 04:29:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28305; Tue, 12 Sep 95 04:28:51 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18651; Tue, 12 Sep 1995 04:17:12 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id EAA06637; Tue, 12 Sep 1995 04:17:05 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id NAA29341; Tue, 12 Sep 1995 13:17:02 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id NAA18579; Tue, 12 Sep 1995 13:17:02 +0200 Message-Id: <199509121117.NAA18579@givry.inria.fr> From: Francis Dupont To: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 655) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of Mon, 11 Sep 1995 12:08:50 PDT. <199509111908.MAA13474@bobo.Eng.Sun.COM> Date: Tue, 12 Sep 1995 13:16:54 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: > When routers will become reachable again preferences will apply > when they will send new RAs (PS: RA makes a router "reachable"). > It seems reasonable and close to the draft ? Just to clarify. => I have quoted "reachable" in order to avoid this remark... Receiving a RA does not mean that the router is reachable. Neighbor Discovery has to be able to detect assymetric reachability such as a router that can transmit packets but not receive them. => I agree. What I meant is receiving a RA should put the router in the PROBE state (which is better than INCOMPLETE, this triggers NUD too). Thus, in order for a router to be considered reachable the host has to get some confirmation that the forward path (host->router) is working. This can be done using transport layer advise or explicit probing using NS/NA. See section 6.3.1 in the draft. => I agree, only NUD can put the router in the REACHABLE state. The reachable/unreachable words are not as clear as the NUD states but from the router discovery point of view only transitions from or to the INCOMPLETE state (done by NUD of course) are important. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 12 05:14:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28341; Tue, 12 Sep 95 05:14:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28335; Tue, 12 Sep 95 05:14:07 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20236; Tue, 12 Sep 1995 05:02:23 -0700 Received: from concorde.inria.fr by venus.Sun.COM (Sun.COM) id FAA29806; Tue, 12 Sep 1995 05:01:19 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id NAA00907; Tue, 12 Sep 1995 13:59:09 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id NAA18673; Tue, 12 Sep 1995 13:59:09 +0200 Message-Id: <199509121159.NAA18673@givry.inria.fr> From: Francis Dupont To: "Thomas Narten" Cc: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark), ipng@sunroof.Eng.Sun.COM Subject: (IPng 656) Re: for a preference option in Neighbor Discovery In-Reply-To: Your message of Mon, 11 Sep 1995 13:08:44. <9509111708.AA18672@cichlid.raleigh.ibm.com> Date: Tue, 12 Sep 1995 13:54:06 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: What I meant to ask was whether your implementation allows routes for destinations X, Y & Z to go via router R1, while routes for destination to A, B & C go via R2, where R1 & R2 are routers on the default list with the same preference. I believe that there are configurations where this sort of traffic splitting is desirable. What I'm hearing is that your implementation (or indeed any implementation that uses an anycast address for the default router) cannot support this (e.g, there is only one default router, and everyone always uses the same default router, unless they have been explicitly redirected elsewhere). => I agree. It is the way IPv4 router discovery goes on today too (because in general the default route is directly used and not cloned for each individual destination). Indeed, without adding some additional rules concerning default router selection, I could see your scheme leading to situations where you have 3 "good" routers (each having the same preference), but all traffic from all nodes is going through one router, with the other two getting nothing. This would not be a good thing. => without exceptional circumstances you couldn't see *all* the nodes selecting the same router. Do you say that the selection strategy should be randomized in order to avoid this ? The current spec is not (and shouldn't be) this restrictive. We want implementors to play with load-balancing traffic through multiple routers so that we gain more experience. => my implementation permits load-balancing traffic but not at the node level. There are three levels of load-balancing: - destination (packets from the same node for the same destination can follow different paths, clearly not what we want) - intra-node (packets from the same node can follow different paths) - inter-node (packets from different nodes can follow different paths) Is inter-node load-balancing not enough ? A related problem that also needs to be dealt with occurs when any of your higher-priority routers becomes reachable after having been unreachable. By definition, you should be using it. But you have to explicitly probe it to see if its reachable, even if you aren't using it at the moment (e.g., all traffic is going through a lower precedence router just fine). Remember, it may be 30 minutes between RAs, so just waiting for the next RA isn't sufficient. => I agree, it is one of the things I am looking for. My implementation sends UDP packets to the discard service of unreachable routers in order to poll them. Handling this sort of complicating case was one of the motivations for removing the precedence field in the first place. => the precedence field is in IPv4 router discovery. I still don't understand why you remove it whereas IPv4 router discovery is commonly considered as satisfactory (ie I understand you'd like more powerful protocol, not a less powerful one). >(I'd like to avoid address resolution with anycast). In the context of ND, performing address resolution on the anycast address to locate a functioning router would be incorrect. The set of routers willing to act as defaults may not be the same as the set of routers configured to recognize the all-routers anycast address. => I agree, address resolution of the anycast address should be avoid! Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 14 10:25:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29796; Thu, 14 Sep 95 10:25:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA29790; Thu, 14 Sep 95 10:25:30 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13715; Thu, 14 Sep 1995 10:13:46 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id KAA15693; Thu, 14 Sep 1995 10:13:43 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id KAA09944; Thu, 14 Sep 1995 10:13:15 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Sep 1995 10:16:23 -0700 To: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 657) IPng and AddrConf Interm Meeting Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk There will be an joint IPng and Addr Conf working group meeting on October 11 & 12 in the Washington, DC area. Main agenda topic will be to finalize the neighbor discovery and auto-configuration specifications. There are a number of other issues such as IPv6 over ethernet/token-ring/etc., path MTU discovery, IGMP, etc. that can be worked on. As soon as the final arrangements are completed with the local host I will announce the specific location, hotel, and directions info. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 15 06:33:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00394; Fri, 15 Sep 95 06:33:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00388; Fri, 15 Sep 95 06:32:50 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25342; Fri, 15 Sep 1995 06:21:06 -0700 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id GAA21639; Fri, 15 Sep 1995 06:21:05 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA08735; Fri, 15 Sep 1995 06:11:00 -0700 Received: by xirtlu.zk3.dec.com; id AA21981; Fri, 15 Sep 1995 09:10:45 -0400 Message-Id: <9509151310.AA21981@xirtlu.zk3.dec.com> To: hinden@ipsilon.com (Bob Hinden) Cc: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com, bound@zk3.dec.com Subject: (IPng 658) Re: IPng and AddrConf Interm Meeting In-Reply-To: Your message of "Thu, 14 Sep 95 10:16:23 PDT." Date: Fri, 15 Sep 95 09:10:39 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk It would be **really** good if we as WG members had a new addrconf and nd spec by Wed 9/20. Is that possible: Sue, Erik, and Tom? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 15 08:53:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00467; Fri, 15 Sep 95 08:53:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00461; Fri, 15 Sep 95 08:53:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05314; Fri, 15 Sep 1995 08:41:23 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id IAA17926; Fri, 15 Sep 1995 08:41:19 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA06034; Fri, 15 Sep 1995 11:41:01 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA03662; Fri, 15 Sep 1995 11:40:52 -0400 Message-Id: <9509151540.AA03662@wasted.zk3.dec.com> To: hinden@ipsilon.com (Bob Hinden) Cc: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com Subject: (IPng 659) Re: IPng and AddrConf Interm Meeting In-Reply-To: Your message of "Thu, 14 Sep 95 10:16:23 PDT." Date: Fri, 15 Sep 95 11:40:52 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Bob, I am thinking now that we have a lot of serious input for ND. I am concerned we will not have a quorum in October representative at this meeting for ND. If we don't what comes out of it should not reflect any consensus. For sure we need Francis Dupont, Matt Thomas, Bill Medlin, Dan McDonald, Peter Sojin, and any other implementors who are in that part of the ND code. I fear that these engineers and others have justified travel to the IETF with their source of funding and not for such an interim meeting? Most of the above mentioned folks will actually be testing the latest ND code at Interop, and this will tell us a lot too, probably more than a meeting will. How about a discussion after Interop too via mail? I don't recall that there would be an interim meeting stated at Stockholm for addr )nconf or ND? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 15 09:20:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00485; Fri, 15 Sep 95 09:20:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00479; Fri, 15 Sep 95 09:20:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB07946; Fri, 15 Sep 1995 09:08:42 -0700 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id JAA24047; Fri, 15 Sep 1995 09:08:42 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id MAA13639; Fri, 15 Sep 1995 12:05:34 -0400 (EDT) Date: Fri, 15 Sep 1995 12:05:34 -0400 (EDT) From: Scott Bradner Message-Id: <199509151605.MAA13639@newdev.harvard.edu> To: bound@zk3.dec.com, hinden@ipsilon.com Subject: (IPng 660) Re: IPng and AddrConf Interm Meeting Cc: addrconf@cisco.com, ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Jim, > I am thinking now that we have a lot of serious input for ND. can you give some examples please thanks Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 15 09:39:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00529; Fri, 15 Sep 95 09:39:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00523; Fri, 15 Sep 95 09:39:19 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09962; Fri, 15 Sep 1995 09:27:33 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id JAA28558; Fri, 15 Sep 1995 09:27:32 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id JAA28580; Fri, 15 Sep 1995 09:24:20 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Sep 1995 09:27:27 -0700 To: bound@zk3.dec.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 661) Re: IPng and AddrConf Interm Meeting Cc: hinden@Ipsilon.COM (Bob Hinden), ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Jim, Not sure I see the problem. Interop is two weeks prior to the meeting. There should be plenty of time to discuss issues encountered at Interop on the mailing list and at the meeting. The purpose of the meeting is to resolve open issues with ND. Having the meeting shortly after Interop while the issues are fresh in the implementors minds seems like just the right thing to me. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 15 10:37:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00663; Fri, 15 Sep 95 10:37:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00657; Fri, 15 Sep 95 10:37:45 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17910; Fri, 15 Sep 1995 10:25:58 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id KAA13356; Fri, 15 Sep 1995 10:25:58 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14905(6)>; Fri, 15 Sep 1995 10:25:50 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Fri, 15 Sep 1995 10:25:35 -0700 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng 662) WG Last Call: Address Formats & Experimental Allocation Date: Fri, 15 Sep 1995 10:25:23 PDT From: Steve Deering Message-Id: <95Sep15.102535pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk This is the IPNG Working Group Last Call for comments on advancing the following two documents to RFC status: An IPv6 Provider-Based Unicast Address Format Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, and J. Postel draft-ietf-ipngwg-unicast-addr-fmt-02.txt proposed RFC status: Informational IPv6 Testing Address Allocation R. Hinden and J. Postel draft-ietf-ipngwg-test-addr-alloc-00.txt proposed RFC status: Experimental Recall that the unicast address format document was discussed in the Danvers meeting, and the concensus of that meeting was to publish it as an Informational RFC after revisions to the format to leave more room for future growth. The -02 version of that document incorporates those revisions. As part of the Last Call comments, the chairs would like to determine if there is still rough consensus that Informational is the right status for the address format document. Possible alternatives are Proposed Standard or the new Best Current Practices (BCP). This Last Call period will last two weeks, until September 29. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 15 10:49:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00685; Fri, 15 Sep 95 10:49:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00673; Fri, 15 Sep 95 10:49:42 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20246; Fri, 15 Sep 1995 10:37:27 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id KAA16730; Fri, 15 Sep 1995 10:36:40 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14976(3)>; Fri, 15 Sep 1995 10:36:22 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Fri, 15 Sep 1995 10:36:06 -0700 To: Keith Johnson Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 663) Re: draft-ietf-ipngwg-unicast-addr-fmt-02.txt comments In-Reply-To: kajohnso's message of Mon, 11 Sep 95 11:15:36 -0800. <199509111818.AA17035@gateway.fedex.com> Date: Fri, 15 Sep 1995 10:36:02 PDT From: Steve Deering Message-Id: <95Sep15.103606pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In (IPng 653), Keith Johnson wrote: > Section 3.2 > ----------- > Should the APNIC regional registry value be 00100 instead of 10100 in > keeping with the binary increments from the left side of the field? Yep. Thanks for catching that. > Section 3.3 > ----------- > Provider ID should NOT be allowed to grow to the right side of the field > into the first 8 bit RES field since the last paragraph of 3.2 mentions > that more than one regional registry ID value could be assigned to a > given regional registry. What do you think? I think it's better to leave both possibilities as ways to increase the number of providers -- no need to eliminate any degrees of freedom at this point. If the time comes that expansion is needed, at that point we can decide on how best to do it, based on up-to-date understanding of growth patterns and consequences. > Section 4.0 > ----------- > Has there been any discussion on what a good value for n is with respect > to the number of bits allocated to the National-Registry ID? No. The discussion in section 4.0 is intended to imply that it is a local decision by each regional registry. Thanks for the comments, Keith. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 15 11:33:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00737; Fri, 15 Sep 95 11:33:57 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00731; Fri, 15 Sep 95 11:33:49 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id LAA29427; Fri, 15 Sep 1995 11:21:39 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id LAA01635; Fri, 15 Sep 1995 11:21:11 -0700 Date: Fri, 15 Sep 1995 11:21:11 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199509151821.LAA01635@bobo.Eng.Sun.COM> To: bound@zk3.dec.com Subject: (IPng 664) Re: IPng and AddrConf Interm Meeting Cc: ipng@sunroof.Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk We'll submit the draft today. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 15 14:44:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00823; Fri, 15 Sep 95 14:44:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00817; Fri, 15 Sep 95 14:44:15 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26188; Fri, 15 Sep 1995 14:32:28 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id OAA16749; Fri, 15 Sep 1995 14:32:24 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id OAA04052; Fri, 15 Sep 1995 14:31:56 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Sep 1995 14:35:04 -0700 To: Steve Deering From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 665) Re: WG Last Call: Address Formats & Experimental Allocation Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Steve, Thanks for doing the last call on these documents. >Recall that the unicast address format document was discussed in the >Danvers meeting, and the concensus of that meeting was to publish it as >an Informational RFC after revisions to the format to leave more room for >future growth. The -02 version of that document incorporates those >revisions. > >As part of the Last Call comments, the chairs would like to determine if >there is still rough consensus that Informational is the right status for >the address format document. Possible alternatives are Proposed Standard >or the new Best Current Practices (BCP). I think the provider unicast address format ("An IPv6 Provider-Based Unicast Address Format") specification should become a Proposed Standard. I have several reasons for this. This document represents the only workable addressing plan we have now. While I am the first to say that provider based allocation has it's problems, I am pretty certain that this plan will work (e.g., provide scalable routing). I think it will even work a lot better than the current IPv4 provider approaches because of the explicit registries and provider ID's. The final reason I think this document should go to PS is that we need it to start any real deployment. I think many people will ignore IPv6 until there is a real (e.g., standard) addressing plan. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 15 20:10:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01059; Fri, 15 Sep 95 20:10:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01053; Fri, 15 Sep 95 20:10:15 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03300; Fri, 15 Sep 1995 19:58:28 -0700 Received: from dylan.mindspring.com by mercury.Sun.COM (Sun.COM) id TAA06250; Fri, 15 Sep 1995 19:58:29 -0700 Received: from sthomas.mindspring.com [168.121.37.118] by dylan.mindspring.com with SMTP id WAA11860; Fri, 15 Sep 1995 22:58:16 -0400 Message-Id: <199509160258.WAA11860@dylan.mindspring.com> X-Sender: sthomas@mindspring.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Sep 1995 22:57:24 -0400 To: ipv6imp@munnari.OZ.AU From: Stephen Thomas Subject: (IPng 666) ICMPv6 Priority (Was: [IPv6Imp] Real live ND packets.) Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk At 02:39 PM 9/13/95 +0000, Matt Thomas wrote: >The following is a neighbor solicitation/advertisement exchange >between FE80::800:2BE4:638C and FE80::800:2BBE:6260.... >13:50:01.619760 8:0:2b:be:62:60 33:33:2b:e4:63:8c 86dd 88: > 6000 0000 0030 3a01 fe80 0000 0000 0000 > 0000 0800 2bbe 6260 ff02 0000 0000 0000 > 0000 0001 2be4 638c 8700 93d0 0000 0000 > fe80 0000 0000 0000 0000 0800 2bbe 6260 > fe80 0000 0000 0000 0000 0800 2be4 638c > 0101 0800 2bbe 6260 >13:50:01.619760 8:0:2b:e4:63:8c 8:0:2b:be:62:60 86dd 72: > 6000 0000 0020 3a01 fe80 0000 0000 0000 > 0000 0800 2be4 638c fe80 0000 0000 0000 > 0000 0800 2bbe 6260 8800 ddb0 4000 0000 > fe80 0000 0000 0000 0000 0800 2be4 638c > 0201 0800 2be4 638c > Maybe a silly question: Shouldn't each of these have a priority of 7? If the "Internet Control Message Protocol" doesn't qualify as "internet control" traffic, then we've definitely ended up with some confusing terminology. Now that I think to look, shouldn't the neighbor discovery draft mention this explicitly when it describes the IPv6 header fields for each message? (This last question is why I've CC'd the ipng mailing list.) --Stephen ________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: s.thomas@acm.org ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 16 09:48:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01289; Sat, 16 Sep 95 09:48:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01283; Sat, 16 Sep 95 09:48:40 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22318; Sat, 16 Sep 1995 09:36:53 -0700 Received: from concorde.inria.fr by venus.Sun.COM (Sun.COM) id JAA19838; Sat, 16 Sep 1995 09:36:53 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id SAA29724; Sat, 16 Sep 1995 18:13:52 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id SAA24844; Sat, 16 Sep 1995 18:13:50 +0200 Message-Id: <199509161613.SAA24844@givry.inria.fr> From: Francis Dupont To: bound@zk3.dec.com Cc: hinden@ipsilon.com (Bob Hinden), ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com Subject: (IPng 667) Re: IPng and AddrConf Interm Meeting In-Reply-To: Your message of Fri, 15 Sep 1995 11:40:52 EDT. <9509151540.AA03662@wasted.zk3.dec.com> Date: Sat, 16 Sep 1995 18:12:13 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: Bob, I am thinking now that we have a lot of serious input for ND. I am concerned we will not have a quorum in October representative at this meeting for ND. If we don't what comes out of it should not reflect any consensus. For sure we need Francis Dupont, Matt Thomas, Bill Medlin, Dan McDonald, Peter Sojin, and any other implementors who are in that part of the ND code. => I'll be at the RIPE meeting in Amsterdam (proposed date conflicts with ATM Forum general meeting too). I fear that these engineers and others have justified travel to the IETF with their source of funding and not for such an interim meeting? => I'm afraid you're right... Most of the above mentioned folks will actually be testing the latest ND code at Interop, and this will tell us a lot too, probably more than a meeting will. How about a discussion after Interop too via mail? => for me Interop was this week in Paris (not Atlanta in 10 days :-). I don't recall that there would be an interim meeting stated at Stockholm for addr )nconf or ND? => no date or location... Thanks Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 17 10:00:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01421; Sun, 17 Sep 95 10:00:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01415; Sun, 17 Sep 95 10:00:37 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26316; Sun, 17 Sep 1995 09:48:44 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id JAA12698; Sun, 17 Sep 1995 09:48:44 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA29789; Sun, 17 Sep 1995 12:48:35 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA14949; Sun, 17 Sep 1995 12:48:32 -0400 Message-Id: <9509171648.AA14949@wasted.zk3.dec.com> To: hinden@ipsilon.com (Bob Hinden) Cc: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com Subject: (IPng 668) Re: IPng and AddrConf Interm Meeting In-Reply-To: Your message of "Fri, 15 Sep 95 09:27:27 PDT." Date: Sun, 17 Sep 95 12:48:32 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Bob, >Not sure I see the problem. The problem I previously stated was the word "funding" for travel and expense. We arrange our funding for 3 IETF meetings a year. Thats at least $9000.00 per person who attends all three meetings. This is what is planned for by most WG members. In addition meetings take engineers away from their work as implementors. Sometimes their bosses have a problem with that and need them to be at work. The managers justify the IETF meetings and permit funding. If we don't have the "implementors" at the meeting because of this problem then I question the validity of the outcome of the meeting as far as consensus. I would be better off writing code and discussing it in mail than coming to a meeting. But if this is to advance the spec then I have to be there. I don't see why this cannot be done electronically until we meet at the Dallas IETF either? The other problem is that if the Chairs want to have an interim meeting advanced notice at Stockholm would have been good for future input so the justification process can begin. So if we see that the implementors are not at the meeting I would like to know because then I am (I will be going) coming with the intention of "review" and not to achieve any consensus. >Interop is two weeks prior to the meeting. >There should be plenty of time to discuss issues encountered at Interop on >the mailing list and at the meeting. The purpose of the meeting is to >resolve open issues with ND. Having the meeting shortly after Interop >while the issues are fresh in the implementors minds seems like just the >right thing to me. I agree with this if we can get the implementors in the room with us. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 17 10:02:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01433; Sun, 17 Sep 95 10:02:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01427; Sun, 17 Sep 95 10:02:33 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26358; Sun, 17 Sep 1995 09:50:45 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id JAA12791; Sun, 17 Sep 1995 09:50:45 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA29970; Sun, 17 Sep 1995 12:50:42 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA13261; Sun, 17 Sep 1995 12:50:40 -0400 Message-Id: <9509171650.AA13261@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 669) Re: WG Last Call: Address Formats & Experimental Allocation In-Reply-To: Your message of "Fri, 15 Sep 95 10:25:23 PDT." <95Sep15.102535pdt.75270@digit.parc.xerox.com> Date: Sun, 17 Sep 95 12:50:40 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Steve, Seems like BCP to me. But no big issue. I think the important point is that this work be advanced expediently. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 17 10:14:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01449; Sun, 17 Sep 95 10:14:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01443; Sun, 17 Sep 95 10:13:55 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26647; Sun, 17 Sep 1995 10:02:06 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id KAA13380; Sun, 17 Sep 1995 10:02:06 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA00287; Sun, 17 Sep 1995 13:01:40 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA14414; Sun, 17 Sep 1995 13:01:32 -0400 Message-Id: <9509171701.AA14414@wasted.zk3.dec.com> To: deering@parc.xerox.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 670) Re: WG Last Call: Address Formats & Experimental Allocation In-Reply-To: Your message of "Fri, 15 Sep 95 14:35:04 PDT." Date: Sun, 17 Sep 95 13:01:32 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Steve, >The final reason I think this document should go to PS is that we need it >to start any real deployment. I think many people will ignore IPv6 until >there is a real (e.g., standard) addressing plan. I think this is the best advancement in my last mail if possible. I agree with Bob we need to have this happen now. I believe we will have serious IPv4 address space problems by 1998 now. This needs to get some deployment. Though I like the idea of a BCP for testing, I also don't think we have much time left to get IPv6 deployed. So if we can do PS then lets do it. Whether we like it or not BCP, Info, and Experimental are not good status in our community. ALso in many companies unless its PS investement in that IETF work will be questioned. I agree with Bob. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 17 10:16:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01469; Sun, 17 Sep 95 10:16:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01463; Sun, 17 Sep 95 10:16:21 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26732; Sun, 17 Sep 1995 10:04:28 -0700 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id KAA13641; Sun, 17 Sep 1995 10:04:27 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id NAA21161; Sun, 17 Sep 1995 13:01:32 -0400 (EDT) Date: Sun, 17 Sep 1995 13:01:32 -0400 (EDT) From: Scott Bradner Message-Id: <199509171701.NAA21161@newdev.harvard.edu> To: bound@zk3.dec.com, deering@parc.xerox.com Subject: (IPng 671) Re: WG Last Call: Address Formats & Experimental Allocation Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Seems like BCP to me. one nit here - BCP is supposed to be *current* practice, seems a bit early for that - how about Experimental, to be moved to BCP after some experience? Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 17 11:25:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01566; Sun, 17 Sep 95 11:25:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01560; Sun, 17 Sep 95 11:25:42 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28536; Sun, 17 Sep 1995 11:13:53 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id LAA22615; Sun, 17 Sep 1995 11:13:54 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA02265; Sun, 17 Sep 1995 14:13:51 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA17229; Sun, 17 Sep 1995 14:13:49 -0400 Message-Id: <9509171813.AA17229@wasted.zk3.dec.com> To: Scott Bradner Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 672) Re: WG Last Call: Address Formats & Experimental Allocation In-Reply-To: Your message of "Sun, 17 Sep 95 13:01:32 EDT." <199509171701.NAA21161@newdev.harvard.edu> Date: Sun, 17 Sep 95 14:13:49 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >> Seems like BCP to me. Well I am now on PS. >one nit here - BCP is supposed to be *current* practice, seems a bit early >for that - how about Experimental, to be moved to BCP after some experience? I think BCP is what we should shoot for if PS absolutely is out of the question. Thats my input to the Chairs. I think the sense of market urgency for IPv6 warrants PS and at a minimum BCP. Its a stronger message from the WG to the IESG and then the market than experimental. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 17 12:20:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01612; Sun, 17 Sep 95 12:20:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01606; Sun, 17 Sep 95 12:20:26 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00061; Sun, 17 Sep 1995 12:08:39 -0700 Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id MAA25219; Sun, 17 Sep 1995 12:08:38 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA03684; Sun, 17 Sep 1995 15:08:31 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA02985; Sun, 17 Sep 1995 15:08:28 -0400 Message-Id: <9509171908.AA02985@wasted.zk3.dec.com> To: Scott Bradner Cc: addrconf@cisco.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng 673) Re: IPng and AddrConf Interm Meeting In-Reply-To: Your message of "Fri, 15 Sep 95 12:05:34 EDT." <199509151605.MAA13639@newdev.harvard.edu> Date: Sun, 17 Sep 95 15:08:28 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Scott, >> I am thinking now that we have a lot of serious input for ND. >can you give some examples please Router Preference Discussion on IPng. IPng Mail #608 NUD may not be the best way to locate black-hole detection. The spec has not numbered the bits. Some confusion on which hi/low. Attached is implementor list discussion of which we are seeing. If it turns out that implementations have problems with the spec then we need to bring it to the list. I perceive that will be the case. For addrconf I will be writing much of that code. I don't even want to think about doing to much on that until I see the ND implemtors have interoperated. I think we can flush this out soon and in the next draft. And get both to PS (if nd is right addrconf will move quickly to be right) right after (or before Dallas IETF) IMHO. But I don't think we need yet another meeting to do this at all. I think it can be done electronically and by us staying at home and implementing to produce the attached mail. It looks like Frank Solensky at FTP can host a connectathon +/- Jan 96 for IPv6 and most folks will be ready for that. Thats more travel besides the IETF meeting for most. Better to use the travel for that than in interim nd and addrconf meeting. We even canceld part 2 of the addr conf meeting in Stockholm and now we have to meet before Dallas? Confuses me a little bit. /jim --------------------------------------- Return-Path: owner-IPv6Imp@munnari.OZ.AU Received: from alpha.zk3.dec.com by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA26817; Sat, 16 Sep 1995 12:33:11 -0400 Received: from decvax.zk3.dec.com by alpha.zk3.dec.com; (5.65v3.0/1.1.8.2/20May95-1022AM) id AA25478; Sat, 16 Sep 1995 12:33:08 -0400 Received: from murtoa.cs.mu.OZ.AU by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA08068; Sat, 16 Sep 1995 12:33:04 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA09132; Sun, 17 Sep 1995 02:18:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA09117; Sun, 17 Sep 1995 02:03:44 +1000 Received: from concorde.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28309; Sun, 17 Sep 1995 02:03:21 +1000 (from Francis.Dupont@inria.fr) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id SAA29692; Sat, 16 Sep 1995 18:03:01 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id SAA24812; Sat, 16 Sep 1995 18:02:39 +0200 Message-Id: <199509161602.SAA24812@givry.inria.fr> From: Francis Dupont To: Matt Thomas Cc: ipv6imp@munnari.OZ.AU Subject: [IPv6Imp] Re: Real live ND packets. In-Reply-To: Your message of Wed, 13 Sep 1995 14:39:02 -0000. <199509131439.OAA18494@whydos.lkg.dec.com> Date: Sat, 16 Sep 1995 18:00:08 +0200 Sender: Francis.Dupont@inria.fr Precedence: bulk In your previous mail you wrote: Since hopefully everyone is busily implementing neighbor discovery, maybe we should verify that the packets we are sending are what each other expects. => in fact you have only one real choice: try with another implementation... The following is a neighbor solicitation/advertisement exchange between FE80::800:2BE4:638C and FE80::800:2BBE:6260. The packet formats are as defined in draft-ietf-ipngwg-discovery-01.txt except for the addition of the ICMP Sender Address (per IPng 608) in the neighbor solicitation packet (which was placed before the Target Address). => I've added something about IPng 608 at the end, I hope you can read tcpdump output! (since a hex dump is probably the best format so there's no possibility of misinterpetation by an analyzer). 13:50:01.619760 8:0:2b:be:62:60 33:33:2b:e4:63:8c 86dd 88: 6000 0000 0030 3a01 fe80 0000 0000 0000 0000 0800 2bbe 6260 ff02 0000 0000 0000 0000 0001 2be4 638c 8700 93d0 0000 0000 fe80 0000 0000 0000 0000 0800 2bbe 6260 fe80 0000 0000 0000 0000 0800 2be4 638c 0101 0800 2bbe 6260 13:50:01.619760 8:0:2b:e4:63:8c 8:0:2b:be:62:60 86dd 72: 6000 0000 0020 3a01 fe80 0000 0000 0000 0000 0800 2be4 638c fe80 0000 0000 0000 0000 0800 2bbe 6260 8800 ddb0 4000 0000 fe80 0000 0000 0000 0000 0800 2be4 638c 0201 0800 2be4 638c Let me know if you have doubts (or certainties) about the correctness of the above packets. => They seem perfect (I've verified the checksum too)! About IPng 608, there is a problem with the idea to carry two addresses in NS without a clear rationate on how to use it: if the sender address is a global one then NS reception will create two entries in the Neighbor cache (one for the global sender, one for the source link-local) and NUD will poll *both*! Address resolution gives two packets with upper layer help, four without it. With an IPng 608 "stupid" implementation it can give 4, 6 or 8 packets then we have to back track or to specify "clever" IPng 608 implementation. I believe the real problem is NUD doesn't define what is a Neighbor: an interface address or a neighbor IPv6 stack ? It is one of the problem of IPng 608, I am still in favor of it but I'll implement it only when the specs will be complete... Thanks Francis.Dupont@inria.fr PS: the extra exchange for NUD on link-local address problem has been pointed out by Dan MacDonald (NRL). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 17 14:28:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01650; Sun, 17 Sep 95 14:28:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01644; Sun, 17 Sep 95 14:28:39 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03724; Sun, 17 Sep 1995 14:16:52 -0700 Received: from nsco.network.com by mercury.Sun.COM (Sun.COM) id OAA01059; Sun, 17 Sep 1995 14:16:48 -0700 Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA22478; Sun, 17 Sep 95 16:37:02 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA08936; Sun, 17 Sep 95 16:16:57 CDT Date: Sun, 17 Sep 95 16:16:57 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9509172116.AA08936@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 674) Re: WG Last Call: Address Formats & Experimental Allocation Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Err, when was it that the status of a document was to be used for signalling, as opposed to representing something like reality? I seem to have missed that debate. Just as well, I expect. Andrew Molitor not representing NSC, STK etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 18 09:38:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01886; Mon, 18 Sep 95 09:38:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01880; Mon, 18 Sep 95 09:38:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25489; Mon, 18 Sep 1995 09:26:43 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id JAA09595; Mon, 18 Sep 1995 09:26:41 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id JAA09170; Mon, 18 Sep 1995 09:26:16 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Sep 1995 09:29:25 -0700 To: hinden@Ipsilon.COM (Bob Hinden) From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 675) Re: IPng and AddrConf Interm Meeting Cc: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com, hinden@Ipsilon.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Folks, >There will be an joint IPng and Addr Conf working group meeting on October >11 & 12 in the Washington, DC area. > >Main agenda topic will be to finalize the neighbor discovery and >auto-configuration specifications. There are a number of other issues such >as IPv6 over ethernet/token-ring/etc., path MTU discovery, IGMP, etc. that >can be worked on. Please RSVP to me if you can or can not attend this meeting. Thanks, Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 18 10:55:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02023; Mon, 18 Sep 95 10:55:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02011; Mon, 18 Sep 95 10:55:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08523; Mon, 18 Sep 1995 10:43:20 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id KAA06530; Mon, 18 Sep 1995 10:43:08 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0199; Mon, 18 Sep 95 13:42:42 EDT Received: by RTP (XAGENTA 4.0) id 1961; Mon, 18 Sep 1995 13:42:15 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17646; Mon, 18 Sep 1995 13:42:40 -0400 Message-Id: <9509181742.AA17646@cichlid.raleigh.ibm.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 676) FYI: draft-ietf-ipngwg-discovery-02.txt Date: Mon, 18 Sep 1995 13:42:24 +22305558 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk A new draft has been submitted and should appear shortly. For advanced copies, go to: ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-discovery-02.txt http://playground.sun.com/pub/ipng/draft-ietf-ipngwg-discovery-02.txt This version of the draft (like the last) does not have router preferences. Router precedences are listed as an open issue. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 18 11:36:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02083; Mon, 18 Sep 95 11:36:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02060; Mon, 18 Sep 95 11:23:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14316; Mon, 18 Sep 1995 11:11:19 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id LAA15128; Mon, 18 Sep 1995 11:11:10 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14557; 18 Sep 95 14:09 EDT To: IETF-Announce:;@mercury Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.Eng.Sun.COM From: The IESG Subject: (IPng 677) Protocol Action: Internet Protocol, Version 6 (IPv6) Specification to Proposed Standard Date: Mon, 18 Sep 95 14:09:05 -0400 Message-Id: <9509181409.aa14557@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The IESG has approved the following four Internet-Draft as Proposed Standards: 1. Internet Protocol, Version 6 (IPv6) Specification 2. IP Version 6 Addressing Architecture 3. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 4. DNS Extensions to Support IP Version 6 The IESG has also approved the publication of An Architecture for IPv6 Unicast Address Allocation as an Informational RFC. These document are the product of the IPNG Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary 1. Internet Protocol, Version 6 (IPv6) Specification is the base specification produced by the IPNGWG, for the proposed successor to IP version 4. The changes from IPv4 to IPv6 fall primarily into the categories of: o Expanded Addressing Capabilities IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy, a much greater number of addressable nodes, and simpler auto-configuration of addresses. The scalability of multicast routing is improved by adding a "scope" field to multicast addresses. And a new type of address called an "anycast address" is defined, used to send a packet to any one of a group of nodes. o Header Format Simplification Some IPv4 header fields have been dropped or moved to optional extension headers, to reduce the common-case processing cost of packet handling and to limit the added bandwidth cost of the IPv6 header (beyond the long addresses). Fragmentation and reassembly are limited to the source and destination. o Improved Support for Extensions and Options Changes in the way IP header options are encoded allow for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future. Among the improvements is a flexible format for the carriage of explicit routing information. o Flow Labeling Capability A new capability is added to enable the labeling of packets belonging to particular traffic "flows" for which the sender requests special handling, such as non-default quality of service or "real-time" service. o Authentication and Privacy Capabilities Extensions to support authentication, data integrity, and (optional) data confidentiality are specified for IP6 in the Proposed Standards RFC 18xx and 18xx. The document specifies the basic header and four extension headers, Hop-by-Hop Options, Destination Options, Fragment Header, and Routing Header. Authentication and Encapsulating Security Payload (privacy) extension headers for IPv6 are defined in the Proposed Standards RFCs 1825-1829 and are required for implementation in IPv6. TCP and UDP processing are directly affected by IPv6 primarily by the pseudo-header that includes IP addresses and other IP header information. This specification includes a section defining the upper layer pseudo-header checksumming procedure for IPv6. 2. The IP Version 6 Addressing Architecture This document specifies the addressing architecture of the IP Version 6 protocol. It defines the three types of addresses, unicast, anycast, and multicast, and their uses. It specifies the use of a variable length Format Prefix, and allocates directly a small fraction of the total IPv6 address space for provider addresses, local use addresses, and multicast addresses. Space is reserved for NSAP addresses, IPX addresses, and geographic addresses. The remainder of the address space is reserved for future use. This can be used for expansion of existing uses (e.g. additional provider addresses, etc.) or new uses (e.g., separate locators and identifiers). 3. The Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) The Internet Protocol, version 6 (IPv6) is a new version of IP. IPv6 uses the Internet Control Message Protocol (ICMP) as defined for IPv4 [RFC-792], with a number of changes. The Internet Group Membership Protocol (IGMP) specified for IPv4 [RFC-1112] has also been revised and has been absorbed into ICMP for IPv6. The resulting protocol is called ICMPv6, and has an IPv6 Next Header value 58. ICMPv6 is required for the implementation of IPv6. Other IPv6 specifications including Neighbor Discovery and Stateless Address Autoconfiguration (Works in Progress) introduce additional ICMPv6 messsages, subject to the general rules for ICMPv6 messages given in this specification. 4. DNS Extensions to Support IP Version 6 This specification defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. 5. An Architecture for IPv6 Unicast Address Allocation (Informational status) This informational document describes ways in which CIDR address allocation and routing techniques can be used with IPv6. Working Group Summary The IETF Last Call comments resulted in a small list of corrections and clarifications for the base and ICMPv6 specifications. The consensus of the working group on the mailing list and at the Stockholm IETF meeting remained clear. The five documents here are part of a comprehensive specification of the IPv6 protocol and its related support, routing, transition, and media adaptation mechanisms. Besides several additional documents from the IPNGWG, other IETF WGs are preparing specifications that are close to or past IETF Last Call: these include the Address Autoconfiguration, Next Generation Transition, DHCP, DNSIND, Mobile IP, OSPF, RIPv2, and IPIDRP WGs. Based on the results of the Transport Next Generation BOF held at the San Jose IETF meeting, future work on transport advances to take advantage of IPv6 deployment will be decoupled from the initial standardization of IPv6. Protocol Quality These specifications were reviewed for the IESG by the IPng Area Directors, following lengthy community discussion and review. There is a growing number of full-function, commercial implementations of these specifications and their companion works in progress. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 18 12:46:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02233; Mon, 18 Sep 95 12:46:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02227; Mon, 18 Sep 95 12:45:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29629; Mon, 18 Sep 1995 12:34:02 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id MAA07216; Mon, 18 Sep 1995 12:33:45 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa16216; 18 Sep 95 15:03 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 678) I-D ACTION:draft-ietf-ipngwg-discovery-02.txt Date: Mon, 18 Sep 95 15:03:48 -0400 Message-Id: <9509181503.aa16216@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 : Neighbor Discovery for IP Version 6 (IPv6) Author(s) : T. Narten, E. Nordmark, W. Simpson Filename : draft-ietf-ipngwg-discovery-02.txt Pages : 74 Date : 07/07/1995 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-discovery-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-discovery-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 (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-discovery-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: <19950915162658.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-discovery-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-discovery-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950915162658.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 18 23:33:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02586; Mon, 18 Sep 95 23:33:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02580; Mon, 18 Sep 95 23:33:06 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14870; Mon, 18 Sep 1995 23:21:13 -0700 Received: from mewgate.mew.co.jp by mercury.Sun.COM (Sun.COM) id XAA24088; Mon, 18 Sep 1995 23:21:13 -0700 Received: from mita.trc.mew.co.jp ([133.254.180.19]) by mewgate.mew.co.jp (8.6.11+2.5Wb2/3.3W-mewgate-940715) with SMTP id PAA12504 for ; Tue, 19 Sep 1995 15:21:09 +0900 Received: by mita.trc.mew.co.jp (5.65/4.2:2.0:master:940923) id AA17105; Tue, 19 Sep 95 15:20:57 +0900 From: claude@trc.mew.co.jp (Claude Huss) Message-Id: <9509190620.AA17105@mita.trc.mew.co.jp> Subject: (IPng 679) Nameservers in IPng? To: ipng@sunroof.Eng.Sun.COM Date: Tue, 19 Sep 1995 15:20:56 +0900 (JST) X-Disclaimer: Opinions expressed here are strictly my own Organization: Matsushita Electric Works, Ltd. X-Mailer: ELM [2.4 PL23.Japanese] (Claude Huss) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Could anyone give me any pointers about any information about Nameservers on IPng? Thanks in advance! -- Claude Huss, Network Research Engineer Matsushita Electric Works, Tokyo R&D Labs Network Software Group http://www2.gol.com/users/claude/shin.html -- Transmitted in recycled IP Broadcast Packets over Dropped ATM cells -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 19 01:50:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02649; Tue, 19 Sep 95 01:50:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02643; Tue, 19 Sep 95 01:49:58 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21653; Tue, 19 Sep 1995 01:38:05 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id BAA06653; Tue, 19 Sep 1995 01:37:52 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id KAA26332; Tue, 19 Sep 1995 10:37:43 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id KAA28874; Tue, 19 Sep 1995 10:37:48 +0200 Message-Id: <199509190837.KAA28874@givry.inria.fr> From: Francis Dupont To: "Thomas Narten" Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 680) Re: FYI: draft-ietf-ipngwg-discovery-02.txt In-Reply-To: Your message of Mon, 18 Sep 1995 13:42:24. <9509181742.AA17646@cichlid.raleigh.ibm.com> Date: Tue, 19 Sep 1995 10:37:42 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: A new draft has been submitted and should appear shortly. This version of the draft (like the last) does not have router preferences. Router precedences are listed as an open issue. => I don't believe it is a good idea. IPv4 router discovery (aka IRDP aka RFC 1256) has preferences and they are heavily used. I did a fast poll last week at Interop 95 (in Paris) and all the network managers agreed: IPv4 router discovery is a nice protocol and preferences are an important part of it. If you don't believe me I can ask them to explain their needs to this mailing-list... Reception of ND packets can still trigger extra NUD exchanges (because they can create neighbor cache entries in the PROBE state). I think I have found a simple way to fix this problem, I'll send a mail about it as soon as I've implemented and tested it. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 19 02:05:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02671; Tue, 19 Sep 95 02:05:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02665; Tue, 19 Sep 95 02:04:51 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22224; Tue, 19 Sep 1995 01:53:02 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id BAA07790; Tue, 19 Sep 1995 01:52:59 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id KAA26582; Tue, 19 Sep 1995 10:52:56 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id KAA28942; Tue, 19 Sep 1995 10:52:55 +0200 Message-Id: <199509190852.KAA28942@givry.inria.fr> From: Francis Dupont To: claude@trc.mew.co.jp (Claude Huss) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 681) Re: Nameservers in IPng? In-Reply-To: Your message of Tue, 19 Sep 1995 15:20:56 +0900. <9509190620.AA17105@mita.trc.mew.co.jp> Date: Tue, 19 Sep 1995 10:52:24 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: Could anyone give me any pointers about any information about Nameservers on IPng? => If you want pointers for IPv6 support in DNS software, there are several sets of patches for BIND (Mark Andrews did one, I did a minimal one for BIND 4.9.3 beta on any platform and a more complete one on NetBSD 1.0 current, I've seen others). If you look for zones with IPv6 RRs then we'll install one as soon as possible with the NIC France and the RIPE NCC but today there is no ip6.int domain then you can't get reverse zone. Regards Francis.Dupont@inria.fr PS: int domain responsible person is Paul Mockapetris , perhaps we should *ask* him for the ip6.int domain ? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 19 11:50:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03145; Tue, 19 Sep 95 11:50:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03139; Tue, 19 Sep 95 11:50:18 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20700; Tue, 19 Sep 1995 11:38:25 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id LAA21177; Tue, 19 Sep 1995 11:38:21 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1293; Tue, 19 Sep 95 14:37:56 EDT Received: by RTP (XAGENTA 4.0) id 3270; Tue, 19 Sep 1995 14:37:27 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17563; Tue, 19 Sep 1995 14:37:30 -0400 Message-Id: <9509191837.AA17563@cichlid.raleigh.ibm.com> To: bound@zk3.dec.com Cc: Scott Bradner , addrconf@cisco.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng 682) Re: IPng and AddrConf Interm Meeting In-Reply-To: Your message of "Sun, 17 Sep 1995 15:08:28 EDT." <9509171908.AA02985@wasted.zk3.dec.com> Date: Tue, 19 Sep 1995 14:37:17 +22305558 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Jim, >NUD may not be the best way to locate black-hole detection. Could you please expand on this point? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 20 08:10:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03821; Wed, 20 Sep 95 08:10:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03815; Wed, 20 Sep 95 08:10:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06271; Wed, 20 Sep 1995 07:58:57 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id HAA12735; Wed, 20 Sep 1995 07:58:52 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4922; Wed, 20 Sep 95 10:58:25 EDT Received: by RTP (XAGENTA 4.0) id 3384; Wed, 20 Sep 1995 10:57:57 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA12890; Wed, 20 Sep 1995 10:58:11 -0400 Message-Id: <9509201458.AA12890@cichlid.raleigh.ibm.com> To: Steve Deering Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 683) Re: WG Last Call: Address Formats & Experimental Allocation In-Reply-To: Your message of "Fri, 15 Sep 1995 10:25:23 PDT." <95Sep15.102535pdt.75270@digit.parc.xerox.com> Date: Wed, 20 Sep 1995 10:57:59 +22305558 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > An IPv6 Provider-Based Unicast Address Format > Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, and J. Postel > draft-ietf-ipngwg-unicast-addr-fmt-02.txt > proposed RFC status: Informational >Recall that the unicast address format document was discussed in the >Danvers meeting, and the concensus of that meeting was to publish it as >an Informational RFC after revisions to the format to leave more room for >future growth. The -02 version of that document incorporates those >revisions. Just what is the practical impact of publishing this document as an Informational vs. PS RFC? It's not at all clear to me that an Informational RFC gives the IANA the go ahead to start handing out addresses under this format. I know that RFC 1602 isn't exactly authoritative, but it says: > An "Informational" specification is published for the > general information of the Internet community, and does > not represent an Internet community consensus or > recommendation. The Informational designation is intended > to provide for the timely publication of a very broad > range of responsible informational documents from many > sources, subject only to editorial considerations and to > verification that there has been adequate coordination > with the standards process. > > Specifications that have been prepared outside of the > Internet community and are not incorporated into the > Internet standards process by any of the provisions of > Section 4 may be published as Informational RFCs, with the > permission of the owner. In short, it would appear that publishing this document as an Informational RFC does not allow the assignment of such addresses to begin. Would someone who (better) understands the process please comment? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 20 12:15:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03963; Wed, 20 Sep 95 12:15:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03956; Wed, 20 Sep 95 12:15:02 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16459; Wed, 20 Sep 1995 12:03:08 -0700 Received: from zephyr.isi.edu by mercury.Sun.COM (Sun.COM) id MAA19805; Wed, 20 Sep 1995 12:03:06 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Wed, 20 Sep 1995 12:02:51 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199509201902.AA03405@zephyr.isi.edu> Subject: (IPng 684) Re: Nameservers in IPng? To: Francis.Dupont@inria.fr (Francis Dupont) Date: Wed, 20 Sep 1995 12:02:51 -0700 (PDT) Cc: claude@trc.mew.co.jp, ipng@sunroof.Eng.Sun.COM In-Reply-To: <199509190852.KAA28942@givry.inria.fr> from "Francis Dupont" at Sep 19, 95 10:52:24 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Francis.Dupont@inria.fr > > PS: int domain responsible person is Paul Mockapetris , > perhaps we should *ask* him for the ip6.int domain ? > ------------------------------------------------------------------------------ The paperwork is in for this domain. -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 20 14:09:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04120; Wed, 20 Sep 95 14:09:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04114; Wed, 20 Sep 95 14:09:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05090; Wed, 20 Sep 1995 13:57:21 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id NAA15972; Wed, 20 Sep 1995 13:57:09 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id NAA23521; Wed, 20 Sep 1995 13:56:42 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Sep 1995 13:59:52 -0700 To: ipng@sunroof.Eng.Sun.COM From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 685) Updated IPng Web Pages Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk A new version of the IPng working group web pages are now installed on playground.sun.com. Check out the implementation page. It has some very interesting new additions! The URL is: http://playground.sun.com/pub/ipng/html/ipng-main.html Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 20 19:47:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04682; Wed, 20 Sep 95 19:47:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04676; Wed, 20 Sep 95 19:47:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20514; Wed, 20 Sep 1995 19:35:09 -0700 Received: from mewgate.mew.co.jp by mercury.Sun.COM (Sun.COM) id TAA16395; Wed, 20 Sep 1995 19:35:05 -0700 Received: from mita.trc.mew.co.jp ([133.254.180.19]) by mewgate.mew.co.jp (8.6.11+2.5Wb2/3.3W-mewgate-940715) with SMTP id LAA13666 for ; Thu, 21 Sep 1995 11:35:02 +0900 Received: by mita.trc.mew.co.jp (5.65/4.2:2.0:master:940923) id AA06227; Thu, 21 Sep 95 11:34:49 +0900 From: claude@trc.mew.co.jp (Claude Huss) Message-Id: <9509210234.AA06227@mita.trc.mew.co.jp> Subject: (IPng 686) Re: Nameservers in IPng? To: bmanning@ISI.EDU (Bill Manning) Date: Thu, 21 Sep 1995 11:34:48 +0900 (JST) Cc: Francis.Dupont@inria.fr, claude@trc.mew.co.jp, ipng@sunroof.Eng.Sun.COM In-Reply-To: <199509201902.AA03405@zephyr.isi.edu> from "Bill Manning" at Sep 20, 95 12:02:51 pm X-Disclaimer: Opinions expressed here are strictly my own Organization: Matsushita Electric Works, Ltd. X-Mailer: ELM [2.4 PL23.Japanese] (Claude Huss) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >From Bill Manning: > > > Francis.Dupont@inria.fr > > > > PS: int domain responsible person is Paul Mockapetris , > > perhaps we should *ask* him for the ip6.int domain ? > > ------------------------------------------------------------------------------ > > The paperwork is in for this domain. > > -- > --bill Do you mean paperwork as in some "document that is available to public"? I would be interested to read it, if there is any, of course. -- Claude Huss, Network Research Engineer Matsushita Electric Works, Tokyo R&D Labs Network Software Group http://www2.gol.com/users/claude/shin.html -- Transmitted in recycled IP Broadcast Packets over Dropped ATM cells -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 21 17:02:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05099; Thu, 21 Sep 95 17:02:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05093; Thu, 21 Sep 95 17:01:54 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA19173; Thu, 21 Sep 1995 16:49:46 -0700 From: bmanning@ISI.EDU Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM) id QAA08407; Thu, 21 Sep 1995 16:49:44 -0700 Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Thu, 21 Sep 1995 16:49:39 -0700 Posted-Date: Thu, 21 Sep 1995 16:46:36 -0700 (PDT) Message-Id: <199509212346.AA05175@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Thu, 21 Sep 1995 16:46:36 -0700 Subject: (IPng 687) Re: Nameservers in IPng? To: claude@trc.mew.co.jp (Claude Huss) Date: Thu, 21 Sep 1995 16:46:36 -0700 (PDT) Cc: bmanning@ISI.EDU, Francis.Dupont@inria.fr, claude@trc.mew.co.jp, ipng@sunroof.Eng.Sun.COM In-Reply-To: <9509210234.AA06227@mita.trc.mew.co.jp> from "Claude Huss" at Sep 21, 95 11:34:48 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > >From Bill Manning: > > > > > Francis.Dupont@inria.fr > > > > > > PS: int domain responsible person is Paul Mockapetris , > > > perhaps we should *ask* him for the ip6.int domain ? > > > ------------------------------------------------------------------------------ > > > > The paperwork is in for this domain. > > > > -- > > --bill > > Do you mean paperwork as in some "document that is available to public"? > I would be interested to read it, if there is any, of course. > > -- > Claude Huss, Network Research Engineer > Matsushita Electric Works, Tokyo R&D Labs Network Software Group > http://www2.gol.com/users/claude/shin.html > -- Transmitted in recycled IP Broadcast Packets over Dropped ATM cells -- > Paperwork, as in, the delegation of the domain to working nameservers. I'm not sure why you would want to review the application for delegation, but if you really want to see it, send me private email and I'll forward it to you. --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 21 21:15:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05204; Thu, 21 Sep 95 21:15:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05198; Thu, 21 Sep 95 21:14:49 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA12052; Thu, 21 Sep 1995 21:02:45 -0700 From: bound@zk3.dec.com Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id VAA10161; Thu, 21 Sep 1995 21:02:47 -0700 Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA29449; Thu, 21 Sep 1995 20:52:16 -0700 Received: by xirtlu.zk3.dec.com; id AA28001; Thu, 21 Sep 1995 23:52:12 -0400 Message-Id: <9509220352.AA28001@xirtlu.zk3.dec.com> To: "Thomas Narten" Cc: addrconf@cisco.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng 688) Re: IPng and AddrConf Interm Meeting In-Reply-To: Your message of "Tue, 19 Sep 95 14:37:17." <9509191837.AA17563@cichlid.raleigh.ibm.com> Date: Thu, 21 Sep 95 23:52:06 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Tom, >>NUD may not be the best way to locate black-hole detection. >Could you please expand on this point? Not until I look closer at the NUD code and its affect. Just figuring out what the spec did now in the code base. OK. I said may and not even should. I am drifting back to the idea of rip, but maybe I am dreaming. For sure we will have a lot to discuss after testing next week on how we implemented it. Plus in all honesty I am so tired and burned out preparing for interop that I don't have the energy to debate right now. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 21 21:17:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05216; Thu, 21 Sep 95 21:17:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05210; Thu, 21 Sep 95 21:16:52 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA12229; Thu, 21 Sep 1995 21:04:39 -0700 From: bound@zk3.dec.com Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id VAA10359; Thu, 21 Sep 1995 21:04:41 -0700 Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA07622; Thu, 21 Sep 1995 20:58:45 -0700 Received: by xirtlu.zk3.dec.com; id AA28053; Thu, 21 Sep 1995 23:58:44 -0400 Message-Id: <9509220358.AA28053@xirtlu.zk3.dec.com> To: hinden@ipsilon.com (Bob Hinden) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 689) Re: Updated IPng Web Pages In-Reply-To: Your message of "Wed, 20 Sep 95 13:59:52 PDT." Date: Thu, 21 Sep 95 23:58:38 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Bob, Thanks for doing this its really appreciated. Also folks outside of the IETF are using and viewing it too. Good Job, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 22 09:11:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05574; Fri, 22 Sep 95 09:11:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05568; Fri, 22 Sep 95 09:11:24 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA01506; Fri, 22 Sep 1995 08:59:21 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id IAA08636; Fri, 22 Sep 1995 08:59:12 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id IAA26925; Fri, 22 Sep 1995 08:56:05 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Sep 1995 08:59:17 -0700 To: bound@zk3.dec.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 690) Re: Updated IPng Web Pages Cc: hinden@Ipsilon.COM (Bob Hinden), ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Jim, >Thanks for doing this its really appreciated. Also folks outside of the >IETF are using and viewing it too. > >Good Job, You are very welcome. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 22 09:58:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05598; Fri, 22 Sep 95 09:58:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05407; Fri, 22 Sep 95 05:06:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA11437; Fri, 22 Sep 1995 04:54:24 -0700 Received: from world-net.sct.fr by mercury.Sun.COM (Sun.COM) id EAA18670; Fri, 22 Sep 1995 04:54:20 -0700 Received: from client25.sct.fr (client25.sct.fr [194.2.128.55]) by world-net.sct.fr (8.6.12/8.6.10) with SMTP id NAA04210 for ; Fri, 22 Sep 1995 13:51:52 +0200 Date: Fri, 22 Sep 1995 13:51:52 +0200 Message-Id: <199509221151.NAA04210@world-net.sct.fr> X-Sender: ces-oxa@world-net.sct.fr (Unverified) 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: cesmo-oxara Subject: (IPng 691) IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hello ! I've got a few questions about IPv6 : - Who are the costumers planning to integrate IPv6, what are the expirations dates - IPv6 is actually implemented in Net' products * Which are the applications and platforms supported * When will we see products on the market * Who are the main constructors working on this new version (Cisco, Bay, Dec ?, IBM ?) Thank in advance for your responses Xavier ___________________________________ CESMO - OXARA 83-87 av. d'Italie 75013 PARIS FRANCE Tel: (33 1) 45 83 77 11 Fax: (33 1) 45 83 69 00 Email: ces-oxa@world-net.sct.fr ___________________________________ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 22 13:00:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05681; Fri, 22 Sep 95 13:00:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05675; Fri, 22 Sep 95 12:59:56 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA18804; Fri, 22 Sep 1995 12:47:45 -0700 From: bound@zk3.dec.com Received: from decvax.dec.com by mercury.Sun.COM (Sun.COM) id MAA17219; Fri, 22 Sep 1995 12:47:43 -0700 Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA06193; Fri, 22 Sep 1995 15:47:40 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.0/1.1.8.2/18Feb95-1123AM) id AA01149; Fri, 22 Sep 1995 15:47:38 -0400 Message-Id: <9509221947.AA01149@wasted.zk3.dec.com> To: cesmo-oxara Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 692) Re: IPv6 In-Reply-To: Your message of "Fri, 22 Sep 95 13:51:52 +0200." <199509221151.NAA04210@world-net.sct.fr> Date: Fri, 22 Sep 95 15:47:38 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Xavier, >I've got a few questions about IPv6 : This is an IETF technical mail working group list. If you have an implementors question I suggest you look at the IPng Home WEB page (attached below). Or send mail to join the implementors list to ipv6imp-request@munnari.oz.au. >- Who are the costumers planning to integrate IPv6, what are the expirations >dates > >- IPv6 is actually implemented in Net' products > * Which are the applications and platforms supported > * When will we see products on the market > * Who are the main constructors working on this new version > (Cisco, Bay, Dec ?, IBM ?) Well we are building prototypes as best I can tell in the community. Our first objective is to test the specificaitons. See the WEB page attached. But besides the list you got doing this is much larger and many more players. I think the WEB Page will give you an idea of who is doing all this now. ------------------------------------- A new version of the IPng working group web pages are now installed on playground.sun.com. Check out the implementation page. It has some very interesting new additions! The URL is: http://playground.sun.com/pub/ipng/html/ipng-main.html Bob ------------------------------------------- /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 25 10:23:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06450; Mon, 25 Sep 95 10:23:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06444; Mon, 25 Sep 95 10:23:27 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA19205; Mon, 25 Sep 1995 10:11:27 -0700 Received: from mprott.ott.mpr.ca by venus.Sun.COM (Sun.COM) id KAA20789; Mon, 25 Sep 1995 10:10:52 -0700 Received: by mprott.ott.mpr.ca id AA19638 (5.67b+/IDA-1.5 for ipng@sunroof.eng.sun.com); Mon, 25 Sep 1995 13:18:06 -0400 From: Mario Godin Message-Id: <199509251718.AA19638@mprott.ott.mpr.ca> Subject: (IPng 693) Reverse routing question To: ipng@sunroof.Eng.Sun.COM Date: Mon, 25 Sep 1995 13:18:06 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, The specifications indicate that a host must use the reverse route for replying to packets it receives (the reverse route is the reverse of the route as indicated by the address sequence of the incoming packet). My question is: What binds the incoming and outcoming packets together as a 'request' and its 'reply'? IP is not a request/reply based protocol. Is the answer to this: once a host receives a packet with an address sequence, then all packets destinated to the origin of that packet are to now use the inverse route? Isn't this giving one host the control on the routing of another, no matter what the traffic is? Ie. the host that first sends a packet will dictate the route for all traffic between those two hosts. Thanks, Mario Godin Kylain Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 25 13:02:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06646; Mon, 25 Sep 95 13:02:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06640; Mon, 25 Sep 95 13:02:08 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA12483; Mon, 25 Sep 1995 12:50:09 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id MAA18920; Mon, 25 Sep 1995 12:50:05 -0700 Received: from 13.2.17.204 ([13.2.17.201]) by alpha.xerox.com with SMTP id <14424(3)>; Mon, 25 Sep 1995 12:49:54 PDT X-Sender: deering@palain.parc.xerox.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Sep 1995 13:50:04 PDT To: Mario Godin From: deering@parc.xerox.com (Steve Deering) Subject: (IPng 694) Re: Reverse routing question Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Mario, > The specifications indicate that a host must use the reverse > route for replying to packets it receives (the reverse > route is the reverse of the route as indicated by the address sequence > of the incoming packet). Which specifications say that? Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 25 15:45:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06824; Mon, 25 Sep 95 15:45:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06818; Mon, 25 Sep 95 15:44:53 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA04473; Mon, 25 Sep 1995 15:32:53 -0700 Received: from iol.unh.edu by mercury.Sun.COM (Sun.COM) id PAA29261; Mon, 25 Sep 1995 15:32:52 -0700 Received: by iol.unh.edu (4.1/SMI-4.1) id AA03912; Mon, 25 Sep 95 18:30:23 EDT From: qv@iol.unh.edu (Quaizar Vohra) Message-Id: <9509252230.AA03912@iol.unh.edu> Subject: (IPng 695) NS and static routes To: ipng@sunroof.Eng.Sun.COM (ipng) Date: Mon, 25 Sep 1995 18:30:22 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I was testing DECs implementation and I did this : ip6_route add 1:2:3:4:5:6:7:0 ffff:ffff:ffff:ffff:ffff:ffff:ffff:0 fe80::0800:200d:b413 and then ip6 pinged to 1:2:3:4:5:6:7:8 ping replies in the negative and I kill the ping process The router address just corresponded to another machine which has no notion of ND and so obviously never replies back to NSs sent to it. So ping fails. So there is no active traffic to 1:2:3:4:5:6:7:0 and nor to this router after ping process is killed. I kept on getting NS messges for this router (fe80::0800:200d:b413) infinitely. and that too multicast ones. As far as my knowledge of ND and NUD goes this shouldn't be the case ( I am sorry if I am overlooking something ). Can someone enlighten me on this. Since this is not a default router, it would be used only when the net 1:2:3:4:5:6:7:0 is actively sent packets. So we should a dest-cache and neighbor-cache entries created and then NS sent for finding the link layer of the router. After MAX_MULTICAST_SOLICIT solicitations the cached entries should be deleted and I should not see any more NSs multicasted. Any comments would be of great help. Thanks Quaizar ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-4488 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 26 07:26:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07289; Tue, 26 Sep 95 07:26:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07283; Tue, 26 Sep 95 07:26:18 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA25644; Tue, 26 Sep 1995 07:14:14 -0700 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id HAA10357; Tue, 26 Sep 1995 07:14:13 -0700 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA01253; Tue, 26 Sep 1995 06:56:26 -0700 Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA02755; Tue, 26 Sep 1995 09:56:21 -0400 Received: by netrix.lkg.dec.com; (5.65/1.1.8.2/28May95-0415PM) id AA26792; Tue, 26 Sep 1995 09:56:22 -0400 Date: Tue, 26 Sep 1995 09:56:22 -0400 From: Dan Harrington Message-Id: <9509261356.AA26792@netrix.lkg.dec.com> To: qv@iol.unh.edu Subject: (IPng 696) Re: NS and static routes Cc: dan@netrix.lkg.dec.com, ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi Quaizar, > I was testing DECs implementation and I did this : Hey, great...thanks for helping us test this out at Interop, by the way! > ip6_route add 1:2:3:4:5:6:7:0 > ffff:ffff:ffff:ffff:ffff:ffff:ffff:0 fe80::0800:200d:b413 > and then ip6 pinged to 1:2:3:4:5:6:7:8 > ping replies in the negative and I kill the ping process > > I kept on getting NS messges for this router (fe80::0800:200d:b413) > infinitely. [...] After MAX_MULTICAST_SOLICIT solicitations the cached > entries should be deleted and I should not see any more NSs multicasted. Yes, an oversight (OK, OK, it's a bug :-) on our part. We checked this out, and because you added the route manually, the reference count on the neighbor cache entry never drops to zero and can't be freed. We'll look into this, thanks. If you have any future queries or problems regarding our prototype code, please contact us directly at ipv6-uproto-feedback@netrix.lkg.dec.com. Feel free to copy the IPV6 Implementor's list (IPv6Imp@munnari.OZ.AU), as the rest of the world will undoubtedly want to see what bugs are biting us... Dan Harrington ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 26 11:12:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07536; Tue, 26 Sep 95 11:12:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07530; Tue, 26 Sep 95 11:11:54 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA23405; Tue, 26 Sep 1995 10:59:53 -0700 Received: from mprott.ott.mpr.ca by mercury.Sun.COM (Sun.COM) id KAA14335; Tue, 26 Sep 1995 10:59:25 -0700 Received: by mprott.ott.mpr.ca id AA06271 (5.67b+/IDA-1.5 for ipng@sunroof.eng.sun.com); Tue, 26 Sep 1995 14:07:40 -0400 From: Mario Godin Message-Id: <199509261807.AA06271@mprott.ott.mpr.ca> Subject: (IPng 697) flow labels in ipng To: ipng@sunroof.Eng.Sun.COM Date: Tue, 26 Sep 1995 14:07:40 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, In the document "IP Next Generation Overview" by Robert M. Hinden it states in section 9.1 (sixth paragraph) that "All packets belonging to the same flow must be sent with the same source address, same destination address, and same non-zero flow label.". That seems logical. But in paragraph 4 it says that "A flow is uniquely identified by the combination of a source address and a non-zero flow label." Shouldn't that also include the destination address? Otherwise those two statements are in contradiction. Mario Godin Kylain Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 26 11:56:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07556; Tue, 26 Sep 95 11:56:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07550; Tue, 26 Sep 95 11:55:52 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA00025; Tue, 26 Sep 1995 11:43:49 -0700 Received: from mprott.ott.mpr.ca by mercury.Sun.COM (Sun.COM) id LAA24947; Tue, 26 Sep 1995 11:43:48 -0700 Received: by mprott.ott.mpr.ca id AA07090 (5.67b+/IDA-1.5 for ipng@sunroof.eng.sun.com); Tue, 26 Sep 1995 14:52:47 -0400 From: Mario Godin Message-Id: <199509261852.AA07090@mprott.ott.mpr.ca> Subject: (IPng 698) IP mailing lists and other sources of information To: ipng@sunroof.Eng.Sun.COM Date: Tue, 26 Sep 1995 14:52:47 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, Could someone point me to other mailing lists (or other types of information sources) that deal with IP issues (version 4)? Is there a directory or listing of these sources somewhere? Thanks, Mario Godin Kylain Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 26 12:24:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07582; Tue, 26 Sep 95 12:24:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07576; Tue, 26 Sep 95 12:24:33 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA03757; Tue, 26 Sep 1995 12:12:34 -0700 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id MAA01376; Tue, 26 Sep 1995 12:12:31 -0700 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HVQGMD5GG0005TVV@FNAL.FNAL.GOV>; Tue, 26 Sep 1995 14:12:05 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA03409; Tue, 26 Sep 95 14:10:59 CDT Date: Tue, 26 Sep 1995 14:10:58 -0500 From: Matt Crawford Subject: (IPng 699) Re: flow labels in ipng In-Reply-To: Your message of Tue, 26 Sep 95 14:07:40 EDT. <199509261807.AA06271@mprott.ott.mpr.ca> To: Mario Godin Cc: ipng@sunroof.Eng.Sun.COM Message-Id: <9509261910.AA03409@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > "All packets belonging to the same flow must be sent with the same source > address, same destination address, and same non-zero flow label." > > That seems logical. > > But in paragraph 4 it says that "A flow is uniquely identified by the > combination of a source address and a non-zero flow label." > > Shouldn't that also include the destination address? Otherwise > those two statements are in contradiction. That's no contradiction. Together, the two statements say that the same flow label can't be re-used during the life of a flow. Or to put it another way, if a packet's source and flow label match those of a packet you've seen recently, you may be sure that the destination address (and several other things) will also be the same. _________________________________________________________ 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/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 26 12:27:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07598; Tue, 26 Sep 95 12:27:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07592; Tue, 26 Sep 95 12:27:29 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA04105; Tue, 26 Sep 1995 12:15:29 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id MAA02129; Tue, 26 Sep 1995 12:15:26 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id MAA09823; Tue, 26 Sep 1995 12:12:38 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Sep 1995 12:15:53 -0700 To: Mario Godin From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 700) Re: IP mailing lists and other sources of information Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Mario, > Could someone point me to other mailing lists (or other types >of information sources) that deal with IP issues (version 4)? > >Is there a directory or listing of these sources somewhere? Check out the IETF Home page at: http://www.ietf.cnri.reston.va.us/home.html It has info on all of the IETF working groups including mailing lists, proceedings, etc. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 26 14:32:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07718; Tue, 26 Sep 95 14:32:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07712; Tue, 26 Sep 95 14:32:29 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA19952; Tue, 26 Sep 1995 14:20:29 -0700 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id OAA02461; Tue, 26 Sep 1995 14:20:25 -0700 Received: from muggsy.lkg.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA01539; Tue, 26 Sep 1995 13:46:04 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA06031; Tue, 26 Sep 1995 16:46:02 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id QAA12691 for ; Tue, 26 Sep 1995 16:47:39 GMT Message-Id: <199509261647.QAA12691@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 701) ND neighbor cache states. X-Mailer: exmh version 1.5omega 10/6/94 Date: Tue, 26 Sep 1995 16:47:37 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk As a result of implementing Neighbor Discovery and after exchanging email with Francis Dupont, I wish to propose the following change to Neighbor Discovery states: The PROBE state (as it currently exists) in Neighbor Discovery should be split into two states, STALE and PROBE. Here are the current definitions of PROBE from draft-ietf-ipngwg-discovery-02.txt: PROBE The neighbor may be reachable, but the last explicit (page 17) reachability confirmation was received long enough ago that verification is now actively sought. PROBE More than ReachableTime milliseconds have elapsed since the (page 51) last positive confirmation was received that the forward path was functioning properly. Upon entering the PROBE state, no Neighbor Solicitation is sent. However, a timer is set to expire DELAY_FIRST_PROBE_TIME seconds later, and a Neighbor Solicitation probe is sent if the entry is still in a PROBE state when the timer expires. Delaying the sending of the initial Neighbor Solicitation gives the upper layers additional time to provide reachability confirmation information. After the initial delay, Neighbor Solicitations are retransmitted every RetransTimer milliseconds until a reachability confirmation is received. These definitions (and especially the latter) are too complex. In the second definition, the first and second statements describe different and possibly overlapping substates of the PROBE state. Does one really enter the PROBE state after "More than ReachableTime milliseconds..."? Not according to the description of the NUD algorithm on page 52: Unreachability detection changes a neighbor's state from REACHABLE to PROBE only on-demand, as a side effect of sending a data packet to that neighbor. If no traffic is sent to a neighbor, no probes are sent either. Note that an entry may technically no longer be in a REACHABLE state, but the condition need not be checked or acted upon until a packet is sent to the neighbor. So let's define the idle period between being REACHABLE and instigating a PROBE as STALE. The new definitions could be: STALE The contents of the neighbor cache entry may be valid, but must be verified upon use. PROBE The neighbor cache entry is undergoing verification of its contents. A possible scenario could be: ie. REACHABLE -> STALE -> PROBE -> (deleted) -> INCOMPLETE A related issue is that ND requires the neighbor cache entry go into PROBE because of various events (such as receipt of neighbor advertisements). Instead, the cache entry should became STALE and only go into PROBE when the next transmission is done. Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 26 16:28:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07787; Tue, 26 Sep 95 16:28:34 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07781; Tue, 26 Sep 95 16:28:25 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id QAA18981; Tue, 26 Sep 1995 16:16:23 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id QAA01164; Tue, 26 Sep 1995 16:15:54 -0700 Date: Tue, 26 Sep 1995 16:15:54 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199509262315.QAA01164@bobo.Eng.Sun.COM> To: matt@lkg.dec.com Subject: (IPng 702) Re: ND neighbor cache states. 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 Your proposal looks good. I think it will simplify the description of NUD. The only thing I wanted to add is that the state should be STALE for at least DELAY_FIRST_PROBE_TIME seconds in order to supress probes when upper layer advise might be coming. The way I understand your proposal the state changes look something like this (please correct me if I am wrong): State Event Action REACHABLE Sending packet and at least State is STALE ReachableTime since the last reachability confirmation. no cache entry Receive unsolicited information Create cache entry (e.g. Neighbor Solicitation) State is STALE STALE Sending packet and at least Send probe DELAY_FIRST_PROBE_TIME since going State is PROBE to STALE state. PROBE Timer fired (every RetransTimer) with Send probe less than MAX_UNICAST_SOLICIT probes sent. PROBE Timer fired (every RetransTimer) with Discard cache entry MAX_UNICAST_SOLICIT probes sent. any state Receive reachability State is REACHABLE confirmation (upper layer advise or Neighbor Advertisement with the Solicited flag set) Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 26 18:23:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08016; Tue, 26 Sep 95 18:23:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08010; Tue, 26 Sep 95 18:23:11 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA18798; Tue, 26 Sep 1995 18:11:10 -0700 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id SAA24328; Tue, 26 Sep 1995 18:11:10 -0700 Subject: (IPng 703) New ND state To: IPng Mailing list Date: Tue, 26 Sep 1995 21:11:33 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9509270211.aa08956@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Although I had no problems understanding the overloaded PROBE state, I can deal with the more specific STALE and PROBE quite easily. One small nit with your chart, though, > PROBE Timer fired (every RetransTimer) with Discard cache entry > MAX_UNICAST_SOLICIT probes sent. Discarding the entry, I assume, will mean subsequent packets will attempt a new-neighbor-discovery cycle, and if it cannot find the neighor, the neighbor will be declared unreachable (which I mark my neighbor entry with RTF_REJECT, as I believe Francis does as well). Thanks! Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 27 10:26:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08445; Wed, 27 Sep 95 10:26:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08439; Wed, 27 Sep 95 10:26:23 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA14672; Wed, 27 Sep 1995 10:14:16 -0700 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id KAA24983; Wed, 27 Sep 1995 10:14:14 -0700 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA01136; Wed, 27 Sep 1995 09:50:20 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA13675; Wed, 27 Sep 1995 12:50:17 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id MAA16704; Wed, 27 Sep 1995 12:52:15 GMT Message-Id: <199509271252.MAA16704@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 704) Re: ND neighbor cache states. In-Reply-To: Your message of "Tue, 26 Sep 1995 16:15:54 MST." <199509262315.QAA01164@bobo.Eng.Sun.COM> X-Mailer: exmh version 1.5omega 10/6/94 Date: Wed, 27 Sep 1995 12:52:13 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In <199509262315.QAA01164@bobo.Eng.Sun.COM> , you wrote: > > Your proposal looks good. I think it will simplify the > description of NUD. Thanks. > The only thing I wanted to add is that the state should be STALE > for at least DELAY_FIRST_PROBE_TIME seconds in order to supress probes > when upper layer advise might be coming. Not quite. You will be in PROBE when waiting for DELAY_FIRST_PROBE_TIME seconds. STALE has no actions associated with it (however it should be noted that if garbage collection of neighbor cache entries needs to be performedm, entries in STALE state should preferred over entries in other states). > The way I understand your proposal the state changes look something > like this (please correct me if I am wrong): Not quite. But close. > State Event Action > REACHABLE Sending packet and at least State is STALE > ReachableTime since the last > reachability confirmation. REACHABLE More than ReachableTime since the State is STALE last reachability confirmation. > no cache entry Receive unsolicited information Create cache entry > (e.g. Neighbor Solicitation) State is STALE Correct. > STALE Sending packet and at least Send probe > DELAY_FIRST_PROBE_TIME since going State is PROBE > to STALE state. STALE Sending packet. State is PROBE start DELAY_FIRST_ PROBE_TIME timer > PROBE Timer fired (every RetransTimer) with Send probe > less than MAX_UNICAST_SOLICIT probes > sent. PROBE Timer fired (either DelayFirstProbe or Send probe RetransTimer) with less than MAX_ UNICAST_SOLICIT+1 probes sent. > > PROBE Timer fired (every RetransTimer) with Discard cache entry > MAX_UNICAST_SOLICIT probes sent. PROBE Timer fired with MAX_UNICAST_SOLICIT Discard cache entry probes sent. > any state Receive reachability State is REACHABLE > confirmation (upper layer > advise or Neighbor Advertisement > with the Solicited flag set) And upper layer advise with no cache entry does not result in a new REACHABLE cache entry. REACHABLE Receive reachability State is REACHABLE or STALE confirmation (upper layer or PROBE advise or Neighbor Advertisement with the Solicited flag set) Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 27 10:56:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08511; Wed, 27 Sep 95 10:56:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08505; Wed, 27 Sep 95 10:56:09 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA19299; Wed, 27 Sep 1995 10:44:06 -0700 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id KAA08573; Wed, 27 Sep 1995 10:43:58 -0700 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA09496; Wed, 27 Sep 1995 10:22:10 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA13982; Wed, 27 Sep 1995 13:22:06 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id NAA16858; Wed, 27 Sep 1995 13:24:05 GMT Message-Id: <199509271324.NAA16858@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: Dan McDonald Cc: IPng Mailing list Subject: (IPng 705) Re: New ND state In-Reply-To: Your message of "Tue, 26 Sep 1995 21:11:33 EST." <9509270211.aa08956@cs.nrl.navy.mil> X-Mailer: exmh version 1.5omega 10/6/94 Date: Wed, 27 Sep 1995 13:24:03 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In <9509270211.aa08956@cs.nrl.navy.mil> , you wrote: > Although I had no problems understanding the overloaded PROBE state, I can > deal with the more specific STALE and PROBE quite easily. > > One small nit with your chart, though, > > > PROBE Timer fired (every RetransTimer) with Discard cache entry > > MAX_UNICAST_SOLICIT probes sent. > > Discarding the entry, I assume, will mean subsequent packets will attempt a > new-neighbor-discovery cycle, and if it cannot find the neighor, the > neighbor will be declared unreachable (which I mark my neighbor entry with > RTF_REJECT, as I believe Francis does as well). But ND does not have an unreachable state. At the time when you would discard an INCOMPLETE entry, you send back ICMP errors. Then another discovery would take place. However, in my implementation I (as well) added yet another state called REJECTING which immediately return errors to the user (and would cause ICMP errors to be returned for forwarded packets). REJECTING lasts for 3 seconds (ie. the same length of time as a unsuccessful discovery). Maybe I've read to many ISO specs, but I really like to have state tables or diagram over descriptive verbage. So here is (thanks to Dan Harrington who initially typed it in) is the state table that corresponds to our implementation of Neighbor Discovery: \State No Event\ | Reject | Incomp | Reach | Stale | Probe # Entry # ++++++==================================================+ Tx Pkt | [1] | [2] | | Probe | #Incomp[2]# +--------+--------+-------+-------+--------#-------# Rx Solicit| Stale | Stale | Reach*| Stale | Stale # Reach # +--------+--------+-------+-------+--------#-------# Rx SolAdv | Reach | Reach | [3] | [3] | Reach # [3] # +--------+--------+-------+-------+--------#-------# Rx Adv | Stale | Stale | Stale&| Stale&| Stale& # # +--------+--------+-------+-------+--------#-------# Pos Ack | | | Reach*| Reach | Reach # # +--------+--------+-------+-------+--------#-------# Timeout |No Entry| Reject | Stale | [4] |No Entry# # +==================================================+ Notes: [1] - EHOSTUNREACH (or ICMP error) returned to user [2] - Queue packet for transmission [3] - Should not happen (ignore) [4] - Available for garbage collection * - This is a refresh to the original timer value & - Don't update datalink address if secondary advertisement Events: Tx Pkt: Transmission of an "upper" layer packet. Rx Solicit: Reception of Neighbor Solicitation (multicast). [Rx of unicast solicit has no effect on state, though it will cause a Adv to be sent.] Rx SolAdv: Reception of Neighbor Advertisement. Rx Adv: Reception of unsolicited Neighbor Advertisement. Pos Ack: Update holding time based on "upper" layer hint. Timeout: One of various timers expired. States: Reject: No response to multicast Soliciations Incomp: Multicasting Solicitations for neighbor's address Reach: Valid entry Stale: Questionable entry (Inactive) Probe: Confirming validity of entry No Entry: Without form, and void... I certainly wouldn't mind if the above (or a modified version of it) made it into the Neighbor Discovery draft. Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 27 17:37:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08956; Wed, 27 Sep 95 17:37:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08950; Wed, 27 Sep 95 17:37:25 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA10783; Wed, 27 Sep 1995 17:25:23 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id RAA11871; Wed, 27 Sep 1995 17:25:23 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id RAA06691; Wed, 27 Sep 1995 17:25:01 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Sep 1995 17:28:16 -0700 To: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 706) IPng and AddrConf Interm Meeting Location and Travel Info Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Interim Meeting Location and Travel Directions ---------------------------------------------- October 11 & 12, 1995 The meeting will be co-hosted by Dyncorp and ISI, at Dyncorp in Arlington, VA, close to Washington DC. Dyncorp is located at 4001 North Fairfax Drive in Arlington. The local host POC is Scott Behnke, Dyncorp, 703-522-6410. Dyncorp is walking distance from the Orange Line Metro, Ballston stop, as are two recommended hotels (also see map below): Arlington Renaissance, 703-528-6000 Holiday Inn, Arlington at Ballston, 703-243-9800 Other hotels that are nearby: Comfort Inn--Ballston, Glebe Road+Rte 66, 703-247-3399 (short drive) Marriott Key Bridge Hotel, 1401 Lee Hwy, 703-524-6400 (convenient to the Orange Line, Rosslyn stop) Many hotels in downtown DC are also fine for metroing. Metro from Washington National Airport: Take the Blue Line towards Addison Road, change to the Orange Line at Rosslyn, on the same track, taking a train that will be marked Vienna. Get off at Ballston station. Driving from Washington National Airport: Don't. Try to avoid having a car if you're going to have to get here from places other than Dulles, as area traffic is unpleasant, while the Metro is very convenient and safe. Driving from Dulles Airport: Take 267 Dulles Airport Road towards DC. It turns into Rte 66 East. Take Exit 71, Fairfax Rd/Glebe Rd. You will be driving on N. Fairfax, and Dyncorp will be on the left, the metro and the two hotels on the right. The hotels both have parking. Alternatively from Dulles: cab fare Dulles-Arlington is on the order of $35. Immediate Neighborhood Metro and Hotels Map ------------------ | Renaissance Hotel | | | | | ISI-East | ------------------ | | | | | _________ | | | | 4350 N. | |BALLSTON| | | | | Fairfax | | METRO | | | | | | _________________________| |___________| |____________| --> To Holiday N. FAIRFAX DRIVE Inn (1/2 <--- 1/2 block block) to Dyncorp 4001 N. Fairfax ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com