From owner-ipng Fri Nov 3 10:56:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03492; Fri, 3 Nov 95 10:56:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03486; Fri, 3 Nov 95 10:56:19 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05681; Fri, 3 Nov 1995 10:43:14 -0800 Received: from nemesis.ics.forth.gr by mercury.Sun.COM (Sun.COM) id KAA04256; Fri, 3 Nov 1995 10:42:07 -0800 Received: from admete.csi.forth.gr by nemesis.ics.forth.gr (ICS mailhost); on Fri, 3 Nov 1995 20:38:27 +0200 (EET DST); with id AA01307 Date: Fri, 3 Nov 1995 20:38:27 +0200 From: Vidalis Antonis Received: by admete.csi.forth.gr (4.1/SMI-4.1) id AA21212; Fri, 3 Nov 95 20:38:22 +0200 Message-Id: <9511031838.AA21212@admete.csi.forth.gr> Organization: Institute of Computer Science, Foundation for Research and Technology-Hellas (FORTH) Science and Technology Park of Crete Vassilika Vouton, P.O.Box 1385 GR 711 10 Heraklion, Crete, Greece tel.: +30 (81) 39 16 00, fax: +30 (81) 39 16 01 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 780) IPv6 Quality-of-Service Capabilities Cc: vidalis@ics.forth.gr Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi to everyone (i am new to the list, so please excuse my ignorance) I am particularly interested to the IPv6 QoS capabilities. What exactly will be the treatment to the packets carrying real-time data? What is the functionality of the Flow Label? Is there any other way to identify the various packet flows through a router ? Will be needed another reservation protocol (RSVP) ? I would be very grateful if you could inform me on that or propose relevant papers or other resources .. Thanks in advance, Antonis Vidalis ICS-FORTH, Crete, Greece ------------------------------------------------------------------------------ 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 Nov 3 11:31:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03527; Fri, 3 Nov 95 11:31:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03521; Fri, 3 Nov 95 11:31:19 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12171; Fri, 3 Nov 1995 11:18:23 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id LAA17140; Fri, 3 Nov 1995 11:18:22 -0800 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA09586; Fri, 3 Nov 95 14:17:15 EST Received: from maggie.engeast by BayNetworks.com (4.1/SMI-4.1) id AA06902; Fri, 3 Nov 95 14:18:10 EST Date: Fri, 3 Nov 95 14:18:10 EST From: jkrawczy@BayNetworks.com (John Krawczyk) Message-Id: <9511031918.AA06902@BayNetworks.com> Received: by maggie.engeast (4.1/SMI-4.1) id AA16619; Fri, 3 Nov 95 14:18:35 EST To: Vidalis Antonis Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 781) Re: IPv6 Quality-of-Service Capabilities In-Reply-To: <9511031838.AA21212@admete.csi.forth.gr> References: <9511031838.AA21212@admete.csi.forth.gr> Reply-To: jkrawczy@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk On Fri, 3 November, Vidalis Antonis (vidalis@ics.forth.gr) wrote: I am particularly interested to the IPv6 QoS capabilities. What exactly will be the treatment to the packets carrying real-time data? What is the functionality of the Flow Label? Is there any other way to identify the various packet flows through a router ? Will be needed another reservation protocol (RSVP) ? I can give you a quick summary of IPv6 hooks in the current RSVP draft: RSVP messages are comprised of variable-length OBJECTs. Each object is identified by a Class-Num (object class) and a C-type (object type, unique within Class-Num). The C-type is used currently to differentiate between the objects used for v4 and v6. For the most part, this just means that one version of the object has four bytes for addresses and the other has 16 bytes. The one exception is the FILTER_SPEC object. There are two different C-types for IPv6. One lets you filter on the source IPv6 address and the TCP/UDP source port number. The other lets you filter on the source address and the 24-bit flow label. Check out the RSVP draft for more details. -jj ------------------------------------------------------------------------------ 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 Nov 3 11:37:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03559; Fri, 3 Nov 95 11:37:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03553; Fri, 3 Nov 95 11:37:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13490; Fri, 3 Nov 1995 11:24:46 -0800 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id LAA19434; Fri, 3 Nov 1995 11:24:44 -0800 Received: by cs.nrl.navy.mil id aa26077; 3 Nov 95 14:19 EST Subject: (IPng 782) An approach to multihoming To: IPng Mailing list , ipv6imp@munnari.oz.au Date: Fri, 3 Nov 1995 14:14:20 -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: <9511031414.aa26054@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk This note is about our recent experience with multihoming, and how our implementation deals with it. It is not a complete answer yet, but it takes a step toward answering how to deal with multihoming, and reduces the multihoming problem to source address selection. This may not even be the best way to do it, but it is a way that has worked so far for us. Q: What if I don't have a default router, and no "on-link masks", and I want to send an IPv6 datagram? What we did was, where in BSD's IPv4 a "ENETUNREACH" or "Network is unreachable" would be returned, we did the following: AT SOURCE ADDRESS DETERMINATION TIME (in6_pcbconnect(), ipv6_output(), or other places...) - Send multicast neighbor solicits out ALL _physical_ interfaces that have IPv6 configured. (This means a link-local address is verified unique on the physical link.) - The first unicast advertisement with the "solicited bit" on and the "secondary bit" off wins, and now I can fill my neighbor cache accordingly, and can arguably pick a source address that belongs to that interface. - If no advertisements show up, AFTER THE SOURCE ADDRESS HAS BEEN DETERMINED - Fill in source address of datagram, run checksums (if applicable) and send out to destination. As far as I can tell, that's the only case where multihoming really causes additional problems versus non-multihoming. As for multicasting, an interface HAS to be chosen, for reasons that Steve Deering can explain a lot better than I can (tree construction?). If I have a default router, I'll use that for packets I don't know that are globally routable. For link-locals, I can use the above algorithm. The above algorithm works on single-homed machine correctly, but can be optimized for single-homed machines such that the source address selection is the only problem. The above method (spray solicits out all interfaces) was taken from Bill's version of the discovery draft. It is rather effective, from what I've tested. I'd appreciate any comments, especially of the form, "But what about this case..." I _think_ I've covered enough where multihoming reduces to source address determination, and following the "conceptual sending algorithm" in the Nordmark/Narten discovery draft. Now, as for the issue of good source address selection.... :) :) :) 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 Fri Nov 3 13:07:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03660; Fri, 3 Nov 95 13:07:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03654; Fri, 3 Nov 95 13:07:19 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27500; Fri, 3 Nov 1995 12:54:26 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id MAA16649; Fri, 3 Nov 1995 12:54:26 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa17596; 3 Nov 95 11:49 EST To: IETF-Announce:;@mercury Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 783) Document Action Withdrawn: SIPP/SIP documents to Historic From: The IESG Date: Fri, 03 Nov 95 11:49:56 -0500 Message-Id: <9511031149.aa17596@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The IESG has reconsidered its decision, and has decided to withdraw the recommendation that these Internet-Drafts be published as Historic RFCs. The WG chairs have been asked to provide a list of documents that should be preserved as RFCs. ------- Forwarded Message To: IETF-Announce Subject: Document Action: SIPP/SIP documents to Historic Date: Mon, 16 Oct 95 19:06:42 -0400 The IESG recommends that the following nine Internet-Drafts be published by the RFC Editor as Historic documents: 1. IPv6 Security Architecture 2. Simple Internet Protocol Plus (SIPP) Specification (128-bit address version) 3. DNS Extensions to support Simple Internet Protocol Plus (SIPP) 4. The SIPP Interoperability and Transition Mechanism 5 ICMP and IGMP for the Simple Internet Protocol Plus (SIPP) 6. Simple Internet Protocol Plus (SIPP): DHCP Options and BOOTP Vendor Extensions 7. Simple Internet Protocol Plus (SIPP): Addressing Architecture 8. Simple Internet Protocol Plus (SIPP): Unicast Hierarchical Address Assignment 9. OSPF for SIPP These documents are currently under the auspices of the IPNGWG Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. ------------------------------------------------------------------------------ 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 Nov 3 14:07:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03723; Fri, 3 Nov 95 14:07:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03717; Fri, 3 Nov 95 14:07:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06068; Fri, 3 Nov 1995 13:54:07 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id NAA04095; Fri, 3 Nov 1995 13:54:04 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HX7N8NWRSW003HP3@FNAL.FNAL.GOV>; Fri, 03 Nov 1995 15:53:50 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA09110; Fri, 3 Nov 95 15:52:25 CST Date: Fri, 03 Nov 1995 15:52:24 -0600 From: Matt Crawford Subject: (IPng 784) Re: draft-ietf-ipngwg-ethernet-ntwrks-01.txt To: deering@parc.xerox.com, rcallon@baynetworks.com, hinden@ipsilon.com Cc: ipng@sunroof.Eng.Sun.COM Message-Id: <9511032152.AA09110@munin.fnal.gov> Mime-Version: 1.0 Content-Type: application/pgp; format=mime; x-action=signclear; x-originator=566F63C5 Content-Transfer-Encoding: 7bit X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ If a Router Advertisement is received with an MTU option > specifying an MTU larger than 1500, or larger than a manually > configured value less than 1500, that MTU option must be ignored. But I think that's already clear. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMJqPFQAO9YJWb2PFAQG4NwMAvswLY8U/Y4rByjQhN35pBl3kSH84PUcP VzdeavQLWC2DNidmX31LRPX+8HoI75iBynLlWgYG5YzfGOJc9FBWwSnzbpF1vK0l U2YCcxDKv/rXYHNsjvFbrx6j2M4rPi0c =LzX2 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ 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 Nov 6 02:10:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04495; Mon, 6 Nov 95 02:10:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04489; Mon, 6 Nov 95 02:10:34 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25797; Mon, 6 Nov 1995 01:57:36 -0800 Received: from nemesis.ics.forth.gr by mercury.Sun.COM (Sun.COM) id BAA07145; Mon, 6 Nov 1995 01:57:24 -0800 Received: from goose.csi.forth.gr by nemesis.ics.forth.gr (ICS mailhost); on Mon, 6 Nov 1995 11:52:59 +0200 (EET DST); with id AA11982 Date: Mon, 6 Nov 1995 11:52:59 +0200 From: Vidalis Antonis Received: by goose.csi.forth.gr (4.1/SMI-4.1) id AA21647; Mon, 6 Nov 95 11:47:02 +0200 Message-Id: <9511060947.AA21647@goose.csi.forth.gr> Organization: Institute of Computer Science, Foundation for Research and Technology-Hellas (FORTH) Science and Technology Park of Crete Vassilika Vouton, P.O.Box 1385 GR 711 10 Heraklion, Crete, Greece tel.: +30 (81) 39 16 00, fax: +30 (81) 39 16 01 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 785) IPng multicast addresses Cc: vidalis@ics.forth.gr Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I'm reading the IPv6 specifications and Comer's "Internetworking wth TCP/IP", to understand multicasting with IPv6, but it is not clear. Comer wrote: > the designers pre-define multicast adresses that correspond to IPv4's network and >subnet broadcast addresses. Thus in addition to its own unicast address, each host is >required to accept packets addressed to the All Nodes multicast group and to the >All Hosts multicast group for its local environment; an All Routers address also exists. First question: If a host accepts packets destined to All Hosts then it will accept packets not destined for itself. Who will it distinguish among them? Second question: Which address is the "All Nodes multicast group" address and which address is the "All Hosts multicast group" address ? Third question: Will multicasting be handled by higher layer protocols? I would be grateful if i had an answer. Thanks. Antonis Vidalis, CSI-FORTH ------------------------------------------------------------------------------ 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 Nov 6 07:05:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04602; Mon, 6 Nov 95 07:05:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04596; Mon, 6 Nov 95 07:05:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07057; Mon, 6 Nov 1995 06:52:09 -0800 Received: from sics.se by mercury.Sun.COM (Sun.COM) id GAA03401; Mon, 6 Nov 1995 06:52:11 -0800 Received: from peter.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA03747; Mon, 6 Nov 95 15:41:55 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 6 Nov 1995 15:41:47 +0100 To: Dan McDonald , IPng Mailing list , ipv6imp@munnari.oz.au From: peter@sics.se (Peter Sjodin) Subject: (IPng 786) Re: An approach to multihoming Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk At 20.14 95-11-03, Dan McDonald wrote: >This note is about our recent experience with multihoming, and how our >implementation deals with it. It is not a complete answer yet, but it takes >a step toward answering how to deal with multihoming, and reduces the >multihoming problem to source address selection. This may not even be the >best way to do it, but it is a way that has worked so far for us. > >Q: What if I don't have a default router, and no "on-link masks", and I > want to send an IPv6 datagram? > >What we did was, where in BSD's IPv4 a "ENETUNREACH" or "Network is >unreachable" would be returned, we did the following: > > AT SOURCE ADDRESS DETERMINATION TIME > (in6_pcbconnect(), ipv6_output(), or other places...) > - Send multicast neighbor solicits out ALL _physical_ interfaces that > have IPv6 configured. (This means a link-local address is > verified unique on the physical link.) This would work for global addresses, but not for link-local addresses. A link-local address is unique (and valid) only on its link, so there could be different nodes on different links with the same link-local address. However, I'm not sure how you can get into a situation where you want to send to a link-local address without knowing to which link it belongs. If DNS gives you a link-local address, for instance, it should also indicate in some way to which link the address belongs, I think. What we did in our implementation in order to support link-local addresses on multi-homed hosts was just to make sure that a node creates a neighbor cache entry whenever it discovers a neighbor node (typically by receving an ND packet), and stores a pointer to the corresponding interface in the cache entry. This made it possible to implement address autoconfiguration and router discovery on multi-homed nodes. > - The first unicast advertisement with the "solicited bit" on and > the "secondary bit" off wins, and now I can fill my neighbor > cache accordingly, and can arguably pick a source address that > belongs to that interface. > - If no advertisements show up, > > AFTER THE SOURCE ADDRESS HAS BEEN DETERMINED > > - Fill in source address of datagram, run checksums (if applicable) > and send out to destination. > >As far as I can tell, that's the only case where multihoming really causes >additional problems versus non-multihoming. As for multicasting, an >interface HAS to be chosen, for reasons that Steve Deering can explain a lot >better than I can (tree construction?). If I have a default router, I'll >use that for packets I don't know that are globally routable. For >link-locals, I can use the above algorithm. > >The above algorithm works on single-homed machine correctly, but can be >optimized for single-homed machines such that the source address selection >is the only problem. > >The above method (spray solicits out all interfaces) was taken from Bill's >version of the discovery draft. It is rather effective, from what I've >tested. I'd appreciate any comments, especially of the form, "But what >about this case..." I _think_ I've covered enough where multihoming >reduces to source address determination, and following the "conceptual >sending algorithm" in the Nordmark/Narten discovery draft. > >Now, as for the issue of good source address selection.... :) :) :) > >Dan Peter ------------------------------------------------------------------------------ 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 Nov 6 07:34:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04636; Mon, 6 Nov 95 07:34:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04630; Mon, 6 Nov 95 07:33:53 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09312; Mon, 6 Nov 1995 07:20:54 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id HAA08191; Mon, 6 Nov 1995 07:20:57 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HXBGDWJKHS004Z75@FNAL.FNAL.GOV>; Mon, 06 Nov 1995 09:20:25 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA24317; Mon, 6 Nov 95 09:18:56 CST Date: Mon, 06 Nov 1995 09:18:56 -0600 From: Matt Crawford Subject: (IPng 787) Re: IPng multicast addresses In-Reply-To: Your message of Mon, 06 Nov 95 11:52:59 +0200. <9511060947.AA21647@goose.csi.forth.gr> To: Vidalis Antonis Cc: ipng@sunroof.Eng.Sun.COM Message-Id: <9511061518.AA24317@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ First question: > If a host accepts packets destined to All Hosts then it will accept > packets not destined for itself. Who will it distinguish among them? A packet addressed to "all hosts" *is* destined for all hosts. (However, it may not require any action by all hosts.) Here is an example: When the receptionist at the dentist's office steps into the waiting room and asks for Mr. Smith, correction functioning of the protocol requires that everyone hears, but only Mr. Smith needs to act. > Second question: > Which address is the "All Nodes multicast group" address and which address > is the "All Hosts multicast group" address ? "All hosts" no longer exists, only "all nodes" and "all routers" (and a few others). > Third question: > Will multicasting be handled by higher layer protocols? I don't quite understand this. Higher level protocols are not responsible for multicast delivery, but may use the multicast service of the IP layer. Multicast packets today are usually UDP. Applications that send and receive multicasts should be written to have decent behavior -- not sending out a lot of packets with a wide scope and large hop limit, for example. _________________________________________________________ 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 Mon Nov 6 08:11:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04752; Mon, 6 Nov 95 08:11:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04746; Mon, 6 Nov 95 08:11:21 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12502; Mon, 6 Nov 1995 07:58:21 -0800 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id HAA15736; Mon, 6 Nov 1995 07:58:24 -0800 Subject: (IPng 788) Re: An approach to multihoming To: Peter Sjodin Date: Mon, 6 Nov 1995 10:57:46 -0500 (EST) From: Dan McDonald Cc: danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM, ipv6imp@munnari.oz.au In-Reply-To: from "Peter Sjodin" at Nov 6, 95 03:41:47 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9511061057.aa02908@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > This would work for global addresses, but not for link-local addresses. A > link-local address is unique (and valid) only on its link, so there could > be different nodes on different links with the same link-local address. You're right. There is a whole can of worms that opens up when a multi-homed node encounters duplicate link-local addresses across different interfaces. > However, I'm not sure how you can get into a situation where you want to > send to a link-local address without knowing to which link it belongs. If > DNS gives you a link-local address, for instance, it should also indicate > in some way to which link the address belongs, I think. Okay, now how does my application indicate what interface to use for this link-local communication? The sockaddr_in6 structure is getting overloaded already, IMHO. Furthermore, how does DNS encode this information? I don't see this case happening very often, if at all. But if it does, there are other things to consider as well. > What we did in our implementation in order to support link-local addresses > on multi-homed hosts was just to make sure that a node creates a neighbor > cache entry whenever it discovers a neighbor node (typically by receving an > ND packet), and stores a pointer to the corresponding interface in the > cache entry. This made it possible to implement address autoconfiguration > and router discovery on multi-homed nodes. Our cache entries have this information too, but again, how does an application which knows nothing about which interface to use for potential link-local communication indicate this? There are some other problems. Consider the TCP connect, which is a 4-tuple of , now suddenly either source-addr or dest-addr can happen over two interfaces. If I have a TCP connection of: and to be really pathological, let's say the address token for "me" is the same across ALL of my interfaces (which if I recall IEEE 802 specifying that the MAC address indicates a MACHINE, not an interface). Now if linkloc-45, port 2112 on another link attempts to send me a TCP SYN, what happens? Does my TCP code now have to not only demux on the aforementioned 4-tuple, but also check for the right interface? I'll concede that having the same MAC address across multiple interfaces on a multi-homed node might not happen very often, but there are other problems. What about a security association? They exist with respect to a destination address. If I have two identical addresses, do I trust them both enough to use the same security association? I'll admit, my solution to the identical link-locals on different interfaces solution is not a nice as Peter's. My solution is first reply (Neighbor adv., ususally) to me wins, until such time as NUD can't find the winning node, when things start all over again. This means communication might not happen between two otherwise connected nodes. Peter, thank you for bringing up this issue. I posted my original note specifically to bring out issues like this one. I appreciate any input on this topic. 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 Mon Nov 6 12:39:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05198; Mon, 6 Nov 95 12:39:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05192; Mon, 6 Nov 95 12:39:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25226; Mon, 6 Nov 1995 12:26:12 -0800 Received: from iol.unh.edu by mercury.Sun.COM (Sun.COM) id MAA03194; Mon, 6 Nov 1995 12:26:13 -0800 Received: by iol.unh.edu (4.1/SMI-4.1) id AA08031; Mon, 6 Nov 95 15:23:00 EST From: qv@iol.unh.edu (Quaizar Vohra) Message-Id: <9511062023.AA08031@iol.unh.edu> Subject: (IPng 789) issues regarding RS To: ipv6imp@munnari.oz.au (ipv6imp) Date: Mon, 6 Nov 1995 15:22:59 -0500 (EST) Cc: ipng@sunroof.Eng.Sun.COM (ipng) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi everyone, I have several questions with regard to the ND spec ( with a testing perspective). They are as follows : 1. In sec 5.2.3 on router behaviour, it says : In case of a router solicitation, a router may choose to unicast or multicast the response. A unicast response may be delayed but the mulicast response should be delayed ( randomly between 0 and MAX_RTR_RESPONSE_DELAY seconds ). Then it says, if a router chooses to delay the response, if more RSs come the reponse should be multicasted otherwise it should be unicasted. This creates confusion whether a router which chooses to unicast and delay the response actually ends up unicasting the response. I think the intent was that a router may choose or choose not to delay the response. If it doesn't it should send a unicast response immideatly. Else, if it chooses to delay, it should send a multicast if more RSs are received otherwise unicast ( or multicast ??? ) the response. 2.Now in continuation to 1, let us examine the following situation : - A router is configured to advertise between MinAdvertiseInterval = 20 sec MaxAdvertiseInterval = 30 sec - The router chooses to delay responses to RSs. - Now let at t = 0 sec, the timer for next RA is set to t = 22 sec ( Randomly between 20 & 30 secs ). - At t = 20 sec, a RS comes in and the router chooses to delay for 5 seconds ( randomly between 0 and MAX_RTR_RESPONSE_DELAY = 6 ). So it should respond at t = 25 sec. - But the timer for next multicast RA, expires at t = 22 sec, should the router wait till t = 25 second ( I hope not ). If the router sends multicast RA at t = 22 sec, should it respond anymore to the RS ( again I hope not ). 3. On page 31 ( sec 5.2.3. still ), ND spec says : In case of a host becoming a router, the system must also join the all routers multicast group on all interfaces on which the router supports IP multicast ( whether or not they are advertising interfaces ). Does the comment in parenthesis mean that the non-advertising interfaces do not do any router advertisements at all, in which case I do not understand why they should join all routers multicast group. Or do you mean that they do not advertise themselves as default. 4.On page 30 ( again sec 5.2.3. last para ), it says : When a router receives a RS, it records that the source of the packet is a neighbor. If the RS contains a source link layer address option, and the router has a neighbor cache entry for the neighbor, the link layer address should be updated in the neighbor cache. If a neighbor cache entry is created for the source, its eachability state must be set to PROBE. What does it mean by updating the cache entry. I think that if the entry exists and the source link layer address in the RS is same as what the neighbor cache holds, I think the entry should not be updated. If they are different then the entry should be updated and the state set to PROBE. Also if the entry is in REACHABLE state and the link layer address it holds is different than what is in the RS, should it be changed to PROBE state ? 5. In section 5.1.1 ( On RS message format ), it says that IP dest. address should be the the all-routers multicast address. While section 5.2.2 ( on Validation of an RS message ) says : IP dest. address should be a link local address or a multicast address with link local scope. Isn't this a deviation from 5.1.1. 6. In section 5.2.2 ( Validation of an RS ) : shouldn't the router check that the hop count on the incoming RS is 1. Apologies, if I am missing something ( I am not an expert on ND ). 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 Mon Nov 6 14:52:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05341; Mon, 6 Nov 95 14:52:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05335; Mon, 6 Nov 95 14:51:45 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18627; Mon, 6 Nov 1995 14:38:45 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id OAA08440; Mon, 6 Nov 1995 14:38:48 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HXBVNZDQZK0055ZR@FNAL.FNAL.GOV>; Mon, 06 Nov 1995 16:38:26 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA28263; Mon, 6 Nov 95 16:36:57 CST Date: Mon, 06 Nov 1995 16:36:57 -0600 From: Matt Crawford Subject: (IPng 790) draft-ietf-ipngwg-fddi-ntwrks-01.txt To: ipng@sunroof.Eng.Sun.COM Message-Id: <9511062236.AA28263@munin.fnal.gov> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=mimeprimaryboundary Content-Description: IPv6-over-Ethernet revision Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk --mimeprimaryboundary Content-Type: text/plain Content-Description: Summary of changes I have revised the IPv6-over-FDDI document to reflect changes similar to those I just made in the IPv6-over-ethernet -01 draft: * Mentioning that MTU may be reduced by manual configuration * More verbosity in describing the link-layer header * Specifying the byte order as well as the bit order in the address token I also fleshed out the method for detection of mixed-media bridges, which was nothing more than a tantalizing hint in the -00 draft. This might possibly be controversial, since it requires the IPv6 module to make use of the FDDI frame code (FC) field on router and neighbor advertisements. Most IPv4 stacks today never touch that field. (Anyone who has spent hours with an FDDI probe knows who some of the exceptions are.) Matt --mimeprimaryboundary Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-ipngwg-fddi-ntwrks-01.txt" Content-Description: draft-ietf-ipngwg-fddi-ntwrks-01.txt Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force Matt Crawford INTERNET-DRAFT Fermilab November 7, 1995 A Method for the Transmission of IPv6 Packets over FDDI Networks Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. Introduction This memo specifies the MTU frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. It also specifies the method of forming IPv6 link-local addresses on FDDI networks and the content of the Source/Target Link-layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on an FDDI network. Maximum Transmission Unit FDDI permits a frame length of 4500 octets (9000 symbols), including at least 22 octets (44 symbols) of Data Link encapsulation when long-format addresses are used. Subtracting 8 octets of LLC/SNAP Crawford Expires May 1996 [Page 1] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over FDDI 7 November 1995 header, this would, in principle, allow the IPv6 packet in the Information field to be up to 4470 octets. However, it is desirable to allow for the variable sizes and possible future extensions to the MAC header and frame status fields. The default MTU size for IPv6 packets on an FDDI network is therefore 4352 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of a smaller value on each node. If a Router Advertisement is received with an MTU option specifying an MTU larger than the default or the manually configured value, that MTU option may be logged to system or network management but must be otherwise ignored. Frame Format FDDI provides both synchronous and asynchronous transmission, with the latter class further subdivided by the use of restricted and unrestricted tokens. Only asynchronous transmission with unrestricted tokens is required for FDDI interoperability. Accordingly, IPv6 packets shall be sent in asynchronous frames using unrestricted tokens. The robustness principle dictates that nodes should be able to receive synchronous frames and asynchronous frames sent using restricted tokens. IPv6 packets are transmitted in LLC/SNAP frames, using long-format (48 bit) addresses. The data field contains the IPv6 header and payload and is followed by the FDDI Frame Check Sequence, Ending Delimiter, and Frame Status symbols. +-------+ ^ | FC | | +-------+-------+-------+-------+-------+-------+ | | Destination FDDI address | | +-------+-------+-------+-------+-------+-------+ FDDI | Source FDDI address | header +-------+-------+-------+-------+-------+-------+ | | DSAP | SSAP | CTL | OUI | | +-------+-------+-------+-------+-------+-------+ | | Ethertype | v +-------+-------+-------+-------+-------+------+------+ | IPv6 header and payload ... / +-------+-------+-------+-------+-------+------+------+ Crawford Expires May 1996 [Page 2] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over FDDI 7 November 1995 FDDI Header Fields: FC The Frame Code shall be in the range 50 to 57 hexadecimal, inclusive, with the three low order bits indicating the frame priority. Transmission by hosts and routers of frames with priority zero (FC =3D 50 hex) is discouraged in order to= aid implementors who wish to distinguish on-ring nodes from nodes which lie behind bridges. DSAP, SSAP Both the DSAP and SSAP fields shall contain the value AA hexadecimal, indictating SNAP encapsulation. CTL The Control field shall be set to 03 hexadecimal, indicating Unnumbered Information. OUI The Organizationally Unique Identifier shall be set to 000000 hexadecimal. Ethertype The ethernet protocol type ("ethertype") shall be set to the value 86DD hexadecimal. Interaction with Bridges For correct operation when mixed media are bridged together, nodes transmitting IPv6 on FDDI must implement the following simple mechanism for bridge detection. If a node receives a valid Router Advertisement or Neighbor Advertisement on an FDDI interface in a frame with priority zero (FC =3D 50 hexadecimal), the link MTU used by= that node on that interface shall not exceed 1500 octets. The event of detecting a mixed-media bridged network should be logged to system management the first time it occurs after interface initialization, and such logging should include the source IPv6 address of the packet which triggered bridge detection. Nodes transmitting IPv6 on FDDI must provide a configuration option to disable the bridge detection mechanism. This option may be used when the presence of a non-conforming implementation is known. By default, bridge detection must be enabled. It is possible that a medium other than Ethernet may be bridged to FDDI, and that the correct MTU will be neither 1500 nor 4352 octets. In such a case, bridge detection should be disabled and routers should be configured to advertise the correct MTU. The only contemplated use of the LLC priority field of the FC octet is to aid in link MTU determination. It would be sufficient for that purpose to require only that Router Advertisements and Neighbor Crawford Expires May 1996 [Page 3] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over FDDI 7 November 1995 Advertisements sent on FDDI always have non-zero priority. However, it may be simpler or more useful to transmit all IPv6 packets on FDDI with non-zero priority. Stateless Autoconfiguration and Link-Local Addresses The address token [CONF] for an FDDI interface is the interface's built-in 48-bit IEEE 802 address, in canonical bit order and with the octet in the same order in which they would appear in the header of an ethernet frame. (The individual/group bit is in the first octet and the OUI is in the first three octets.) A different MAC address set manually or by software should not be used as the address token. An IPv6 address prefix used for stateless autoconfiguration of an FDDI interface must be 80 bits in length. The IPv6 Link-local address [AARCH] for an FDDI interface is formed by appending the interface's IEEE 802 address to the 80-bit prefix FE80::. +-------+-------+-------+-------+-------+-------+------+------+ | FE 80 00 00 00 00 00 00 | +-------+-------+-------+-------+-------+-------+------+------+ | 00 00 | FDDI Address | +-------+-------+-------+-------+-------+-------+------+------+ Address Mapping -- Unicast The procedure for mapping IPv6 addresses into FDDI link-layer addresses is described in [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is FDDI. +-------+-------+-------+-------+-------+-------+------+------+ | Type |Length | FDDI Address | +-------+-------+-------+-------+-------+-------+------+------+ Option fields: Type 1 for Source Link-layer address. 2 for Target Link-layer address. Crawford Expires May 1996 [Page 4] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over FDDI 7 November 1995 Length 1 (in units of 8 octets). FDDI Address The 48 bit FDDI IEEE 802 address, in canonical bit order. Address Mapping -- Multicast An IPv6 packet with a multicast destination address DST is transmitted to the FDDI multicast address whose first two octets are the value 3333 hexadecimal and whose last four octets are the last four octets of DST, ordered from more to least significant. +-------+-------+-------+-------+-------+-------+ | 33 | 33 | DST13 | DST14 | DST15 | DST16 | +-------+-------+-------+-------+-------+-------+ Security Considerations Security considerations are not addressed in this memo. References [AARCH] R. Hinden, S. Deering, IP Version 6 Addressing Architecture. Currently draft-ietf-ipngwg-addr-arch-03.txt. [CONF] S. Thomson, IPv6 Stateless Address Autoconfiguration. Currently draft-ietf-addrconf-ipv6-auto-05.txt. [DISC] T. Narten, E. Nordmark, W. A. Simpson, Neighbor Discovery for IP Version 6 (IPv6). Currently draft-ietf-ipngwg-discovery-02.txt. [IPV6] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification. Currently draft-ietf-ipngwg-ipv6-spec-02.txt. Crawford Expires May 1996 [Page 5] =0C INTERNET-DRAFT Transmission of IPv6 Packets Over FDDI 7 November 1995 Author's Address Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA Phone: +1 708 840-3461 EMail: crawdad@fnal.gov Crawford Expires May 1996 [Page 6] --mimeprimaryboundary Content-Type: text/plain Content-Description: ascii signature _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A --mimeprimaryboundary-- ------------------------------------------------------------------------------ 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 Nov 6 15:02:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05401; Mon, 6 Nov 95 15:02:43 PST Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05395; Mon, 6 Nov 95 15:02:33 PST Received: from janice.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id OAA08919; Mon, 6 Nov 1995 14:49:17 -0800 Received: by janice.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id OAA22358; Mon, 6 Nov 1995 14:47:39 -0800 Date: Mon, 6 Nov 1995 14:47:39 -0800 From: therbert@jurassic (Tom Herbert) Message-Id: <199511062247.OAA22358@janice.Eng.Sun.COM> To: danmcd@cs.nrl.navy.mil Subject: (IPng 791) Re: An approach to multihoming Cc: ipng@sunroof2.Eng.Sun.COM, ipv6imp@munnari.OZ.AU X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk We've been looking at some of the implemetnation issues of using link local addresses on multihomed hosts for some time so I thought I'd contribute some ideas to this discussion. > > This would work for global addresses, but not for link-local addresses. A > > link-local address is unique (and valid) only on its link, so there could > > be different nodes on different links with the same link-local address. > > You're right. There is a whole can of worms that opens up when a > multi-homed node encounters duplicate link-local addresses across different > interfaces. > IMO link local addresses are only fully qualified given the address and the cooresponding interface of the link. Either the application must specify the link explicitly or the it must be chosen in a deterministic manner-- for example choosing the first interface configured on the system. Spraying the connected links with NS's is a suitable method for finding *any* node with the matching link local address-- ie. this works in the case that the link local address is being used as an "anycast" address. In the case that the packets are being directed to a specific host by an application, spraying may fail because two hosts on different links connected to a multihomed host can have identical link local addresses; the host that the application desires may not be the one selected by spraying. > > However, I'm not sure how you can get into a situation where you want to > > send to a link-local address without knowing to which link it belongs. If > > DNS gives you a link-local address, for instance, it should also indicate > > in some way to which link the address belongs, I think. > > Okay, now how does my application indicate what interface to use for this > link-local communication? > Source routing can be used to accomplish this without changing the the sockaddr_in6 structure. When a packet is sent to a link local address it can be routed through an address of the outgoing interface. > Furthermore, how does DNS encode this information? Good question! > There are some other problems. Consider the TCP connect, which is a 4-tuple > of , now suddenly either > source-addr or dest-addr can happen over two interfaces. If I have a TCP > connection of: > > > > and to be really pathological, let's say the address token for "me" is the > same across ALL of my interfaces (which if I recall IEEE 802 specifying that > the MAC address indicates a MACHINE, not an interface). Now if linkloc-45, > port 2112 on another link attempts to send me a TCP SYN, what happens? > Does my TCP code now have to not only demux on the aforementioned 4-tuple, > but also check for the right interface? I'll concede that having the same > MAC address across multiple interfaces on a multi-homed node might not > happen very often, but there are other problems. > This pathological case is exactly the situation that occurs on Sun machines :-(. The hardware address can be shared across muliple devices and hence the link local address for the cooresponding network interfaces will be identical. This makes the above case a problem and even indicating an interface uniquely by address could be difficult (ie. what address would be used to route out a specific interface). We're looking at two possible solutions to this: 1) Devise a way to either configure unique ethernet addresses on each interface at boot time, or at least configure unique link local addresses across the interfaces. 2) Assign to each network interface a unique "interal" address. This address would be used for within a host and never appear on the network. So, for example, each interface could be assigned a unique internal address and applications could use this address to specify an interface. I haven't considered the case of the TCP tuple in depth, but I suppose that "internal" addresses may be useful also. For each pair that a multihomed host is communicating with, there could be an "internal" address used as an alias to reference the pair. One caveat to this of course, is choosing an "internal" address. It would have to be one which is not usable as a regular v6 address. One possilbilty is to grab a chunk of the IPv6 addresses for "node-local" use. These would indicate addresses which are only used for communication within a node. Tom ------------------------------------------------------------------------------ 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 Nov 6 22:10:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00524; Mon, 6 Nov 95 22:10:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00518; Mon, 6 Nov 95 22:09:58 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07271; Mon, 6 Nov 1995 21:56:58 -0800 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id VAA20438; Mon, 6 Nov 1995 21:57:01 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA09150; Mon, 6 Nov 1995 21:05:24 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31313; Tue, 7 Nov 1995 00:05:23 -0500 Message-Id: <9511070505.AA31313@wasted.zk3.dec.com> To: Tom.Herbert@Eng (Tom Herbert) Cc: danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM, ipv6imp@munnari.OZ.AU Subject: (IPng 792) Re: An approach to multihoming In-Reply-To: Your message of "Mon, 06 Nov 95 14:47:39 PST." <199511062247.OAA22358@janice.Eng.Sun.COM> Date: Tue, 07 Nov 95 00:05:22 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk First I think Dan's approach of spraying all interfaces is a logical approach and then Peter S. point of keeping a pointer of the interface in the cache is probably what will need to be done unless we add something to DNS. Which I will discuss at the end of my response. >1) Devise a way to either configure unique ethernet addresses on each interface >at boot time, or at least configure unique link local addresses across the >interfaces. I think this should be a requirement? But it does not for sure make non duplicates go away. But at least DAD can detect them in addrconf. But I do think this should be the norm. Would we need to add this to addrconf or ND? I am not sure yet. What do others think? >2) Assign to each network interface a unique "interal" address. This address >would be used for within a host and never appear on the network. So, >for example, each interface could be assigned a unique internal address and >applications could use this address to specify an interface. But if we do #1 above is this still necessary. Its all there in if_addr struct once we agree that each interface will have a unique interface? >I haven't considered the case of the TCP tuple in depth, but I suppose that >"internal" addresses may be useful also. For each >pair that a multihomed host is communicating with, there could be an "internal" >address used as an alias to reference the pair. I think at least a 2-tuple approach is the only one that seems feasible. Another would be to hash the addresses to interfaces and then do a check on the hash scheme so the buckets (interfaces) would always line up with the correct addr-to-interface relationship. But I think a 2-tuple will be more efficient. >One caveat to this of course, is choosing an "internal" address. It would >have to be one which is not usable as a regular v6 address. One possilbilty is >to grab a chunk of the IPv6 addresses for "node-local" use. These would >indicate addresses which are only used for communication within a node. I definitely like the idea of internal addresses for reasons other than multihoming (that are real bonified Internet addresses) but I am not sure as I said before #1 above does not solve the problem. DNS: One thing we could do is create an IP6.INF record. It would work logicially like IP6.INT domain record (PTR). For each address it would have a corresponding interface-ID record that could be returned when addr2hostname or hostname2addr was called in the array of records. The IP6.INF would be the last record of a set returned for that interface. The resolver could turn this on and off as an option. When IP6.INF ON the server would do above. This way the application would be able to transmit the interface to the socket layer and then to the transport modules. Or set an option TCP or UDP. Tom suggested I think we can use the source route in the v6 API spec. But if this were to be a very common usage I think we may want to explore alternatives. Note this defaults to what Peter suggested especially for TCP that we need to keep the 2-tuple binding in the transport layer tables (not saying PCB because I ran into a system that uses someting other than PCBs). Comments? (sue thomson / paul vixie / christian huitema ???) /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 Tue Nov 7 07:10:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00770; Tue, 7 Nov 95 07:10:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00764; Tue, 7 Nov 95 07:10:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06021; Tue, 7 Nov 1995 06:57:05 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id GAA15483; Tue, 7 Nov 1995 06:57:08 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10372; 7 Nov 95 9:33 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 793) I-D ACTION:draft-ietf-ipngwg-fddi-ntwrks-01.txt Date: Tue, 07 Nov 95 09:33:08 -0500 Message-Id: <9511070933.aa10372@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 : A Method for the Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-fddi-ntwrks-01.txt Pages : 6 Date : 11/06/1995 This memo specifies the MTU frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. It also specifies the method of forming IPv6 link-local addresses on FDDI networks and the content of the Source/Target Link-layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on an FDDI network. 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-fddi-ntwrks-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951106172719.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-fddi-ntwrks-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951106172719.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 Nov 7 07:36:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00788; Tue, 7 Nov 95 07:36:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00782; Tue, 7 Nov 95 07:35:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08224; Tue, 7 Nov 1995 07:22:55 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id HAA21888; Tue, 7 Nov 1995 07:22:57 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HXCUQVF2Z4005QO2@FNAL.FNAL.GOV>; Tue, 07 Nov 1995 09:22:31 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA02154; Tue, 7 Nov 95 09:21:05 CST Date: Tue, 07 Nov 1995 09:21:05 -0600 From: Matt Crawford Subject: (IPng 794) Re: [IPv6Imp] Re: An approach to multihoming In-Reply-To: Your message of Tue, 07 Nov 95 00:05:22 EST. <9511070505.AA31313@wasted.zk3.dec.com> To: ipv6imp@munnari.OZ.AU Cc: Tom.Herbert@Eng (Tom Herbert), danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM, bound@zk3.dec.com Message-Id: <9511071521.AA02154@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{> 1) Devise a way to either configure unique ethernet addresses on each >> interface at boot time, or at least configure unique link local >> addresses across the interfaces. Does the text on address tokens from the IPv6-over-ethernet document help resolve this? I draw your attention to the first and last sentences of this paragraph. The address token [CONF] for an Ethernet interface is the interface's built-in 48-bit IEEE 802 address, in canonical bit order and with the octets in the same order in which they would appear in the header of an ethernet frame. (The individual/group bit is in the first octet and the OUI is in the first three octets.) A different MAC address set manually or by software should not be used as the address token. Suns were mentioned as an example. Suns have a 48 bit address on each ethernet/fddi/token ring interface, which they override with an address from the ID PROM. A method is provided for undoing that substitution. Would the above text be construed as mandating use of the interface's token rather than the ID PROM's? _________________________________________________________ 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 Nov 7 10:10:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00971; Tue, 7 Nov 95 10:10:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00965; Tue, 7 Nov 95 10:09:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24450; Tue, 7 Nov 1995 09:56:54 -0800 Received: from sics.se by mercury.Sun.COM (Sun.COM) id JAA27597; Tue, 7 Nov 1995 09:56:56 -0800 Received: from sics1.electrum.kth.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA06997; Tue, 7 Nov 95 18:54:11 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 7 Nov 1995 18:53:45 +0100 To: bound@zk3.dec.com, Tom.Herbert@Eng (Tom Herbert) From: peter@sics.se (Peter Sjodin) Subject: (IPng 795) Re: [IPv6Imp] Re: An approach to multihoming Cc: danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM, ipv6imp@munnari.OZ.AU Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk At 06.05 95-11-07, bound@zk3.dec.com wrote: >First I think Dan's approach of spraying all interfaces is a logical >approach and then Peter S. point of keeping a pointer of the interface >in the cache is probably what will need to be done unless we add >something to DNS. Which I will discuss at the end of my response. I think an important question is how and when we want to use link-local addresses. The idea behind the scheme of keeping an interface pointer in the neighbor cache is that it allows nodes to dynamically learn addresses of its neighbors, and that this would be useful for plug-and-play configurations. For example, a node that needs some network service could multicast a solicitation for the service. The server, if there is one, sends back a response, and the node creates a neighbor cache entry for the server. Applications on the node can then send packets to the server, without having to worry about on which link it is. >[...] > >DNS: > >One thing we could do is create an IP6.INF record. It would work >logicially like IP6.INT domain record (PTR). For each address it would >have a corresponding interface-ID record that could be returned when >addr2hostname or hostname2addr was called in the array of records. The >IP6.INF would be the last record of a set returned for that interface. >The resolver could turn this on and off as an option. When IP6.INF ON >the server would do above. This way the application would be able to >transmit the interface to the socket layer and then to the transport >modules. Or set an option TCP or UDP. Tom suggested I think we can use >the source route in the v6 API spec. But if this were to be a very >common usage I think we may want to explore alternatives. Note this >defaults to what Peter suggested especially for TCP that we need to keep >the 2-tuple binding in the transport layer tables (not saying PCB >because I ran into a system that uses someting other than PCBs). Yes, this would make it possible to use link-local addresses with DNS. But then we are developing an addressing scheme for link-local addresses, in order to extend the scope of link-local addresses beyond individual links. We also need to allocate and configure interface ID:s in some way, and I'm not sure we are gaining anything this way. We could use site-local or global addresses instead. I am tempted to take the easy way out here, and claim that we should limit the usage of link-local addresses to autoconfiguration, discovery and such things. >Comments? (sue thomson / paul vixie / christian huitema ???) > >/jim Peter ------------------------------------------------------------------------------ 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 Nov 7 11:51:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01054; Tue, 7 Nov 95 11:51:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01048; Tue, 7 Nov 95 11:51:22 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08314; Tue, 7 Nov 1995 11:38:21 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id LAA29442; Tue, 7 Nov 1995 11:38:24 -0800 Received: from pobox.BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA06252; Tue, 7 Nov 95 14:37:09 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA07211; Tue, 7 Nov 95 14:37:57 EST Date: Tue, 7 Nov 95 14:37:57 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9511071937.AA07211@pobox.BayNetworks.com> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 796) Re: [IPv6Imp] Re: An approach to multihoming Cc: ipv6imp@munnari.OZ.AU Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, Not that I have any experience with link-local addresses and multihoming but it seems that it would be helpful if link local addresses were unique across all interfaces. Wouldn't it possible to achieve such an uniqueness by requiring that the interface's logical number is included into the link-local addresses structure? I assume that any box can uniquely number its interfaces. Regards, Dimitry ------------------------------------------------------------------------------ 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 Nov 7 13:43:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01141; Tue, 7 Nov 95 13:43:25 PST Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01135; Tue, 7 Nov 95 13:43:16 PST Received: from janice.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id NAA00358; Tue, 7 Nov 1995 13:30:09 -0800 Received: by janice.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id NAA23973; Tue, 7 Nov 1995 13:28:32 -0800 Date: Tue, 7 Nov 1995 13:28:32 -0800 From: therbert@jurassic (Tom Herbert) Message-Id: <199511072128.NAA23973@janice.Eng.Sun.COM> To: bound@zk3.dec.com, Tom.Herbert@Eng, peter@sics.se Subject: (IPng 797) Re: [IPv6Imp] Re: An approach to multihoming Cc: danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM, ipv6imp@munnari.OZ.AU X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I think an important question is how and when we want to use link-local > addresses. The idea behind the scheme of keeping an interface pointer in > the neighbor cache is that it allows nodes to dynamically learn addresses > of its neighbors, and that this would be useful for plug-and-play > configurations. For example, a node that needs some network service could > multicast a solicitation for the service. The server, if there is one, > sends back a response, and the node creates a neighbor cache entry for the > server. Applications on the node can then send packets to the server, > without having to worry about on which link it is. > Yes, I agree that link local addresses are of limited usefulness. But this doesn't address the real difficulty in dealing with link local addresses: the fact that link local addresses don't have to be globally unique. This allows the possiblity, however slight, that two hosts with identical addresses can exist on two links of a multihomed host. Given that, they have to be dealt with for: 1) correctness: packets need to go where an applications intends them to go and 2) security: hosts can't be allowed to masquerade themselves as being a host on the other side of a multihomed server. I think spraying or storing an interface pointer in a neighbor cache as described is insufficient to deal with the problem. Consider the case of a server (router discovery server for example) running on a multihomed hosts and suppose there are two hosts A1 and A2 on two connected links with identical link local addresses (A). Requests are made to B with the link local address of the host as the source. A1 -- B -- A2 Now if host A1 makes a request to the server B, the server can respond and will put the client host (A1) into it's neighbor cache. If host A2 on the other link makes a request how does the server know to direct its response to A2? If the server does a lookup in the neighbor cache it will find the first host which is A1, so the response goes to the wrong place. Not only incorrect, but probably a security hole. I think the clearest solution is for B to have two cache entries, one for A1 and A2, each containing the address and cooresponding interface. When the server application needs to send a packet to one of them, it must somehow (source routing is one option) specify an outgoing interface. > Yes, this would make it possible to use link-local addresses with DNS. But > then we are developing an addressing scheme for link-local addresses, in > order to extend the scope of link-local addresses beyond individual links. > We also need to allocate and configure interface ID:s in some way, and I'm > not sure we are gaining anything this way. We could use site-local or > global addresses instead. > I agree. Attempting to assign interface ID's across an network is almost equivalent to assigning prefixes to the links, so why not use a site local or global address in the DNS? "any cast" link local addresses (if such a thing exists!) would be an obvious exception. Tom ------------------------------------------------------------------------------ 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 Nov 7 17:57:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01350; Tue, 7 Nov 95 17:57:39 PST Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01344; Tue, 7 Nov 95 17:57:29 PST Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id RAA16113; Tue, 7 Nov 1995 17:44:28 -0800 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id RAA10822; Tue, 7 Nov 1995 17:44:00 -0800 Date: Tue, 7 Nov 1995 17:44:00 -0800 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199511080144.RAA10822@bobo.Eng.Sun.COM> To: qv@iol.unh.edu Subject: (IPng 798) Re: issues regarding RS Cc: ipv6imp@munnari.oz.au, 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 > I have several questions with regard to the ND spec ( with a testing > perspective). > They are as follows : > 1. In sec 5.2.3 on router behaviour, it says : > > In case of a router solicitation, a router may choose to unicast > or multicast the response. A unicast response may be delayed but > the mulicast response should be delayed ( randomly between 0 and > MAX_RTR_RESPONSE_DELAY seconds ). Then it says, if a router chooses > to delay the response, if more RSs come the reponse should be > multicasted otherwise it should be unicasted. > > This creates confusion whether a router which chooses to unicast and delay > the response actually ends up unicasting the response. > I think the intent was that a router may choose or choose not to delay the > response. If it doesn't it should send a unicast response immideatly. Else, > if it chooses to delay, it should send a multicast if more RSs are received > otherwise unicast ( or multicast ??? ) the response. The above text gives the router the option to choose multicasting or unicasting a response. As a result of the interrim meeting (See message with subject (IPng 763) IPng/AddrConf Interm Meeting Notes.) we will change it to always multicast the response to a router solicitation. > 2.Now in continuation to 1, let us examine the following situation : > - A router is configured to advertise between > MinAdvertiseInterval = 20 sec > MaxAdvertiseInterval = 30 sec > - The router chooses to delay responses to RSs. > - Now let at t = 0 sec, the timer for next RA is set to t = 22 sec > ( Randomly between 20 & 30 secs ). > - At t = 20 sec, a RS comes in and the router chooses to delay for > 5 seconds ( randomly between 0 and MAX_RTR_RESPONSE_DELAY = 6 ). > So it should respond at t = 25 sec. > - But the timer for next multicast RA, expires at t = 22 sec, > should the router wait till t = 25 second ( I hope not ). > If the router sends multicast RA at t = 22 sec, should it > respond anymore to the RS ( again I hope not ). The current spec isn't very clear on this. The next rev will add a rate limit for router advertsements (again, see the meeting minutes). > 3. On page 31 ( sec 5.2.3. still ), ND spec says : > In case of a host becoming a router, the system must also join > the all routers multicast group on all interfaces on which the > router supports IP multicast ( whether or not they are > advertising interfaces ). > Does the comment in parenthesis mean that the non-advertising interfaces > do not do any router advertisements at all, in which case I do not > understand why they should join all routers multicast group. Or do you > mean that they do not advertise themselves as default. An "advertising interface" is defined at the top of section 5.2.3 to be any interface that has at least one IP address assigned to it. > 4.On page 30 ( again sec 5.2.3. last para ), it says : > When a router receives a RS, it records that the source of the > packet is a neighbor. If the RS contains a source link > layer address option, and the router has a neighbor cache > entry for the neighbor, the link layer address should be > updated in the neighbor cache. If a neighbor cache entry is > created for the source, its eachability state must be set > to PROBE. > > What does it mean by updating the cache entry. I think that if the entry > exists and the source link layer address in the RS is same as what the > neighbor cache holds, I think the entry should not be updated. If they are > different then the entry should be updated and the state set to PROBE. Also > if the entry is in REACHABLE state and the link layer address it holds is > different than what is in the RS, should it be changed to PROBE state ? It would make sense to only change the state if the link-layer address is different than the already recorded one. > 5. In section 5.1.1 ( On RS message format ), it says that IP dest. address > should be the the all-routers multicast address. While section 5.2.2 ( on > Validation of an RS message ) says : IP dest. address should be a link > local address or a multicast address with link local scope. Isn't this a > deviation from 5.1.1. Yes. This will be cleaned up in the next revision. > 6. In section 5.2.2 ( Validation of an RS ) : shouldn't the router check > that the hop count on the incoming RS is 1. There is no benefit in adding such a check. In the next rev of the draft we will use Hop Count 255 and verify this by the receivers. This "trick" allows us to ignore packets that have been forwarded from off-link senders. See message with subject (IPng 763) IPng/AddrConf Interm Meeting Notes. 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 Wed Nov 8 07:11:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01835; Wed, 8 Nov 95 07:11:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01829; Wed, 8 Nov 95 07:11:05 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10983; Wed, 8 Nov 1995 06:58:06 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id GAA24405; Wed, 8 Nov 1995 06:58:06 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10964; 8 Nov 95 9:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 799) I-D ACTION:draft-ietf-ipngwg-pmtuv6-00.txt Date: Wed, 08 Nov 95 09:27:08 -0500 Message-Id: <9511080927.aa10964@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 : Path MTU Discovery for IP version 6 Author(s) : J. McCann, S. Deering Filename : draft-ietf-ipngwg-pmtuv6-00.txt Pages : 13 Date : 11/07/1995 This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC-1191, which describes Path MTU Discovery for IP version 4. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-pmtuv6-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-pmtuv6-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-pmtuv6-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: <19951107114716.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-pmtuv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-pmtuv6-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951107114716.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 8 10:43:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02266; Wed, 8 Nov 95 10:43:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02260; Wed, 8 Nov 95 10:42:54 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05606; Wed, 8 Nov 1995 10:29:53 -0800 Received: from sics.se by mercury.Sun.COM (Sun.COM) id KAA17988; Wed, 8 Nov 1995 10:29:52 -0800 Received: from sics1.electrum.kth.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA02274; Wed, 8 Nov 95 19:29:44 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Nov 1995 19:29:27 +0100 To: Tom.Herbert@Eng (Tom Herbert) From: peter@sics.se (Peter Sjodin) Subject: (IPng 800) Re: An approach to multihoming Cc: ipng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >Yes, I agree that link local addresses are of limited usefulness. But this >doesn't address the real difficulty in dealing with link local addresses: >the fact that link local addresses don't have to be globally unique. This >allows the possiblity, however slight, that two hosts with identical >addresses can exist on two links of a multihomed host. Given that, >they have to be dealt with for: 1) correctness: packets need to go where >an applications intends them to go and 2) security: hosts can't be allowed >to masquerade themselves as being a host on the other side of a multihomed >server. > >I think spraying or storing an interface pointer in a neighbor cache as >described is insufficient to deal with the problem. > >Consider the case of a server (router discovery server for example) running >on a multihomed hosts and suppose there are two hosts A1 and A2 on two >connected links with identical link local addresses (A). Requests are >made to B with the link local address of the host as the source. > >A1 -- B -- A2 > >Now if host A1 makes a request to the server B, the server can respond >and will put the client host (A1) into it's neighbor cache. If host >A2 on the other link makes a request how does the server know to direct >its response to A2? If the server does a lookup in the neighbor cache it >will find the first host which is A1, so the response goes to the wrong >place. Not only incorrect, but probably a security hole. > >I think the clearest solution is for B to have two cache entries, one for >A1 and A2, each containing the address and cooresponding interface. When the >server application needs to send a packet to one of them, it must somehow >(source routing is one option) specify an outgoing interface. You are right, in order to solve this in the general case we need to maintain address-interface pairs in the cache and we need an API to pass such pairs to/from applications. If we want a general solution, we should probably do something about DNS too. I think this requires rather extensive modifications involving both protocol and applications, and I doubt that this is worthwhile. I think it is possible to do specific things, like discovery and autoconfiguration, on multi-homed nodes without such modifications. The request/response processing could for instance be done at interrupt level (which means that you won't get the above problem of overwriting the cache), or the discovery server could multicast responses on all links. I would rather see that link-local addresses are used for general purpose addressing only when there is no problem with their uniqueness, i.e. on single links. On networks with routers and other kinds of multi-homed nodes, we use configured addresses. If there are routers in your network, you probably want configured addresses anyway. So the only configuration I think is ruled out by this is multi-link networks with multi-homed nodes, no routers, and only link-local addresses, and I don't know if such configurations are very useful. >> Yes, this would make it possible to use link-local addresses with DNS. But >> then we are developing an addressing scheme for link-local addresses, in >> order to extend the scope of link-local addresses beyond individual links. >> We also need to allocate and configure interface ID:s in some way, and I'm >> not sure we are gaining anything this way. We could use site-local or >> global addresses instead. >> >I agree. Attempting to assign interface ID's across an network is almost >equivalent to assigning prefixes to the links, so why not use a site local >or global address in the DNS? "any cast" link local addresses (if such a >thing exists!) would be an obvious exception. > >Tom Peter ------------------------------------------------------------------------------ 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 Nov 8 11:31:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02398; Wed, 8 Nov 95 11:31:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02392; Wed, 8 Nov 95 11:31:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13622; Wed, 8 Nov 1995 11:18:02 -0800 Received: from CORALS.nhn.navair.navy.mil by mercury.Sun.COM (Sun.COM) id LAA07396; Wed, 8 Nov 1995 11:18:03 -0800 Received: from mr.navair.navy.mil by corals.nhn.navair.navy.mil (PMDF V5.0-4 #5358) id <01HXEJ66EP6O91W9VP@corals.nhn.navair.navy.mil> for ipng@sunroof.eng.sun.com; Wed, 08 Nov 1995 14:13:59 -0400 (EDT) Received: with PMDF-MR; Wed, 08 Nov 1995 14:13:34 -0400 (EDT) Mr-Received: by mta JFK.MUAS; Relayed; Wed, 08 Nov 1995 14:13:34 -0400 Mr-Received: by mta KTYHWK; Relayed; Wed, 08 Nov 1995 14:13:35 -0400 Mr-Received: by mta CORALS; Relayed; Wed, 08 Nov 1995 14:13:55 -0400 Disclose-Recipients: prohibited Date: Wed, 08 Nov 1995 14:13:34 -0400 (EDT) From: BUCHTERR Subject: (IPng 801) Request for IPng Information To: ipng%sunroof.eng.sun.com%internet@mr.navair.navy.mil Message-Id: <1834131408111995/A06851/KTYHWK/119B438D2100*@MHS> Autoforwarded: false Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Importance: normal Priority: normal Sensitivity: Company-Confidential Ua-Content-Id: 119B438D2100 X400-Mts-Identifier: [;1834131408111995/A06851/KTYHWK] Hop-Count: 2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I am researching how IPng was/is being developed. I need a breakdown of the working groups(the hierchy is difficult to follow with what I have to date), what models were used and the development strategy. Have read "IPng, Internet Protocol Next Generation" by Bradner and Mankin, and have reviewed several Web sites. Any ideas on where I can find this information? My address is buchterr.jfk@navair.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 8 11:37:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02439; Wed, 8 Nov 95 11:37:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01742; Wed, 8 Nov 95 03:23:58 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00734; Wed, 8 Nov 1995 03:11:00 -0800 Received: from integd.integralis.co.uk by mercury.Sun.COM (Sun.COM) id DAA27908; Wed, 8 Nov 1995 03:10:49 -0800 From: justin.clark@integralis.co.uk Received: from ccgate.integralis.co.uk by INTEGD.INTEGRALIS.CO.UK (PMDF V4.3-10 #8244) id <01HXECTAM2E80009IT@INTEGD.INTEGRALIS.CO.UK>; Wed, 08 Nov 1995 11:10:39 +0000 (GMT) Date: Wed, 08 Nov 1995 10:30 +0000 (GMT) Subject: (IPng 802) Transition from IPv4 to IPv6 - unresolved issue? To: ipng@sunroof.Eng.Sun.COM Message-Id: <01HXECTAROXU0009IT@INTEGD.INTEGRALIS.CO.UK> Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In the UK "Network News" of 8 November 1995, there is an article headed "TCP/IP standards development still too slow" with the by-line "The next generation of TCP/IP is coming along slowly, but most of the industry sees it as incomplete until a clear transition mechanism is in place". The article suggests that "about 85% of the IP V6 documentation is complete", but "... is incomplete to the extent that its most compelling pieces, such as transition mechanisms, are incomplete, which in turn makes it unattractive to users" We found this article rather interesting as it seems to add weight to the oft-expressed view that IP V4 to V6 migration is a major unresolved issue What are your feelings and comments on this? Please include my address in your responses as I dropped off the IPng list this week after thinking I had gained all the information needed :) Much appreciated Justin.Clark@Integralis.co.uk INTEGRALIS EUROPE. ------------------------------------------------------------------------------ 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 Nov 8 15:25:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02733; Wed, 8 Nov 95 15:25:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02727; Wed, 8 Nov 95 15:25:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19107; Wed, 8 Nov 1995 15:12:39 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id PAA06548; Wed, 8 Nov 1995 15:12:39 -0800 Received: from pobox.BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA01300; Wed, 8 Nov 95 18:11:23 EST Received: from cabernet.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA11989; Wed, 8 Nov 95 18:12:26 EST Date: Wed, 8 Nov 95 18:12:26 EST From: rcallon@BayNetworks.com (Ross Callon) Message-Id: <9511082312.AA11989@pobox.BayNetworks.com> To: ipng@sunroof.Eng.Sun.COM, buchterr.jfk@NAVAIR.NAVY.MIL Subject: (IPng 803) Re: Request for IPng Information Cc: rcallon@BayNetworks.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > I am researching how IPng was/is being developed. I need a breakdown of the > working groups(the hierchy is difficult to follow with what I have to date), > what models were used and the development strategy. Have read "IPng, Internet > Protocol Next Generation" by Bradner and Mankin, and have reviewed several Web > sites. Any ideas on where I can find this information? > > My address is buchterr.jfk@navair.navy.mil This all depends a bit on what sort of detail you need. If you want to fully understand the IPng process you have to understand the way in which the IETF works. The process will seem rather disorganized and chaotic to an outsider (hmmmm, actually it seems rather disorganized and chaotic to an old IETF fart also). However, the process works for reasons which may be debated, but which in my opinion includes: - Contrary and various alternatives / technical options are allowed to grow and be considered. There is no successful attempt to stop ideas ahead of time. No central body sets direction. Attempts to sidetrack the "rough consensus and running code" requirements are inevitably doomed to failure. - There are a substantial number of folks involved in the process (including enough folks to prevent any progress without their consent) who are real smart and genuinely interested in technical feasibility and reasonableness of the ideas above all else. Some of these folks run actual networks and thus want to make sure that their networks work. Others build products and want to sell to the first set. Thus, if your goal is to figure out whether IPng will work, then the quick answer is yes it will. If you want to write a history, then you will need a lot of detail. In this case you will probably want to dig up some of the old NAT, SIPP, IPAE, PIP, TUBA, "IPv7"/RAP documents. You will then want to call multiple of the folks who were involved from the beginning. In my opinion *all* of the original proposals were either flawed or had some pieces missing. However, Scott and Allison did a very good job with the IPng directorate of bringing the various technical ideas together and along with Steve and a cast of tens came up with a solution which many of us (myself included) feel very positive about. I could certainly privately mention some of the problems with each of the original approaches, and why the resulting IPv6 does not suffer from these problems. Ross ------------------------------------------------------------------------------ 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 Nov 8 18:19:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02846; Wed, 8 Nov 95 18:19:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02839; Wed, 8 Nov 95 18:19:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11893; Wed, 8 Nov 1995 18:06:05 -0800 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id SAA16482; Wed, 8 Nov 1995 18:06:06 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id VAA11251; Wed, 8 Nov 1995 21:05:34 -0500 (EST) Date: Wed, 8 Nov 1995 21:05:34 -0500 (EST) From: Scott Bradner Message-Id: <199511090205.VAA11251@newdev.harvard.edu> To: buchterr.jfk@NAVAIR.NAVY.MIL, ipng@sunroof.Eng.Sun.COM, rcallon@BayNetworks.com Subject: (IPng 804) Re: Request for IPng Information Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk fyi - I've put on-line all of the old IPng docs I could find take a look on ndtl.harvard.edu in pub/ipng/archive 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 Thu Nov 9 09:39:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03159; Thu, 9 Nov 95 09:39:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03124; Thu, 9 Nov 95 09:14:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04696; Thu, 9 Nov 1995 09:01:42 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id JAA07029; Thu, 9 Nov 1995 09:01:43 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20416 Fri, 10 Nov 1995 04:01:40 +1100 (from kre@cs.mu.OZ.AU) To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 805) Re: [IPv6Imp] Re: An approach to multihoming In-Reply-To: Your message of "Tue, 07 Nov 1995 14:37:57 EST." <9511071937.AA07211@pobox.BayNetworks.com> Date: Fri, 10 Nov 1995 04:01:52 +1100 Message-Id: <1170.815936512@cs.mu.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Tue, 7 Nov 95 14:37:57 EST From: dhaskin@baynetworks.com (Dimitry Haskin) Message-ID: <9511071937.AA07211@pobox.BayNetworks.com> Wouldn't it possible to achieve such an uniqueness by requiring that the interface's logical number is included into the link-local addresses structure? Maybe I missed it, but I don't recall seeing any discussion of this suggestion, which seems like an effective, cheap, and worthwhile thing to do. It doesn't solve all the problems of link local addresses by any means, but it certainly makes some a lot simpler, and is so cheap and effective at what it does I would suggest we should immediately adopt it. Just in case it isn't obvious what was suggested, let me give my interpretation... (if you understand, stop reading here) When constructing a link local address, we take a known prefix, and append a link-unique token (in practice, close to globally unique, but we don't depend upon that), that combination makes the local address (which we can verify for uniqueness using duplicate address detection). The prefix is simply found in the draft, that's easy. In order to make uniqueness very likely, we specify the means by which the token is generated to be appended for each link layer. If implementations were free to adopt any method, we couldn't expect different implementations to necessarily produce addresses that didn't conflict. But note this is the only reason we specify the token - we don't ever (I hope) look at an address, see it is link-local, see the link is ethernet, and then decide "I know this, the MAC address is the low 48 bits, I can avoid ND and just use the address obtained from the IPv6 addr". Not only would that be stupid, it also wouldn't work, as nothing has ever said that the particular MAC address (token for ethernet) is one taken from the particular interface on that link (or if it has said that, it need not, as we don't need that restriction). Next, note that the prefix is some known number of bits, I forget and am too lazy to check, but I doubt it is more than 32. The token isn't going to be longer than 80 for sure (it better be much shorter or addrconf for global numbers isn't going to work with current address plans). The two together are thus no more than 112 bits, leaving at least 16 bits with no purpose other than to carry zeroes. There is no reason at all a host need stick 0's in those free bits, anything at all is acceptable - as long as it is consistent enough that it is reasonably stable (as stable as the DNS entry that corresponds). That is, random numbers are no good, but non-zero bit patterns are just fine. Should a host choose to stick in a different bit pattern for each interface it happened to have connected, then other hosts seeing the various link local addresses would never be confused about which link was used - they need not be able to decypher the bit pattern inserted, but simply seeing different patterns on different links will allow it to detect which pattern belongs to which link. If we were to require this extra piece, we'd no longer have any problem at all in determining just where a multi-homed host with just one MAC address to share (original ethernet recommendation) is located. NB: this does not mean that we now have a link local address that identifies a particular link - there's no requirement (in fact it wouldn't happen) that all hosts use the same bit pattern in the spare field, all this does is cause host A's 3 link local addresses for its 3 interfaces to differ from each other, if I see .1. on my initerface number 6, and .2. on my interface number 7, then when I want to send to .1. I know to use my interface 6. So, a recommendation - require that all hosts place some local (stable) identification of the interface being used in the spare bits between the token and the prefix, rather than 0's, when constructing link local addresses. This will cause all link local addresses for a multi-homed host to be different. We need not require more that that, all hosts don't have to use the same identification scheme, or even the same spare bits (for that matter, some could shift the mac address left and put the identifier in the least significant bits - this simply doesn't matter). kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 9 11:37:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03408; Thu, 9 Nov 95 11:37:35 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03402; Thu, 9 Nov 95 11:37:25 PST Received: from janice.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id LAA26233; Thu, 9 Nov 1995 11:24:01 -0800 Received: by janice.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id LAA01747; Thu, 9 Nov 1995 11:22:23 -0800 Date: Thu, 9 Nov 1995 11:22:23 -0800 From: therbert@jurassic (Tom Herbert) Message-Id: <199511091922.LAA01747@janice.Eng.Sun.COM> To: kre@cs.mu.OZ.AU Subject: (IPng 806) Re: [IPv6Imp] Re: An approach to multihoming Cc: ipng@sunroof2.Eng.Sun.COM X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Wouldn't it possible to achieve such an uniqueness by requiring > that the interface's logical number is included into the > link-local addresses structure? > > Maybe I missed it, but I don't recall seeing any discussion of > this suggestion, which seems like an effective, cheap, and > worthwhile thing to do. > > It doesn't solve all the problems of link local addresses by > any means, but it certainly makes some a lot simpler, and is > so cheap and effective at what it does I would suggest we should > immediately adopt it. > > Just in case it isn't obvious what was suggested, let me give > my interpretation... (if you understand, stop reading here) > I don't think this is all that obvious. First of all, every single interface on every machine would need its own globally unique address. This would include PPP links and other non 802 addressed interfaces. This requires that every host be capable of producing a globally unique token. For hosts with a device such as an ethernet this may be doable, but for others this may not be an alternative. How would a PC with just a PPP interface be able to generate a globally unique address if there is nothing guaranteed to be globally unique in the system. Secondly, even if there was a way to produce such globally unique addresses, how would one verify uniqueness. Ethernet addresses are supposedly unique, however due to misconfiguration two devices with the same address can still be brought up on the link-- hence the need for running Duplicate Address Detection on ethernet. If link local addresses were turned into globally unique addresses this would require multi homed hosts to verify the uniqueness of all the hosts on all connected links in order to avoid the problems discussed earlier-- do you know a simple way to do that? Nice try... Tom ------------------------------------------------------------------------------ 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 Nov 9 13:17:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03504; Thu, 9 Nov 95 13:17:39 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03498; Thu, 9 Nov 95 13:17:27 PST Received: from janice.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id NAA02113; Thu, 9 Nov 1995 13:04:23 -0800 Received: by janice.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id NAA01803; Thu, 9 Nov 1995 13:02:45 -0800 Date: Thu, 9 Nov 1995 13:02:45 -0800 From: therbert@jurassic (Tom Herbert) Message-Id: <199511092102.NAA01803@janice.Eng.Sun.COM> To: kre@cs.mu.OZ.AU, therbert@jurassic Subject: (IPng 807) Re: [IPv6Imp] Re: An approach to multihoming Cc: ipng@sunroof2.Eng.Sun.COM X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > Wouldn't it possible to achieve such an uniqueness by requiring > > that the interface's logical number is included into the > > link-local addresses structure? > > > > Maybe I missed it, but I don't recall seeing any discussion of > > this suggestion, which seems like an effective, cheap, and > > worthwhile thing to do. > > > > > It doesn't solve all the problems of link local addresses by > > any means, but it certainly makes some a lot simpler, and is > > so cheap and effective at what it does I would suggest we should > > immediately adopt it. > > > > Just in case it isn't obvious what was suggested, let me give > > my interpretation... (if you understand, stop reading here) > > > I don't think this is all that obvious. > > First of all, every single interface on every machine would need its > own globally unique address. This would include PPP links and other ... Someone pointed out to me that the original idea was concerned with assigning unique interface addresses on a single host as opposed to globally unique addresses. My above arguments addresses an attempt at configuring globally unique interface addresses. Sorry for any confusion. Tom ------------------------------------------------------------------------------ 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 Nov 9 13:32:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03699; Thu, 9 Nov 95 13:32:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03693; Thu, 9 Nov 95 13:32:02 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17607; Thu, 9 Nov 1995 13:19:00 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id NAA25905; Thu, 9 Nov 1995 13:19:00 -0800 Received: from pobox.BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA11359; Thu, 9 Nov 95 16:16:18 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA01236; Thu, 9 Nov 95 16:17:14 EST Date: Thu, 9 Nov 95 16:17:14 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9511092117.AA01236@pobox.BayNetworks.com> To: Tom.Herbert@Eng, kre@cs.mu.OZ.AU Subject: (IPng 808) Re: [IPv6Imp] Re: An approach to multihoming Cc: ipng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Tom, > Date: Thu, 9 Nov 1995 11:22:23 -0800 > From: Tom.Herbert@Eng.Sun.COM (Tom Herbert) > > > Wouldn't it possible to achieve such an uniqueness by requiring > > that the interface's logical number is included into the > > link-local addresses structure? > > > > Maybe I missed it, but I don't recall seeing any discussion of > > this suggestion, which seems like an effective, cheap, and > > worthwhile thing to do. > > > > > It doesn't solve all the problems of link local addresses by > > any means, but it certainly makes some a lot simpler, and is > > so cheap and effective at what it does I would suggest we should > > immediately adopt it. > > > > Just in case it isn't obvious what was suggested, let me give > > my interpretation... (if you understand, stop reading here) > > > I don't think this is all that obvious. > > First of all, every single interface on every machine would need its > own globally unique address. This would include PPP links and other > non 802 addressed interfaces. This requires that every host be capable > of producing a globally unique token. > You've clearly misread what has been suggested. No one ever suggested that a *globally* unique token was used for a link-local address. I see attempts to solve the following problems: 1) to ensure that link-local interface addresses are unique accross all interfaces that attach to the same link; 2) to ensure that link-local addresses are uniquely identified accross all interfaces of a single multihomed node (logically we can view a node as a link that links all its interfaces, don't we?); 3) and ultimately, to ensure that a given multihomed node can uniquely identify all adjacent nodes by their link-local addresses. The address autoconfiguration protocol attempts to solve 1). In addition to what the address autoconfiguration does, I suggested a simple mechanism to solve 2). As it has been kindly pointed out to me, the proposed mechanism does not solve 3) in some pathological cases. But, as Robert pointed out, it is cheap and reduces the problem scope. Regards, Dimitry ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 9 14:23:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03960; Thu, 9 Nov 95 14:23:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03954; Thu, 9 Nov 95 14:23:24 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25438; Thu, 9 Nov 1995 14:10:22 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id OAA09713; Thu, 9 Nov 1995 14:10:19 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HXG1K3WHE8006Q9M@FNAL.FNAL.GOV>; Thu, 09 Nov 1995 16:10:15 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA16945; Thu, 9 Nov 95 16:08:49 CST Date: Thu, 09 Nov 1995 16:08:49 -0600 From: Matt Crawford Subject: (IPng 809) Re: [IPv6Imp] Re: An approach to multihoming In-Reply-To: Your message of Fri, 10 Nov 95 04:01:52 +1100. <1170.815936512@cs.mu.OZ.AU> To: Robert Elz Cc: ipng@sunroof2.Eng.Sun.COM Message-Id: <9511092208.AA16945@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04485; Thu, 9 Nov 95 20:58:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04479; Thu, 9 Nov 95 20:58:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15372; Thu, 9 Nov 1995 20:45:32 -0800 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id UAA21477; Thu, 9 Nov 1995 20:45:34 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26935; Fri, 10 Nov 1995 15:45:01 +1100 (from kre@munnari.OZ.AU) To: Matt Crawford Cc: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 810) Re: [IPv6Imp] Re: An approach to multihoming In-Reply-To: Your message of "Thu, 09 Nov 1995 16:08:49 MDT." <9511092208.AA16945@munin.fnal.gov> Date: Fri, 10 Nov 1995 15:44:16 +1100 Message-Id: <1459.815978656@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Thu, 09 Nov 1995 16:08:49 -0600 From: Matt Crawford Message-ID: <9511092208.AA16945@munin.fnal.gov> Pardon me, but I think we've dragged anchor and drifted out to sea. Yes, it seems I did allow myself to wander aimlessly a bit further than required (or feasible). But we must not go so far as kre suggests when he says: Of course, you're right, it does need to be specified more than I had thought. We need to specify just what the address token is on each medium if we want to minimize clashes. Yes, even my lunacy hadn't extended that far, I always intended that the token be specified, I simply forgot, or didn't consider, that where its put makes a difference too, so that also must be agreed. But once we have that, which is as good as we can do for uniqueness (apart from dup addr detection) what we put in the other bits doesn't matter, we won't gain any uniqueness on the link, but nor will we lose any (taking a field that was always the same and making it possibly differ from one address to another has that property). The gain in Dimitry's suggestion is that all link-local addresses on a multi-homed host will be unique, even if only one IEEE token is available (if none is available then this suggestion neither adds or removes any other mechanisms that would be needed).. The most complex part of the whole thing is writing the spec for it - the implementation is trivial (most implementations, those with only one interface, and those with separate tokens for each interface, would already comply), one extra line in others... kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 9 22:35:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04532; Thu, 9 Nov 95 22:35:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04526; Thu, 9 Nov 95 22:35:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22891; Thu, 9 Nov 1995 22:22:05 -0800 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id WAA00122; Thu, 9 Nov 1995 22:22:05 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA04032; Thu, 9 Nov 1995 21:35:16 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24270; Fri, 10 Nov 1995 00:35:15 -0500 Message-Id: <9511100535.AA24270@wasted.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 811) Re: [IPv6Imp] Re: An approach to multihoming In-Reply-To: Your message of "Thu, 09 Nov 95 16:08:49 CST." <9511092208.AA16945@munin.fnal.gov> Date: Fri, 10 Nov 95 00:35:15 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Folks, I have to agree with Robert and Matt that Dimitrys idea is a good one. It solves most of the problem. If we do what Dimitry suggested we can at least use link-local addresses to solve link problems in multihomed situation. I do agree with Peter that we may want to limit the use of link-local addresses to what they do best. So if we want to do this we need to figure it out because I think we want Matts drafts to got to proposed and this would cause a change to fddi/ethernet specs. I still think though an implementation needs to keep an interface pointer in the cache in a multihome situation for any address. My DNS idea as Peter suggested could be opening Pandoras Box to an area we really don't want to enter. /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 Nov 10 09:51:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04904; Fri, 10 Nov 95 09:51:55 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03049; Thu, 9 Nov 95 01:08:18 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04923; Thu, 9 Nov 1995 00:55:17 -0800 Received: from hermes.research.ptt.nl by mercury.Sun.COM (Sun.COM) id AAA00758; Thu, 9 Nov 1995 00:55:18 -0800 Received: from dnlts0.research.ptt.nl by research.kpn.com (PMDF V4.3-11 #7381) id <01HXFNT5TWC000QXFO@research.kpn.com>; Thu, 09 Nov 1995 09:36:41 +0100 Received: from gn01.ms.research.kpn.com by dnlts0.research.kpn.com (PMDF V4.3-11 #7381) id <01HXFNTJVO6OAYM3E4@dnlts0.research.kpn.com>; Thu, 09 Nov 1995 09:37:00 +0100 Date: Thu, 09 Nov 1995 09:32 +0100 From: "Wietmarschen, V.R. van" Subject: (IPng 812) IPng; Header Translators and other. To: "'IPng mailing list'" Message-Id: <01HXFNTJWH4IAYM3E4@dnlts0.research.kpn.com> X-Envelope-To: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT Posting-Date: Thu, 09 Nov 1995 09:32 +0100 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi to everyone. Currently Iam working on a project in order to investigate IPng. Questions like: Whats is IPng, differences with IPv4, IPng deployment,, ... Iam not involved in technical specs!! Iam curently working on the Interworking and deployment, and need more info on the following: 1) What is the actual status on Header Translators. Read some about it in SIT,but the subjec tis not mentioned in , , . If not considered anymore: How can IPv4-only host communicate with IPv6-only?? 2) A sending (dual) Host which encapsulates IPv4-in-IPv6 packets (auto tunneling) must have an IPv4 related IPv6 address (IPv4-compatible-IPv6 address) , Why?? If Host has unrelated IPv4 and IPv6 address it can use IPv4 address as IPv4 source and IPv6 address as IPv6 source in the IPv4/IPv6 packet. 3) Does there exist a single document which gives an overview of all IP and related protocols that need to be redesinged for IPv6 compatibility?? 4) Suppose the following: An organizations deploys a dual router at its Internet entry. Its provider does not deploy any IPv6 functionality yet. The organization never gets an DNS reply with an IPv6 address. Does it have to create a manual static tunnel to an other organization in order to get IPv6 routing info from that organization ??? 5) Does anyone have more information about IPv6 deployment and IPv6 functionality. 6) Does anyone has more information on the consequences of IPv6 deployment for service- and backbone providers. How should their deployment scenario look like. 7) IPv6 security architecture is moved to historic??? Its an (expired) Internet-Draft, I thought only RFC are assigned a State.?? 8) All Internet-Drafts documents refer to the '1id-abstracts.txt' to learn the current status of a draft document. To check I ftp: ftp://ftp.ripe.net/internet-drafts/1id-abstracts.txt But this gives me only abstracts of Internet-Drafts, no statusses??? By the way many Drafts in this list are from 1994 ??? Iam sorry for the size of questions. Roy van Wietmarschen Email: V.R.van Wietmarschen@research.kpn.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 10 11:40:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05042; Fri, 10 Nov 95 11:40:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05036; Fri, 10 Nov 95 11:40:48 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29237; Fri, 10 Nov 1995 11:27:44 -0800 Received: from PASCAL.MATH.YALE.EDU by mercury.Sun.COM (Sun.COM) id LAA05019; Fri, 10 Nov 1995 11:27:44 -0800 Received: from wfeit.slip.yale.edu by PASCAL.MATH.YALE.EDU via SMTP; Fri, 10 Nov 1995 14:32:35 -0500 Date: Sat, 11 Nov 95 01:55:51 PST From: Sidnie Feit Subject: (IPng 813) RE: Transition from IPv4 to IPv6 - unresolved issue? To: justin.clark@integralis.co.uk, ipng@sunroof.Eng.Sun.COM X-Mailer: Chameleon V0.05, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk On Wed, 08 Nov 1995 10:30 +0000 (GMT) justin.clark@integralis.co.uk wrote: > > >In the UK "Network News" of 8 November 1995, there is an article headed >"TCP/IP standards development still too slow" with the by-line "The next >generation of TCP/IP is coming along slowly, but most of the industry sees >it as incomplete until a clear transition mechanism is in place". > >The article suggests that "about 85% of the IP V6 documentation is >complete", but "... is incomplete to the extent that its most compelling >pieces, such as transition mechanisms, are incomplete, which in turn makes >it unattractive to users" > I am not one of the people working on version 6, but... The article to which you refer sounds like it is of a type that is all too common in our industry. The author was probably told "Write something by such and such a deadline, and give it a confrontational slant." My guess is that the author of the article knows absolutely nothing about version 6. IPv6 work is progressing far more rapidly than I personally ever thought it could. There are some very smart people involved. The work is in draft form, and of course it will be a long road until every detail is nailed down. However, there already are implementations, and they are testing in order to get implementations to interwork, unearth ambiguities, and check to see whether pieces of the architecture may have been overlooked. This is a very major piece of software architecture, and it has to be done carefully. Making a statement like "85% is complete" is just not meaningful. This architecture will be worked and reworked until it is right. It is true that the important parts of the framework are there, and they are exciting. To cite just a few of the capabilities: 1) Extend the address space, but do it in such a way that: A) Organizations that are not connected to the Internet can safely assign site-specific addresses to themselves. There will be a big prefix in front of the site address that has a fixed (boilerplate) value. B) When such an organization gets a Service Provider and connects to the Internet, the boilerplate is replaced by a provider ID and site ID. The rest of the address, which was designed at the site, does not change. C) Systems will switch over to their new addresses automatically, because the new prefix will be advertised by their local routers. 2) ALL address assignments can be automated, using router advertisements. 3) Detecting the presence of new routers and dead routers has been improved enormously - it is now built into the protocol. 4) Headers are chained in a way the enables future extensions to the protocol to be added without changing the version 6 framework. Software code addtions can be made without changing existing code. 5) Routers will no longer need to fragment datagrams. 6) New security standards enable authentication, detection of data tampering, and privacy to be executed at the IP layer. Thus, for example, branch offices could communicate with headquarters securely across the Internet. This part of the work can be applied to version 4 as well as version 6. 7) Finally, the transition plan appears to me to have been quite well thought out. Coexistence of version 4 and version 6 can go on indefinitely at any site for which that is convenient. There are new "AAAA" records in the Domain Name System that identify version 6 addresses. A version 4 client would not ask for these. In a bilingual network, important servers will have dual version 4 and version 6 stacks for a while. As long as CIDR can take care of the address space problem, we should be patient and let these good ideas continue to bud and bloom. What this group does now will have to last for many years. Personally, I find statements like the one quoted above to be infuriating. Suppose that right after Salk's polio vaccine had been discovered, but was not yet tested, someone had said: "Mr. Salk's polio vaccine is not available on the market, which makes it unattractive to users." Is that intelligent discourse? Sidnie Feit ------------------------------------------------------------------------------ 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 Nov 13 09:38:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05977; Mon, 13 Nov 95 09:38:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05971; Mon, 13 Nov 95 09:38:48 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29215; Mon, 13 Nov 1995 09:25:40 -0800 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id JAA00082; Mon, 13 Nov 1995 09:25:40 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA01752; Mon, 13 Nov 1995 08:56:37 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA30185; Mon, 13 Nov 1995 11:56:27 -0500 Message-Id: <9511131656.AA30185@wasted.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM, ipv6imp@munnari.oz.au Cc: shand@shand.reo.dec.com, thomas@netrix.lkg.dec.com, bound@zk3.dec.com Subject: (IPng 814) Call for input on IPv6 multihoming issues Date: Mon, 13 Nov 95 11:56:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I am sending this message for Mike Shand to get the word out. IPng WG Chairs can we get time on the IPng Agenda at Dallas to discuss with the working group. thanks /jim Call for input on IPv6 multihoming issues. ========================================= I'm starting work, in collaboration with Matt Thomas and Jim Bound, on a draft dealing with mechanisms for the support of multihoming in IPv6. I have some experience in this area, having designed the multihoming support in another protocol suite! I'm looking for input in the following areas. 1) What are the requirements for multihoming support? a) Must have b) Nice to have 2) What particular problems have been exposed? 3) What proposals already exist to solve these problems? I've got a feel from previous discussions on the lists, but if you have a strong opinion about the direction we should take, I'd like hear it. I have no desire to re-invent any wheels. It would be nice to have a good idea of where we are going before Dallas. You can contact me at shand@shand.reo.dec.com Mike Shand ================================================================== ------------------------------------------------------------------------------ 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 Nov 13 10:28:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06009; Mon, 13 Nov 95 10:28:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06003; Mon, 13 Nov 95 10:28:04 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08466; Mon, 13 Nov 1995 10:14:56 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id KAA15509; Mon, 13 Nov 1995 10:14:55 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17679 Tue, 14 Nov 1995 05:14:53 +1100 (from kre@cs.mu.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 815) Re: IPng/AddrConf Interm Meeting Notes In-Reply-To: Your message of "Wed, 18 Oct 1995 12:12:12 MST." <199510181912.MAA25808@walnut.ipsilon.com> Date: Tue, 14 Nov 1995 05:15:05 +1100 Message-Id: <2208.816286505@cs.mu.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Wed, 18 Oct 1995 12:12:12 -0700 From: "Robert M. Hinden" Message-ID: <199510181912.MAA25808@walnut.ipsilon.com> IPng/AddrConf Working Groups Interim Meeting October 11 & 12 1995 Discussion on "The IPv6 Payload Header" draft. I had no idea you planned on discussing that draft at the interim meeting - a new version of the draft appeared, probably during it, by co-incidence (I had mail saying the old one was about to be deleted...) There does not appear to be any commercial implementations of TMUX No, there's the standard chicken & egg problem - if I implement this, to whom do I talk. The people for whom this kind of thing is of most benefit cannot expect TMUX at their targets as there there's no benefit in implementing it. That's why (and only why) being able to receive the payload header is/was to be mandatory. author will have to make a better case. So far I hadn't really made any case at all, nothing more than a description, as there's never been more than a couple of minutes available - more urgent work always needing doing... kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 13 10:42:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06075; Mon, 13 Nov 95 10:42:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06069; Mon, 13 Nov 95 10:41:56 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10949; Mon, 13 Nov 1995 10:28:49 -0800 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id KAA19913; Mon, 13 Nov 1995 10:28:50 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA06295; Mon, 13 Nov 1995 09:37:22 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA03585; Mon, 13 Nov 1995 12:37:20 -0500 Message-Id: <9511131737.AA03585@wasted.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM, ipv6imp@munnari.oz.au Cc: shand@shand.reo.dec.com, thomas@netrix.lkg.dec.com, danmcd@cs.nrl.navy.mil, bound@zk3.dec.com Subject: (IPng 816) IPv6 Multihome Node another Co-Author Date: Mon, 13 Nov 95 12:37:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dan McDonald at NRL will also be working with Mike, Matt, and I on the spec. 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 Nov 13 13:22:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06254; Mon, 13 Nov 95 13:22:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06248; Mon, 13 Nov 95 13:21:55 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07455; Mon, 13 Nov 1995 13:08:49 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id NAA10929; Mon, 13 Nov 1995 13:08:49 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15108(3)>; Mon, 13 Nov 1995 12:40:01 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 13 Nov 1995 12:39:46 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng 817) WG last call: IPv6 over Ethernet Date: Mon, 13 Nov 1995 12:39:44 PST From: Steve Deering Message-Id: <95Nov13.123946pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk This is an ipng working group last call for comments on advancing the following document to Proposed Standard: Title : A Method for the Transmission of IPv6 Packets over Ethernet Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-ethernet-ntwrks-01.txt Pages : 4 Date : 10/10/1995 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end two weeks from today, on Monday November 27. Also, if the authors of any of the other IPv6-over-foo documents feel they are ready for WG last call, please let Bob and me know. 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 Tue Nov 14 12:46:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06857; Tue, 14 Nov 95 12:46:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06851; Tue, 14 Nov 95 12:46:09 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17072; Tue, 14 Nov 1995 12:33:01 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id MAA04060; Tue, 14 Nov 1995 12:33:01 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8262; Tue, 14 Nov 95 15:32:39 EST Received: by RTP (XAGENTA 4.0) id 5779; Tue, 14 Nov 1995 15:32:42 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17247; Tue, 14 Nov 1995 15:32:10 -0500 Message-Id: <9511142032.AA17247@cichlid.raleigh.ibm.com> To: Robert Elz Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 818) Re: IPng/AddrConf Interm Meeting Notes In-Reply-To: Your message of "Tue, 14 Nov 1995 05:15:05 +1100." <2208.816286505@cs.mu.OZ.AU> Date: Tue, 14 Nov 1995 15:32:09 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Robert Elz writes: >So far I hadn't really made any case at all, nothing more than >a description, as there's never been more than a couple of >minutes available - more urgent work always needing doing... You suggest that a case can be made. Please find a few minutes to at least outline the need. At the interim meeting, no one could come up with a concrete example where it would be useful. With no perceived need, there is little incentive for anyone to followup. LAT (terminal servers) were cited as one example where this sort of functionality was (at least at one point in the past) useful. But it's not clear that even terminal servers would find such a facility useful today. 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 Tue Nov 14 13:27:09 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06897; Tue, 14 Nov 95 13:27:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06891; Tue, 14 Nov 95 13:26:55 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22643; Tue, 14 Nov 1995 13:13:47 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id NAA14219; Tue, 14 Nov 1995 13:13:47 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA14976 Wed, 15 Nov 1995 07:55:24 +1100 (from kre@cs.mu.OZ.AU) To: "Thomas Narten" Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 819) Re: IPng/AddrConf Interm Meeting Notes In-Reply-To: Your message of "Tue, 14 Nov 1995 15:32:09 EDT." <9511142032.AA17247@cichlid.raleigh.ibm.com> Date: Wed, 15 Nov 1995 07:55:36 +1100 Message-Id: <2551.816382536@cs.mu.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Date: Tue, 14 Nov 1995 15:32:09 -0400 From: "Thomas Narten" Message-ID: <9511142032.AA17247@cichlid.raleigh.ibm.com> > [me...] more urgent work always needing doing... You suggest that a case can be made. Please find a few minutes to at least outline the need. OK, I will try, but not right now (soon). Note that the "more urgent work" I was referring to above was WG work - time at the meetings has always been limited - not my work (though there is plenty of that too). kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 17 15:08:04 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00521; Fri, 17 Nov 95 15:08:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00499; Fri, 17 Nov 95 15:07:32 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04637; Wed, 15 Nov 1995 15:54:13 -0800 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id PAA26314; Wed, 15 Nov 1995 15:54:13 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA15609; Wed, 15 Nov 1995 15:01:59 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA11292; Wed, 15 Nov 1995 18:01:56 -0500 Message-Id: <9511152301.AA11292@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com, addrconf@cisco.com Subject: (IPng 821) Prefixes/Autoconfig: ND and Addrconf Date: Wed, 15 Nov 95 18:01:55 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For ND and Addrconf: #1 I think we need some wording that states the following: If more than one router is on a link they MUST advertise the same Prefixes for ON-LINK, Addr Conf, and the same managed bit values for autoconfiguration (stateless or stateful). It will be a real mess if this is not the case. The host will go beserk. We need the MUST word too. #2 Why is an option that routers do not have to supply ON-LINK prefixes (not addr conf)? I think this should not be an option in ND but a MUST requirement. Why is it not? What good is the router if does not know the prefixes? /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 Nov 17 15:08:02 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00520; Fri, 17 Nov 95 15:08:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00486; Fri, 17 Nov 95 15:07:27 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27252; Wed, 15 Nov 1995 08:41:00 -0800 Received: from oberon.di.fc.ul.pt by mercury.Sun.COM (Sun.COM) id IAA28934; Wed, 15 Nov 1995 08:40:42 -0800 Received: from localhost (roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) with SMTP id RAA16088 for ; Wed, 15 Nov 1995 17:39:34 +0100 Message-Id: <199511151639.RAA16088@oberon.di.fc.ul.pt> X-Authentication-Warning: oberon.di.fc.ul.pt: Host localhost didn't use HELO protocol X-Authentication-Warning: oberon.di.fc.ul.pt: roque owned process doing -bs X-Mailer: exmh version 1.6.1 5/23/95 To: ipng@sunroof.eng.sun.com Subject: (IPng 820) Anycast Addresses From: roque@di.fc.ul.pt Reply-To: roque@di.fc.ul.pt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 1995 17:39:15 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Anycast addresses have well known scalability problems when members are dispersed. Multicast also has this kind of problems and the approach of the Internet community for the development of multicast was to work first using only "local" scope ( i.e. dvmrp and dense mode multicast routing algorithms were maily tought for intra-domain operation) and to try, after some experience is gained, to scale things to the Internet scope ( PIM sparse mode looks promissing ). One of the major uses of anycast addresses might be at the "site" level to allow load sharing between servers for some applications ( take DNS for instance ) and/or replication ( again DNS might be a good example ). Other proposed uses were "identify the set of router of provider A" or the set of Mail Exchangers. All this applications don't require the visibility of anycast routing information outside of a "local" scope and don't impose load on the global routing information. These are of course not all the kind of applications that one would like to have available and that use anycast but are IMHO a good starting point. What I would like to propose is that the "only routers can have anycast addresses" restriction would be lifted and maybe changed to something like: "anycast addresses must fit on the address space already available for a site, that is they must have a common prefix with addresses already available for normal unicast addresses on a given AS". On a local scope anycast routing does not, to my knowledge, impose unsolvable problems. A link based routing algorithm ( in the style of OSPF ) could do the trick... also i believe that extending IGMP to allow the announcement of anycast addresses would allow the routers to build in a dynamic way the map of anycast addresses of the domain. This kind of mecanisms could be introduced, I think, as experimental in the early stages of IPng development. My main concern is that router software is not that hard to change host software is. If the use of anycasting requires changes to any machine that wants to *serve* a anycast address it would be better to have that interface planned in advance even if it's only a experimental feature and the initial solution is not optimal. Pedro Roque ( roque@di.fc.ul.pt ) Faculdade de Ciências da Universidade de Lisboa Departamento de Informática ------------------------------------------------------------------------------ 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 Nov 17 15:08:05 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00522; Fri, 17 Nov 95 15:08:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00490; Fri, 17 Nov 95 15:07:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26738; Wed, 15 Nov 1995 11:35:12 -0800 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id LAA22989; Wed, 15 Nov 1995 11:35:14 -0800 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA02151; Wed, 15 Nov 1995 11:28:25 -0800 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA13270; Wed, 15 Nov 1995 14:28:22 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id TAA25473 for ; Wed, 15 Nov 1995 19:30:36 GMT Message-Id: <199511151930.TAA25473@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 822) ND Secondary Advertisement Query X-Mailer: exmh version 1.5omega 10/6/94 Date: Wed, 15 Nov 1995 19:30:35 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I'm resending this since I haven't received the copy I sent last night] Is a Secondary ND Advertisement of a Link Local Address Legal? If not (and I can't see a reason to allow it), then the ND draft should probably explicitly state that it is not allowed. Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 17 15:10:15 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00645; Fri, 17 Nov 95 15:10:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00582; Fri, 17 Nov 95 15:09:17 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05943; Tue, 14 Nov 1995 14:39:02 -0800 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id OAA07046; Tue, 14 Nov 1995 14:38:59 -0800 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA13293; Tue, 14 Nov 1995 14:27:35 -0800 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA09226; Tue, 14 Nov 1995 17:27:31 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id WAA20437 for ; Tue, 14 Nov 1995 22:29:24 GMT Message-Id: <199511142229.WAA20437@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 823) ND Secondary Advertisement Query X-Mailer: exmh version 1.5omega 10/6/94 Date: Tue, 14 Nov 1995 22:29:15 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is a Secondary ND Advertisement of a Link Local Address Legal? If not (and I can't see a reason to allow it), then the ND draft should probably explicitly state that it is not allowed. Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Nov 17 15:10:17 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00646; Fri, 17 Nov 95 15:10:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00625; Fri, 17 Nov 95 15:09:42 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13779; Wed, 15 Nov 1995 10:24:54 -0800 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id KAA27873; Wed, 15 Nov 1995 10:24:54 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA21044; Wed, 15 Nov 1995 09:38:20 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27130; Wed, 15 Nov 1995 12:38:17 -0500 Message-Id: <9511151738.AA27130@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 824) link-local address Date: Wed, 15 Nov 95 12:38:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, So are we going to discuss Dimitrys idea on making sure links are unique with the high order bits? I think this is important. Will this be an agenda item for Dallas? /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 Nov 17 16:34:52 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00843; Fri, 17 Nov 95 16:34:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00837; Fri, 17 Nov 95 16:34:41 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23789; Fri, 17 Nov 1995 10:28:08 -0800 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id KAA27000; Fri, 17 Nov 1995 10:28:08 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA19078; Fri, 17 Nov 1995 10:19:44 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA08010; Fri, 17 Nov 1995 13:19:38 -0500 Message-Id: <9511171819.AA08010@wasted.zk3.dec.com> To: "Thomas Narten" Cc: bound@zk3.dec.com, Matt Crawford , ipng@sunroof.eng.sun.com, addrconf@cisco.com Subject: (IPng 825) Re: Prefixes/Autoconfig: ND and Addrconf In-Reply-To: Your message of "Thu, 16 Nov 95 11:31:23 EST." <199511161635.LAA00286@hygro> Date: Fri, 17 Nov 95 13:19:37 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tom, >>If more than one router is on a link they MUST advertise the same >>Prefixes for ON-LINK, Addr Conf, and the same managed bit values for >>autoconfiguration (stateless or stateful). > >I don't see a strong reason to require this. For one thing, even if >we say it is a MUST, sys admins will screw up, so we already have to >spell out the rules saying what to do when conflicting information is >advertised. Given that the rules are there, let the sys admin suffer >the consequences if they configure things foolishly. > >Note also, that having all routers advertise "the same prefixes ..." >is stronger than necessary. What we want to avoid is having routers >advertise conflicting information that results in hosts continually >changing internal state (e.g., going "beserk"). The ND draft does >include such a warning. I just thought it should be a stronger statement. If we don't hear more on the list from others I will let it go and assume the warning will work. >>#2 >>Why is an option that routers do not have to supply ON-LINK prefixes >>(not addr conf)? I think this should not be an option in ND but a MUST >>requirement. Why is it not? What good is the router if does not know >>the prefixes? >It is assumed that the router knows what the on-link prefixes >are. That does not mean, however, that the router must tell hosts what >those prefixes are. The router may prefer to have all traffic sent to >it, so that it can send individual redirects for on-link destinations. > >An example where this would actually be useful is if an interface >fails. Consider two machines A & B. B is multihomed. A is sending data >to one of B's on-link IP addresses. If B's on-link interface fails, A >will continue sending to B's broken interface forever. Communication >fails. On the other hand, if A didn't know that the address it was >using was on-link, A would first go to the router, which would >redirect it to B. Later, when B's interface breaks, A detects the >problem (thanks to NUD) and performs next-hop determination again. At >this point it goes back to the router, which may route the packet to B >via an alternate interface. The reason I asked for this too was I believe if hosts do know they have a router (or several routers) and there are not prefix advertisements I think that implementations will default to RIP or some other mechanism to obtain the prefixes because the hosts believe they can be more efficient. I am not advocating this is a good idea but that this is reality. If routers MUST send prefixes then much of the above will be avoided. What do others in the working group think? /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 Nov 17 16:53:42 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00932; Fri, 17 Nov 95 16:53:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00926; Fri, 17 Nov 95 16:53:26 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19771; Fri, 17 Nov 1995 16:40:13 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id QAA15911; Fri, 17 Nov 1995 16:40:14 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14757(8)>; Fri, 17 Nov 1995 16:39:59 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Fri, 17 Nov 1995 16:39:51 -0800 To: ipng@sunroof.eng.sun.com Cc: deering@parc.xerox.com Subject: (IPng 826) WG last call: Neighbor Discovery Date: Fri, 17 Nov 1995 16:39:39 PST From: Steve Deering Message-Id: <95Nov17.163951pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is an ipng working group last call for comments on advancing the following document to Proposed Standard: Title : Neighbor Discovery for IP Version 6 (IPv6) Author(s) : T. Narten, E. Nordmark, W. A. Simpson Filename : draft-ietf-ipngwg-discovery-03.txt Pages : 86 Date : 11/17/95 This should be reviewed in conjunction with latest addrconf spec, which is also being last-called today (draft-ietf-addrconf-ipv6-auto-06.txt). Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end on Sunday, Dec 3 (the day before the IETF meeting in Dallas). If no substantive problems are identified during this last call period, or if all identified problems are resolved with sufficient consensus at the subsequent ipng meeting in Dallas, the WG chairs will recommend to our ADs that the document be published as a Proposed Standard RFC. We have been informed that the document will appear in the Internet Draft directories tomorrow or the next day. If you want to pick up a copy before then, you can find it in: ftp://parcftp.xerox.com/pub/ipng/draft-ietf-ipngwg-discovery-03.txt 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 Nov 17 17:57:36 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01097; Fri, 17 Nov 95 17:57:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01091; Fri, 17 Nov 95 17:57:19 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07379; Thu, 16 Nov 1995 07:13:07 -0800 Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM) id HAA11246; Thu, 16 Nov 1995 07:13:07 -0800 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HXPF10UOC000B34N@FNAL.FNAL.GOV>; Thu, 16 Nov 1995 09:12:52 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA04822; Thu, 16 Nov 95 09:11:20 CST Date: Thu, 16 Nov 1995 09:11:20 -0600 From: Matt Crawford Subject: (IPng 827) Re: Prefixes/Autoconfig: ND and Addrconf In-Reply-To: Your message of Wed, 15 Nov 95 18:01:55 EST. <9511152301.AA11292@wasted.zk3.dec.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com, addrconf@cisco.com Message-Id: <9511161511.AA04822@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ #1 > I think we need some wording that states the following: > > If more than one router is on a link they MUST advertise the same > Prefixes for ON-LINK, Addr Conf, and the same managed bit values for > autoconfiguration (stateless or stateful). If we require this, we may want to suggest who should squawk about a mismatch. I nominate the routers. > #2 > Why is an option that routers do not have to supply ON-LINK prefixes > (not addr conf)? I think this should not be an option in ND but a MUST > requirement. Why is it not? I'm sure that I'd usually want all prefixes to be mentioned, but I can imagine several circumstances when I'd want the freedom to do otherwise. Will there be trouble? By the way, I'd like the discovery draft to say that the link-local prefix FE80::/10 should not (or must not) be advertised in Prefix Information options. _________________________________________________________ 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 Sat Nov 18 05:25:20 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01582; Sat, 18 Nov 95 05:25:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01576; Sat, 18 Nov 95 05:25:08 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21353; Sat, 18 Nov 1995 05:11:55 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id FAA05602; Sat, 18 Nov 1995 05:11:56 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0062; Sat, 18 Nov 95 08:11:36 EST Received: by RTP (XAGENTA 4.0) id 6580; Sat, 18 Nov 1995 08:11:41 -0500 Received: from rsal3p68.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20396; Sat, 18 Nov 1995 08:11:46 -0500 Received: from localhost (localhost [127.0.0.1]) by hygro (8.6.11/8.6.9) with SMTP id IAA00188; Sat, 18 Nov 1995 08:10:30 -0500 Message-Id: <199511181310.IAA00188@hygro> X-Authentication-Warning: hygro.raleigh.ibm.com: Host localhost didn't use HELO protocol To: Matt Thomas Cc: ipng@sunroof.eng.sun.com Subject: (IPng 828) Re: ND Secondary Advertisement Query In-Reply-To: Your message of "Wed, 15 Nov 1995 19:30:35 GMT." <199511151930.TAA25473@whydos.lkg.dec.com> Date: Sat, 18 Nov 1995 08:10:24 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, >Is a Secondary ND Advertisement of a Link Local Address Legal? Yes it is legal, though we've changed the name "secondary" to "override". >If not (and I can't see a reason to allow it), then the ND draft should >probably explicitly state that it is not allowed. Even if not immediately useful in practice, there is little harm in allowing it. Disallowing it would also rule out the possibility of having link-local anycast addresses (NAs for anycast addresses set the Override bit to 0), for example. 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 Sat Nov 18 05:43:43 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01605; Sat, 18 Nov 95 05:43:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01599; Sat, 18 Nov 95 05:43:31 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21616; Sat, 18 Nov 1995 05:30:19 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id FAA06456; Sat, 18 Nov 1995 05:30:19 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0095; Sat, 18 Nov 95 08:30:00 EST Received: by RTP (XAGENTA 4.0) id 6584; Sat, 18 Nov 1995 08:30:05 -0500 Received: from rsal3p68.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA16648; Sat, 18 Nov 1995 08:29:15 -0500 Received: from localhost (localhost [127.0.0.1]) by hygro (8.6.11/8.6.9) with SMTP id IAA00206; Sat, 18 Nov 1995 08:27:58 -0500 Message-Id: <199511181327.IAA00206@hygro> X-Authentication-Warning: hygro.raleigh.ibm.com: Host localhost didn't use HELO protocol To: roque@di.fc.ul.pt Cc: ipng@sunroof.eng.sun.com Subject: (IPng 829) Re: Anycast Addresses In-Reply-To: Your message of "Wed, 15 Nov 1995 17:39:15 +0100." <199511151639.RAA16088@oberon.di.fc.ul.pt> Date: Sat, 18 Nov 1995 08:27:52 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, >This kind of mecanisms could be introduced, I think, as experimental in the >early stages of IPng development. My main concern is that router software is >not that hard to change host software is. If the use of anycasting requires >changes to any machine that wants to *serve* a anycast address it would be >better to have that interface planned in advance even if it's only a >experimental feature and the initial solution is not optimal. It's not clear to me that anycast addresses can/should be used for generic services in the same way unicast IP addresses are used. For example, one can't open a TCP connection to an anycast address because anycast addresses aren't allowed as source addresses. The response packets would come from a different (read "wrong") address and which the client would not be able to associate return packets with the connection being opened. (A similiar argument applies to much UDP-based traffic.) Consequently, it is likely that any *host* (client) wanting to use anycast addresses will need to be modified to somehow "do the right thing". That is, modifications won't necessarily be restricted to just routers. Another reason for restricting anycast addresses to routers is that routers presumably will be running routing protocols and can inject prefixes covering their anycast addresses into the routing systems. How will servers (i.e., hosts) do this? Will we require that all servers with anycast addresses run routing protocols? Ouch! 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 Sat Nov 18 06:51:46 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01683; Sat, 18 Nov 95 06:51:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01677; Sat, 18 Nov 95 06:51:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23088; Sat, 18 Nov 1995 06:38:22 -0800 Received: from oberon.di.fc.ul.pt by mercury.Sun.COM (Sun.COM) id GAA08637; Sat, 18 Nov 1995 06:38:13 -0800 Received: from localhost (roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) with SMTP id PAA24730; Sat, 18 Nov 1995 15:36:48 +0100 Message-Id: <199511181436.PAA24730@oberon.di.fc.ul.pt> X-Authentication-Warning: oberon.di.fc.ul.pt: Host localhost didn't use HELO protocol X-Authentication-Warning: oberon.di.fc.ul.pt: roque owned process doing -bs X-Mailer: exmh version 1.6.1 5/23/95 To: "Thomas Narten" Reply-To: roque@di.fc.ul.pt Cc: ipng@sunroof.eng.sun.com From: roque@di.fc.ul.pt Subject: (IPng 830) Re: Anycast Addresses In-Reply-To: Your message of "Sat, 18 Nov 1995 08:27:52 EST." <199511181327.IAA00206@hygro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Nov 1995 15:36:42 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Pedro, > > >This kind of mecanisms could be introduced, I think, as experimental in the > >early stages of IPng development. My main concern is that router software is > >not that hard to change host software is. If the use of anycasting requires > >changes to any machine that wants to *serve* a anycast address it would be > >better to have that interface planned in advance even if it's only a > >experimental feature and the initial solution is not optimal. > > It's not clear to me that anycast addresses can/should be used for > generic services in the same way unicast IP addresses are used. For > example, one can't open a TCP connection to an anycast address because > anycast addresses aren't allowed as source addresses. Of course that this implies that the source address would be replaced by the unicast address of the server.. impling that the packet needs to be signed width the anycast address by the repective private key ... gosh! i've started thinking of the dreadful EIDs again :-) > The response > packets would come from a different (read "wrong") address and which > the client would not be able to associate return packets with the > connection being opened. (A similiar argument applies to much > UDP-based traffic.) Consequently, it is likely that any *host* > (client) wanting to use anycast addresses will need to be modified to > somehow "do the right thing". yes the a mofication is necessary for the host to recognise the "Autenticated Address Change" > That is, modifications won't necessarily > be restricted to just routers. You are totaly right ... but can we reach a small set of simple modifications that can allow us to explore this kind of possibilities ? ( i don't know the answer ... ) > Another reason for restricting anycast addresses to routers is that > routers presumably will be running routing protocols and can inject > prefixes covering their anycast addresses into the routing > systems. How will servers (i.e., hosts) do this? Will we require that > all servers with anycast addresses run routing protocols? Ouch! No, just a "Anycast Group Membership Report" ICMP. We just the same very thing for multicast. Group members are left the iniciative of joining & leaving groups and don't have to know a thing about routing. The difference here is just in the semantics of the groups that the network layer will provide. Pedro Roque ( roque@di.fc.ul.pt ) Faculdade de Ciências da Universidade de Lisboa Departamento de Informática ------------------------------------------------------------------------------ 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 Nov 18 08:18:44 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01796; Sat, 18 Nov 95 08:18:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01790; Sat, 18 Nov 95 08:18:32 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23037; Thu, 16 Nov 1995 15:53:34 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id PAA00043; Thu, 16 Nov 1995 15:53:33 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5062; Thu, 16 Nov 95 18:53:13 EST Received: by RTP (XAGENTA 4.0) id 6301; Thu, 16 Nov 1995 18:53:13 -0500 Received: from rsal3p3.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20664; Thu, 16 Nov 1995 18:53:07 -0500 Received: from localhost (localhost [127.0.0.1]) by hygro (8.6.11/8.6.9) with SMTP id LAA00286; Thu, 16 Nov 1995 11:35:14 -0500 Message-Id: <199511161635.LAA00286@hygro> X-Authentication-Warning: hygro: Host localhost didn't use HELO protocol To: bound@zk3.dec.com, Matt Crawford Cc: ipng@sunroof.eng.sun.com, addrconf@cisco.com Subject: (IPng 831) Re: Prefixes/Autoconfig: ND and Addrconf In-Reply-To: Your message of "Wed, 15 Nov 1995 18:01:55 EST." <9511152301.AA11292@wasted.zk3.dec.com> Date: Thu, 16 Nov 1995 11:31:23 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >If more than one router is on a link they MUST advertise the same >Prefixes for ON-LINK, Addr Conf, and the same managed bit values for >autoconfiguration (stateless or stateful). I don't see a strong reason to require this. For one thing, even if we say it is a MUST, sys admins will screw up, so we already have to spell out the rules saying what to do when conflicting information is advertised. Given that the rules are there, let the sys admin suffer the consequences if they configure things foolishly. Note also, that having all routers advertise "the same prefixes ..." is stronger than necessary. What we want to avoid is having routers advertise conflicting information that results in hosts continually changing internal state (e.g., going "beserk"). The ND draft does include such a warning. >#2 >Why is an option that routers do not have to supply ON-LINK prefixes >(not addr conf)? I think this should not be an option in ND but a MUST >requirement. Why is it not? What good is the router if does not know >the prefixes? It is assumed that the router knows what the on-link prefixes are. That does not mean, however, that the router must tell hosts what those prefixes are. The router may prefer to have all traffic sent to it, so that it can send individual redirects for on-link destinations. An example where this would actually be useful is if an interface fails. Consider two machines A & B. B is multihomed. A is sending data to one of B's on-link IP addresses. If B's on-link interface fails, A will continue sending to B's broken interface forever. Communication fails. On the other hand, if A didn't know that the address it was using was on-link, A would first go to the router, which would redirect it to B. Later, when B's interface breaks, A detects the problem (thanks to NUD) and performs next-hop determination again. At this point it goes back to the router, which may route the packet to B via an alternate interface. Matt Crawford writes: >If we require this, we may want to suggest who should squawk about a >mismatch. I nominate the routers. Quoting from the current ND draft: 6.2.7. Router Advertisement Consistency Routers SHOULD inspect valid Router Advertisements sent by other routers and verify that the routers are advertising consistent information on a link. Detected inconsistencies indicate that one or more routers might be misconfigured and SHOULD be logged to system or network management. The minimum set of information to check includes: - Max Hop Limit values (except for the unspecified value of zero). - Values of the M or O flags. - Reachable Time values (except for the unspecified value of zero). - Retrans Timer values (except for the unspecified value of zero). - Values in the MTU options. - Preferred and Valid Lifetimes for the same prefix. Note that it is not an error for different routers to advertise different sets of prefixes. Also, some routers might leave some fields as unspecified, i.e., with the value zero, while other routers specify values. The logging of errors SHOULD be restricted to conflicting information that causes hosts to switch from one value to another with each received advertisement. >By the way, I'd like the discovery draft to say that the link-local >prefix FE80::/10 should not (or must not) be advertised in Prefix >Information options. The addrconf draft includes the following text with regards to processing Prefix Information Options: For each Prefix-Information option in the Router Advertisement: a) If the Autonomous flag is not set, silently ignore the Prefix Information option. b) If the prefix is the link-local prefix, silently ignore the Prefix Information option. [remainder of rules deleted] 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 Sun Nov 19 11:10:33 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02246; Sun, 19 Nov 95 11:10:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02240; Sun, 19 Nov 95 11:10:22 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06506; Sun, 19 Nov 1995 10:57:06 -0800 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id KAA00139; Sun, 19 Nov 1995 10:57:09 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA19974; Sun, 19 Nov 1995 10:51:16 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31695; Sun, 19 Nov 1995 13:51:11 -0500 Message-Id: <9511191851.AA31695@wasted.zk3.dec.com> To: roque@di.fc.ul.pt Cc: "Thomas Narten" , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 832) Re: Anycast Addresses In-Reply-To: Your message of "Sat, 18 Nov 95 15:36:42 +0100." <199511181436.PAA24730@oberon.di.fc.ul.pt> Date: Sun, 19 Nov 95 13:51:11 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Working Group. I strongly urge you to get into this discussion. I agree with Pedro that anycast addresses should also be assignable to hosts. For different reasons I will enter into below. Lets think about this and possibly yet another discussion for Dallas. %> Pedro, %> %> >This kind of mecanisms could be introduced, I think, as experimental in the %> >early stages of IPng development. My main concern is that router software is %> >not that hard to change host software is. If the use of anycasting requires %> >changes to any machine that wants to *serve* a anycast address it would be %> >better to have that interface planned in advance even if it's only a %> >experimental feature and the initial solution is not optimal. It really does need to be supported at a minimum so we can experiment with anycast addresses on LANs and then solve the more complex problem for WANs. In addition they can be used by emerging protocols like Service Location to locate agents for the clients and those registering services. I have the believe that anycast addresses are useful when multicast is too noisy for the LAN in particular and I also believe for the WAN. %> It's not clear to me that anycast addresses can/should be used for %> generic services in the same way unicast IP addresses are used. For %> example, one can't open a TCP connection to an anycast address because %> anycast addresses aren't allowed as source addresses. What we need to discuss are what uses does an anycast address have to an implementer of IPv6 Host products? And why would it be used instead of Multicast? Its clear to me anyway that anycast addresses have a use on hosts. %Of course that this implies that the source address would be replaced by the %unicast address of the server.. impling that the packet needs to be signed %width the anycast address by the repective private key ... %gosh! i've started thinking of the dreadful EIDs again :-) I don't believe this is a problem as Thomas stated. WHen I get my DNS AAAA record I get back an address for foo.com. It happens to be an anycast address (or I got it back from the Service Location protocol). I think we can head down the path Pedro suggests as one avenune. ANother one would be the host that processes the anycast address knows to in fact respond via unicast with the anycast address. We can define and discuss a one-to-one relationship between anycast and unicast. The host with the anycast address knows to use it as a source address. The only node that will respond to the packet is the destination address. This type of rule-set can be specified. I don't like this but discussing it might be useful for us. Another option is note anycast addresses in some way in the DNS. Then the originating host notes that this PCB entry is an anycast address. We can define a destination option in IPv6 that when the sender is responding to an anycast packet it must enter a final destination option that contains the anycast address responding to the original sender to the anycast host. This could be used to build many services where anycast is better for the network than a multicast packet. I would think that anycast addresses would be used for optional types services on the network as opposed to required services. %> The response %> packets would come from a different (read "wrong") address and which %> the client would not be able to associate return packets with the %> connection being opened. (A similiar argument applies to much %> UDP-based traffic.) Consequently, it is likely that any *host* %> (client) wanting to use anycast addresses will need to be modified to %> somehow "do the right thing". %yes the a mofication is necessary for the host to recognise the "Autenticated %Address Change" This is a no brainer if we want to use them. %>> That is, modifications won't necessarily %>> be restricted to just routers. %>You are totaly right ... but can we reach a small set of simple modifications %>that can allow us to explore this kind of possibilities ? %>( i don't know the answer ... ) So what if the modifications support a needed and useful function sys admins will make them and engineers like me will build mechanisms for them to do it in future products. Modifications are a red herring in this debate. %> Another reason for restricting anycast addresses to routers is that %> routers presumably will be running routing protocols and can inject %> prefixes covering their anycast addresses into the routing %> systems. How will servers (i.e., hosts) do this? Will we require that %> all servers with anycast addresses run routing protocols? Ouch! %No, just a "Anycast Group Membership Report" ICMP. %We just the same very thing for multicast. Group members are left the %iniciative of joining & leaving groups and don't have to know a thing about %routing. The difference here is just in the semantics of the groups that the %network layer will provide. This is why I wanted routers to share the prefixes with hosts as a MUST. But if ND does not do that then your right we will listen to the routing protocols on the hosts and make it work. But I like Pedro's idea of Anycast Group Membership. That is doable. I would like to hear other "technical" or "architecture" arguments against anycast addresses for hosts other than the ones presented thus far, which IMHO were not very strong. Also uses of anycast addresses you can think of for hosts. Working Group please respond to this.... 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 Nov 19 14:38:13 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02349; Sun, 19 Nov 95 14:38:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02343; Sun, 19 Nov 95 14:38:02 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12456; Sun, 19 Nov 1995 14:24:47 -0800 Received: from oberon.di.fc.ul.pt by mercury.Sun.COM (Sun.COM) id OAA10172; Sun, 19 Nov 1995 14:24:42 -0800 Received: from localhost (roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) with SMTP id XAA27936; Sun, 19 Nov 1995 23:21:00 +0100 Message-Id: <199511192221.XAA27936@oberon.di.fc.ul.pt> X-Authentication-Warning: oberon.di.fc.ul.pt: Host localhost didn't use HELO protocol X-Authentication-Warning: oberon.di.fc.ul.pt: roque owned process doing -bs X-Mailer: exmh version 1.6.1 5/23/95 To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Reply-To: roque@di.fc.ul.pt From: roque@di.fc.ul.pt Subject: (IPng 833) Re: Anycast Addresses In-Reply-To: Your message of "Sun, 19 Nov 1995 13:51:11 EST." <9511191851.AA31695@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Nov 1995 23:20:46 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What we need to discuss are what uses does an anycast address have to an > implementer of IPv6 Host products? And why would it be used instead of > Multicast? Its clear to me anyway that anycast addresses have a use on > hosts. I think that any medium size domain would like to use anycast for DNS servers if it would provide a way to balance the load between servers and if it would detect server failures and provide a replicated service. I can think of some ISPs that would use them for their news server and mailhost too if it worked ... it seams to me that they would even like to replicate their pop servers. Those kind of machines take a lot of load and their failure is quite annoying ... it would be nice to hear something from the "we've-got-two-power-supply- generators" industry as well > ANother one would be the host that processes the anycast address knows > to in fact respond via unicast with the anycast address. We can define > and discuss a one-to-one relationship between anycast and unicast. The > host with the anycast address knows to use it as a source address. The > only node that will respond to the packet is the destination address. > This type of rule-set can be specified. I don't like this but > discussing it might be useful for us. It would be better if the client didn't need to have a splicit notion of anycast address. Let me clarify my proposal a bit ... Suppose you people get to define a "Transport Address Change Extension Header" (well i realy don't like this name :-( ).. on receipt it would work as follows: - The IPng layer would autenticate the packet width the address contained in the Extension Header - After authentication it would search for the socket identified by: and change the socket's foreign address to Extension Header Addr. - Notify the transport protocol now this poses a question to the end-to-end people: wich protocols can take an address change with no pain ? I think TCP can... the old destination cache entry could be copyed and it's next_hop pointer set to Unknown but i don't think that to be a good ideia... Now this puts the problem of identifying a anycast address on the server... but the server allready knows that this address is anycast because it has registred her as so ( supposing you ppl. buy the ideia of the Anycast ICMP report ) The advantages i see with this aproach is that this kind of TLA change could be usefull for mobility support... i.e. the mobile host after receiving a SYN from the automatic tunnel it's host agent sets for him could request a TLA change I can be mistaken but i think this opens a new full can of worms to TCP retransmition ... hummm TLA could only be changed in the requester on the receipt of an ACK ... Also in the case you have a multihomed domain that uses multiple global prefixes and the host as knoledge of routing paths, either by participating in router protocols or by quering a route server, the could cost request a TLA change so that trafic would be done by a sortest path > %yes the a mofication is necessary for the host to recognise the "Autenticated > %Address Change" > > This is a no brainer if we want to use them. I'm a bit ashamed to ask this but does that expression means that it's an easy think to do ? I'm not to confortable with some expressions sorry :-( well the big problem i see with it is the authentication part ... how are the current efforts on key distribution going ? > So what if the modifications support a needed and useful function sys > admins will make them and engineers like me will build mechanisms for > them to do it in future products. Modifications are a red herring in > this debate. I didn't express myself too well in the first mail... I was asking for the minimum set of modifications now because to introduce them later is problematic .. there are still to many machines out there that cannot be multicast clients of the implementor point of view we can say that multicast client support is simple (IMHO) > This is why I wanted routers to share the prefixes with hosts as a MUST. > But if ND does not do that then your right we will listen to the routing > protocols on the hosts and make it work. > > But I like Pedro's idea of Anycast Group Membership. That is doable. > > I would like to hear other "technical" or "architecture" arguments > against anycast addresses for hosts other than the ones presented thus > far, which IMHO were not very strong. Also uses of anycast addresses > you can think of for hosts. There is a potential problem ... how to protect ppl. from configuring anycast addresses that are used as another hosts as a anycast address ... ? cleary on a given site the anycast address pool should be taken out of an unused subnet address space with the sites prefix... but there should be a way to enforce this ... IPng must try hard not let ppl. shoot themselfs in their feet... (hint: routers know the domain topology, only routers should be able to register anycast addresses in an anycast routing system ) > thanks > /jim > Thanks, Pedro Roque ( roque@di.fc.ul.pt ) Faculdade de Ciências da Universidade de Lisboa Departamento de Informática ------------------------------------------------------------------------------ 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 Nov 20 08:56:12 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02785; Mon, 20 Nov 95 08:56:12 PST Received: from caribe.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00737; Fri, 17 Nov 95 15:50:40 PST Received: from bobo.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA19736; Fri, 17 Nov 1995 15:37:16 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA01813; Fri, 17 Nov 1995 15:36:48 -0800 Date: Fri, 17 Nov 1995 15:36:48 -0800 From: nordmark@caribe-86 (Erik Nordmark) Message-Id: <199511172336.PAA01813@bobo.eng.sun.com> To: ipng@sunroof, addrconf@cisco.com Subject: (IPng 834) New ND draft submitted Cc: nordmark@caribe-86, narten@vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We've submitted a revised Neighbor Discovery internet draft today. If you want to look at it before it shows up in the internet drafts directory you can get it from: ftp://parcftp.xerox.com/pub/ipng/draft-ietf-ipngwg-discovery-03.txt The changes are based on the discussions at the interim WG meeting in Washington DC. Note that there are some changes to packet formats in this revision as detailed in the minutes from that meeting. The key ones are: - the ICMP Sender Address field has been removed from the NA - use of Hop Limit 255 for all ND packets - no longer using link-local source address for RS, NS, and NA packets - Changed redirect ICMP type from 5 to 137 (to make it an informational message) - renamed the secondary advertisement flag to "override" and inverted its semantics Also, the draft has been restructured to have all the packet and option formats in one place. Below is the exerpted list of changes. Erik & Thomas ---------- APPENDIX E: CHANGES SINCE PREVIOUS VERSION There are several changes since the previous version documented in: based on feedback from the working group: Protocol changes: o Changed redirect ICMP type from 5 to 137 to make it an informational ICMP message. o Simplified the technique for filtering out ND packets sent from off-link sources. This entailed: o Added the Hop Count 255 rules for transmit and receive verification to be able to ignore packets sent from off-link sources. o Removed the requirement that NS and NA be sent with link-local source address. This removed the need for the ICMP Sender Address field in the NA messages. These changes undo many of the changes between the -01 and -02 revisions of this document. o Removed the validity check for all messages that did not allow a routing header. o Removed "no NUD for ND Packets" rule o Setting the IP priority field to 15 in all ND packets. o Inverted the semantics of the 'N' flag (secondary advertisement flag) in Neighbor Advertisements and renamed it to the Override flag. o Added rules for periodic randomization of ReachableTime to avoid long-range periodic behavior when there are no routers on the link. The ReachableTime randomization only takes place when a RA advertises a different value or once every few hours. o Made the bits in the prefix after prefix length bit reserved (zero on transmit and ignored on receipt). o Allow RS packets to be sent with an unspecified source address so that duplicate address detection can be done in parallel with sending a RS. o Changed the router behavior for responding to RS so that all solicited RA messages are multicast to all-nodes with a rate limit (one message at most every 3 seconds) and a random dithering (of .5 seconds). o Increased the lower limit on MaxRtrAdvInterval and MinRtrAdvInterval to match the rate limit imposed on solicited RA messages. o Changed the timers for hosts sending RS to match the routers response. o Made hosts always send one RS messages when initializing to avoid problems when routers only send subsets of options in RA messages. o Made the RETRANS_TIMER 1 second with the ability for IP-over-foo documents to override this default value. o Added general rules that default values for protocol constants and variables may be overridden by an IP-over-foo document. This rule allows ND to operate over links with widely varying performance characteristics. o Default setting of AdvSendAdvertisements changed to FALSE to prevent "routers" from connecting to the network "out of the box" and sending out bogus advertisements prior to being explicitly configured. Editorial changes: o Created standalone Packet Formats Section between Overview and Conceptual Model sections. Packet Formats had previously appeared at the start of the section describing a particular message type. o Changed AdvertiseDefault flag to AdvSendAdvertisements. Flag now indicates whether RAs should be sent. The variable AdvDefaultLifetime controls whether we advertise ourselves as a default router. Thus, a router can advertise prefixes and other info without being used as a default router. o Added paragraph to Requirements section making it clear that compliance is defined by external behavior, not use of variables described in the document o Changed the name of "is_router" flag to IsRouter for consistency with other names. o Changed names of all router configuration variables to begin with the prefix Adv (e.g., AdvRetransTimer) o Changed deprecation lifetime to preferred lifetime and invalidation lifetime to valid lifetime to make the names consistent with [ADDRCONF]. o Added text to point out that options that don't belong in a particular ND message (e.g., prefix option on neighbor solicitation) MUST be silently ignored. o Added text to state that on-link flag being zero in a prefix option does not imply that the prefix is off-link. o Moved the multihoming material to an appendix. o Added bit numbering to all formats. o Clarified that the Target link-layer address option in a NA has to be the address of the sender. o Introduced the STALE and DELAY states to better explain the behavior of NUD. o Clarified that updated cache entries only go to STALE state when the link-layer address is different than the recorded address. o Clarified that NUD specifies that reachability confirmations to change state to REACHABLE independent of current state. o Created an appendix to illustrate the rules for reachability state transitions. o Added some minor text to "Comparison with IPv4" about why IPv4 router discovery preferences are not needed in ND. o Added text to "Comparison with IPv4" to point out that the use of link-local source addresses for RA and Redirect messages makes it possible for hosts the maintain the router associations in the event of renumbering. o Strengthened text pointing out that the conceptual model is not required by implementations but instead it is only the externally visible behavior that is specified. o Added text about implementation issues with positive reachability advice from upper layers. o Add wording that says all subsequent text assumes that message/action applies to a specific interface so we don't always have to say "receiving interface", etc.? o Made it more clear that the text in the packet format describes "common use", e.g., "the destination address is ...". It does not (always) list hard constraints. o Added text to point out that when an entry is deleted from the router list all destination cache entries using that router must be "updated". ------------------------------------------------------------------------------ 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 Nov 20 09:46:48 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02830; Mon, 20 Nov 95 09:46:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01331; Fri, 17 Nov 95 23:58:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00797; Thu, 16 Nov 1995 13:23:29 -0800 Received: from brookfield.ans.net by mercury.Sun.COM (Sun.COM) id NAA21220; Thu, 16 Nov 1995 13:23:28 -0800 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id QAA04039; Thu, 16 Nov 1995 16:23:05 -0500 Message-Id: <199511162123.QAA04039@brookfield.ans.net> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au, shand@shand.reo.dec.com, thomas@netrix.lkg.dec.com Reply-To: curtis@ans.net Subject: (IPng 835) Re: [IPv6Imp] Call for input on IPv6 multihoming issues In-Reply-To: Your message of "Mon, 13 Nov 1995 11:56:27 EST." <9511131656.AA30185@wasted.zk3.dec.com> Date: Thu, 16 Nov 1995 16:23:02 -0500 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <9511131656.AA30185@wasted.zk3.dec.com>, bound@zk3.dec.com writes: > I am sending this message for Mike Shand to get the word out. > IPng WG Chairs can we get time on the IPng Agenda at Dallas to discuss > with the working group. > > thanks > /jim > > Call for input on IPv6 multihoming issues. > ========================================= > > I'm starting work, in collaboration with Matt Thomas and Jim Bound, on > a draft dealing with mechanisms for the support of multihoming in > IPv6. I have some experience in this area, having designed the > multihoming support in another protocol suite! I'm looking for input > in the following areas. > > 1) What are the requirements for multihoming support? > a) Must have > b) Nice to have Absolutely must have! > 2) What particular problems have been exposed? Applications which bind to one of the interface addresses fail to use an alternate address if that interface goes down. > 3) What proposals already exist to solve these problems? Put a sepoarate address on the loopback address in addition to the usual address for the loopback (127.0.0.1 for IPv4). Make the DNS A record address of the box equal to the loopback alias. Make sure all applications that you care a lot about (in our case kerberized applications, so a change to some kerberos libraries did the trick for everything) bind to the loopback address. If one interface goes down, existing TCP flows stay up, with traffic simply reaching the loopback through a different route. > I've got a feel from previous discussions on the lists, but if you > have a strong opinion about the direction we should take, I'd like > hear it. I have no desire to re-invent any wheels. > > It would be nice to have a good idea of where we are going before > Dallas. > > You can contact me at shand@shand.reo.dec.com > > Mike Shand Curtis ------------------------------------------------------------------------------ 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 Nov 20 10:40:27 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03059; Mon, 20 Nov 95 10:40:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03044; Mon, 20 Nov 95 10:40:00 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09539; Mon, 20 Nov 1995 10:26:43 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id KAA10677; Mon, 20 Nov 1995 10:26:43 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13318; 20 Nov 95 9:39 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 836) I-D ACTION:draft-ietf-ipngwg-discovery-03.txt Date: Mon, 20 Nov 95 09:39:50 -0500 Message-Id: <9511200939.aa13318@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-03.txt Pages : 86 Date : 11/17/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-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-discovery-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-discovery-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951117172243.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-discovery-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-discovery-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951117172243.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 Nov 20 14:14:34 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03280; Mon, 20 Nov 95 14:14:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03274; Mon, 20 Nov 95 14:14:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07957; Mon, 20 Nov 1995 14:01:07 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id OAA08177; Mon, 20 Nov 1995 14:01:07 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15413(8)>; Mon, 20 Nov 1995 14:01:00 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 20 Nov 1995 14:00:55 -0800 To: ipng@sunroof.eng.sun.com Cc: hinden@ipsilon.com, deering@parc.xerox.com Subject: (IPng 837) call for ipngwg agenda items Date: Mon, 20 Nov 1995 14:00:47 PST From: Steve Deering Message-Id: <95Nov20.140055pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have two consecutive slots on the Dallas agenda for IPng Working Group meetings: Thursday, Dec 7, 0900 - 1130 Thursday, Dec 7, 1300 - 1500 I have started to put together a list of agenda topics (yeah, I know, this is breaking precedent to do this before the day of the meeting :-) ). Below are the topics I have so far; if there are additional topics you wish to add to this list, please post them to the ipng list (or privately to Bob and myself, if you are uncertain about the appropriateness of your suggested topic). o deal with comments, if any, arising from WG Last Call for: - IPv6-over-Ethernet spec - Neighbor Discovery spec o status of other IPv6-over-foo specs: - Token Ring - FDDI - PPP - other o multihomed hosts - uniquifying link-local addresses within host? - other issues? o review PMTU Discovery for IPv6 draft o review IPv6 tunneling draft o use/possession of anycast addresses by hosts o authentication as an Option, rather than Extension Header? 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 Tue Nov 21 06:24:00 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03932; Tue, 21 Nov 95 06:24:00 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03926; Tue, 21 Nov 95 06:23:49 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27438; Tue, 21 Nov 1995 06:10:32 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id GAA26145; Tue, 21 Nov 1995 06:10:32 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4482; Tue, 21 Nov 95 09:10:28 EST Received: by RTP (XAGENTA 4.0) id 6938; Tue, 21 Nov 1995 09:10:14 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA15633; Tue, 21 Nov 1995 09:10:14 -0500 Message-Id: <9511211410.AA15633@cichlid.raleigh.ibm.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com, hinden@ipsilon.com Subject: (IPng 838) Re: call for ipngwg agenda items In-Reply-To: Your message of "Mon, 20 Nov 1995 14:00:47 PST." <95Nov20.140055pst.75270@digit.parc.xerox.com> Date: Tue, 21 Nov 1995 09:10:14 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scanning the 10/10/95 IAB meeting minutes, I stumbled across the following: > IPv6 specification now moved to proposed, but there is not a lot of strong > support. A number of people feel that the IETF consensus on IPv6 was not > technically strong. Also, other parts of the stack need to be worked on, > but doesn't seem to be getting adequate attention. It was generally agreed > that we should encourage the IESG to move IPv6 (and upper layer > modifications to go with it) forward as quickly as possible. I think it would be a useful exercise to have some discussion about what areas we are "neglecting" and setting overall priorities. Routing on multihomed hosts is an issue that comes to mind. Everyone seems to agree that we need to spend time on it, but so far little has been done. I think we have a window of opportunity in this area. If we wait too long, however, the opportunity vanishes. What do folks think are the key neglected issues/areas that must be addressed before deployment/acceptance? What are the showstoppers? The comment that "IETF consensus on IPv6 was not technically strong" is also a bit unsettling. Is this because IPv6 isn't a big enough advance beyond IPv4 (e.g., "solve" the routing/growth problem) or what? 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 Tue Nov 21 06:55:57 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03978; Tue, 21 Nov 95 06:55:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03972; Tue, 21 Nov 95 06:55:46 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29789; Tue, 21 Nov 1995 06:42:28 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id GAA02151; Tue, 21 Nov 1995 06:42:29 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5972; Tue, 21 Nov 95 09:42:26 EST Received: by RTP (XAGENTA 4.0) id 6946; Tue, 21 Nov 1995 09:42:16 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20857; Tue, 21 Nov 1995 09:42:20 -0500 Message-Id: <9511211442.AA20857@cichlid.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 839) Length value of ND options Date: Tue, 21 Nov 1995 09:42:20 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the current ND spec, the Length field of an option specifies the length in 8-octet units, including the first 8 octets of the option. E.g., the minimum sized Length is 1; 0 is not a legal value. In the IPv6 Hop-by-Hop and Destination header options, the Length excludes the first 8 octets, so a value of 0 means "8 octets total". Which encoding should ND use? The second style does eliminate the Length==0? test and allows the max sized option to be 8 octets bigger than at present. 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 Tue Nov 21 07:32:12 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04117; Tue, 21 Nov 95 07:32:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04111; Tue, 21 Nov 95 07:32:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02914; Tue, 21 Nov 1995 07:18:45 -0800 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id HAA09231; Tue, 21 Nov 1995 07:18:43 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA18810; Tue, 21 Nov 1995 16:17:55 +0100 Received: by dxcoms.cern.ch id AA25684; Tue, 21 Nov 1995 16:17:53 +0100 Message-Id: <9511211517.AA25684@dxcoms.cern.ch> Subject: (IPng 840) Re: call for ipngwg agenda items To: narten@VNET.IBM.COM (Thomas Narten) Date: Tue, 21 Nov 1995 16:17:53 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: deering@parc.xerox.com, ipng@sunroof.eng.sun.com, hinden@ipsilon.com In-Reply-To: <9511211410.AA15633@cichlid.raleigh.ibm.com> from "Thomas Narten" at Nov 21, 95 09:10:14 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, > I think it would be a useful exercise to have some discussion about > what areas we are "neglecting" and setting overall priorities. I think the full list is in RFC 1752. The issue is not that the ipng and addrconf WGs are slipping, but that many other groups need to take IPv6 on board. Some have started (ATM and mobility to name but two) so it is not all bad. Making a prioritised list is an excellent suggestion IMHO. > > The comment that "IETF consensus on IPv6 was not technically strong" > is also a bit unsettling. Is this because IPv6 isn't a big enough > advance beyond IPv4 (e.g., "solve" the routing/growth problem) or > what? The people who disagreed with the recommendation in Toronto still disagree. And yes, I guess their basic argument was that IPv6 is "too little, too soon". The IAB consensus was strong support for IPv6 and we wanted to re-emphasise that. Thanks for reading the IAB minutes! Brian Carpenter ------------------------------------------------------------------------------ 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 Nov 21 07:43:52 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04162; Tue, 21 Nov 95 07:43:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04153; Tue, 21 Nov 95 07:43:40 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03809; Tue, 21 Nov 1995 07:30:23 -0800 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id HAA11508; Tue, 21 Nov 1995 07:30:23 -0800 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7338; Tue, 21 Nov 95 10:30:20 EST Received: by RTP (XAGENTA 4.0) id 6968; Tue, 21 Nov 1995 10:30:09 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20810; Tue, 21 Nov 1995 10:30:10 -0500 Message-Id: <9511211530.AA20810@cichlid.raleigh.ibm.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 841) Re: WG last call: IPv6 over Ethernet In-Reply-To: Your message of "Mon, 13 Nov 1995 12:39:44 PST." <95Nov13.123946pst.75270@digit.parc.xerox.com> Date: Tue, 21 Nov 1995 10:30:10 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, Looks good overall. Just a few comments, some of which WG input might be useful. > Maximum Transmission Unit > > The default MTU size for IPv6 packets on an Ethernet is 1500 octets. > This size may be reduced by a Router Advertisement [DISC] containing > an MTU option which specifies a smaller MTU, or by manual > configuration of each node. If a Router Advertisement is received > with an MTU option specifying an MTU larger than 1500, or larger than > a manually configured value less than 1500, that MTU option must be > ignored. Do we want the "or larger than a manually configured value less than 1500" part of the last sentence to be true in general? That is, an MTU advertisement can't increase the MTU above a manually configured value? This could lead to situations where a sending node thinks the MTU is XXX, but a receiving node thinks its YYY (YYY < XXX). It's even conceivable (??) that the receiving node may even be unable to receive packets of size XXX. Also, if the above is really the desired default behavior, wouldn't it be more appropriate to put the rule in the ND spec rather than in each individual v6-over-foo document? > Frame Format > > IPv6 packets are transmitted in standard Ethernet frames. The > ethernet header contains the Destination and Source ethernet > addresses and the ethernet type code, which must contain the value > 86DD hexadecimal. The data field contains the IPv6 header followed > immediately by the payload, and possibly padding octets to meet the > minimum frame size for Ethernet. > > +-------+-------+-------+-------+-------+-------+ ^ > | Destination Ethernet address | | > +-------+-------+-------+-------+-------+-------+ ethernet > | Source Ethernet address | header > +-------+-------+-------+-------+-------+-------+ | > | 86 DD | v > +-------+-------+-------+-------+-------+------+------+ > | IPv6 header and payload ... / > +-------+-------+-------+-------+-------+------+------+ The above picture might be a bit confusing, in that the third line contains only 2 bytes while the other ones contain 6 (or more). (This wasn't immediately obvious to me.) Would it be less confusing to have the same number of bytes in each line? Also, for completeness, shouldn't you include a heading showing the bit number positions for at least some of the pictures? > The address token [CONF] for an Ethernet interface is the interface's > built-in 48-bit IEEE 802 address, in canonical bit order and with the > octets in the same order in which they would appear in the header of > an ethernet frame. (The individual/group bit is in the first octet > and the OUI is in the first three octets.) A different MAC address > set manually or by software should not be used as the address token. Perhaps change "should not" in last sentence to "MUST NOT" (or at least "must not")? We really don't want the the token to be taken from an alternate MAC address. It should be the IEEE 802 address, or an alternate token supplied by the sys admin. Right? 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 Tue Nov 21 07:53:36 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04187; Tue, 21 Nov 95 07:53:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04181; Tue, 21 Nov 95 07:53:20 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04787; Tue, 21 Nov 1995 07:40:03 -0800 Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM) id HAA13579; Tue, 21 Nov 1995 07:40:04 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id KAA19549; Tue, 21 Nov 1995 10:39:06 -0500 (EST) Date: Tue, 21 Nov 1995 10:39:06 -0500 (EST) From: Scott Bradner Message-Id: <199511211539.KAA19549@newdev.harvard.edu> To: brian@dxcoms.cern.ch, narten@VNET.IBM.COM Subject: (IPng 842) Re: call for ipngwg agenda items Cc: deering@parc.xerox.com, hinden@ipsilon.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I guess their basic argument was that IPv6 is "too little, too soon" and this is at the same time as outside observers (Metcalf for example) worry about IPv6 & the second system effect ... 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 Tue Nov 21 09:17:22 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04374; Tue, 21 Nov 95 09:17:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04368; Tue, 21 Nov 95 09:17:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14438; Tue, 21 Nov 1995 09:03:54 -0800 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id JAA03104; Tue, 21 Nov 1995 09:03:55 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA04144; Tue, 21 Nov 1995 08:51:20 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31891; Tue, 21 Nov 1995 11:51:14 -0500 Message-Id: <9511211651.AA31891@wasted.zk3.dec.com> To: "Thomas Narten" Cc: Steve Deering , ipng@sunroof.eng.sun.com, hinden@ipsilon.com, bound@zk3.dec.com Subject: (IPng 843) Re: call for ipngwg agenda items In-Reply-To: Your message of "Tue, 21 Nov 95 09:10:14 -0400." <9511211410.AA15633@cichlid.raleigh.ibm.com> Date: Tue, 21 Nov 95 11:51:14 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >> IPv6 specification now moved to proposed, but there is not a lot of strong >> support. A number of people feel that the IETF consensus on IPv6 was not >> technically strong. Also, other parts of the stack need to be worked on, >> but doesn't seem to be getting adequate attention. It was generally agreed >> that we should encourage the IESG to move IPv6 (and upper layer >> modifications to go with it) forward as quickly as possible. > >I think it would be a useful exercise to have some discussion about >what areas we are "neglecting" and setting overall priorities. >Routing on multihomed hosts is an issue that comes to mind. Everyone >seems to agree that we need to spend time on it, but so far little has >been done. I think we have a window of opportunity in this area. If we >wait too long, however, the opportunity vanishes. Well I took this as sour grapes. I was on the IPng Directorate and been hear awhile now and I believe we do have consensus. As far as the upper layer protocols I think that is vague. As one who keeps harping on if we don't view implementations equally with the abstract we will fail with IPv6, we cannot take on too much at once. This was the feeling in the charter of the IPng Directorate. Like Scott stated read RFC 1752 or I suggest the new book IPng Internet Next Generation Protocol from Addison Wesley. Regarding Multihome: Mike Shand, Matt Thomas, Dan McDonald, and I are going to provide an Internet Draft after Dallas. We are on the agenda for IPv6 at Dallas and Mike Shand has sent out a call for issues on Multihome Nodes (Routers and Hosts). So I suggest for now you respond to that IPng mail with your issues on Multihome Nodes. So that work is in progress and we look forward to your input. >What do folks think are the key neglected issues/areas that must be >addressed before deployment/acceptance? What are the showstoppers? As Brian commented there are no neglected issues in the stack per se we have no issues presented for TCP or UDP. We are working DHCP, DNS, APIs, Transition, et al. We will see OSPFv6 update at Dallas and RIP is out there now. But what is missing is RFC 1001/1002 Update and what other IPv4 specs are affected by IPv6. This is something Scott and Allison stated had to be done, but we had to get our essentials done first. I think its time for someone to make a list of the specs that need updates because of IPv6 or additions that are not being worked on now. Three are 1001/1002 I mentioned above, IDRP, and SNMP. Who is going to compile this list? Are you volunteering? But I see no changes per IPv6 for TCP or UDP. There may be other issues for the transport but not because of IPv6. >The comment that "IETF consensus on IPv6 was not technically strong" >is also a bit unsettling. Is this because IPv6 isn't a big enough >advance beyond IPv4 (e.g., "solve" the routing/growth problem) or >what? Again sour grapes. The IETF was real gentle about selecting IMHO the architecture of SIPP (note two P's from PIP) for IPng and then IPv6. It betwee real intense between the different proposals and in some cases personal. In fact some of us still don't speak to each other at this time as the sour grapes was quite intense. One person has not been to an IETF meeting since the decision and I think that is a loss for our community but thats the way it goes. So your mail is I think bringing up old wounds I think are healing in some respects. But there was consensus for IPv6. Also if your not on the ipv6imp (implementors) list you should know we are not seeing these "other" issues at least in the stacks. I think you (or others on IPng WG) may want to sit down at Dallas with Brian, Scott, or Allison to get a "balanced-objective" picture of what was done for IPng. Now if you want the direct, bold, upfront, or market view on why I think that the orginal ideas of Steve D. and Bob H. were the surpreme and "right" answer for IPng, and why the others were completely not a good idea come talk to me. I am not on the IESG or IAB so I can do this right now anyway. I did believe EIDs were a good idea and still do per the EID view of the world based on Paul Francis work on PIP, but that was a debate a few of us lost, and we move on. /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 Tue Nov 21 09:49:43 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04427; Tue, 21 Nov 95 09:49:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04421; Tue, 21 Nov 95 09:49:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19077; Tue, 21 Nov 1995 09:36:11 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id JAA11660; Tue, 21 Nov 1995 09:36:11 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07916 Wed, 22 Nov 1995 04:33:07 +1100 (from kre@cs.mu.OZ.AU) To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 844) Re: call for ipngwg agenda items In-Reply-To: Your message of "Tue, 21 Nov 1995 11:51:14 CDT." <9511211651.AA31891@wasted.zk3.dec.com> Date: Wed, 22 Nov 1995 04:33:19 +1100 Message-Id: <3478.816975199@cs.mu.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 21 Nov 95 11:51:14 -0500 From: bound@zk3.dec.com Message-ID: <9511211651.AA31891@wasted.zk3.dec.com> we have no issues presented for TCP or UDP. I don't agree with that, except if taken very literally. There has been a TCPng effort supposed to be on the agenda of each of the last two IETFs but which hasn't happened, since the BOF at San Jose. TCP related issues are being pushed that direction, or are simply waiting assuming that would be the correct forum for them. Unfortunately the IPng issues related to TCP, and the question of generally redoing TCP the way that has been done for IP. Because of that TCPng is being treated as a Transport area matter, not IPng, and is also generating deep suspision, as an open slate without either reason or control. However the TCP related issues with IPng - and particularly so that TCP can handle the renumbering that is being so intensely worked upon in IPng. Addresses that fade into oblivion aren't particularly useful if they require TCP connections to die. Either large numbers of applications or TCP will need to be modified to be able to handle this transparently. IPng simply isn't done until this has been attended to. There may be other minor issues as well. Fortunately there are moves now to at least start this at Dallas, so somethig may be done. We certainly can't consider shipping IPv6 to more than beta testers until implementations can handle whatever results. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 21 10:27:58 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04498; Tue, 21 Nov 95 10:27:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04488; Tue, 21 Nov 95 10:27:43 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24625; Tue, 21 Nov 1995 10:14:25 -0800 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id KAA22527; Tue, 21 Nov 1995 10:14:26 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA32353; Tue, 21 Nov 1995 10:08:23 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA06229; Tue, 21 Nov 1995 13:08:17 -0500 Message-Id: <9511211808.AA06229@wasted.zk3.dec.com> To: Robert Elz Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 845) Re: call for ipngwg agenda items In-Reply-To: Your message of "Wed, 22 Nov 95 04:33:19 +1100." <3478.816975199@cs.mu.OZ.AU> Date: Tue, 21 Nov 95 13:08:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre, >> we have no issues presented for TCP or UDP. >I don't agree with that, except if taken very literally. WHOOOAAAA. I was very careful with my mail and you took the above sentence out of context. I said because of what we have "specfied" for IPv6 there are no TCP or UDP issues. Not that we don't have transport issues in general (e.g. ATM, RSVP, EIDs). I just spent the entire a.m. reviewing IPv6 transport code for reasons I won't go into. There is nothing in RFC 768 (UDP) or RFC 793 (TCP) that REQUIRES ANY CHANGES BECAUSE OF IPv6. So lets be very specific. Sure there are thoughts for TCP and UDP that may need TCPng and UDPng work. NOTE NOT JUST FOR TCP BUT UDP TOO. >There has been a TCPng effort supposed to be on the agenda >of each of the last two IETFs but which hasn't happened, since >the BOF at San Jose. Yep. At San Jose nothing new was presented IMHO. So again be specific. >TCP related issues are being pushed that direction, or are >simply waiting assuming that would be the correct forum for >them. What ISSUES? What DIRECTION? WHat has this to do with IPv6 and IMHO NOTHING? >Unfortunately the IPng issues related to TCP, and the question >of generally redoing TCP the way that has been done for IP. >Because of that TCPng is being treated as a Transport area >matter, not IPng, and is also generating deep suspision, as >an open slate without either reason or control. First IPng is no longer a valid term except for the title of Working Groups and possibly some marketing strategy. Its IPv6. Now if we believe we need changes to TCP and UDP then we MAY need a TCPng and UDPng effort and I suggest the IETF go through the same process we did for IPng to determine a set of issues and proposals. IPng is DONE its IPv6. What is the deep suspision? I don't want to be paranoid? >However the TCP related issues with IPng - and particularly so >that TCP can handle the renumbering that is being so intensely >worked upon in IPng. Addresses that fade into oblivion aren't >particularly useful if they require TCP connections to die. >Either large numbers of applications or TCP will need to be >modified to be able to handle this transparently. Again your being very vague and I see no technical input here. TCP and UDP need to deal with in IPv6 the deprecated and valid address scenarios and it does affect the "implementation" of TCP and UDP but so does the API spec and transition. But these are "implementation" matters not RFC 768 or RFC 793 matters. Renumbering in "general". We need to see what PIER BOF produces at Dallas for work to make sure renumbering will work for IPv4 and IPv6. Whether the transport layers are part of that outcome needs discussion but I don't think so. >IPng simply isn't done until this has been attended to. There >may be other minor issues as well. What Renumbering, TCPng, UDPng, or what? What is your last sentence referring too. Your also under the WRONG IMPRESSION IMHO that its not IPng anymore its IPv6 (sorry but your mail makes me want to repeat myself). >Fortunately there are moves now to at least start this at >Dallas, so somethig may be done. We certainly can't consider >shipping IPv6 to more than beta testers until implementations >can handle whatever results. What the heck does the above mean? What does "whatever" mean above? You provide a very negative statement without any supporting data to this list and I object to that greatly. Please be clear what your issues are about IPv6 and Transports? So far you have presented NONE. It appears to me you have a hidden agenda or purpose or general frustration with where IPv6 is now. Be direct because I can't parse youre vagueness in your mail and I believe your input to be very important in the IETF. I just don't get your point or why you still call things IPng when they are IPv6? /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 Tue Nov 21 11:07:16 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04567; Tue, 21 Nov 95 11:07:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04561; Tue, 21 Nov 95 11:07:00 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01544; Tue, 21 Nov 1995 10:53:41 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id KAA11277; Tue, 21 Nov 1995 10:53:36 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA09441 Wed, 22 Nov 1995 05:49:49 +1100 (from kre@cs.mu.OZ.AU) To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 846) Re: call for ipngwg agenda items In-Reply-To: Your message of "Tue, 21 Nov 1995 13:08:17 CDT." <9511211808.AA06229@wasted.zk3.dec.com> Date: Wed, 22 Nov 1995 05:50:00 +1100 Message-Id: <3534.816979800@cs.mu.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 21 Nov 95 13:08:17 -0500 From: bound@zk3.dec.com Message-ID: <9511211808.AA06229@wasted.zk3.dec.com> I said because of what we have "specfied" for IPv6 there are no TCP or UDP issues. I disagree. IPv6 has addresses that transparently change, and that is good, and desireable. TCP uses addresses as connection identifiers, which must remain stable for the life of the conenction. Other than requiring that TCP connections not survive a renumber event, which I believe is unacceptable, TCP is going to have to deal with its connection identifiers changing out from under it. First IPng is no longer a valid term except for the title of Working Groups and possibly some marketing strategy. Actually, I was (attempting to be) quite careful in my usages of IPng and IPv6 - where I used IPng I meant the IPng area (the WG is IPngwg, and the protocol, as you point out, is IPv6). IPng is DONE its IPv6. Again, I disagree. The IP level protocol of IPng is done, and that is IPv6 - there is more that has to be done to make the whole thing work (which includes transition, etc, as well as TCP related issues). What is the deep suspision? I don't want to be paranoid? There I just meant that the people who think of what I call TCPng as being a next generation TCP, and not TCP for IPng, or some of them, probably with good reason, are suspicious of attempts to start on a whole new transport protocol spec, especially any such attempt that appears to be modifying TCP. That isn't what I want, and isn't what I call TCPng, but there may be others who do. It may be that TCPng is a poor name, I don't care one way or the other. But I do believe there are TCP related issues that at least need to be discussed before considering IPng (nb: IPng, not IPv6) done. TCP and UDP need to deal with in IPv6 the deprecated and valid address scenarios and it does affect the "implementation" of TCP and UDP Unless your definition of "deal" is "reet the connection" (or similar), these aren't implementation issues, they're protocol. The TCP connection has to be able to survive when the address used to establish it is long gone (and probably reallocated to soem other host). Recall the people who argued against keepalives, requiring that TCP connections be able to remain alive for as long as the two hosts remain active, and the user (or whatever) wants the connection to remain alive? That is, regardless of what is happening at the IP or lower layers. This is the same issue, but actually even simpler (keepalives also detect hosts that have rebooted, or simply vanished) We need to see what PIER BOF produces at Dallas for work to make sure renumbering will work for IPv4 and IPv6. Without knowing what will happen in pier its hard to say. I must admit that my impression is that pier is much more related to the practical issues of what needs to be done to renumber (currnt) IPv4 hosts, and what might be possible to make that easier. I'm not sure that IPv6 will get a lot of consideration, in theory, renumbering (and all address assignments) in IPv6 are automatic, right? Whether the transport layers are part of that outcome needs discussion but I don't think so. Needs discussion is the important part. Some of that looks scheduelled for Dallas (distinct from pier, last I heard in the transport directorate meeting). What Renumbering, TCPng, UDPng, or what? The transport protocols need to be able to handle that which the IPv6 protocol makes available. IPv6 allows host addresses to change, the transport protocols must cope with that. What is your last sentence referring too. I don't know - that was the point. I don't claim to be able to predict every issue that someone may have with TCP (or UDP) and its operation under IPv6. That's why we need the opportunity to discuss the issues. There's no question but that TCP (as exists) will work with IPv6, I believe that has been demonstrated. Whether the fit is right is what I question. What the heck does the above mean? It means that real customer shipping of IPng (which includes IPv6 - just in case you think I am mixing up labels again) needs to have the complete thing, with everything working together correctly, for optimal results. Retro-fitting later would be difficult, and that difficulty is likely to lead to compromises that we don't need to make. Eg: for one simplistic example, if IPv6 had been shipped to customers already, and was in use, it would have been very difficult to adopt the TTL=255 technique for ND, as all the systems shipped already would no longer work. Because we still have no more than prototypes, that kind of change can still be made where it is seen to be the best technical solution. What does "whatever" mean above? It means that the IETF needs to consider what might need to be done to TCP (etc), and that whatever the results of those considerations are (which I do not predict) need to be taken into account in the implementations before wide deployment. Please be clear what your issues are about IPv6 and Transports? My prime concern is that TCP connections should be able to last years (decades) without being broken, and regardless of how many IPv6 level address changes the hosts involved undergo. However there may well be other issues. It appears to me you have a hidden agenda or purpose or general frustration with where IPv6 is now. Come on Jim, let's remain professional please. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 21 12:38:28 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04653; Tue, 21 Nov 95 12:38:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04647; Tue, 21 Nov 95 12:38:16 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12008; Tue, 21 Nov 1995 12:24:59 -0800 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id MAA07875; Tue, 21 Nov 1995 12:24:59 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA11868; Tue, 21 Nov 1995 12:11:38 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23852; Tue, 21 Nov 1995 15:11:30 -0500 Message-Id: <9511212011.AA23852@wasted.zk3.dec.com> To: Robert Elz Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 847) Re: call for ipngwg agenda items In-Reply-To: Your message of "Wed, 22 Nov 95 05:50:00 +1100." <3534.816979800@cs.mu.OZ.AU> Date: Tue, 21 Nov 95 15:11:30 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre, I said because of what we have "specfied" for IPv6 there are no TCP or UDP issues. >I disagree. IPv6 has addresses that transparently change, >and that is good, and desireable. TCP uses addresses as >connection identifiers, which must remain stable for the life >of the conenction. Other than requiring that TCP connections >not survive a renumber event, which I believe is unacceptable, >TCP is going to have to deal with its connection identifiers >changing out from under it. I don't agree with this point unless we change the existing addr conf and DHCPv6 specs which I am open to if need be. Let me explain (lets just use TCP for now OK). Deprecated Address Processing: App opens TCP connect for addr 1::2 (passive or active don't matter IMHO). The preferred lifetime expires. The node is to go off and find another address or optionally can permit existing connections continue and just not accept connections above the IP layer once an address is deprecated (preferred lifetime expires). Or permit new connections from the node. NOTE existing connections are not broken at this time in anyones interpretation of the spec for a deprecated address. How I determine the other parts is an implementation matter and I am looking at two designs now to do this. One on incoming if the address is deprecated and the other at the transport when going out. We may need a new socket API return code but I am trying to avoid even that change. Valid Address Expires: When this happens all connections are broke. The ODD case is a TCP connection or UDP application that continues over the period between preferred and valid lifetimes expiring. Here is ONE case where we may have a problem. But this is the only case I can come up with so far. Right now according to the specs I have to break the connection in this case. ???????? So here is the problem. TCP cannot survive the renumber event but I think folks need to set the lifetimes for the application environment they understand and this can be avoided for the most part. Other Addresses: If we make an anycast address valid for hosts then we have another issue we talked about a little yesterday on the mail list. I agree this needs some thought. I see nothing in my response above that affects or changes anything about TCP or UDP RFCs that exist today or need to be changed. I have to alter the TCP and UDP mods of today but not the spirit of the RFCs. First IPng is no longer a valid term except for the title of Working Groups and possibly some marketing strategy. >Actually, I was (attempting to be) quite careful in my usages of >IPng and IPv6 - where I used IPng I meant the IPng area (the >WG is IPngwg, and the protocol, as you point out, is IPv6). OK. IPng is DONE its IPv6. >Again, I disagree. The IP level protocol of IPng is done, and >that is IPv6 - there is more that has to be done to make the >whole thing work (which includes transition, etc, as well as >TCP related issues). I consider Transition and the like as part of IPv6 so we agree on that but I am still not clear on your transport issues. I will read on!!!! What is the deep suspision? I don't want to be paranoid? >There I just meant that the people who think of what I call >TCPng as being a next generation TCP, and not TCP for IPng, >or some of them, probably with good reason, are suspicious of >attempts to start on a whole new transport protocol spec, >especially any such attempt that appears to be modifying TCP. >That isn't what I want, and isn't what I call TCPng, but >there may be others who do. It may be that TCPng is a poor >name, I don't care one way or the other. But I do believe >there are TCP related issues that at least need to be discussed >before considering IPng (nb: IPng, not IPv6) done. Well lets find the TCP issues. I can't see them yet! TCP and UDP need to deal with in IPv6 the deprecated and valid address scenarios and it does affect the "implementation" of TCP and UDP >Unless your definition of "deal" is "reet the connection" >(or similar), these aren't implementation issues, they're >protocol. The TCP connection has to be able to survive when >the address used to establish it is long gone (and probably >reallocated to soem other host). OK here is the issue. I agree with you but I can accept just killing the connection when the valid lifetime expires. This is a MUST in the addr conf spec and in my DHCPv6 spec. I see no other option. But am willing to discuss technical ideas? But I am not sure we need to fix UDP and TCP RFCs to make this work, which was my point. Don't forget UDP has the same problem only most likely at the application layer. >Recall the people who argued against keepalives, requiring >that TCP connections be able to remain alive for as long as >the two hosts remain active, and the user (or whatever) wants >the connection to remain alive? That is, regardless of what >is happening at the IP or lower layers. This is the same >issue, but actually even simpler (keepalives also detect >hosts that have rebooted, or simply vanished) Well maybe with renumbering this cannot be the case anymore and the real crux I think of your issue? We need to see what PIER BOF produces at Dallas for work to make sure renumbering will work for IPv4 and IPv6. >Without knowing what will happen in pier its hard to say. >I must admit that my impression is that pier is much more >related to the practical issues of what needs to be done >to renumber (currnt) IPv4 hosts, and what might be possible >to make that easier. I'm not sure that IPv6 will get a lot >of consideration, in theory, renumbering (and all address >assignments) in IPv6 are automatic, right? I agree for Hosts. I am not clear for routers yet. I want to understand what pain routers cause in IPv4 for renumbering and what we may have "overlooked" in IPv6 because we punted on router autoconfiguration and those are nodes at a customers site too. So far all we have discussed on PIER is Hosts. Whether the transport layers are part of that outcome needs discussion but I don't think so. >Needs discussion is the important part. Some of that looks >scheduelled for Dallas (distinct from pier, last I heard in >the transport directorate meeting). Yeah I saw that too! I don't think I can make it if you go an offline update from you would be appreciated. What Renumbering, TCPng, UDPng, or what? >The transport protocols need to be able to handle that which >the IPv6 protocol makes available. IPv6 allows host addresses >to change, the transport protocols must cope with that. I think its only ONE case the valid lifetime expires. What is your last sentence referring too. >I don't know - that was the point. I don't claim to be able >to predict every issue that someone may have with TCP (or UDP) >and its operation under IPv6. That's why we need the >opportunity to discuss the issues. There's no question but that >TCP (as exists) will work with IPv6, I believe that has been >demonstrated. Whether the fit is right is what I question. OK I think thats a good idea and worth discussing too. What the heck does the above mean? >It means that real customer shipping of IPng (which includes >IPv6 - just in case you think I am mixing up labels again) >needs to have the complete thing, with everything working >together correctly, for optimal results. Retro-fitting later >would be difficult, and that difficulty is likely to lead >to compromises that we don't need to make. I agree and right now when that valid lifetime goes off for any existing connections they are dead (meaning flushed or how ever you implement addrconf or DHCPv6). >Eg: for one simplistic example, if IPv6 had been shipped to >customers already, and was in use, it would have been very >difficult to adopt the TTL=255 technique for ND, as all the >systems shipped already would no longer work. Because we >still have no more than prototypes, that kind of change can >still be made where it is seen to be the best technical >solution. I agree COMPLETELY. We need to keep testing the theories. What does "whatever" mean above? >It means that the IETF needs to consider what might need to be >done to TCP (etc), and that whatever the results of those >considerations are (which I do not predict) need to be >taken into account in the implementations before wide deployment. Absolutely. Please be clear what your issues are about IPv6 and Transports? >My prime concern is that TCP connections should be able to >last years (decades) without being broken, and regardless of >how many IPv6 level address changes the hosts involved undergo. OUCH.. I don't agree. Can you give me an example of a TCP connection that lasts for years? Or one where it would be valuable? Even OS particular parts on a distributed LAN don't try this. Clearly with the present renumbering strategy this will not work. >However there may well be other issues. OK. It appears to me you have a hidden agenda or purpose or general frustration with where IPv6 is now. >Come on Jim, let's remain professional please. SORRY. That was mean't in the positive. Hidden Agendas IMHO are not bad and necessary. Sometimes you cannot unload the whole point immediately and be succinct initially. Its better to lead into an area before one dumps the whole problem on the table (or direction) to see if it can be avoided. I thought you may be heading down we need a TCPng (not IPng) because of IPv6 and I wanted to understand that before we talked much more and you cleared that up above. Sorry it came off different your one of the most professional persons I know and would not respond to you an any other manner on purpose. I see your key issue with the valid lifetime rule set when it expires in IPv6. But we should flush out others. Right now I am implementing it so that a TCP or UDP connect/app dies when the valid lifetime expires. Interested in your "transition" thoughts on the transport too. I think this works out but there is one case. IPv4 to IPv6 only. But this is the translation mess and not sure we can figure it out in a standard or that it affects TCP or UDP RFCs. Another potential issue is the use of anycast addresses. Lets suppose I use an anycast address to respond to a client service request. But the real node has a unicast address that the anycast node selects as the node to handle this request (load balancing, clusters. etc). For some reason the unicast addr node goes down but the anycast address is still up. The anycast node wants to transition the entire TCP or UDP state to another node so the client connection continues transparently. I think this to be a useful research project for some of us. So how we define those anycast semantics for a host (and I believe they are useful more than just for routers) is critical to such research work and eventual added value I think for distributed computing in general. But even here I am not clear we need to change TCP or UDP. I think in cases where really new functionality is needed then we need to move to a new transport protocol like the new drafts on RTP or other ideas. /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 Tue Nov 21 14:11:52 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04743; Tue, 21 Nov 95 14:11:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04737; Tue, 21 Nov 95 14:11:36 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26585; Tue, 21 Nov 1995 13:58:15 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id NAA03259; Tue, 21 Nov 1995 13:58:08 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15680 Wed, 22 Nov 1995 08:48:25 +1100 (from kre@cs.mu.OZ.AU) To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 848) Re: call for ipngwg agenda items In-Reply-To: Your message of "Tue, 21 Nov 1995 15:11:30 CDT." <9511212011.AA23852@wasted.zk3.dec.com> Date: Wed, 22 Nov 1995 08:48:37 +1100 Message-Id: <3652.816990517@cs.mu.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 21 Nov 95 15:11:30 -0500 From: bound@zk3.dec.com Message-ID: <9511212011.AA23852@wasted.zk3.dec.com> I don't agree with this point unless we change the existing addr conf and DHCPv6 specs which I am open to if need be. Perhaps. It may not be needed, even if TCP can survive renumbering that these need changing, that is, if TCP switches the address it is using, then it would no longer be using the old address when the valid lifetime expires, and so statements about what should happen in that case would not really be relevant. On the other hand, if a TCP connection was still using an address that is no longer valid (and has not been changed), then I see no viable alternative to killing the connection. So, it is likely that those specs will remain fine as is. Let me explain (lets just use TCP for now OK). Yes, that's what I have been doing all along. TCP is where I see the biggest issue, so that's what I use as a label. All transport protocols are relevant here however (even ST2 I guess, if anyone can be bothered, and even understands it, which is certainly not me). Deprecated Address Processing: Valid Address Expires: Everything you describe there I agree with. However, I would, upon reaching deprecated state, and assuming I have another valid (non deprecated) address I can use, be having TCP switch to using the new address for all existing connections using the deprecated one. That is assuming we create a method for so doing. The hope there is that we then don't get to the expired address state. Other Addresses: Yes, all kinds of side effects might follow from the ability to change a TCP address while retaining the connection. Right now I would prefer not to speculate, any suggestions of possible other benefits tend to result in "but you can do that this other way" and then are treated as an argument against, rather than simply being irrelevant. I see nothing in my response above that affects or changes anything about TCP or UDP RFCs that exist today or need to be changed. This largely depends on whather you are prepared to have TCP connections killed or not. This in turn largely depends upon how frequent you see renumbering as being. I'm afraid I'm in the camp that sees this (into the future) as probably being a very frequent event (perhaps hourly...) At the minute people tend to think of renumbering as something that is very rare, and which is usually caused by something that is done deliberately. I'm afraid I can't see how we can scale things to the very large sizes that are being planned and keep that model. I agree with you but I can accept just killing the connection when the valid lifetime expires. This is a MUST in the addr conf spec and in my DHCPv6 spec. See above. I see no other option. Again, see above, I agree as written. But am willing to discuss technical ideas? Good. Don't forget UDP has the same problem only most likely at the application layer. Yes, for UDP things vary wildly by application. I don't see a problem (for example) with DNS queries failing and needing to be retried if a client or server address changes between when the query is sent and the reply is received. That I believe is tolerable. Even semi-connection servers like tftp I would be prepared to have simply die (would require application change and I doubt for tftp that it is worth it). The multicast UDP applications are a much bigger issue, and (perhaps fortunately) one I am totally unqualified to say anything about. Well maybe with renumbering this cannot be the case anymore and the real crux I think of your issue? Yes. I am not clear for routers yet. I want to understand what pain routers cause in IPv4 for renumbering Fine - this is (I don't think) not very relevant to this particular discussion. Can you give me an example of a TCP connection that lasts for years? Not off hand, that was more just to get attention... I see the real problem being renumbering that is more frequent than many people imagine. I really don't want my telnet sessions vanishing every hour - I do leave telnets, and X sessions, connected for months. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Nov 21 14:42:02 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04796; Tue, 21 Nov 95 14:42:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04790; Tue, 21 Nov 95 14:41:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02150; Tue, 21 Nov 1995 14:28:32 -0800 Received: from oberon.di.fc.ul.pt by mercury.Sun.COM (Sun.COM) id OAA12277; Tue, 21 Nov 1995 14:28:23 -0800 Received: from localhost (roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) with SMTP id XAA03917; Tue, 21 Nov 1995 23:23:27 +0100 Message-Id: <199511212223.XAA03917@oberon.di.fc.ul.pt> X-Authentication-Warning: oberon.di.fc.ul.pt: Host localhost didn't use HELO protocol X-Authentication-Warning: oberon.di.fc.ul.pt: roque owned process doing -bs X-Mailer: exmh version 1.6.1 5/23/95 To: bound@zk3.dec.com, kre@cs.mu.oz.au Reply-To: roque@di.fc.ul.pt Cc: ipng@sunroof.eng.sun.com From: roque@di.fc.ul.pt Subject: (IPng 849) Re: call for ipngwg agenda items In-Reply-To: Your message of "Tue, 21 Nov 1995 15:11:30 EST." <9511212011.AA23852@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 1995 23:23:03 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On the discussion by kre and jim: kre: The transport protocols need to be able to handle that which the IPv6 protocol makes available. IPv6 allows host addresses to change, the transport protocols must cope with that. jim: I think its only ONE case the valid lifetime expires. I think that things don't need to be that way... both of you seam to agree that TCP doesn't need to be changed... i.e. the arquitecture of TCP works well and makes a great protocol but to TCP IP address are *just* an identifier it uses with the network layer if we put on paper a formal model of the TCP/IP stack at the application level identifiers are DNS names... formaly (but not in practice) dns names are what is used at the App - Transport interface... IMHO changing TCP to be able to cope with IP address changes does not change anything in TCP model or functionality by itself in fact i suppose that many of the current TCP implementations need to be changed.. for instance PMTU disc is not a feature avaliable at every implementation today and it's mandatory for ng TCP/IP stack jim states that there is ONE case where you might need that and rather a rare case because invalidation lifetimes are greater than 99% of TCP connections ( the same might just not be true when you consider NFS mounts... and it's UDP beeing used ... the connection less transport protocol :-) there is a bit of irony here i guess) now i would like to call the mobility issue on the table... the current drafts use tunneling from the Home Agent to the Mobile Host ... there is also the possibility of using source routing headers... but in fact tunneling is a soluction that does not scale well ( the opinion is not just mine ... for instance, i was reading today a chapter on mobily from Huitema's book on routing where he shows the drawbacks of such approach ) source routing could be used ... but if the transport protocols where able to deal with network address changes you could get away without using a routing header on every packet ... i believe in kre's view that the future stack of protocols should have transport protocols that could continue comunication even in the case of network address changes... and in fact i don't think this means any change in TCP arquitecture or algorithms. just to give one more example of why i think that invalidation lifetime expiration could not be the only situation where a host needs to renumber there is the case refered here by Curtis Villamizar when a multihomed host as sockets bound to a interface that fails... Curtis uses what i consider to be an "hack" to overcome this but i think that everybody would prefer to have a TCP/IP model that could cope directly with this situation rather to have people using "last resort solutions" that are not allways obvious to everyone ... regards, Pedro Roque ( roque@di.fc.ul.pt ) Faculdade de Ciências da Universidade de Lisboa Departamento de Informática ------------------------------------------------------------------------------ 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 Nov 21 21:10:50 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05090; Tue, 21 Nov 95 21:10:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05084; Tue, 21 Nov 95 21:10:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14651; Tue, 21 Nov 1995 20:57:20 -0800 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id UAA23354; Tue, 21 Nov 1995 20:57:23 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA19407; Tue, 21 Nov 1995 20:50:51 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA01496; Tue, 21 Nov 1995 23:50:49 -0500 Message-Id: <9511220450.AA01496@wasted.zk3.dec.com> To: Robert Elz Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 850) Re: call for ipngwg agenda items In-Reply-To: Your message of "Wed, 22 Nov 95 08:48:37 +1100." <3652.816990517@cs.mu.OZ.AU> Date: Tue, 21 Nov 95 23:50:49 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre, Lots of good points in your last mail. I think we need to make a list of the issues. Should this be an agenda item to Bob and Steve for IPng? If addresses switch every hour as the norm (which I don't think will happen as the norm for the next 5 years maybe then as I can see your vision I think) then we need to disconnect and connect back TCP and UDP connections (UDP could be an application function too). Then we need a release-address code between transport protocols just to begin with. This would be a change to TCP and UDP RFCs clearly. But lets say that is the only case OK. This could also be accomplished end-to-end at the application stating the address is released and if there is a new address provide it to the "other" application. This would be in a destination option. We would see it at the IP layer and the transport and socket PCBs would be altered to accept the new address. If there was not a new address the applications is informing the "other" application its address is deleted and cannot be used anymore. Say X time before validation lifetime expires. Whoa to them who write ill-behaved IP network applications that do not refresh the incoming source address. This is probably a note we need to make to PIER too. But if we are talking more than this "issue" and come up with a few more we need to sort out what we come up with and provide a technical solution for the transports and move it to that area in the IETF and see what else we may want to do with TCP or integrate into others needed changes (non IPv6) for the transport, if the IETF so desires and the market really needs it. Multicast. OUCH. Clearly needs much discussion for the above issue. Should this not being solved prevent deployment of IPv6! I need to think about that and would like to hear from our other colleages. Are we doing the basic engineer error of solving every little problem that will not occur immediately and not shipping our product when the market needs it? We need to talk in person at the IETF I think too. p.s. Thanks Giving Holiday weekend in the U.S. this week Thur-Sun so I will be off and on the mail routine. /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 Wed Nov 22 07:35:29 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05273; Wed, 22 Nov 95 07:35:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05267; Wed, 22 Nov 95 07:35:13 PST Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14478; Wed, 22 Nov 1995 07:21:55 -0800 Received: from IETF.nri.reston.VA.US by venus.Sun.COM (Sun.COM) id HAA13329; Wed, 22 Nov 1995 07:21:54 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11649; 22 Nov 95 10:01 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@venus Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 851) I-D ACTION:draft-ietf-ipngwg-bsd-api-03.txt Date: Wed, 22 Nov 95 10:01:41 -0500 Message-Id: <9511221001.aa11649@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 : IPv6 Program Interfaces for BSD Systems Author(s) : R. Gilligan, S. Thomson, J. Bound Filename : draft-ietf-ipngwg-bsd-api-03.txt Pages : 33 Date : 11/21/1995 In order to implement the version 6 Internet Protocol (IPv6) [1] in an operating system based on Berkeley Unix (4.x BSD), changes must be made to the application program interface (API). TCP/IP applications written for BSD-based operating systems have in the past enjoyed a high degree of portability because most of the systems derived from BSD provide the same API, known informally as "the socket interface". We would like the same portability with IPv6. This memo presents a set of extensions to the BSD socket API to support IPv6. The changes include a new data structure to carry IPv6 addresses, new name to address translation library functions, new address conversion functions, and some new setsockopt() options. The extensions are designed to provide access to IPv6 features, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. 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-bsd-api-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-bsd-api-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951121171011.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-api-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951121171011.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 22 10:37:36 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05342; Wed, 22 Nov 95 10:37:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05129; Tue, 21 Nov 95 22:14:40 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17485; Tue, 21 Nov 1995 22:01:22 -0800 Received: from zephyr.isi.edu by mercury.Sun.COM (Sun.COM) id WAA29851; Tue, 21 Nov 1995 22:01:23 -0800 Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17) id ; Tue, 21 Nov 1995 22:01:23 -0800 Message-Id: <199511220601.AA17586@zephyr.isi.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 852) Proposal for re-attachable TCP addresses is to be discussed Reply-To: mankin@isi.edu Date: Tue, 21 Nov 95 22:01:22 PST From: Allison Mankin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, The Open Transport Area Directorate meeting will focus on a proposal for allowing TCP addresses to change during the life of the connection. The proposal is by Christian Huitema. It applies to both TCP /IPv4 and /IPv6. IPv6 adds to the functionality because of the auto-renumbering features, which this proposal will address. The meeting will be on Monday evening (we're swapping its time with that of tcpfix, so the final agenda has the wrong time for both tsvdir and tcpfix). We hope for your attendance, Allison Mankin Transport AD, IPng Co-AD ----------------- Subject: I-D ACTION:draft-huitema-multi-homed-01.txt Date: Tue, 21 Nov 95 09:43:31 -0500 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi-homed TCP Author(s) : C. Huitema Filename : draft-huitema-multi-homed-01.txt Pages : 17 Date : 11/20/1995 Current TCP connections are identified by pairs of host addresses and port numbers. This introduces a "fate sharing" dependency between the connection and these values, and specially with the time to live of the host addresses. There are at least three cases where this dependency is unduly harmful: (1) when the host moves to a new location and is assigned a new address, (2) when the interface used by a multi-homed host to initiate the connection is temporarily disconnected, (3) when the host's network is renumbered, e.g. after changing provider. We propose to remove this fate sharing effect by allowing the set of addresses used by a TCP connection to change over time. We modify TCP defining a new type of parameter, PCB-ID, to be used during the initial synchronisation. ------------------------------------------------------------------------------ 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 Nov 22 11:00:34 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05415; Wed, 22 Nov 95 11:00:34 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05409; Wed, 22 Nov 95 11:00:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08961; Wed, 22 Nov 1995 10:47:04 -0800 Received: from mailhost.Ipsilon.COM by mercury.Sun.COM (Sun.COM) id KAA03579; Wed, 22 Nov 1995 10:46:57 -0800 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA18970; Wed, 22 Nov 1995 10:47:17 -0800 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Nov 1995 10:47:06 -0800 To: mankin@isi.edu From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 853) Re: Proposal for re-attachable TCP addresses is to be discussed Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Allison, >The Open Transport Area Directorate meeting will focus on a proposal for >allowing TCP addresses to change during the life of the connection. >The proposal is by Christian Huitema. It applies to both TCP /IPv4 >and /IPv6. IPv6 adds to the functionality because of the >auto-renumbering features, which this proposal will address. I think this is a great idea! >The meeting will be on Monday evening (we're swapping its time >with that of tcpfix, so the final agenda has the wrong time for >both tsvdir and tcpfix). However, it conflicts with the MBONE Engingeering BOF. Perhaps one of these could be rescheduled. Bob >To: mbone@ISI.EDU, idmr@cs.ucl.ac.uk >Cc: dino@cisco.com, deering@parc.xerox.com >Subject: MBone Engineering BOF in Dallas >Date: Tue, 21 Nov 1995 11:33:01 PST >Sender: Steve Deering >From: Steve Deering > >[This message is being sent to both the mbone and idmr mailing lists; please > post any follow-ups to the mbone list only.] > >An MBone Engineering BOF has been scheduled for the Dallas IETF, on Monday >evening from 7:30 to 10:00. It will be chaired by Steve Deering and >Dino Farinacci. The purpose of the BOF is: > > (1) to identify what problems need to be addressed and what steps > need to be taken to evolve the current "experimental" MBone > infrastructure into a ubiquitously-available, "native" IP > multicast service in the Internet, > > (2) to learn the status of current and planned solutions to the > outstanding problems, and > > (3) to begin planning for the deployment of those solutions. > >Like any IETF BOF, anyone is welcome to attend, but we particularly solicit >participation by Internet service providers and IP multicast implementors. >We invite ISPs to give brief (5 minute) presentations on what they see as >the issues and obstacles to deployment of native multicast in their networks, >and we invite implementors of IP multicast infrastructure technology (e.g., >routing protocols, management and diagnostic tools, traffic management >algorithms) to give brief (5 minute) status reports on their implementations. >The BOF will be 'cast on the MBone (of course) to try to enable participation >by those who cannot attend in person. > >Here is a tentative agenda; if you have any changes or additions to suggest, >or if you are willing to give a presentation, please send mail to >deering@parc.xerox.com and dino@cisco.com. > > o ISP presentations -- possible issues/topics: > - ISP plans for / experiments with native multicast > - un-met software requirements - routing, mgmt tools, etc. > - need for hardware upgrades? > - traffic management/congestion concerns > - bandwidth availability forecasts > - vulnerability to misconfiguration, "storms", etc. > - other? > > o status reports on management and debugging tools > - multicast debugging architecture - Van Jacobson > - SNMP support for multicast - Dave Thaler > - multicast traceroute - Bill Fenner > - IGMP-based router info messages - Bill Fenner > - other? > > o status reports on multicast routing implementations > - 3Com - ?? > - Bay - ?? > - cisco - Dino Farinacci > - PARC - Bill Fenner and/or Steve Deering > - USC - ?? > - SGI? Sun? Digital? UCL? Alantec? other? > > o status reports on multicast traffic management mechanisms > (for best-efforts traffic only, i.e., excluding resource > reservation approaches, which are being addressed in other > forums) > - multicast rate limits and priority dropping - Deering > - administrative scope control - Jacobson? > - RED? > - other? > > o next steps for growing/improving the MBone > - replacing tunnels with native multicast forwarding > wherever possible. > - using DVMRP routing through transit PIM clouds. > - using route aggregation and default routes in DVMRP. > - scheduling an "MBone re-engineering week", during which > no one is allowed to complain that the MBone isn't working. > - configuring administrative scope boundaries around all > organizations, and change sd, etc. to allocate > appropriately-scoped group addresses. > - banning the use of multicast routing implementations that > don't correctly support pruning, mtrace, and longest-match > routing, e.g., pre-3.3 mrouted kernels and pre-3.5 mrouted > demons. > - raising the 500 Kbps MBone bandwidth ceiling. > - ... > >Steve & Dino ------------------------------------------------------------------------------ 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 Nov 22 15:44:27 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00331; Wed, 22 Nov 95 15:44:27 PST Received: from caribe.eng.sun.com (caribe-86) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00325; Wed, 22 Nov 95 15:44:18 PST Received: from janice.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA15513; Wed, 22 Nov 1995 15:30:53 -0800 Received: by janice.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA02438; Wed, 22 Nov 1995 15:29:12 -0800 Date: Wed, 22 Nov 1995 15:29:12 -0800 From: therbert@caribe (Tom Herbert) Message-Id: <199511222329.PAA02438@janice.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 854) Question on link layer multicast X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The ICMPv6 draft reads that ICMPv6 error messages MUST NOT be sent as a result of receiving: (e.1) an ICMPv6 error message, or (e.2) a packet destined to an IPv6 multicast address (an exception to this rule is the Packet Too Big Message - Section 3.2 - to allow Path MTU discovery to work for IPv6 multicast), or (e.3) a packet sent as a link-layer multicast, (the exception from e.2. applies to this case too), or (e.4) a packet sent as a link-layer broadcast, (the exception from e.2., applies to this case too), or (e.5) a packet whose source address does not uniquely identify a single node -- e.g., the IPv6 Unspecified Address, or an IPv6 multicast address, or an IPv6 anycast address. (e.3) and (e.4) require a check of information from the link layer. IPv6 multicast packets will be handled by case (e.2), so (e.3) and (e.4) only cover the case of unicast packets that are link layer multicast or broadcast. Are IPv6 unicast packets that are link layer broadcast or multicast even legal to send? I can't offhand think of any reason why they should be allowed... In the case that they are not, a stronger statement may be "upon receiving a packet with a unicast destination address which was sent as a link layer multicast or broadcast, the packet MUST be silently dropped." Comments? Tom ------------------------------------------------------------------------------ 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 Nov 22 21:02:48 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00592; Wed, 22 Nov 95 21:02:48 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00586; Wed, 22 Nov 95 21:02:38 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15876; Wed, 22 Nov 1995 20:49:19 -0800 Received: from sangam.ncst.ernet.in by mercury.Sun.COM (Sun.COM) id UAA26973; Wed, 22 Nov 1995 20:49:06 -0800 Received: from kurinji ([144.16.241.213]) by sangam.ncst.ernet.in (8.6.12/8.6.6) with SMTP id KAA20061 for ; Thu, 23 Nov 1995 10:20:45 +0530 Received: by kurinji; (5.65/1.1.8.2/14Nov95-0650PM) id AA07966; Thu, 23 Nov 1995 10:19:51 +0530 Date: Thu, 23 Nov 1995 10:19:51 +0530 From: "GanapathiSubramaniam.P.P." Message-Id: <9511230449.AA07966@kurinji> To: ipng@sunroof.eng.sun.com Subject: (IPng 855) IPv6 Testing Reply-To: ganes%kurinji@shiva.iitm.ernet.in Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I tried to tunnel my IPv6 packets to sipper.pa-x.dec.com (204.123.39.2). But I didn't get any reply. I am wondering if my IPv6 packets reach him at all. Any of you tested (tunneled) IPv6 with this site or any other IPv6 implementation? Please let me know. We have implemented IPv6 on DEC Alpha(OSF/1) and PC (MSDOS). We have ping, telnet and ftp running on IPv6 on PC. I am eager to know about other implementors. Regards, Ganapathi Subramaniam (o o) /~~~~~~~~~~~~~~~~~~~~~~~~~ooO~(_)~Ooo~~~~~~~~~~~~~~~~~~~~~~~~~~~\ / P.P.Ganapathisubramaniam, Proj. Asso. & MS Scholor \ || Computer Science and Engineering, Voice: 2351365 || || 304A BSB, DON Lab , RAX: 3531 || || Indian Institute of Technology || || Madras 600 036, INDIA || || || || Email: ganes%kurinji@iitm.ernet.in || || || (o o) /~~~~~~~~~~~~~~~~~~~~~~~~~ooO~(_)~Ooo~~~~~~~~~~~~~~~~~~~~~~~~~~~\ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------------------------------ 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 Nov 23 01:48:51 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00694; Thu, 23 Nov 95 01:48:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00688; Thu, 23 Nov 95 01:48:41 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25757; Thu, 23 Nov 1995 01:35:24 -0800 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id BAA19252; Thu, 23 Nov 1995 01:35:16 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.6.9) with ESMTP id KAA28780; Thu, 23 Nov 1995 10:35:10 +0100 (MET) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id KAA17941; Thu, 23 Nov 1995 10:35:08 +0100 Message-Id: <199511230935.KAA17941@givry.inria.fr> From: Francis Dupont To: ganes%kurinji@shiva.iitm.ernet.in Cc: ipng@sunroof.eng.sun.com Subject: (IPng 856) Re: IPv6 Testing In-Reply-To: Your message of Thu, 23 Nov 1995 10:19:51 +0530. <9511230449.AA07966@kurinji> Date: Thu, 23 Nov 1995 10:35:02 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I tried to tunnel my IPv6 packets to sipper.pa-x.dec.com (204.123.39.2). But I didn't get any reply. I am wondering if my IPv6 packets reach him at all. Any of you tested (tunneled) IPv6 with this site or any other IPv6 implementation? Please let me know. We have implemented IPv6 on DEC Alpha(OSF/1) and PC (MSDOS). We have ping, telnet and ftp running on IPv6 on PC. I am eager to know about other implementors. => There is a fine list of implementations available in the IPng html documents (http://playground.sun.com/pub/ipng/html/ipng-main.html). >From time to time there are some IPv4 compatible IPv6 addresses published in this list but there is *not* *yet* a centralized list of such hosts. Here is an attempt: Digital Unix sipper.pa-x.dec.com ::204.123.39.2 (working) INRIA (NetBSD) ottawa.inria.fr ::128.93.1.21 (working) tavel.inria.fr ::193.51.193.149 (not working, ask me) mercurey.inria.fr ::128.93.8.17 (not working, ask me) ganesha.imag.fr ::129.88.30.31 (working) uma.imag.fr ::192.44.68.2 (not working, ask Alain.Durand@imag.fr) cruiser-3.ie.org ::192.48.115.85 (working) SICS (HP-UX) sauce.sics.se ::192.16.123.101 (not working ?) hewlett.sics.se ::192.16.123.70 (working) packard.sics.se ::192.16.123.88 (not working) NRL (BSD 4.4) mallorn.itd.nrl.navy.mil ::132.250.80.6 (not working ?) Sun Solaris ??? .sun.com ::192.9.5.6 (working) Bay Networks quincy_adams.wellfleet.com ::192.32.29.62 (working) Note some of these hosts are not more on the network or needs some special routes. I have not asked the authorization to publish these addresses here then please keep this for the moment for internal usage of the IPv6 implementor community. Regards Francis.Dupont@inria.fr PS: in general there are telnet/ftp "guest" accounts on these hosts. PPS: the usual problem with IPv6 ping over a tunnel is bad checksum. You should use an IPv6 capable tcpdump and manually verify it in the dump (I have the tools). ------------------------------------------------------------------------------ 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 Nov 24 12:35:45 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01095; Fri, 24 Nov 95 12:35:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01089; Fri, 24 Nov 95 12:35:36 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00888; Fri, 24 Nov 1995 12:22:16 -0800 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id MAA13858; Fri, 24 Nov 1995 12:22:16 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA17054; Fri, 24 Nov 1995 12:16:45 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA25209; Fri, 24 Nov 1995 15:16:36 -0500 Message-Id: <9511242016.AA25209@wasted.zk3.dec.com> To: mankin@isi.edu Cc: ipng@sunroof.eng.sun.com Subject: (IPng 857) Re: Proposal for re-attachable TCP addresses is to be discussed In-Reply-To: Your message of "Tue, 21 Nov 95 22:01:22 PST." <199511220601.AA17586@zephyr.isi.edu> Date: Fri, 24 Nov 95 15:16:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sounds like an interesting meeting. Many of us booked in tracks though for Monday. But I hear what Scott said and we have no choice. I am not clear that for IPv6 this same functionality cannot be done via a Destination Option. I have everything to write a draft to approach IPv6 in this manner. But cannot get to it before Dallas now. And I have to be at DNSIND as we are trying to finish up last call parts at Dallas. Sooooo I don't think I can make it but have a lot of input on this work. I also think we need to address UDP. Not addressing UDP only solves 1/2 the problem. My destination option idea could be made to solve UDP too. The idea ends up much like what Christians spec does but does not mess with the TCP RFC or UDP RFC. I will try to find an IETF colleague MOnday during the day who is going to this meeting and do a core dump for them to represent my view if I can. I would hope we will get "wide" community consensus before we mess with IPv4 TCP? For IPv6 we are building it now and can make adjustments in architecture and even code base. This is not the case with IPv4 because its a running product! We need to think real hard about this in the IETF. So much work to do at Dallas and so few days. p.s. If anyone can make this meeting and can meet me for lunch Monday please send me PRIVATE mail. 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 Nov 26 21:45:18 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01739; Sun, 26 Nov 95 21:45:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01733; Sun, 26 Nov 95 21:45:09 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21067; Sun, 26 Nov 1995 21:31:44 -0800 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id VAA08002; Sun, 26 Nov 1995 21:31:46 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA13632; Sun, 26 Nov 1995 21:25:47 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA21344; Mon, 27 Nov 1995 00:25:46 -0500 Message-Id: <9511270525.AA21344@wasted.zk3.dec.com> To: ganes%kurinji@shiva.iitm.ernet.in Cc: ipng@sunroof.eng.sun.com Subject: (IPng 858) Re: IPv6 Testing In-Reply-To: Your message of "Thu, 23 Nov 95 10:19:51 +0530." <9511230449.AA07966@kurinji> Date: Mon, 27 Nov 95 00:25:46 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Ganapathi, I think you want to get on the IPv6 Implementors list. sipper.pa-xx.dec.com is up and I checked it in addition to Francis Duponts response. You can join ipv6imp by sending mail to: ipv6imp-request@munnari.oz.au This is where we discuss implementation issues I think you will find this forum useful too. You should also send Bob Hinden hinden@ipsilon.com a note to get your implementation added to the IPng WEB Page and other details you want to announce, etc.. See pointer to that WEB PAGE below: --------------------------------------------------- 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 ------------------------------------------------------ Also as long as you have a Digital UNIX (previous OSF/1) User license you can also get the Digital IPv6 implementation and the IPv6 BSD API to run against your Alpha version. This would be a good test too. We want to wait until after Dallas before we give out any more kits because it would be nice if neighbor discovery, stateless addrconf, ICMP, and the base spec were nailed down before we update the code base. Plus there are some outstanding questions I think will be resolved at Dallas. Our goal is to get the Dallas fixes in before the Feb 6-10, 1996 University of New Hampshire interoperability test here in the U.S. 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 Nov 27 09:09:41 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01980; Mon, 27 Nov 95 09:09:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00727; Thu, 23 Nov 95 02:53:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27912; Thu, 23 Nov 1995 02:39:43 -0800 Received: from hermes.research.ptt.nl by mercury.Sun.COM (Sun.COM) id CAA24094; Thu, 23 Nov 1995 02:39:41 -0800 Received: from dnlts0.research.ptt.nl by research.kpn.com (PMDF V4.3-11 #7381) id <01HXZC7CSU2O000PWM@research.kpn.com>; Thu, 23 Nov 1995 11:39:36 +0100 Received: from gn01.ms.research.kpn.com by dnlts0.research.kpn.com (PMDF V4.3-11 #7381) id <01HXZC7ZKO68BIJDPJ@dnlts0.research.kpn.com>; Thu, 23 Nov 1995 11:40:06 +0100 Date: Thu, 23 Nov 1995 11:36 +0100 From: "Wietmarschen, V.R. van" Subject: (IPng 859) FW: IPng; Header Translators and other. To: "'IPng mailing list'" Message-Id: <01HXZC7ZLH42BIJDPJ@dnlts0.research.kpn.com> X-Envelope-To: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT Posting-Date: Thu, 23 Nov 1995 11:36 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (Re-isseud request) Hi to everyone. Currently Iam working on a project in order to investigate IPng. Questions like: Whats is IPng, differences with IPv4, IPng deployment,, ... Iam not involved in technical specs!! Iam curently working on the Interworking and deployment, and need more info on the following: 1) What is the actual status on Header Translators. Read some about it in SIT,but the subjec tis not mentioned in , , . If not considered anymore: How can IPv4-only host communicate with IPv6-only?? 2) A sending (dual) Host which encapsulates IPv4-in-IPv6 packets (auto tunneling) must have an IPv4 related IPv6 address (IPv4-compatible-IPv6 address) , Why?? If Host has unrelated IPv4 and IPv6 address it can use IPv4 address as IPv4 source and IPv6 address as IPv6 source in the IPv4/IPv6 packet. 3) Does there exist a single document which gives an overview of all IP and related protocols that need to be redesinged for IPv6 compatibility?? 4) Suppose the following: An organizations deploys a dual router at its Internet entry. Its provider does not deploy any IPv6 functionality yet. The organization never gets an DNS reply with an IPv6 address. Does it have to create a manual static tunnel to an other organization in order to get IPv6 routing info from that organization ??? 5) Does anyone have more information about IPv6 deployment and IPv6 functionality. 6) Does anyone has more information on the consequences of IPv6 deployment for service- and backbone providers. How should their deployment scenario look like. 7) IPv6 security architecture is moved to historic??? Its an (expired) Internet-Draft, I thought only RFC are assigned a State.?? 8) All Internet-Drafts documents refer to the '1id-abstracts.txt' to learn the current status of a draft document. To check I ftp: ftp://ftp.ripe.net/internet-drafts/1id-abstracts.txt But this gives me only abstracts of Internet-Drafts, no statusses??? By the way many Drafts in this list are from 1994 ??? Iam sorry for the size of questions. Roy van Wietmarschen Email: V.R.van Wietmarschen@research.kpn.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 27 10:33:50 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02096; Mon, 27 Nov 95 10:33:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02090; Mon, 27 Nov 95 10:33:41 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05292; Mon, 27 Nov 1995 10:34:16 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id KAA21481; Mon, 27 Nov 1995 10:34:17 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16043(1)>; Mon, 27 Nov 1995 10:31:04 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 27 Nov 1995 10:30:55 -0800 To: ipng@sunroof.eng.sun.com Cc: deering@parc.xerox.com Subject: (IPng 860) change of ipngwg meeting time Date: Mon, 27 Nov 1995 10:30:40 PST From: Steve Deering Message-Id: <95Nov27.103055pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In order to resolve a number of conflicts, the first of the two ipngwg sessions in Dallas is being moved from 9 am Thursday to 9 am Tuesday. Thus, the two sessions will be: Tuesday, 9:00 am - 11:30 am Thursday, 1:00 pm - 3:00 pm Of course, this may create new conflicts. For example, the Tuesday ipngwg session now collides with the second session of dhc, which some of you may be involved with. If this creates a conflict for you, please let me know which specific ipng topics you are most concerned with, and I will try to ensure that those topics are postponed to the Thursday afternoon ipngwg session. 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 Nov 27 13:37:12 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02342; Mon, 27 Nov 95 13:37:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02336; Mon, 27 Nov 95 13:37:03 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06140; Mon, 27 Nov 1995 13:37:38 -0800 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id NAA12573; Mon, 27 Nov 1995 13:37:35 -0800 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16495(9)>; Mon, 27 Nov 1995 12:34:56 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 27 Nov 1995 12:34:15 -0800 To: ipng@sunroof.eng.sun.com Cc: deering@parc.xerox.com Subject: (IPng 861) Re: change of ipngwg meeting time In-Reply-To: deering's message of Mon, 27 Nov 95 10:30:40 -0800. <95Nov27.103055pst.75270@digit.parc.xerox.com> Date: Mon, 27 Nov 1995 12:34:11 PST From: Steve Deering Message-Id: <95Nov27.123415pst.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One thing I forgot to mention: the intserv session scheduled for Tuesday morning is moving to a different slot, so that won't conflict with ipngwg at that time. 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 Nov 27 19:03:23 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02635; Mon, 27 Nov 95 19:03:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02629; Mon, 27 Nov 95 19:03:14 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25194; Mon, 27 Nov 1995 19:03:46 -0800 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id TAA00257; Mon, 27 Nov 1995 19:03:47 -0800 Received: from muggsy.lkg.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA16211; Mon, 27 Nov 1995 18:58:19 -0800 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA06109; Mon, 27 Nov 1995 19:50:53 -0500 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id AAA21887; Tue, 28 Nov 1995 00:55:39 GMT Message-Id: <199511280055.AAA21887@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: Tom.Herbert@Eng (Tom Herbert) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 862) Re: Question on link layer multicast In-Reply-To: Your message of "Wed, 22 Nov 1995 15:29:12 PST." <199511222329.PAA02438@janice.eng.sun.com> X-Mailer: exmh version 1.5omega 10/6/94 Date: Tue, 28 Nov 1995 00:53:08 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Are IPv6 unicast packets that are link layer broadcast or multicast even > legal to send? I can't offhand think of any reason why they should be > allowed... I can see many possible (but slimey) uses. Send a DNS request to the link-local all-nodes UDP port. I could also see sending packets to the a node's link-local solicited multicast. Although you can do (though I think of *real* reason you might want to), you will be filtering out the packet anyways so what's the harm of allowing it? Is it because you don't know whether the packet was received via a multicast mechanism (for instance, ULTRIX has that problem)? 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 Mon Nov 27 19:31:45 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02674; Mon, 27 Nov 95 19:31:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02668; Mon, 27 Nov 95 19:31:36 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28150; Mon, 27 Nov 1995 19:32:10 -0800 Received: from zafu.bbn.com by mercury.Sun.COM (Sun.COM) id TAA04407; Mon, 27 Nov 1995 19:32:12 -0800 Received: from localhost (day@localhost) by zafu.bbn.com (8.6.11/8.6.5) with SMTP id WAA28455; Mon, 27 Nov 1995 22:32:20 -0500 Message-Id: <199511280332.WAA28455@zafu.bbn.com> From: "John Day" Subject: (IPng 863) Re: call for items on ipng To: cwade@bbn.com, ipng@sunroof.eng.sun.com, lyman@bbn.com, yakov@cisco.com Date: Mon, 27 Nov 95 22:28:49 EST Mail-System-Version: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Wrt, to this discussion of maintaining TCP connections over IP-address changes. I admit I was out of the loop here for awhile, but did we drop the TCP pseudo-header? Now strictly speaking this should not cause a problem, but I would certainly be suspicious. How does a receiver distinguish an address change from an illegal data insertion? I blast a stream of packets at a TCP socket with a different address. To TCP it looks like a change of address followed by another change of address. The fact that it goes back to the old address isn't noticed. Am I wrong or does this create a monster security hole in TCP? I think you should more consider maintaining application connections and tear down and set up the TCP connections. It is probably a lot safer. Take care, John ------------------------------------------------------------------------------ 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 Nov 27 21:42:22 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02730; Mon, 27 Nov 95 21:42:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02724; Mon, 27 Nov 95 21:42:13 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06383; Mon, 27 Nov 1995 21:42:46 -0800 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id VAA19097; Mon, 27 Nov 1995 21:42:49 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA16171; Mon, 27 Nov 1995 21:37:28 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14358; Tue, 28 Nov 1995 00:37:27 -0500 Message-Id: <9511280537.AA14358@wasted.zk3.dec.com> To: "John Day" Cc: cwade@bbn.com, ipng@sunroof.eng.sun.com, lyman@bbn.com, yakov@cisco.com Subject: (IPng 864) Re: call for items on ipng In-Reply-To: Your message of "Mon, 27 Nov 95 22:28:49 EST." <199511280332.WAA28455@zafu.bbn.com> Date: Tue, 28 Nov 95 00:37:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I think you should more consider maintaining application connections and >tear down and set up the TCP connections. It is probably a lot safer. IMHO.... This is at the heart of what I believe is correct to resolve this dilemma architecturally. This is where we should proceed from in thought and design. I would also like to add one other advantage to safer! It will get through the IETF quicker because we can test it and prototype it very quickly, given we agree on a mechanism, and this means it will get deployed quicker. /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 Nov 27 21:47:09 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02746; Mon, 27 Nov 95 21:47:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02740; Mon, 27 Nov 95 21:47:01 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06563; Mon, 27 Nov 1995 21:47:34 -0800 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id VAA19641; Mon, 27 Nov 1995 21:47:37 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA00411; Mon, 27 Nov 1995 21:42:44 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16783; Tue, 28 Nov 1995 00:42:43 -0500 Message-Id: <9511280542.AA16783@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 865) IPv6 over ATM at Dallas fyi ... Date: Tue, 28 Nov 95 00:42:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------- Forwarded Message X-Mailer: exmh version 1.6.1 5/23/95 To: ip-atm@matmos.hpl.hp.com Subject: re: draft agenda Date: Mon, 27 Nov 95 15:41:30 -0500 From: schulter X-Mts: smtp >WEDNESDAY, December 6, 1995 > >0900-1130 Morning Sessions > > INT ipatm IP Over Asynchronous Transfer Mode WG > > Min Item >1. 10 Opening remarks >2. 10 ipatm/rolc chairs statement >3. 10 ATM Forum Liaison report(s) > ATM Forum/MPOA/etc > ATM Forum/LANE, Kieth McCloghrie >4. 15 draft-smith-ipatm-bcast-01, Tim Smith, Grenville Armitage >5. 20 draft-ietf-ipatm-mib-00, Ted Kuo, et. al >6. 30 draft-ietf-ipatm-classic2-00, Mark Laubach > Epidemic database synchronization and multi-server overview >7. 20 RSVP over IP over ATM - Steve Berson, ISI >8. 15 draft-ietf-ipatm-ipv6nd-00, Grenville Armitage >9. 20 draft-schulter-ipv6atm-framework, Markus Jork, Peter Schulter Folks, The I-D for this discussion is now available from the I-D servers. I've included the abstract below. Both text and PostScript versions are available. While there are some details that remain to be worked out, there should be enough detail here to start a discussion on this proposal. Title : A Framework for IPv6 over ATM Autor : Peter Schulter Filename: draft-schulter-ipv6atm-framework-00.txt draft-schulter-ipv6atm-framework-00.ps Pages : 52 (text) 43 (Postscript) Date : 11/21/95 Work in specifying the IPv6 [IPv6-SPEC] has now progressed to a point that work on IPv6 implementations is beginning at many organizations. So far, the IPv6 specifications have dealt with broadcast media LANs [IPv6-ETHER]with very little attention to ATM. The IP over ATM WG is now starting to look at IPv6 over ATM [IP-IPV6ND]. Many of the problems encountered in running IPv4 over ATM [IP-FRAME, IP-ATM, IP- ATMU, IP-ATMMC] must also be dealt with when running IPv6 over ATM. Since ATM networks are point-to- point networks that offer no connectionless broadcast or multicast capabilities, many of the IPv6 protocols cant be directly applied to the ATM network. Instead, some software framework built on top of the ATM network must be built to handle those protocols or functions which rely on connectionless multicast capabilities. Among these functions are neighbor discovery and address configuration. Another difficulty with ATM is that ATM networks have a flat address space, and are expected to become very large (even global). It is desirable to logically partition a large ATM network into IPv6 subnets and to be able to maintain IPv6 subnet semantics while still maintaining the ability to interconnect any two nodes on the ATM network so that ATM QoS services can be provided within the framework of IPv6 networking. This document proposes a framework for performing IPv6 Neighbor Discovery and address configuration on ATM networks. This framework also permits the logical partitioning of ATM networks into logical groups of nodes so that the semantics of IPv6 link- local and site- local addresses are maintained. Finally, this framework permits any two systems on separate subnets to directly connect so that virtual circuits with specific QoS requirements can be established. --- pete - - ------------------ Peter Schulter schulter@zk3.dec.com Digital UNIX Networking voice (603) 881-2920 Digital Equipment Corp voice (DTN) 381-2920 ZK3-03/U14 FAX (603) 881-2257 110 Spit Brook Road FAX (DTN) 381-2257 Nashua, NH 03062 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Nov 27 21:52:01 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02763; Mon, 27 Nov 95 21:52:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02757; Mon, 27 Nov 95 21:51:52 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06792; Mon, 27 Nov 1995 21:52:26 -0800 Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM) id VAA20104; Mon, 27 Nov 1995 21:52:29 -0800 From: bound@zk3.dec.com Received: from abelia.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA05361; Mon, 27 Nov 1995 21:46:36 -0800 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19582; Tue, 28 Nov 1995 00:46:35 -0500 Message-Id: <9511280546.AA19582@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 866) Re: change of ipngwg meeting time In-Reply-To: Your message of "Mon, 27 Nov 95 10:30:40 PST." <95Nov27.103055pst.75270@digit.parc.xerox.com> Date: Tue, 28 Nov 95 00:46:35 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NOTE on DHC. The WG Chair is now trying to schedule the DHCPv6 discussion for Monday a.m. DHC meeting. /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 Tue Nov 28 08:54:57 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03118; Tue, 28 Nov 95 08:54:57 PST Received: from caribe.eng.sun.com (caribe-85) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02646; Mon, 27 Nov 95 19:07:03 PST Received: from kandinsky.eng.sun.com by caribe.eng.sun.com (5.x/SMI-SVR4) id AA06654; Mon, 27 Nov 1995 19:07:30 -0800 Received: by kandinsky.eng.sun.com (5.x/SMI-SVR4) id AA05170; Mon, 27 Nov 1995 19:12:12 -0800 Date: Mon, 27 Nov 1995 19:12:12 -0800 From: gilligan@caribe.eng.sun.com (Bob Gilligan) Message-Id: <9511280312.AA05170@kandinsky.eng.sun.com> To: ipng@sunroof Subject: (IPng 867) New IPv6 API spec Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As announced last week, Jim, Sue and I have revised the IPv6 API spec and the new version is now in the internet-drafts archive. The new document is draft-ietf-ipngwg-bsd-api-03.txt. This draft includes changes that were suggested in discussion over the summer on the mailing list plus a number of minor changes that people sent to us individually. We have also tried to fill in some of the missing pieces in the API, such as supporting applications running on multi-homed hosts, setting the priority field, and IPv6 equivalents for INADDR_ANY and INADDR_LOOPBACK. The complete list of changes in this version is included below. I think the document is now pretty close to being considered "finished". If there are any remaining issues, please bring them up on the IPng mailing list. Bob. Changes from previous version: - Changed u_long and u_short types in structures to u_int32_t and u_int16_t for consistency and clarity. - Added implementation-provided constants for IPv4 and IPv6 text address buffer length. - Defined a set of constants for subfields of sin6_flowid and for priority values. - Defined constants for getting and setting the source route flag. - Define where ansi prototypes for hostname2addr(), addr2hostname(), addr2ascii(), ascii2addr(), and ipv6_isipv4addr() reside. - Clarified the include file requirements. Say that the structure definitions are defined as a result of including the header file , not that the structures are necessarily defined there. - Removed underscore chars from is_ipv4_addr() function name for BSD compatibility. - Added inet6_ prefix to is_ipv4_addr() function name to avoid name space conflicts. - Changes setsockopt option naming convention to use IPV6_ prefix instead of IP_ so that there is clearly no ambiguity with IPv4 options. Also, use level IPPROTO_IPV6 for these options. - Made hostname2addr() and addr2hostname() functions thread-safe. - Added support for sendmsg() and recvmsg() in source routing section. - Changed in_addr6 to in6_addr for consistency. - Re-structured document into sub-sections. - Deleted the implementation experience section. It was too wordy. - Added argument types to multicast socket options. - Added constant for largest source route array buffer. - Added the freehostent() function. - Added receving interface determination and sending interface selection options. - Added definitions of ipv6addr_any and ipv6addr_loopback. - Added text making the lookup of IPv4 addresses by hostname2addr() optional. ------------------------------------------------------------------------------ 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 Nov 28 11:34:28 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03450; Tue, 28 Nov 95 11:34:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03444; Tue, 28 Nov 95 11:34:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13185; Tue, 28 Nov 1995 11:34:43 -0800 Received: from oberon.di.fc.ul.pt by mercury.Sun.COM (Sun.COM) id LAA01743; Tue, 28 Nov 1995 11:34:35 -0800 Received: from localhost (roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) with SMTP id UAA21948 for ; Tue, 28 Nov 1995 20:34:12 +0100 Message-Id: <199511281934.UAA21948@oberon.di.fc.ul.pt> X-Authentication-Warning: oberon.di.fc.ul.pt: Host localhost didn't use HELO protocol X-Authentication-Warning: oberon.di.fc.ul.pt: roque owned process doing -bs X-Mailer: exmh version 1.6.1 5/23/95 To: ipng@sunroof.eng.sun.com Subject: (IPng 868) Re: call for items on ipng From: roque@di.fc.ul.pt Reply-To: roque@di.fc.ul.pt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Nov 1995 20:34:05 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John Day writes: > I think you should more consider maintaining application connections and > tear down and set up the TCP connections. It is probably a lot safer. humm.. are you proposing something like a libsession.a that would do end-point to end-point mannagement on top of dynamic addresses ? The drawback i see is that there is litle chance for fancy anycast or multicast initiated connection support... but it should do the trick for multihomed hosts support mobility and renumbering... and has the advantage that it's realy a low cost solution... it's seams that we can come out with solutions at all levels: network, transport and application :-) well if you don't make it compatible with T.62 it's an idea that sounds realy reasonable ;-). regards, Pedro Roque ( roque@di.fc.ul.pt ) Faculdade de Ciências da Universidade de Lisboa Departamento de Informática ------------------------------------------------------------------------------ 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 Nov 28 11:46:24 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03491; Tue, 28 Nov 95 11:46:24 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03485; Tue, 28 Nov 95 11:46:11 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15160; Tue, 28 Nov 1995 11:46:44 -0800 Received: from zephyr.isi.edu by mercury.Sun.COM (Sun.COM) id LAA05443; Tue, 28 Nov 1995 11:46:42 -0800 Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17) id ; Tue, 28 Nov 1995 11:46:41 -0800 Message-Id: <199511281946.AA08080@zephyr.isi.edu> To: ipng@sunroof.eng.sun.com Cc: mankin@ISI.EDU Subject: (IPng 869) Change of time for TCP re-attachment discussion Reply-To: mankin@isi.edu Date: Tue, 28 Nov 95 11:46:41 PST From: Allison Mankin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, The meeting time for the Open Transport Area Directorate has been changed to Thursday 9 AM (it is taking the old time and place of the IPNG WG meeting that moved to Tuesday morning). It will be multicast. Presenters include Robert Elz and Christian Huitema. Reading list: Subject: I-D ACTION:draft-huitema-multi-homed-01.txt Date: Tue, 21 Nov 95 09:43:31 -0500 - --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi-homed TCP Author(s) : C. Huitema Filename : draft-huitema-multi-homed-01.txt Pages : 17 Date : 11/20/1995 Current TCP connections are identified by pairs of host addresses and port numbers. This introduces a "fate sharing" dependency between the connection and these values, and specially with the time to live of the host addresses. There are at least three cases where this dependency is unduly harmful: (1) when the host moves to a new location and is assigned a new address, (2) when the interface used by a multi-homed host to initiate the connection is temporarily disconnected, (3) when the host's network is renumbered, e.g. after changing provider. We propose to remove this fate sharing effect by allowing the set of addresses used by a TCP connection to change over time. We modify TCP defining a new type of parameter, PCB-ID, to be used during the initial synchronisation. ------------------------------------------------------------------------------ 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 Nov 28 13:12:45 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03670; Tue, 28 Nov 95 13:12:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03664; Tue, 28 Nov 95 13:12:35 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28506; Tue, 28 Nov 1995 13:13:08 -0800 Received: from zafu.bbn.com by mercury.Sun.COM (Sun.COM) id NAA27493; Tue, 28 Nov 1995 13:13:06 -0800 Received: from localhost (day@localhost) by zafu.bbn.com (8.6.11/8.6.5) with SMTP id QAA11370; Tue, 28 Nov 1995 16:13:17 -0500 Message-Id: <199511282113.QAA11370@zafu.bbn.com> From: "John Day" Subject: (IPng 870) Re: call for items on ipng To: roque@di.fc.ul.pt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199511281934.UAA21948@oberon.di.fc.ul.pt> Date: Tue, 28 Nov 95 16:12:34 EST Mail-System-Version: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >John Day writes: > >> I think you should more consider maintaining application connections and >> tear down and set up the TCP connections. It is probably a lot safer. > >humm.. are you proposing something like a libsession.a that would do end-point >to end-point mannagement on top of dynamic addresses ? > Pardon my ignorance but what is libsession.a? >The drawback i see is that there is litle chance for fancy anycast or >multicast initiated connection support... but it should do the trick for >multihomed hosts support mobility and renumbering... >and has the advantage that it's realy a low cost solution... > I don't see that there should be any problems with multicast or anycast. Although I have always thought that anycast was a bit of a hoax anyway. As far as the network layer (or transport layer for that matter) is concerned who cares how many responses there are to a multicast. As I told someone earlier today, much of the moral of this is that the network and transport layers are not the appropriate place to solve all problems. But then if they are the only ones you have you tend only see solutions there. >it's seams that we can come out with solutions at all levels: network, >transport and application :-) > >well if you don't make it compatible with T.62 it's an idea that sounds realy >reasonable ;-). > Wash your mouth out with soap!! for saying such nasty words!! :-) ------------------------------------------------------------------------------ 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 Nov 28 18:15:52 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04087; Tue, 28 Nov 95 18:15:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04081; Tue, 28 Nov 95 18:15:39 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11805; Tue, 28 Nov 1995 18:16:07 -0800 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id SAA11146; Tue, 28 Nov 1995 18:16:08 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18241; 27 Nov 95 10:37 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 871) I-D ACTION:draft-ietf-ipngwg-ipv6-tunnel-00.txt Date: Mon, 27 Nov 95 10:36:58 -0500 Message-Id: <9511271037.aa18241@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 : Generic Packet Tunneling in IPv6 Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-ipv6-tunnel-00.txt Pages : 25 Date : 11/22/1995 This document defines the model and mechanisms for IPv6 tunneling of various Internet or lower layer protocol packets, such as IPv6, IPv4, AppleTalk, IPX, etc. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-tunnel-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-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-ipv6-tunnel-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: <19951122180814.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-tunnel-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122180814.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Nov 29 07:02:31 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04391; Wed, 29 Nov 95 07:02:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04385; Wed, 29 Nov 95 07:02:22 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22869; Wed, 29 Nov 1995 07:02:52 -0800 Received: from sangam.ncst.ernet.in by mercury.Sun.COM (Sun.COM) id HAA01608; Wed, 29 Nov 1995 07:02:44 -0800 Received: from kurinji ([144.16.241.213]) by sangam.ncst.ernet.in (8.6.12/8.6.6) with SMTP id UAA15601 for ; Wed, 29 Nov 1995 20:33:54 +0530 Received: by kurinji; (5.65/1.1.8.2/14Nov95-0650PM) id AA16571; Wed, 29 Nov 1995 20:32:32 +0530 Date: Wed, 29 Nov 1995 20:32:32 +0530 From: "GanapathiSubramaniam.P.P." Message-Id: <9511291502.AA16571@kurinji> To: ipng@sunroof.eng.sun.com Subject: (IPng 872) IPng Drafts Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Greetings : As Wietmarschen, V.R. van has pointed out, >> All Internet-Drafts documents refer to the '1id-abstracts.txt' to learn >> the current status of a draft document. >> To check I ftp: ftp://ftp.ripe.net/internet-drafts/1id-abstracts.txt >> But this gives me only abstracts of Internet-Drafts, no statusses??? By the >> way many Drafts in this list are from 1994 ??? it is better to keep the status of the IPng drafts in a separate file, say 1id-abstracts-ipng.txt, so that it will be available in one place. Also, for those who want to know about what are all the relevent documents at the beginning. Right now, the file 1id-abstracts.txt is fairly big enough and ftpying the whole file to know about the status of various drafts of IPng is painful. Also, status of different drafts are kept in diff places in this file. Regards, Ganapathi Subramaniam (o o) /~~~~~~~~~~~~~~~~~~~~~~~~~ooO~(_)~Ooo~~~~~~~~~~~~~~~~~~~~~~~~~~~\ / P.P.Ganapathisubramaniam, Proj. Asso. & MS Scholor \ || Computer Science and Engineering, Voice: 2351365 || || 304A BSB, DON Lab , RAX: 3531 || || Indian Institute of Technology || || Madras 600 036, INDIA || || || || Email: ganes%kurinji@iitm.ernet.in || (o o) /~~~~~~~~~~~~~~~~~~~~~~~~~ooO~(_)~Ooo~~~~~~~~~~~~~~~~~~~~~~~~~~~\ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------------------------------ 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 Nov 29 11:34:20 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04553; Wed, 29 Nov 95 11:34:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04547; Wed, 29 Nov 95 11:34:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02117; Wed, 29 Nov 1995 11:34:39 -0800 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id LAA20568; Wed, 29 Nov 1995 11:34:41 -0800 Received: from pobox.BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA13550; Wed, 29 Nov 95 14:33:28 EST Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA11249; Wed, 29 Nov 95 14:34:29 EST Date: Wed, 29 Nov 95 14:34:29 EST From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9511291934.AA11249@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 873) ICMP Echo reply Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, The ICMPv6 draft states that the data received in the Echo Request message is to be truncated to fit path MTU when the Echo Reply message is sent. I'm not sure if this is the desirable behavior. It seems that if a path is probed with a large message, it would make more sence if it is attemted to send the requested size message in both direction even if fragmentation is to occur (may be it is my intend to test the return path with fragmented packets). Any comments from people with the operational experience? Dimitry ------------------------------------------------------------------------------ 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 Nov 29 11:46:38 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04570; Wed, 29 Nov 95 11:46:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04564; Wed, 29 Nov 95 11:46:28 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04230; Wed, 29 Nov 1995 11:46:58 -0800 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id LAA24157; Wed, 29 Nov 1995 11:46:57 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id UAA17471; Wed, 29 Nov 1995 20:46:55 +0100 (MET) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id UAA03892; Wed, 29 Nov 1995 20:46:53 +0100 Message-Id: <199511291946.UAA03892@givry.inria.fr> From: Francis Dupont To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 874) Re: ICMP Echo reply In-Reply-To: Your message of Wed, 29 Nov 1995 14:34:29 EST. <9511291934.AA11249@pobox.BayNetworks.com> Date: Wed, 29 Nov 1995 20:46:49 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The ICMPv6 draft states that the data received in the Echo Request message is to be truncated to fit path MTU when the Echo Reply message is sent. I'm not sure if this is the desirable behavior. It seems that if a path is probed with a large message, it would make more sence if it is attemted to send the requested size message in both direction even if fragmentation is to occur (may be it is my intend to test the return path with fragmented packets). Any comments from people with the operational experience? => I fully agree, reply should have the same size than request! 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 Wed Nov 29 13:40:36 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04722; Wed, 29 Nov 95 13:40:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04716; Wed, 29 Nov 95 13:40:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20934; Wed, 29 Nov 1995 13:40:52 -0800 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id NAA22773; Wed, 29 Nov 1995 13:40:50 -0800 Subject: (IPng 875) Re: ICMPv6 Echo reply To: IPng Mailing list Date: Wed, 29 Nov 1995 16:41:02 -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: <9511291641.aa24359@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My echo/echo-reply code replies with the whole packet. Having such a limitation is (IMHO) silly, and I agree with Francis & Dimitry. 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 Nov 29 22:42:23 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05110; Wed, 29 Nov 95 22:42:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05104; Wed, 29 Nov 95 22:42:13 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19093; Wed, 29 Nov 1995 22:42:35 -0800 Received: from mulga.cs.mu.OZ.AU by mercury.Sun.COM (Sun.COM) id WAA25867; Wed, 29 Nov 1995 22:42:35 -0800 Received: from muri.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07018 Thu, 30 Nov 1995 17:42:32 +1100 (from kre@cs.mu.OZ.AU) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: (IPng 876) Argument for payload header Date: Thu, 30 Nov 1995 17:42:44 +1100 Message-Id: <1116.817713764@cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is intended to discuss only the concept of a payload header - that is a header that will allow old headers to emulate the general IPv6 standard header characteristics basically - and why the ability to receive it should be mandatory. No intended discussion here that is specific to the particular definition of the header that can be found in draft-kre-ipv6-payload-01.txt, that can happen later if needed. The argument for making it mandatory to receive is simplest so I will make it first. Understand that this assumes that the later argument is accepted, and the need for the header is accepted. If this header is to be useful it really needs to be able to be used any time the sender feels it will be beneficial - we currently have no method of negotiating capabilities of hosts, that could be used to indicate that the header is supported, but even if we did, I'd still prefer that this header did not require that any extra negotiation be performed, it is really the type of thing you want to be able to do when the need arises, not sometime later. Its also really the kind of thing that you want to be able to depend on being able to use, that is, that the recipient will process it correctly. For all of this, I believe we must require that recipients be able to process the thing, which should not be much of an imposition. Now for why to have the thing at all. First, the architectural purity argument, which I know does not appeal to many here, so I will keep it brief. All new IPv6 headers have a "next header" field, which allow the headers to be chained together. This is a conceptually simple, and very elegant mechanism, with flexibility to permit many varied usages not yet imagined. However the current plan (at least) is that the "upper layer" protocols will be used more or less unchanged, with their existing headers as they exist in IPv4 - lacking the next header field. The payload header can act as a wrapper for those old headers, bringing them up to the full capabilities of IPv6, but without requiring a redesign of those protocols. Second, and more practical perhaps, one of the perennial problems is that almost everything related to the Internet is growing very quickly, with one notable exception - the average packet size. This means that the switching capacity of routers has to increase essentially at the same rate as the bandwidth. Ideally packets would grow larger, perhaps not as quickly as bandwidth, but enough to reduce the switching rate increases being required of the routers. To increase packet sizes we could change the nature of the applications or upper level protocols - put requirements upon them which will effectively raise the average packet size. This is not necessarily easy, even with the freedom to go and make changes to all the protocols in use. Further, even with the best possible intentions of the upper layers, IPv6 packets cannot possibly be made larger than that imposed by the PMTU, and that's constrained by the smallest MTU on the path, typically near one of the ends of the communications. Since ethernets are not going away, just serving fewer hosts per segment, a PMTU for most internet paths of no greater than 1500 can be expected for some time to come. Hosts connected via an Apple localtalk segment reduce that to under 600. The other way we can increase average effective packet sizes is by carrying multiple application packets in one packet through the backbone of the net (whatever you think of that as). We have a tunneling spec (draft-ietf-ipngwg-ipv6-tunnel-00.txt) proposed, which, if I read it correctly, will work without configuration of tunnels (ie: any host can decide to tunnel to anyone else if required). That would allow a LAN exit node to notice a packet flow to a destination, and tunnel through the core of the internet, building bigger packets. The tunnelling itself will make the packets bigger - but that's not the objective. Being able to carry multiple payloads would allow the tunnel to carry multiple packets, instead of just one, per packet through the backbone. In cases where applications or transport protocols either want to, or need to, send small packets - which includes the classic terminal server case, if "terminals" are actually used much any more to need this (terminal servers routing ppp/slipp don't have the same problem) - then the IP layer in the host could use the payload header to make the packets approach the PMTU, instead of being considerably smaller. Third, and perhaps of marginal relevance, and more particular to the particular payload header I defined (but never mind), in IPv4 the 20 byte IP header, and 20 byte TCP header caused the TCP data to be aligned on a multiple of 8 boundary from the start of the IP header in most cases (no options). IPv6 has moved toward multiple of 8 alignment for all headers, to assist processing on the current, and coming, generations of 64 bit processors, however the effect of this has been that the 20 byte TCP header will cause the data to be aligned on a multiple of 4 but not 8 boundary from the start of the IP header. The payload header, even if not used to carry multiple payloads, will "fix" that, by making the effective TCP+payload header be 24 bytes, a multiple of 8. TCP could decide whether to do this on a packet by packet basis, adding the extra 4 bytes only when it seems likely to be useful (packets carrying user data more than just a few bytes), or when there really are multiple payloads of course. Fourth, the payload header allows an "empty" payload to be carried, by setting one of the next header fields to "no next header". A common case of this would be when used as in the previous point, to align TCP data, the payload header's "next" field would be "no next", with only the one payload carried, the TCP packet. However, the internal payload could also be "none" - this has the effect of very effeciently permitting a potentially large meaningless field be transmitted, before the real payload. While normally useless, this could be used to cause user data to be aligned on a "nice" boundary when data is being transmitted across one of those very high speed, very large MTU LANs that jumbograms were created to serve. That is, if it would be useful for consenting hosts to transmit packets with the data on a (say) 8KB boundary from the start of the packet, a null payload of the appropriate size can easily be inserted. If the packet size is large enough, and the benefits of avoiding copying great enough, it just might be worth aligning the end user data this way. Of course the alignment could be to a much greater boundary, the current spec allows anything up to 64Kb from the start of the packet, even that might be justified if sending data of several megabytes per packet. I think this pretty much covers the benefits I see, providing a way to allow the average packet size to be increased seems to be the most important to me. The question now is, I guess, whether anyone else believes that these benefits are worth the cost of implementing at least the receive side of the protocol, which is the important part. If receivers can be assumed to work, senders can then implement and use the header as their needs require it. If receivers cannot be counted upon to process the header, then no sender would be likely to ever want to even think about sending it. kre ps: I will probably now not see any replies to this message until I get to look at mail in Dallas, I am taking a rather leisurely path to there,a nd arriving a bit early. ------------------------------------------------------------------------------ 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 Nov 30 01:40:57 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05286; Thu, 30 Nov 95 01:40:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05280; Thu, 30 Nov 95 01:40:44 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28066; Thu, 30 Nov 1995 01:41:07 -0800 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id BAA13301; Thu, 30 Nov 1995 01:41:06 -0800 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 877) Re: ICMPv6 Echo reply To: danmcd@cs.nrl.navy.mil (Dan McDonald) Date: Thu, 30 Nov 1995 09:41:49 +0000 (GMT) Cc: ipng@sunroof2.eng.sun.com In-Reply-To: <9511291641.aa24359@cs.nrl.navy.mil> from "Dan McDonald" at Nov 29, 95 04:41:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My echo/echo-reply code replies with the whole packet. Having such a > limitation is (IMHO) silly, and I agree with Francis & Dimitry. Short of sending the whole packet how will you discover the path MTU anyway if you don't happen to have it cached ? Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 30 05:55:53 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05359; Thu, 30 Nov 95 05:55:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05353; Thu, 30 Nov 95 05:55:38 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08029; Thu, 30 Nov 1995 05:56:10 -0800 Received: from vulcan.inlink.com by mercury.Sun.COM (Sun.COM) id FAA04795; Thu, 30 Nov 1995 05:56:11 -0800 Received: (from jbaltzer@localhost) by vulcan.inlink.com (8.6.12/V8) id HAA24220; Thu, 30 Nov 1995 07:51:21 -0600 Date: Thu, 30 Nov 1995 07:51:20 -0600 (CST) From: John Baltzer To: Alan Cox Cc: Dan McDonald , ipng@sunroof2.eng.sun.com Subject: (IPng 878) Re: ICMPv6 Echo reply In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How is the implementation of IPv6 on Linux coming along? Will it be ready to go with the release of the 1.4.x Linux kernel? Regards, John ------------------------------------------------------------------------------ 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 Nov 30 06:37:36 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05414; Thu, 30 Nov 95 06:37:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05408; Thu, 30 Nov 95 06:37:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11037; Thu, 30 Nov 1995 06:37:49 -0800 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id GAA11325; Thu, 30 Nov 1995 06:37:50 -0800 Subject: (IPng 879) Re: ICMPv6 Echo reply To: Alan Cox Date: Thu, 30 Nov 1995 09:37:51 -0500 (EST) From: Dan McDonald Cc: danmcd@cs.nrl.navy.mil, ipng@sunroof2.eng.sun.com In-Reply-To: from "Alan Cox" at Nov 30, 95 09:41:49 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9511300937.aa25488@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Short of sending the whole packet how will you discover the path MTU anyway > if you don't happen to have it cached ? Hey, if the echo-reply is dropped and a "too big" message is sent by a midway router, fine! This is ICMP and IP, after all, and they are unreliable. Currently, a cache entry will be created for that destination, so if subsequent pings are sent, subsequent replies will have better path MTU information. Yes, this can mean a lot of cache entries, but good garbage collection should prevent that from being too much of a problem. 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 Thu Nov 30 10:54:42 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05601; Thu, 30 Nov 95 10:54:42 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05595; Thu, 30 Nov 95 10:54:23 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15183; Thu, 30 Nov 1995 10:54:22 -0800 Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM) id KAA24833; Thu, 30 Nov 1995 10:54:17 -0800 Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: (IPng 880) Re: ICMPv6 Echo reply To: jbaltzer@inlink.com (John Baltzer) Date: Thu, 30 Nov 1995 18:55:07 +0000 (GMT) Cc: danmcd@cs.nrl.navy.mil, ipng@sunroof2.eng.sun.com In-Reply-To: from "John Baltzer" at Nov 30, 95 07:51:20 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > How is the implementation of IPv6 on Linux coming along? Will it be > ready to go with the release of the 1.4.x Linux kernel? We are waiting for everyones first cut code to see how to do it best using their experience. Early 1.5 releases (thus development code not production systems) are the intended target. Possibly with patches for 1.3.x that wont go into 1.4.0 Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 30 12:52:03 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05726; Thu, 30 Nov 95 12:52:03 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05720; Thu, 30 Nov 95 12:51:50 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04737; Thu, 30 Nov 1995 12:52:21 -0800 Received: from A.crl.com by mercury.Sun.COM (Sun.COM) id MAA27166; Thu, 30 Nov 1995 12:52:21 -0800 Received: from A119006.sat1.as.crl.com by A.crl.com with SMTP id AA05773 (5.65c/IDA-1.5 for ); Thu, 30 Nov 1995 12:51:32 -0800 Date: Thu, 30 Nov 1995 12:51:32 -0800 Message-Id: <199511302051.AA05773@A.crl.com> X-Sender: trohling@a.crl.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Dan McDonald From: Ted Rohling Subject: (IPng 881) Re: ICMPv6 Echo reply Cc: ipng@sunroof2.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:37 AM 11/30/95 -0500, you wrote: >> Short of sending the whole packet how will you discover the path MTU anyway >> if you don't happen to have it cached ? > >Hey, if the echo-reply is dropped and a "too big" message is sent by a >midway router, fine! This is ICMP and IP, after all, and they are >unreliable. > >Currently, a cache entry will be created for that destination, so if >subsequent pings are sent, subsequent replies will have better path MTU >information. Yes, this can mean a lot of cache entries, but good garbage >collection should prevent that from being too much of a problem. > >Dan OK---so is the "too big" messages counted as a ping response or as a "too big" message? If my ICMP request packets are too big for the network then I guess I just have to forget it and take it down a bit? Regards, Ted trohling@a.crl.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Nov 30 21:56:29 1995 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05995; Thu, 30 Nov 95 21:56:29 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05989; Thu, 30 Nov 95 21:56:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09255; Thu, 30 Nov 1995 21:56:34 -0800 Received: from fore.com by mercury.Sun.COM (Sun.COM) id VAA23235; Thu, 30 Nov 1995 21:56:28 -0800 Received: from dolphin (dolphin.fore.com [169.144.1.16]) by fore.com (8.6.11/8.6.11) with SMTP id AAA19334; Fri, 1 Dec 1995 00:57:36 -0500 Received: from marlin-atm.fore.com by dolphin (4.1/SMI-4.1) id AA04470; Fri, 1 Dec 95 00:55:54 EST From: rcoltun@fore.com (Robert Coltun) Received: by marlin-atm.fore.com (4.1/SMI-4.1) id AA20561; Fri, 1 Dec 95 00:55:48 EST Date: Fri, 1 Dec 95 00:55:48 EST Message-Id: <9512010555.AA20561@marlin-atm.fore.com> To: ipng@sunroof2.eng.sun.com, ospf@gated.cornell.edu Subject: (IPng 882) OSPF Version 2 For IP Version 6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Enclosed is OSPF Version 2 For IP Version 6 draft to be discussed next week. As allways comments would be appreciated. Thanks, ---rob ------------------------------------------------------------------------------ Internet Draft OSPFv6 December 1995 Expiration Date: June 1996 FORE Systems File name: draft-ietf-ospf-ospfv6-00.txt OSPF Version 2 For IP Version 6 Rob Coltun FORE Systems (301) 571-2521 rcoltun@fore.com Status Of This Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Coltun Expires June 1996 [Page 1] Internet Draft OSPFv6 December 1995 Table Of Contents 1.0 Abstract ................................................. 4 2.0 Overview ................................................. 4 2.1 Organization Of This Document ............................ 4 2.2 Acknowledgments .......................................... 4 3.0 OSPFv4 To OSPFv6 Diffs ................................... 5 3.1 Features That Haven't Been Modified ...................... 5 3.2 Features That Have Been Removed .......................... 6 3.2.1 TOS-Based Routing ...................................... 6 3.3 Modifications And Extensions ............................. 6 3.3.1 Extensions To Address And ID Fields .................... 6 3.3.2 Semantics Of The Network Mask Field .................... 6 3.3.3 External LSA Forwarding Address And Route Tag .......... 7 3.3.4 Protocol Packet Processing Modifications ............... 7 3.4 Additions To OSPFv6 ...................................... 8 3.4.1 Support Of The Opaque LSA .............................. 8 3.4.2 Instance ID ............................................ 8 4.0 Overview Of OSPFv6 Packet Formats ........................ 8 4.1 The OSPF Packet Header ................................... 9 4.2 The Hello Packet ......................................... 9 4.3 The Link-State Advertisement Header ...................... 10 4.4 The Database Description Packet .......................... 10 4.5 The Link-State Request Packet ............................ 10 4.6 The Link-State Acknowledgment Packet ..................... 11 4.7 The Link-State Update Packet ............................. 11 4.7.1 The Router LSA ......................................... 12 4.7.2 The Network LSA ........................................ 12 4.7.3 Summary LSA ............................................ 12 4.7.4 The AS External LSA .................................... 12 5.0 Protocol Packet Processing ............................... 14 5.1 Sending Protocol Packets ................................. 14 5.2 Receiving Protocol Packets ............................... 16 6.0 Opaque LSAs .............................................. 19 6.1 Modifications To The Neighbor State Machine .............. 20 6.2 Modifications To The Flooding Procedures ................. 20 7.0 AS External Routes ....................................... 22 7.1 Origination Of AS External Reference Opaque LSA .......... 22 7.2 Calculating AS External Routes ........................... 22 8.0 References ............................................... 24 Appendix A: OSPFv6 Data Formats .............................. 25 A.1 Encapsulation Of OSPFv6 Packets .......................... 25 A.2 The Options Field ........................................ 27 A.3 OSPFv6 Packet Formats .................................... 29 A.3.1 The OSPFv6 Packet Header ............................... 29 A.3.2 The Hello Packet ....................................... 32 A.3.3 The Database Description Packet ........................ 35 A.3.4 The Link-State Request Packet .......................... 37 A.3.5 The Link-State Update Packet ........................... 40 A.3.6 The Link-State Acknowledgment Packet ................... 41 A.4 Link-State Advertisement (LSA) Formats ................... 43 A.4.1 The Link-State Advertisement Header .................... 43 A.4.2 Router LSA ............................................. 46 A.4.3 Network LSA ............................................ 49 Coltun Expires June 1996 [Page 2] Internet Draft OSPFv6 December 1995 A.4.4 Summary LSA ............................................ 51 A.4.5 AS External LSA ........................................ 53 A.4.6 Opaque LSA ............................................. 55 A.4.6.1 Link-Local Opaque LSA ................................ 57 A.4.6.2 AS External Reference Opaque LSA ..................... 59 Appendix B: Architectural Constants .......................... 61 Appendix C: Configurable Constants ........................... 62 C.1 Global Parameters ........................................ 62 Coltun Expires June 1996 [Page 3] Internet Draft OSPFv6 December 1995 1.0 Abstract This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. The packet formats have been extended to support IPv6 addressing as IPv6 increases the IP address size from 32 bits to 128 bits. Additionally, an Instance ID (i.e., process identifier) has been added to the OSPF packet header to facilitate routers runing more than one OSPFv6 instance. 2.0 Overview Over the last few years the OSPF routing protocol [OSPF] has been widely deployed throughout the Internet. As a result of this deploy- ment OSPF has been cleaned up, tuned up and extended as new require- ments have emerged. We now have a large operational and implementa- tion knowledge base. Our goal is to utilize this existing experience base and extend OSPF to support IPv6 [IPV6], which we will refer to as OSPFv6. The OSPF area architecture and its fundamental mechanisms (flooding, DR election, SPF calculations, etc.) remain unchanged. OSPF's options (on-demand circuits support, NSSA areas, multicast extensions, point- to-multipoint, etc.) are directly applicable. It is assumed that the reader is familiar with the OSPF protocol as specified in [OSPF]. The basic change to OSPF to support IPv6 is to extend the net/subnet address, link-state ID, router ID and area ID fields from 32 to 128 bits. We change the syntax of the network mask from an explicit mask to an integer which represents the number of bits in the mask. There- fore when referring to [OSPF], addresses and network masks expressed as a 32-bit "dotted quads" (e.g., 128.185.1.0) should be thought of as IPv6 address in the form expressed in the IPv6 address architecture document [IPV6ADDR] (e.g., FEDC:BA98:7654:3210:FEDC:BA98:7654:3210). 2.1 Organization Of This Document This document first lists the differences between OSPF for IPv4 (OSPFv4) and OSPFv6, followed by the details of these changes includ- ing a description of the packet formats which have been extended to support IPv6. Following that are the mechanisms needed to support the addition of an instance ID in the packet header. Finally we discuss the modifications to the AS external LSA processing and AS External Opaque LSA origination (which is used in conjunction with AS external LSAs). Appendix A gives the packet formats. 2.2 Acknowledgments The author would like to thank Fred Baker, Jim Bound, John Moy and the rest of the OSPF Working Group for the ideas and support they have Coltun Expires June 1996 [Page 4] Internet Draft OSPFv6 December 1995 given to this project. 3.0 OSPFv4 To OSPFv6 Diffs 3.1 Features That Haven't Been Modified The fundamental concept of (sub)networks, CIDR style address and gen- eral routing architecture of IPv6 [IPV6] is the same as those of IPv4. Therefore the mechanisms of OSPF remain unchanged including: o IP subnetting support o The representation of routers and networks o The representation of non-broadcast networks o The link-state database organization o The link-state database exchange mechanisms o The link-state database flooding mechanisms o Neighbor and interface state machines o The (Backup) Designated Router Election Algorithms o Building the shortest-path tree o Support for equal-cost multipath o The splitting of an AS into Areas o Supporting stub areas o The backbone of the Autonomous System o Inter-area routing o The use of external routing information (AS external routes) All of OSPF optional capabilities (on-demand circuits support, NSSA areas, multicast extensions, point-to-multipoint, etc.) are directly applicable to OSPFv6 (with the appropriate IPv6 address extensions). In fact, the version number for OSPFv6 remains as version 2 as this document is viewed to be an extension of OSPFv4 with [OSPF] remaining the base document. Coltun Expires June 1996 [Page 5] Internet Draft OSPFv6 December 1995 3.2 Features That Have Been Removed 3.2.1 TOS-Based Routing The semantics of IPv4 TOS have not been moved forward to IPv6; IPv6 has priority and flow identifiers. Priority gives the IPv6 forwarding engine a hint as to how to queue the packet for processing but does not necessarily represent an independent routing path. The IPv6 header does have a 24-bit Flow Label field which may be used by a source to label those packets for which it requests special handling by IPv6 routers, such as non-default quality of service or "real-time" ser- vice. In the future the IPv6 Flow Label may be a associated with a non-default route which may turn out to be loosely related to IPv4 TOS, but the Flow Label concept is still experimental and subject to change as the requirements for flow support in the Internet become clearer. Along with the fact that TOS has rarely been used in OSPFv4, OSPFv6 does not support TOS as defined in OSPFv4. 3.3 Modifications And Extensions One of the the fundamental motivations for IPv6 was to increase the IP address size from 32 bits to 128 bits so that IP can support more lev- els of the addressing hierarchy and so that it can address a much greater number of nodes. The majority of the changes were made to accommodate the IPv6 expanded address space while maintaining the phi- losophy of 32-bit aligned fixed-length fields. (Needless to say the routing table must be modified to handle 128-bit network addresses). 3.3.1 Extensions To Address And ID Fields To support IPv6 we extend the (sub)network address, link-state ID, router ID and area ID fields from 32 to 128 bits. An overview of these changes and their effect on database size and fragmentation is given in Section 4.0 entitled "Overview Of OSPFv6 Packet Formats". The packet formats are given in Appendix A. 3.3.2 Semantics Of The Network Mask Field The semantics of the network mask has been changed from an explicit mask to an integer which expresses the number of bits in the network mask (the field is now called "Network Mask Length"). At the time that the original OSPF spec was written, non-contiguous masks were legal. This has since changed and IPv4 and IPv6 allows contiguous masks only. Since the network mask may be up to 128 bits, link-state database memory resources can be saved by representing the mask as the number of bits in the network mask. In the case of the link-data field in the Router LSA the semantics is type specific so that the 128-bits may be an IPv6 address or a network mask length. When it is the network mask length, the first 32 bits of the 128-bit field is treated as an integer which expresses the number of bits in the Coltun Expires June 1996 [Page 6] Internet Draft OSPFv6 December 1995 network mask. 3.3.3 External LSA Forwarding Address And Route Tag OSPFv6 AS External LSAs do not include the forwarding address or the external route tag. Instead, OSPFv6 external LSAs include a 32-bit Opaque LSA Reference field. The reason for this is as follows. In OSPFv4 the Route Tag was not used by the OSPF protocol itself; it was used to communicate information between AS boundary routers. In [BGPOSPF] the route tag is divided into two parts or kept as locally defined information. When it is divided into two parts the upper 16 bits denotes origin information (indications whether the routing information was originated via an IGP, or some other means) and an arbitrary tag. The lower 16 bits are used to communicate an auto- nomous system number. Since CIDR-style addresses [CIDR] are used in IPv6, it is unlikely that a separate address space will be used for IPv6 domains as they are for IPv4's Autonomous System numbers. Instead it is likely that a prefix will be used to represent a domain as it does in IDRP [IDRP]. For the tag to continue to have the same function as in OSPFv4 we would need to include the domain identifier (which is a prefix of a 128-bit address), a length field for the domain identifier, an arbitrary tag and origin information. This information would take up 20 octets. Additionally the forwarding address would have to be extended to 128 bits (another 16 octets). Within an OSPF system, there are relatively few number of AS boundary routers and anywhere from a single default route to tens of thousands of AS external routes injected into the OSPF system. That is a pair will most likely be repeated in a number of External LSAs. If the External Tag were to be extended to include domain, and origin information and the forwarding address were extended to a 128-bit address the External LSA would incur another 36 octets of overhead. When this is combined with the already extended link-state ID and router ID fields the external LSA would be 88-octets much of which is redundant information resulting in unnecessary memory overhead. OSPFv6 introduces a new type of LSA which carries the forwarding address, domain and origin information. See Section A.4.6.2 ("AS External Reference Opaque LSA") for a description of the packet for- mat. This LSA is referenced by the AS External LSA so as to reduce the link-state database overhead. 3.3.4 Protocol Packet Processing Modifications Protocol packet processing has been modified to include the Instance ID (see Section 3.4.2 below). Also, because there is no checksum in the IPv6 header, these sections have been removed. See Section 5.0 ("Protocol Packet Processing") for a description of the OSPFv6 proto- col packet processing. Coltun Expires June 1996 [Page 7] Internet Draft OSPFv6 December 1995 3.4 Additions To OSPFv6 The following items are not part of OSPF but are part of OSPFv6. 3.4.1 Support Of The Opaque LSA The Opaque LSA is need by OSPFv6 as a replacement for OSPFv4's exter- nal LSA's forwarding address and route tag as explained in section 3.3.3 above. To support distribution of the Opaque LSA, modifications were made to the neighbor state machine and to the flooding pro- cedures. See Section 6 of this document for the details of these modifications. 3.4.2 Instance ID OSPFv6 introduces an Instance ID which is used when multiple OSPFv6 instances (or processes) are used. The Instance ID is used both by network management to identify the particular instance to be managed and by the OSPFv6 send and receive functions to identify packet's tar- get OSPFv6 instance. As an example, multiple Instance IDs may be used by a network service provider when the provider participates in a subscriber's IGP (which happens to be OSPF). The provider would therefore need to support several OSPFv6 instances within the same router. Multiple OSPF instances allows the router to have logically partitioned OSPF for reasons of management and policy enforcement. See section 5 of this document for the details of the modifications to the protocol packet processing needed to support the Instance ID. 4.0 Overview Of OSPFv6 Packet Formats The result of extending the IP address to 128 bits is an increase in the size of several of the packet formats for OSPFv6. To support IPv6 we extend the (sub)network address, link-state ID, router ID and area ID fields in the OSPF packet formats from 32 to 128 bits. Addition- ally we change the semantics of the network mask from an explicit mask to be the number of bits (length) of the network mask. The major impact of increasing the lengths of several of the fields is on the link-state database's memory utilization. For larger networks there may be some impact on IP fragmentation of OSPFv6 packets. The OSPF protocol has mechanisms which allows an implementation to manage the contents and size of the OSPF packets. That is, database description, link-state request, link-state update and link-state ack- nowledgement packets all include lists of entries so that an implemen- tation can optimize the size of each of these packets. Most OSPF packets travel a single hop. Hello, database description, link-state request, link-state update and link-state acknowledgement packets are sent on a single interface. At each router, link-state update packets are disassembled into their constituent link-state Coltun Expires June 1996 [Page 8] Internet Draft OSPFv6 December 1995 advertisements which may be then flooded as part of a link-state update packet originated by the receiving router. Since the MTU for the media type associated with the interface is known (except in the case of virtual interfaces), the packets can be optimized for the interface's MTU. In the case of virtual links, the path between virtual neighbors is dynamically discovered so the packets may need to be fragmented by the IP layer along the way. But unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by the routers along a packet's delivery path. Needless to say that OSPF would break if it did not handle the MTU correctly. It is reasonable to assume that for the OSPFv6 packets traversing a virtual link that either 1) an MTU of 576 octets is assumed by OSPF and used by the IP layer or 2) the "Path MTU Discovery for IP version 6" [PMTU] protocol is run by the IP layer on area border routers which are end points of a virtual link. The following describes the modifications to the OSPF packet formats to support IPv6 and the effects of extending the net/subnet address, link-state ID, router ID and area ID fields from 32 to 128 bits. All of the packets formats are described in detail in Appendix A. 4.1 The OSPF Packet Header Every OSPF packet starts with a common header. This header contains all the necessary information to determine whether the packet should be accepted for further processing. The packet format has been modi- fied so that the Router ID field and the Area ID field are increased to 128 bits. The effect of this is that the packet header is now 48 octets and was 24 octets in OSPFv4. This extension contributes very little to additional memory overhead of the implementation (as the packet headers are not usually maintained in the database) and when added to the extensions of the other OSPF packet formats this exten- sion is a minor contributor to the need for IP fragmentation. 4.2 The Hello Packet OSPF's Hello Protocol is responsible for establishing and maintaining neighbor relationships. It also ensures that communication between neighbors is bidirectional. Hello packets are sent periodically out all router interfaces and include a list of the Router IDs of each router from whom valid Hello packets have been seen recently on the network. Bidirectional communication is indicated when the router sees itself listed in the neighbor's Hello Packet. On multi-access networks, the Hello Protocol elects a Designated Router for the net- work. The effect of extending the Area and Router IDs to 128 bits in the Hello Packet is that the Hello Header is now 88 octets. Additionally, each advertised neighbor (the Router ID) on the network is 16 octets Coltun Expires June 1996 [Page 9] Internet Draft OSPFv6 December 1995 so that at around 90 neighbors the Hello packet would be larger than an Ethernet MTU. Although for most networks this is not an issue, there are some networks that exceed this number of neighbors. This extension only contributes to additional memory overhead of the imple- mentation if the Hello Packets are maintained (a rare but not unthink- able occurrence). 4.3 The Link-State Advertisement Header All link-state advertisements begin with a common header. This header contains enough information to uniquely identify the advertisement (LS type, Link-State ID, and Advertising Router). This header is used in database description packets, link-state advertisements and link-state acknowledgement packets. The effects of extending the link-state ID and the advertising router fields to 128 bits is that the link-state header for OSPFv6 is 44 octets (was 20 octets for OSPFv4). This clearly increases the memory requirements as the LSA headers are stored in the link-state database for every link-state advertisement. The effects on fragmentation are specific to the packet using the link-state advertisement header. 4.4 The Database Description Packet Database description packets are exchanged when an adjacency is being initialized. They describe the contents of the topological database. Multiple packets may be used to describe the database. Each database description packet consists of the database description header and after the initial master/slave determination is complete, a list of link-state advertisement headers. The database description packet has an explicit fragmentation mechanism so that an implementation should build database description packets of the appropriate size (i.e., to avoid IP fragmentation). Extending the link-state advertisement header and the OSPF packet header contributes very little to addi- tional memory overhead as database description packets are not usually stored after being sent. 4.5 The Link-State Request Packet Link-state request packets are used during the initial database exchange process to request the pieces of the neighbor's database that are more up to date than those held in the router's database. Multiple link-state request packets may need to be used in the database exchange. Sending of link-state request packets is the last step in bringing up an adjacency. Each link-state request packet includes a link-state request header and a list of requested advertisements. The requested advertisements are specified by an LS type, Link-State ID, and Advertising Router which uniquely identifies the advertisement, but not its instance as Link-State Request packets are understood to be requests for the most Coltun Expires June 1996 [Page 10] Internet Draft OSPFv6 December 1995 recent instance. In OSPFv6 the link-state ID and advertising router fields are extend to 128 bits. The link-state request packet has explicit fragmentation mechanism so that an implementation should build link-state request packets of the appropriate size (i.e., to avoid IP fragmentation). This extension contributes little to additional memory overhead as link-state request packets are not usually stored after being sent. 4.6 The Link-State Acknowledgment Packet Link-State Acknowledgment Packets are used to make the flooding of link-state advertisements reliable; flooded advertisements are expli- citly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link-State Acknowledgment packets. Multiple link-state advertisements can be acknowledged in a single Link-State Acknowledgment packet. The format of this packet is similar to that of the Data Description packet. The body of both packets is simply a list of link-state adver- tisement headers. The database acknowledgement packet has an explicit fragmentation mechanism so that an implementation should build link- state acknowledgement packets of the appropriate size (i.e., to avoid IP fragmentation). Extending the link-state advertisement header and the OSPF packet header contributes very little to additional memory overhead as acknowledgement packets are not usually stored after being sent. 4.7 The Link-State Update Packet Link-State Update packets implement the flooding of link-state adver- tisements. Each Link-State Update packet carries a collection of link-state advertisements one hop further from its origin. Several link-state advertisements may be included in a single packet. For OSPFv6 the link-state ID field and advertising router field are 128 bits. Additionally, in the specific advertisements types (see below) fields that represent network/subnet numbers, interface addresses or router IDs are also 128 bits. Network mask fields (except for router LSAs) need not increase since a mask in OSPFv6 is an integer which represents the number of bits (length) of the network address mask. It is clear that the memory requirements for the link-state database for OSPFv6 is significantly greater than those for IPv4. Even though the link-state update packets have explicit fragmentation mechanism which allows an implementation to attempt to build link-state update packets of the appropriate size to avoid IP fragmentation there are issues that are specific to the link-state types that make it possible for a specific link-state advertisement to be larger than the required MTU. We now look at the issues unique to specific link-state adver- tisement types. Coltun Expires June 1996 [Page 11] Internet Draft OSPFv6 December 1995 4.7.1 The Router LSA Router link-state advertisements are originated by all routers. These LSAs consist of a list of interfaces to the area which may be a point-to-point connection to another router, a connections to a tran- sit network, a connection to a stub network, or virtual links. Each of these links includes the cost of the link. OSPF requires that all of the router's links to the area must be described in a single router LSA. The link ID and link data fields are now 128 bits making each link 36 octets (as opposed to 12 octets for OSPFv4). A router having greater than 40 links in its router LSA would exceed an Ethernet MTU. 4.7.2 The Network LSA Network link-state advertisements are originated for multi-access net- works by the Designated Router. This advertisement contains a list of the router IDs for each of the routers attached to the network. Net- work LSAs are flooded throughout a single area only. Since the OSPFv6 router IDs are 128 bits each link is 16 octets (as opposed to 4 octets for OSPFv4). A transit network having greater than 90 routers attached would exceed an Ethernet MTU. Although for most networks this is not an issue, there are some networks that exceed this number of neighbors. 4.7.3 Summary LSA Summary link-state advertisements are the type-3 and type-4 link-state advertisements. These advertisements are originated by area border routers and sent into an area. A separate summary LSA is made for each destination (known to the router) which belongs to the AS, yet is outside the area. Type 3 link-state advertisements are used when the destination is an IP network. In this case the advertisement's link-state ID field is an IPv6 network number and the Network Mask Length field is an integer which represents the number of bits in the network number's mask. When the destination is an AS boundary router, a type-4 advertisement is used, the link-state ID field is the AS boundary router's OSPF router ID and the Network Mask Length field is unused (i.e., set to 0). Since the OSPFv6 Link-State IDs and Router IDs are 128 bits summary link advertisements are 52 octets (as opposed to 28 octets for OSPFv4); there are no fragmentation issues for summary link advertise- ments. 4.7.4 The AS External LSA AS external link-state advertisements are the type-5 link-state Coltun Expires June 1996 [Page 12] Internet Draft OSPFv6 December 1995 advertisements. These advertisements are originated by AS boundary routers. A separate advertisement is made for each destination (known to the router) which is external to the AS. AS external link-state advertisements usually describe a particular external destination. For these advertisements the Link-State ID field specifies an IP network number. AS external link advertisements are also used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the link-state ID is always set to IPv6DefaultDestination (0::0) and the Network Mask Length is set to 0. The Link-State ID and Router ID and are 128 bits. OSPFv6 does not include the forwarding address or the external route tag but does have a 32-bit Opaque LSA Reference field (see Section 3.3.3 "External LSA Forwarding Address And Route Tag"). The OSPFv6 AS external LSA is 56 octets (as opposed to 28 octets for OSPFv4); there are no fragmentation issues for AS external link adver- tisements. Coltun Expires June 1996 [Page 13] Internet Draft OSPFv6 December 1995 5.0 Protocol Packet Processing This section discusses the general processing of OSPFv6 routing proto- col packets. It is essentially section 8 of [OSPF] but includes the specific checks for Instance ID. It is very important that the router link-state databases remain syn- chronized. For this reason, routing protocol packets should get pre- ferential treatment over ordinary data packets, both in sending and receiving. Routing protocol packets are sent along adjacencies only (with the exception of Hello packets, which are used to discover the adjacen- cies). This means that all routing protocol packets travel a single IP hop, except those sent over virtual links. All routing protocol packets begin with a standard header. The sec- tions below provide details on how to fill in and verify this standard header. Then, for each packet type, the section giving more details on that particular packet type's processing is listed. 5.1 Sending Protocol Packets When a router sends a routing protocol packet, it fills in the fields of the standard OSPF packet header as follows. For more details on the header format consult Section A.3.1 of this document: Version # Set to 2, the version number of the protocol as documented in this specification. Packet type The type of OSPF packet, such as a Link-State Update or Hello Packet. Packet Length The length of the entire OSPF packet in octets, including the standard OSPF packet header. Router ID The identity of the router itself (who is originating the packet). Area ID The OSPF area that the packet is being sent into. Instance ID The OSPFv6 instance that is originating the packet. See Section 3.4.2 of this document for more details. AuType and Authentication Each OSPF packet exchange is authenticated. Authentication Coltun Expires June 1996 [Page 14] Internet Draft OSPFv6 December 1995 types are assigned by the protocol and are documented in Appendix D of [OSPF]. A different authentication procedure can be used for each IP network/subnet. Autype indicates the type of authentication procedure in use. The 64-bit authen- tication field is then for use by the chosen authentication procedure. This procedure should be the last called when forming the packet to be sent. See Section D.4 of [OSPF] for details. The IPv6 destination address for the packet is selected as follows. On physical point-to-point networks, the IPv6 destination is always set to the address Allv6SPFRouters. On all other network types (including virtual links), the majority of OSPF packets are sent as unicasts, i.e., sent directly to the other end of the adjacency. In this case, the IPv6 destination is just the Neighbor'ss IPv6 address associated with the other end of the adjacency (see Section 10 of [OSPF]). The only packets not sent as unicasts are on broadcast net- works; on these networks Hello packets are sent to the multicast des- tination Allv6SPFRouters, the Designated Router and its Backup send both Link-State Update Packets and Link-State Acknowledgment Packets to the multicast address Allv6SPFRouters, while all other routers send both their Link-State Update and Link-State Acknowledgment Packets to the multicast address Allv6DRouters. Retransmissions of Link-State Update packets are ALWAYS sent as uni- casts. The IPv6 source address should be set to the IPv6 address of the send- ing interface. Interfaces to unnumbered point-to-point networks have no associated IPv6 address. On these interfaces, the IP source should be set to any of the other IPv6 addresses belonging to the router. For this reason, there must be at least one IPv6 address assigned to the router. Note that, for most purposes, virtual links act precisely the same as unnumbered point-to-point networks. However, each virtual link does have an IPv6 interface address (discovered during the routing table build process) which is used as the IP source when sending pack- ets over the virtual link. For more information on the format of specific OSPF packet types, con- sult the sections listed in Table 1. Type Packet name Detailed section (transmit) _________________________________________________________ 1 Hello Section 9.5 of [OSPF] 2 Database Description Section 10.8 of [OSPF] 3 Link-State Request Section 10.9 of [OSPF] 4 Link-State Update Section 13.3 of [OSPF] 5 Link-State Ack Section 13.5 of [OSPF] Coltun Expires June 1996 [Page 15] Internet Draft OSPFv6 December 1995 Table 1: Sections describing OSPF protocol packet transmission. 5.2 Receiving Protocol Packets Whenever a protocol packet is received by the router it is marked with the interface it was received on. For routers that have virtual links configured, it may not be immediately obvious which interface to asso- ciate the packet with. For example, consider the Router RT11 depicted in Figure 6 of [OSPF]. If RT11 receives an OSPF protocol packet on its interface to Network N8, it may want to associate the packet with the interface to Area 2, or with the virtual link to Router RT10 (which is part of the backbone). In the following, we assume that the packet is initially associated with the non-virtual link. In order for the packet to be accepted at the IP level, it must pass a number of tests, even before the packet is passed to appropriate OSPF Instance for processing: o The packet's IPv6 destination address must be the IPv6 address of the receiving interface, or one of the IPv6 multicast addresses Allv6SPFRouters or Allv6DRouters. o The IP protocol specified must be OSPF (89). o Locally originated packets should not be passed on to OSPF. That is, the source IPv6 address should be examined to make sure this is not a multicast packet that the router itself generated. Next, the OSPF packet header is verified. The fields specified in the header must match those configured for the receiving interface. If they do not, the packet should be discarded: o The version number field must specify protocol version 2. o The Instance ID found in the OSPF header must match the Instance ID of one of the OSPF instances bound to the receiving interface. Upon locating the OSPF instance all protocol process- ing of this packet will be associated with this OSPF instance. If no OSPF instance is located the packet is discarded. o The Area ID found in the OSPF header must be verified. If both of the following cases fail, the packet should be discarded. The Area ID specified in the header must either: (1) Match the Area ID of the receiving OSPF interface. In this case, the packet has been sent over a single hop. Therefore, the packet's IPv6 source address is required to be on the same net- work as the receiving interface. This can be verified by compar- ing the packet's IPv6 source address to the OSPF interface's IPv6 address, after masking both addresses with the interface's net- work mask. This comparison should not be performed on point-to- point networks. On point-to-point networks, the interface Coltun Expires June 1996 [Page 16] Internet Draft OSPFv6 December 1995 addresses of each end of the link are assigned independently, if they are assigned at all. (2) Indicate the backbone. In this case, the packet has been sent over a virtual link. The receiving router must be an area border router, and the Router ID specified in the packet (the source router) must be the other end of a configured virtual link. The receiving OSPF interface must also attach to the virtual link's configured Transit area. If all of these checks succeed, the packet is accepted and is from now on associated with the virtual link (and the backbone area). o Packets whose IPv6 destination is Allv6DRouters should only be accepted if the state of the receiving interface is DR or Backup (see Section 9.1). o The AuType specified in the packet must match the AuType speci- fied for the associated area. o The packet must be authenticated. The authentication procedure is indicated by the setting of AuType (see Appendix D of [OSPF]). The authentication procedure may use one or more Authentication keys, which can be configured on a per- interface basis. The authentication procedure may also verify the checksum field in the OSPFv6 packet header (which, when used, is set to the stan- dard IP 16-bit one's complement checksum of the OSPFv6 packet's contents after excluding the 64-bit authentication field). If the authentication procedure fails, the packet should be dis- carded. If the packet type is Hello, it should then be further processed by the Hello Protocol (see Section 10.5 of [OSPF]). All other packet types are sent/received only on adjacencies. This means that the packet must have been sent by one of the router's active neighbors. If the receiving interface connects to a broadcast network, Point-to- MultiPoint network or NBMA network the sender is identified by the IPv6 source address found in the packet's IPv6 header. If the receiv- ing interface connects to a point-to-point network or a virtual link, the sender is identified by the Router ID (source router) found in the packet's OSPFv6 header. The data structure associated with the receiving interface contains the list of active neighbors. Packets not matching any active neighbor are discarded. At this point all received protocol packets are associated with an active neighbor. For the further input processing of specific packet types, consult the sections listed in Table 2. Type Packet name Detailed section (receive) ________________________________________________________ 1 Hello Section 10.5 of [OSPF] 2 Database description Section 10.6 of [OSPF] 3 Link-state request Section 10.7 of [OSPF] Coltun Expires June 1996 [Page 17] Internet Draft OSPFv6 December 1995 4 Link-state update Section 13 of [OSPF] 5 Link-state ack Section 13.7 of [OSPF] Table 2: Sections describing OSPF protocol packet reception. Coltun Expires June 1996 [Page 18] Internet Draft OSPFv6 December 1995 6.0 Opaque LSAs Opaque LSAs are the Type 15 link-state advertisements. These adver- tisements are originated by any router and may be used directly by OSPFv6 as well as to provide for future extensibility. The Opaque LSA may also be used by other protocols such as BGP wishing to distribute information throughout the OSPFv6 domain. This information isn't used directly by OSPFv6. The contents of the Opaque LSA is some number of octets padded to 32- bit alignment. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. Flooding Scope identifies the range of the topology to which this LSA may be distributed to. The following denotes the possible values of the Flooding Scope field. o A value of 0 denotes a link-local scope. Opaque LSAs with a Flooding Scope of 0 are not flooded beyond the local (sub)network. o A value of 1 denotes an area-local scope. Opaque LSAs with a flooding scope of 1 are not flooded beyond the area that they are originated into. o A value of 2 denotes that the LSA is flooded throughout (but not beyond) the routing domain. That is the information contained within these LSAs will not be distributed to any protocols beyond OSPFv6. o A value of 3 or greater denotes distribution throughout as well as beyond the routing domain. Origination of Opaque LSAs are unique to the application using it. OSPFv6 used the Opaque LSA as a replacement for OSPFv4's external LSA's forwarding address and route tag as explained in section 3.3.3 above. The link-state ID of the Opaque LSA is divided into a type field (the first 32 bits) a type-specific ID (the second 32-bit field) and a reserved field (the remaining 64 bits). The packet format of the AS External Reference Opaque LSA is given in section A.4.6.1 of this document. The responsibility of proper handling of the Opaque LSA's Flooding Scope field is both on the sender and receiver. The receiver must always store a valid received Opaque LSA in its link-state database. Flooding scope effects both the building of the Database summary list during the initial synchronization of the link-state database and the flooding procedure. The following describes the modifications to these procedures necessary for insuring proper use of the Opaque LSA's Scoping Rules. Coltun Expires June 1996 [Page 19] Internet Draft OSPFv6 December 1995 6.1 Modifications To The Neighbor State Machine The state machine as it exists in section 10.3 of [OSPF] remains unchanged except for the action associated with State: ExStart, Event: NegotiationDone which is where the Database summary list is built. To incorporate the Opaque LSA in OSPFv6 the action is changed to the fol- lowing. State(s): ExStart Event: NegotiationDone New state: Exchange Action: The router must list the contents of its entire area link-state database in the neighbor Database summary list. The area link-state database consists of the Router LSAs, Network LSAs and Summary LSAs contained in the area structure, along with Opaque and AS External LSAs contained in the global structure. AS External LSAs are omitted from a virtual neighbor's Database summary list. AS External LSAs are omitted from the Database summary list if the area has been configured as a stub (see Section 3.6 of [OSPF]). Opaque LSAs are omitted from the from the Database summary list if the following conditions are met: 1) the Flooding Scope is link-local and the interface address and mask in the Opaque LSA does not equal the interface address and mask found in the neighbor's interface; 2) the Flooding Scope is area-local and the area associated with Opaque LSA is not the area associated with the neighbor's interface, see Appendix A.4.6 of this document. Any advertisement whose age is equal to MaxAge is omitted from the Database summary list. It is instead added to the neighbor's link-state retransmission list. A summary of the Database summary list will be sent to the neighbor in Database Description packets. Each Database Description Packet has a DD sequence number, and is explicitly acknowledged. Only one Database Description Packet is allowed outstanding at any one time. For more detail on the sending and receiving of Database Description packets, see Sections 10.8 and 10.6 of [OSPF]. 6.2 Modifications To The Flooding Procedures Coltun Expires June 1996 [Page 20] Internet Draft OSPFv6 December 1995 The flooding of Opaque LSAs must follow the rules of Flooding Scope as denoted in this section. The flooding mechanisms must therefore suppress the flooding of Opaque LSAs as follows. o If the Flooding Scope is link-local and the interface address and mask in the Opaque advertisement does not equal the address and mask found in the neighbor's interface the Opaque LSA must not be flooded out or received by the interface. o If the Flooding Scope is area-local and the area associated with Opaque LSA is not the area associated with the neighbor's interface the Opaque LSA must not be flooded out the interface. The Flooding Scope rules affect Section 13 ("The Flooding Procedure") in [OSPF]. Coltun Expires June 1996 [Page 21] Internet Draft OSPFv6 December 1995 7.0 AS External Routes 7.1 Origination Of AS External Reference Opaque LSA As explained in Section 3.3.3 of this document the formats of the AS External LSA has changed. Instead of embedding the Forwarding Address and the Route Tag in the external LSA, the external LSA has an Opaque LSA Reference field. This field "references" an Opaque LSA containing a Forwarding Address and information that was previously stored in the Route Tag. OSPFv6 therefore must maintain a list of unique pairs and a 32-bit identifier for each of these pairs. (Since the goal of the Opaque LSA is to reduce the size of the link-state database, a single Opaque LSA should be originated containing a unique .) AS boundary routers originating AS External LSAs that require either a Forwarding Address or Route Tag information, must originate Opaque LSAs which are referenced in the Opaque LSA Reference field of the AS External LSA. (see Appendix A.4.6.2 for the format of the AS External Reference Opaque LSA). 7.2 Calculating AS External Routes For performing routing table calculations on AS External LSAs, there is an extra level of indirection needed so that a router 1) must have a valid path to the originator of the AS External route; 2) locate the referenced Opaque LSA in its link-state database and 3) validate the forwarding address contained in the Opaque LSA before it adds it con- siders the AS External route valid. To accommodate the changes to the AS External LSA packet format, the following replaces 16.4 of [OSPF]. AS external routes are calculated by examining AS external LSAs. Each of the AS external LSAs is considered in turn. Most AS external LSAs describe routes to specific IP destinations. An AS external LSAs can also describe a default route for the Autonomous System (Destination ID = 0::0, subnet mask length = 0). For each AS external link adver- tisement: (1) If the cost specified by the advertisement is LSInfinity, or if the advertisement's LS age is equal to MaxAge, then examine the next advertisement. (2) If the advertisement was originated by the calculating router itself, examine the next advertisement. (3) Call the destination described by the advertisement N. N's address is obtained by masking the advertisement's Link-State ID with the network/subnet mask which is referenced by the network Mask Length Field (i.e., the length of the network mask in bits) in the advertisement. Look up the routing table entry for the AS boundary router (ASBR) that originated the advertisement. If no Coltun Expires June 1996 [Page 22] Internet Draft OSPFv6 December 1995 entry exists for router ASBR (i.e., ASBR is unreachable), do nothing with this advertisement and consider the next in the list. Else, this advertisement describes an AS external path to desti- nation N. Examine the Opaque LSA Reference field in the AS External LSA. If the field is set to 0x00000000 packets should be set to the ASBR itself. Otherwise look up the Opaque LSA in the link-state database. The Opaque LSA was originated by the AS boundary router that originated the external advertisement. The Link-State ID of Opaque LSA is <1, Opaque ID Reference, 0, 0> (see Appendix A.4.6.2 for the format of the AS External Reference Opaque LSA). Examine the forwarding address specified in the Opaque LSA. This indicates the IP address to which packets for the destination should be forwarded. If the forwarding address is set to 0::0, packets should be sent to the ASBR itself. Otherwise, look up the forwarding address in the routing table. An intra-area or inter- area path must exist to the forwarding address. If no such path exists, do nothing with the advertisement and consider the next in the list. Call the routing table distance to the forwarding address X (when the forwarding address is set to 0::0, this is the distance to the ASBR itself), and the cost specified in the advertisement Y. X is in terms of the link-state metric, and Y is a type 1 or 2 external metric. (4) Next, look up the routing table entry for the destination N. If no entry exists for N, install the AS external path to N, with next hop equal to the list of next hops to the forwarding address, and advertising router equal to ASBR. If the external metric type is 1, then the path-type is set to type 1 external and the cost is equal to X+Y. If the external metric type is 2, the path-type is set to type 2 external, the link-state component of the route's cost is X, and the type 2 cost is Y. (5) Else, if the paths present in the table are not type 1 or type 2 external paths, do nothing (AS external paths have the lowest priority). (6) Otherwise, compare the cost of this new AS external path to the ones present in the table. Type 1 external paths are always shorter than type 2 external paths. Type 1 external paths are compared by looking at the sum of the distance to the forwarding address and the advertised type 1 metric (X+Y). Type 2 external paths are compared by looking at the advertised type 2 metrics, and then if necessary, the distance to the forwarding addresses. If the new path is shorter, it replaces the present paths in the routing table entry. If the new path is the same cost, it is added to the routing table entry's list of paths. Coltun Expires June 1996 [Page 23] Internet Draft OSPFv6 December 1995 8.0 References [OSPF] Moy, J., "OSPF Version 2", IETF Internet Draft, Cascade, November 1995. [IPV6] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification", IETF Internet Draft, Xerox PARC, Ipsilon, June 1995 [IPV6ADDR] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", IETF Internet Draft Xerox PARC, Ipsilon, June 1995 [BGPOSPF] Varadhan, K., Hares, S., Rekhter, Y., "BGP4/IDRP for IP---OSPF Interaction", RFC1745, December 1994 [CIDR] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, OARnet, September 1993. [IDRP] Kunzinger, C., Editor, "INTER-DOMAIN ROUTING PROTOCOL (IDRP)", IETF Internet Draft version of ISO10747, IBM Corp., June 1995 [PMTU] McCann, J., Deering, S., "Path MTU Discovery for IP version 6", IETF Internet Draft, Digital Equipment Corporation, Xerox PARC, November 6, 1995 [MOPSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc., March 1994. [NSSA] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, RainbowBridge Communications, Stanford University, March 1994. [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, Cascade, April 1995. Coltun Expires June 1996 [Page 24] Internet Draft OSPFv6 December 1995 Appendix A: OSPFv6 Data formats This appendix describes the format of OSPFv6 protocol packets and OSPFv6 link-state advertisements. The OSPFv6 protocol runs directly over the IP version 6 network layer. Before any data formats are described, the details of the OSPFv6 encapsulation are explained. Next the OSPFv6 Options field is described. This field describes vari- ous capabilities that may or may not be supported by pieces of the OSPFv6 routing domain. The OSPFv6 Options field is contained in OSPFv6 Hello packets, Database Description packets and in OSPFv6 link-state advertisements. OSPFv6 packet formats are detailed in Section A.3. A description of OSPFv6 link-state advertisements appears in Section A.4. A.1 Encapsulation Of OSPFv6 Packets OSPFv6 runs directly over the Internet Protocol's version 6 network layer. OSPFv6 packets are therefore encapsulated solely by IPv6 and local data-link headers. OSPFv6 does not define a way to fragment its protocol packets, and depends on IPv6 fragmentation when transmitting packets larger than the network MTU. The OSPFv6 packet types that are likely to be large (Database Description Packets, Link-State Request, Link-State Update, and Link-State Acknowledgment packets) can usually be split into several separate protocol packets, without loss of functionality. This is recommended; IPv6 fragmentation should be avoided whenever possible. Using this reasoning, an attempt should be made to limit the sizes of packets sent over virtual links to 576 octets. Alternately, OSPFv6 routers may run "Path MTU Discovery for IP version 6" [PMTU] between virtual neighbors so as to discover the optimal size path MTU between the virtual neighbors. However, if necessary, the length of OSPF packets can be up to 65,535 octets (including the IPv6 header). The other important features of OSPFv6's IP encapsulation are: o Use of IP multicast. Some OSPFv6 messages are multicast, when sent over broadcast networks. Two distinct IPv6 multicast addresses are used. Packets sent to these multicast addresses should never be for- warded; they are meant to travel a single hop only. To ensure that these packets will not travel multiple hops, their IPv6 Hop Limit must be set to 1. Allv6SPFRouters For IPv6 this multicast address has been assigned the value FF02:0:0:0:0:0:0:5 (which has a link-local scope). All routers running OSPFv6 should be prepared to receive packets sent to this address. Hello packets are always sent to this destination. Also, certain OSPFv6 protocol packets are sent to this address during the flooding procedure. Coltun Expires June 1996 [Page 25] Internet Draft OSPFv6 December 1995 Allv6DRouters This multicast address has been assigned the value FF02:0:0:0:0:0:0:6 (which has a link-local scope). Both the Designated Router and Backup Designated Router must be prepared to receive packets destined to this address. Certain OSPFv6 pro- tocol packets are sent to this address during the flooding pro- cedure. o OSPFv6 is IPv6 protocol number 89. This number has been registered with the Network Information Center. IP protocol number assignments are documented in [11]. o Routing protocol packets are sent with IPv6 Priority of 7 (internet control traffic). o Routing protocol packets are sent with IPv6 Priority of Internet Control Traffic (type 7). OSPFv6 protocol packets should be given precedence over regular IPv6 data traffic, in both sending and receiv- ing. Setting the IPv6 Priority field in the IPv6 header to Internet- work Control Traffic may help implement this objective. Coltun Expires June 1996 [Page 26] Internet Draft OSPFv6 December 1995 A.2 The Options Field The OSPFv6 Options field is present in OSPFv6 Hello packets, Database Description packets and all link-state advertisements. The Options field enables OSPFv6 routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPFv6 routers. Through this mechanism routers of differing capabili- ties can be mixed within an OSPFv6 routing domain. When used in Hello packets, the Options field allows a router to reject a neighbor because of a capability mismatch. Alternatively, when capabilities are exchanged in Database Description packets a router can choose not to forward certain link-state advertisements to a neighbor because of its reduced functionality. Lastly, listing capabilities in link-state advertisements allows routers to forward traffic around reduced functionality routers, by excluding them from parts of the routing table calculation. Six bits of the OSPFv6 Options field have been assigned, although only two (the T-bit and E-bit) are described completely by this memo. Each bit is described briefly below. Routers should reset (i.e. clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating link-state adver- tisements. Conversely, routers encountering unrecognized Option bits in received Hello Packets, Database Description packets or link-state advertisements should ignore the capability and process the packet/advertisement normally. +------------------------------------+ | * | * | DC | * | N/P | MC | E | T | +------------------------------------+ The Options Field R-bit This bit is reserved for future TOS/QOS capability definitions. E-bit This bit describes the way AS-external-LSAs are flooded, as described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF]. MC-bit This bit describes whether IP multicast datagrams are forwarded according to the specifications in [MOSPF]. N/P-bit This bit describes the handling of Type-7 LSAs, as specified in [NSSA]. DC-bit This bit describes the router's handling of demand circuits, as Coltun Expires June 1996 [Page 27] Internet Draft OSPFv6 December 1995 specified in [DEMD]. Coltun Expires June 1996 [Page 28] Internet Draft OSPFv6 December 1995 A.3 OSPFv6 Packet Formats There are five distinct OSPFv6 packet types. All OSPFv6 packet types begin with a standard 24-octets header. This header is described first. Each packet type is then described in a succeeding section. In these sections each packet's division into fields is displayed, and then the field definitions are enumerated. All OSPFv6 packet types (other than the OSPFv6 Hello packets) deal with lists of link-state advertisements. For example, Link-State Update packets implement the flooding of advertisements throughout the OSPFv6 routing domain. Because of this, OSPFv6 protocol packets cannot be parsed unless the format of link-state advertisements is also understood. The format of the link-state advertisements packet is given in Section A.4. The receive processing of OSPFv6 packets is detailed in Section 5.2 of this document. The sending of OSPFv6 pack- ets is explained in Section 5.1 of this document. A.3.1 The OSPFv6 Packet Header Every OSPFv6 packet starts with a standard 48-octet header. This header contains all the information necessary to determine whether the packet should be accepted for further processing. This determination is described in Section 5.0 of this document. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | Type | Packet Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Router ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Area ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication + | | Coltun Expires June 1996 [Page 29] Internet Draft OSPFv6 December 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version # The OSPFv6 version number. This specification documents version 2 of the protocol. Type The OSPF packet types are as follows. See Sections A.3.2 through A.3.6 for details. Type Description ________________________________ 1 Hello 2 Database Description 3 Link-State Request 4 Link-State Update 5 Link-State Acknowledgment Packet Length The length of the OSPFv6 protocol packet in octets. This length includes the standard OSPFv6 header. Router ID The Router ID of the packet's source. Area ID A 128-bit number identifying the area that this packet belongs to. All OSPFv6 packets are associated with a single area. Most travel a single hop only. Packets traversing a virtual link are labeled with the backbone Area ID of 0::0. Checksum The standard IP checksum of the entire contents of the packet, starting with the OSPFv6 packet header but excluding the 64-bit authentication field. This checksum is calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excepting the authentication field. If the packet's length is not an integral number of 16-bit words, the packet is padded with an octet of zero before checksumming. The checksum is considered to be part of the packet authentication procedure; for some authentication types the checksum calculation is omitted. Instance ID This is a 8-bit number that uniquely identifies the OSPFv6 Instance (or process) within the router that will be accepting Coltun Expires June 1996 [Page 30] Internet Draft OSPFv6 December 1995 this packet. The Instance ID was added to OSPFv6 to facilitate identifying a particular OSPFv6 Instance by network management (to identify the particular instance to be managed) and by the OSPFv6 send and receive functions (to identify packet's target OSPFv6 instance). See Section 3.4.2 and Section 5 of this docu- ment for further details. AuType Identifies the authentication procedure to be used for the packet. Authentication is discussed in Appendix D of [OSPF]. Consult Appendix D of [OSPF] for a list of the currently defined authentication types. Authentication A 64-bit field for use by the authentication scheme. See Appendix D of the [OSPF] for details. Coltun Expires June 1996 [Page 31] Internet Draft OSPFv6 December 1995 A.3.2 The Hello Packet Hello packets are OSPFv6 packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. In addition, Hello Packets are multicast on those physical networks having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers. All routers connected to a common network must agree on certain param- eters (Network mask, HelloInterval and RouterDeadInterval). These parameters are included in Hello packets, so that differences can inhibit the forming of neighbor relationships. A detailed explanation of the receive processing for Hello packets is presented in Section 10.5 of [OSPF]. The sending of Hello packets is covered in Section 9.5 of [OSPF]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 1 | Packet Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Router ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Area ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval | Options | Rtr Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RouterDeadInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | Coltun Expires June 1996 [Page 32] Internet Draft OSPFv6 December 1995 + Designated Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Backup Designated Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Neighbor + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Network Mask Length The length in bits of the network mask associated with this interface. Unlike OSPFv4 the network mask length for OSPFv6 is an integer representing the number of bits in the mask. For exam- ple, if the interface address is 1080:0:0:0:8:800:200C:417A and the network mask is FFFF:FFFF:FFFF:FFFF:FFFF:0:0:0 the Network Mask Length field is 80. Options The optional capabilities supported by the router, as documented in Appendix A.2 of this document. HelloInterval The number of seconds between this router's Hello packets. Rtr Pri This router's Router Priority as used in the (Backup) Designated Router election. If set to 0, the router will be ineligible to become (Backup) Designated Router. RouterDeadInterval The number of seconds before declaring a silent router down. Designated Router The identity of the Designated Router for this network, in the view of the sending router. The Designated Router is identified here by its IP interface address on the network. Set to 0::0 if there is no Designated Router. Coltun Expires June 1996 [Page 33] Internet Draft OSPFv6 December 1995 Backup Designated Router The identity of the Backup Designated Router for this network, in the view of the sending router. The Backup Designated Router is identified here by its IP interface address on the network. Set to 0::0 if there is no Backup Designated Router. Neighbor The Router IDs of each router from whom valid Hello packets have been seen recently on the network. Recently means in the last RouterDeadInterval seconds. Coltun Expires June 1996 [Page 34] Internet Draft OSPFv6 December 1995 A.3.3 The Database Description Packet Database Description packets are OSPFv6 packet type 2. These packets are exchanged when an adjacency is being initialized. They describe the contents of the link-state database. Multiple packets may be used to describe the database. For this purpose a poll-response procedure is used. One of the routers is designated to be the master, the other the slave. The master sends Database Description packets (polls) which are acknowledged by Database Description packets sent by the slave (responses). The responses are linked to the polls via the packets' DD sequence numbers. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 2 | Packet Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Router ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Area ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | Options |0|0|0|0|0|I|M|MS +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DD sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | A | +- Link-State Advertisement -+ | Header | +- -+ | | +- -+ | | Coltun Expires June 1996 [Page 35] Internet Draft OSPFv6 December 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | The format of the Database Description packet is very similar to both the Link-State Request and Link-State Acknowledgment packets. The main part of all three is a list of items, each item describing a piece of the link-state database. The sending of Database Description Packets is documented in Section 10.8 of [OSPF]. The reception of Database Description packets is documented in Section 10.6 of [OSPF]. 0 These fields are reserved. They must be 0. Options The optional capabilities supported by the router, as documented in Section A.2 of this document. I-bit The Init bit. When set to 1, this packet is the first in the sequence of Database Description Packets. M-bit The More bit. When set to 1, it indicates that more Database Description Packets are to follow. MS-bit The Master/Slave bit. When set to 1, it indicates that the router is the master during the Database Exchange process. Oth- erwise, the router is the slave. DD sequence number Used to sequence the collection of Database Description Packets. The initial value (indicated by the Init bit being set) should be unique. The DD sequence number then increments until the com- plete database description has been sent. The rest of the packet consists of a (possibly partial) list of the link-state database's pieces. Each link-state advertisement in the database is described by its link-state advertisement header. The link-state advertisement header is documented in Section A.4.1. It contains all the information required to uniquely identify both the advertisement and the advertisement's current instance. Coltun Expires June 1996 [Page 36] Internet Draft OSPFv6 December 1995 A.3.4 The Link-State Request Packet Link-State Request packets are OSPFv6 packet type 3. After exchanging Database Description packets with a neighboring router, a router may find that parts of its link-state database are out-of-date. The Link-State Request packet is used to request the pieces of the neighbor's database that are more up-to-date. Multiple Link-State Request packets may need to be used. A router that sends a Link-State Request packet has in mind the pre- cise instance of the database pieces it is requesting. Each instance is defined by its LS sequence number, LS checksum, and LS age, although these fields are not specified in the Link-State Request Packet itself. The router may receive even more recent instances in response. The sending of Link-State Request packets is documented in Section 10.9 of the [OSPF]. The reception of Link-State Request packets is documented in Section 10.7 of [OSPF]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 3 | Packet Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Router ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Area ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | Coltun Expires June 1996 [Page 37] Internet Draft OSPFv6 December 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Each advertisement requested is specified by its LS type, Link-State ID, and Advertising Router. This uniquely identifies the advertise- ment, but not its instance. Link-State Request packets are understood to be requests for the most recent instance (whatever that might be). Coltun Expires June 1996 [Page 38] Internet Draft OSPFv6 December 1995 A.3.5 The Link-State Update Packet Link-State Update packets are OSPFv6 packet type 4. These packets implement the flooding of link-state advertisements. Each Link-State Update packet carries a collection of link-state advertisements one hop further from their origin. Several link-state advertisements may be included in a single packet. Link-State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding pro- cedure reliable, flooded advertisements are acknowledged in Link-State Acknowledgment packets. If retransmission of certain advertisements is necessary, the retransmitted advertisements are always carried by unicast Link-State Update packets. For more information on the reli- able flooding of link-state advertisements, consult Section 13 of [OSPF]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 4 | Packet Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Router ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Area ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # advertisements | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- +-+ | Link-State Advertisements | +- +-+ | ... | Coltun Expires June 1996 [Page 39] Internet Draft OSPFv6 December 1995 # advertisements The number of link-state advertisements included in this update. The body of the Link-State Update packet consists of a list of link- state advertisements. Each advertisement begins with a common 44- octet header, described in Section A.4.1. Detailed formats of the dif- ferent types of link-state advertisements are described in Section A.4. Coltun Expires June 1996 [Page 40] Internet Draft OSPFv6 December 1995 A.3.6 The Link-State Acknowledgment Packet Link-State Acknowledgment Packets are OSPFv6 packet type 5. To make the flooding of link-state advertisements reliable, flooded advertise- ments are explicitly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link-State Acknowledgment pack- ets. Multiple link-state advertisements can be acknowledged in a sin- gle Link-State Acknowledgment packet. Depending on the state of the sending interface and the sender of the corresponding Link-State Update packet, a Link-State Acknowledgment packet is sent either to the multicast address Allv6SPFRouters, to the multicast address Allv6DRouters, or as a unicast. The sending of Link-State Acknowledgement packets is documented in Section 13.5 of [OSPF]. The reception of Link-State Acknowledgement packets is docu- mented in Section 13.7 of [OSPF]. The format of this packet is similar to that of the Data Description packet. The body of both packets is simply a list of link-state advertisement headers. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 5 | Packet Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Router ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Area ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- -+ Coltun Expires June 1996 [Page 41] Internet Draft OSPFv6 December 1995 | | +- -+ | | +- -+ | A | +- Link-State Advertisement -+ | Header | +- -+ | | +- -+ | | +- -+ | | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Each acknowledged link-state advertisement is described by its link- state advertisement header. The link-state advertisement header is documented in Section A.4.1 of this document. It contains all the information required to uniquely identify both the advertisement and the advertisement's current instance. Coltun Expires June 1996 [Page 42] Internet Draft OSPFv6 December 1995 A.4 Link-State Advertisement (LSA) Formats This memo defines five distinct types of link-state advertisements. Each link-state advertisement begins with a standard 44-octet link- state advertisement header. This header is explained in Section A.4.1 of this document. Succeeding sections then diagram the separate link-state advertisement types. Each link-state advertisement describes a piece of the OSPFv6 routing domain. Every router originates a router LSA. In addition, whenever the router is elected Designated Router, it originates a network LSA. Other types of link-state advertisements may also be originated (see Section 12.4 of [OSPF]). All link-state advertisements are then flooded throughout the OSPFv6 routing domain. The flooding algorithm is reliable, ensuring that all routers have the same collection of link-state advertisements. (See Section 13 of [OSPF] for more infor- mation concerning the flooding algorithm). This collection of adver- tisements is called the link-state database. From the link-state database, each router constructs a shortest path tree with itself as root. This yields a routing table (see Section 11 of [OSPF]). For the details of the routing table build process, see Section 16 of [OSPF]. A.4.1 The Link-State Advertisement Header All link-state advertisements begin with a common 44-octet header. This header contains enough information to uniquely identify the advertisement (LS type, Link-State ID, and Advertising Router). Mul- tiple instances of the link-state advertisement may exist in the rout- ing domain at the same time. It is then necessary to determine which instance is more recent. This is accomplished by examining the LS age, LS sequence number and LS checksum fields that are also contained in the link-state advertisement header. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link-State ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | Coltun Expires June 1996 [Page 43] Internet Draft OSPFv6 December 1995 + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LS age The time in seconds since the link-state advertisement was ori- ginated. Options The optional capabilities supported by the described portion of the routing domain. OSPFv6's optional capabilities are docu- mented in Section A.2 of this document. LS type The type of the link-state advertisement. Each link-state type has a separate advertisement format. The link-state types defined in this memo are as follows (see Section 12.1.3 of [OSPF] for further explanation): LS Type Description ___________________________________ 1 Router LSA 2 Network LSA 3 Summary LSA (IP network) 4 Summary LSA (ASBR) 5 AS External LSA 15 Opaque LSA Link-State ID This field identifies the portion of the internet environment that is being described by the advertisement. The contents of this field depend on the advertisement's LS type. For example, in network LSAs the Link-State ID is set to the IPv6 interface address of the network's Designated Router (from which the network's IP address can be derived). The Link-State ID is further discussed in Section 12.1.4 in [OSPF]. Advertising Router The Router ID of the router that originated the link-state adver- tisement. For example, in network LSAs this field is equal to the Coltun Expires June 1996 [Page 44] Internet Draft OSPFv6 December 1995 Router ID of the network's Designated Router. LS sequence number Detects old or duplicate link-state advertisements. Successive instances of a link-state advertisement are given successive LS sequence numbers. See Section 12.1.6 of [OSPF] for more details. LS checksum The Fletcher checksum of the complete contents of the link-state advertisement, including the link-state advertisement header but excluding the LS age field. See Section 12.1.7 of [OSPF] for more details. Length The length in octets of the link-state advertisement. This includes the 44-octet link-state advertisement header. Coltun Expires June 1996 [Page 45] Internet Draft OSPFv6 December 1995 A.4.2 Router LSA Router LSAs are the Type 1 link-state advertisements. Each router in an area originates a router LSA. The advertisement describes the state and cost of the router's links (i.e., interfaces) to the area. All of the router's links to the area must be described in a single router LSA. For details concerning the construction of router LSAs, see Section 12.4.1 of [OSPF]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link-State ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link Data + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Metric | Coltun Expires June 1996 [Page 46] Internet Draft OSPFv6 December 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | In router LSAs, the Link-State ID field is set to the router's OSPFv6 Router ID. Router LSAs are flooded throughout a single area only. bit V When set, the router is an endpoint of an active virtual link that is using the described area as a Transit area (V is for vir- tual link endpoint). bit E When set, the router is an AS boundary router (E is for exter- nal). bit B When set, the router is an area border router (B is for border). # links The number of router links described in this advertisement. This must be the total collection of router links (i.e., interfaces) to the area. The following fields are used to describe each router link (i.e., interface). Each router link is typed (see the below Type field). The Type field indicates the kind of link being described. It may be a link to a transit network, to another router or to a stub network. The values of all the other fields describing a router link depend on the link's Type. For example, each link has an associated 128-bit Link Data field. For links to stub networks this field specifies the length of the network's IP address mask. For other link types the Link Data field specifies the router interface's IP address. When the Link Data field is the IP address mask length, the first 32-bit field is treated as an integer which contains the length in bits of the mask. Type A quick description of the router link. One of the following. Note that host routes are classified as links to stub networks with network mask length of 128. Type Description __________________________________________________ 1 Point-to-point connection to another router 2 Connection to a transit network 3 Connection to a stub network 4 Virtual link Coltun Expires June 1996 [Page 47] Internet Draft OSPFv6 December 1995 Link ID Identifies the object that this router link connects to. Value depends on the link's Type. When connecting to an object that also originates a link-state advertisement (i.e., another router or a transit network) the Link ID is equal to the neighboring advertisement's Link-State ID. This provides the key for looking up the neighboring advertisement in the link-state database dur- ing the routing table calculation. See Section 12.2 of [OSPF] for more details. Type Link ID ______________________________________ 1 Neighboring router's Router ID 2 IP address of Designated Router 3 IP network/subnet number 4 Neighboring router's Router ID Link Data Value again depends on the link's Type field. For connections to stub networks, Link Data specifies the bit-length of the network's IPv6 address mask. For unnumbered point-to-point con- nections, it specifies (in the first 32-bit field) the interface's MIB-II [8] ifIndex value. For the other link types it specifies the router interface's IP address. This latter piece of information is needed during the routing table build process, when calculating the IP address of the next hop. See Section 16.1.1 of [OSPF] for more details. Reserved Currently unused. Metric The cost of using this outbound router link. Coltun Expires June 1996 [Page 48] Internet Draft OSPFv6 December 1995 A.4.3 Network LSA Network LSAs are the Type 2 link-state advertisements. A network LSA is originated for each broadcast and NBMA network in the area which supports two or more routers. The network LSA is originated by the network's Designated Router. The advertisement describes all routers attached to the network, including the Designated Router itself. The advertisement's Link-State ID field lists the IP interface address of the Designated Router. The distance from the network to all attached routers is zero. For details concerning the construction of network LSAs, see Section 12.4.2 of [OSPF]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link-State ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Attached Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Coltun Expires June 1996 [Page 49] Internet Draft OSPFv6 December 1995 Network Mask Length The length in bits of the network mask associated with this interface. Unlike OSPFv4 the network mask length for OSPFv6 is an integer representing the number of bits in the mask. For exam- ple, if the interface address is 1080:0:0:0:8:800:200C:417A and the network mask is FFFF:FFFF:FFFF:FFFF:FFFF:0:0:0 the Network Mask Length field is 80. Attached Router The Router IDs of each of the routers attached to the network. Actually, only those routers that are fully adjacent to the Designated Router are listed. The Designated Router includes itself in this list. The number of routers included can be deduced from the link-state advertisement header's length field. Coltun Expires June 1996 [Page 50] Internet Draft OSPFv6 December 1995 A.4.4 Summary LSA Summary LSA are the Type 3 and 4 link-state advertisements. These advertisements are originated by area border routers. Summary link advertisements describe inter-area destinations. For details concern- ing the construction of summary link advertisements, see Section 12.4.3 of [OSPF]. Type 3 link-state advertisements are used when the destination is an IPv6 network. In this case the advertisement's Link-State ID field is an IPv6 network number (if necessary, the Link-State ID can also have one or more of the network's "host" bits set; see Appendix E of [OSPF] for details). When the destination is an AS boundary router, a Type 4 advertisement is used, and the Link-State ID field is the AS boundary router's OSPFv6 Router ID. (To see why it is necessary to advertise the location of each ASBR, consult Section 16.4 of [OSPF].) Other than the difference in the Link-State ID field, the format of Type 3 and 4 link-state advertisements is identical. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 3 or 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link-State ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | For stub areas, Type 3 summary link advertisements can also be used to describe a (per-area) default route. Default summary routes are used Coltun Expires June 1996 [Page 51] Internet Draft OSPFv6 December 1995 in stub areas instead of flooding a complete set of external routes. When describing a default summary route, the advertisement's Link- State ID is always set to DefaultDestination (0::0) and the Network Mask Length is set to 0. Network Mask Length For Type 3 link-state advertisements, this indicates the number of bits in the destination network's IPv6 address mask. For example, when advertising the location of FF01:0::0 with the net- work mask of FFFF:0::0, the value of 16 would be used in the mask field. This field is not meaningful and must be zero for Type 4 link-state advertisements. Metric The cost of this route. Expressed in the same units as the inter- face costs in the router LSA. Reserved This field is currently unused. Coltun Expires June 1996 [Page 52] Internet Draft OSPFv6 December 1995 A.4.5 AS External LSA AS external link advertisements are the Type 5 link-state advertise- ments. These advertisements are originated by AS boundary routers, and describe destinations external to the AS. For details concerning the construction of AS external link advertisements, see Section 12.4.3 of [OSPF] and Section 7.0 of this document. AS external link advertisements usually describe a particular external destination. For these advertisements the Link-State ID field speci- fies an IP network number (if necessary, the Link-State ID can also have one or more of the network's "host" bits set; see Appendix E for details). AS external link advertisements are also used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the Link-State ID is always set to DefaultDestination (0::0) and the Network Mask Length is set to 0. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link-State ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Reserved | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque LSA Reference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network Mask Length Coltun Expires June 1996 [Page 53] Internet Draft OSPFv6 December 1995 The number if bits in the IPv6 address mask for the advertised destination. For example, when advertising the location of FF01:0::0 with the network mask of FFFF:0::0, the value of 16 would be used in the mask field. bit E The type of external metric. If bit E is set, the metric speci- fied is a Type 2 external metric. This means the metric is con- sidered larger than any link-state path. If bit E is zero, the specified metric is a Type 1 external metric. This means that it is expressed in the same units as the link-state metric (i.e., the same units as interface cost). Metric The cost of this route. Interpretation depends on the external type indication (bit E above). Opaque LSA Reference A 32-bit field attached to each external route. The semantics of the Opaque LSA Reference for OSPFv6 is different than the OSPFv4 Route Tag in that it is used to reference an Opaque LSA (see Sec- tion 7.0 of this document) which may include the Forwarding Address as well as information which may be used for policy by other protocols resident in the AS boundary router (i.e., used to communicate information between AS boundary routers). If the External Route Tag is not set (i.e., set to zero), data traffic will be forwarded to the advertisement's originator. Coltun Expires June 1996 [Page 54] Internet Draft OSPFv6 December 1995 A.4.6 Opaque LSA Opaque LSAs are the Type 15 link-state advertisements. These adver- tisements are originated by any router and may be used directly by OSPFv6; they are a useful tool for providing for future extensibility to OSPFv6. The Opaque LSA may also be used by other protocols such as BGP wishing to distribute information throughout the OSPFv6 domain. The BGP information isn't used directly by OSPFv6. The contents of the Opaque LSA is some number of octets padded to 32- bit alignment. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. However, the Opaque LSA has a Flooding Scope associated with it so that the scope of flooding may be link-local, area-local, the OSPFv6 routing domain or beyond. Origination of Opaque LSAs are unique to the application using it. Section 6 of this document describes the flooding procedures for the Opaque LSA. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Reserved + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flooding Scope | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Opaque Information | + + | ... | Coltun Expires June 1996 [Page 55] Internet Draft OSPFv6 December 1995 Syntax Of The Opaque LSA's Link-State ID The link-state ID of the Opaque LSA is divided into an Opaque Type field (the first 32 bits), an Opaque ID (the second 32-bit field) and a reserved field (the remaining 64 bits). Flooding Scope Flooding Scope identifies the range of the topology to which this LSA may be distributed to. The following denotes the possible values of the Flooding Scope field. o A value of 0 denotes a link-local scope. Opaque LSAs with a Flooding Scope of 0 are not flooded beyond the local (sub)network. The local network is identified by the interface's network number and network mask length. See Section A.4.6.1 below for a description of the Link-Local Opaque LSA. o A value of 1 denotes an area-local scope. Opaque LSAs with a flooding scope of 1 are not flooded beyond the area that they are originated into. o A value of 2 denotes that the LSA is flooded throughout (but not beyond) the routing domain. That is, the information con- tained within these LSAs will not be distributed to any protocols beyond OSPFv6. o A value of 3 or greater denotes distribution throughout as well as beyond the routing domain. Network Mask Length The Network Mask Length field is an integer representing the length in bits of the prefix's mask. This field may be used when the first 128 bits of the Opaque Information is an address prefix (the interpretation of this field is dependent on the Opaque Type). When unused the Network Mask Length should be set to 0. Coltun Expires June 1996 [Page 56] Internet Draft OSPFv6 December 1995 A.4.6.1 Link-Local Opaque LSA Link-Local Opaque LSAs the Type 15 link-state advertisements. These advertisements are originated by any router and may be used directly by OSPFv6; they are a useful tool for providing for future extensibil- ity to OSPFv6. The contents of the Opaque LSA is some number of octets padded to 32- bit alignment. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. However, the Opaque LSA has a Flooding Scope associated with it so that the scope of flooding may be link-local, area-local, the OSPFv6 routing domain or beyond. This section pro- vides the packet format for Link-Local Opaque LSAs which must include the IPv6 address and mask of the IP interface to insure that the intended Flooding Scope is realized. Origination of Opaque LSAs are unique to the application using it. Section 6 of this document describes the flooding procedures for the Opaque LSA. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Reserved + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flooding Scope = 0 | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Interface Address + | | Coltun Expires June 1996 [Page 57] Internet Draft OSPFv6 December 1995 + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Opaque Information | + + | ... | Syntax Of The Opaque LSA's Link-State ID The link-state ID of the Opaque LSA is divided into an Opaque Type field (the first 32 bits), an Opaque ID (the second 32-bit field) and a reserved field (the remaining 64 bits). Flooding Scope Flooding Scope identifies the range of the topology to which this LSA may be distributed to. A value of 0 denotes a link-local scope. Opaque LSAs with a Flooding Scope of 0 are not flooded beyond the local (sub)network. Network Mask Length The Network Mask Length field is an integer representing the length in bits of the IPv6 interface network mask. The length is used along with the IPv6 interface address to insure that the intended Flooding Scope is realized. IPv6 Interface Address The IPv6 interface address representing the (sub)network to which the link-local flooding this Opaque LSA is limited to. The IPv6 Interface Address is used along with the Network Mask field to insure that the intended Flooding Scope is realized. Coltun Expires June 1996 [Page 58] Internet Draft OSPFv6 December 1995 A.4.6.2 AS External Reference Opaque LSA Opaque LSAs are the Type 15 link-state advertisements. AS External Reference Opaque LSA are originated by an AS boundary routers and used directly by OSPFv6 in conjunction with AS External LSAs. AS External Reference Opaque LSA are Opaque Type 1 LSAs. These are used to distribute the forwarding address, tag and origination infor- mation that were previously included in the AS External LSA. These are referenced by the Opaque LSA Reference field in the OSPFv6 AS External LSA by including the Opaque ID in Opaque LSA Reference field. Section 6 of this document describes the flooding procedures for the Opaque LSA. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Reserved + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flooding Scope = 2 | Network Mask Length = 128 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Forwarding Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Optional External Route Tag | + + Coltun Expires June 1996 [Page 59] Internet Draft OSPFv6 December 1995 | ... | Opaque Type The Opaque Type for AS External Reference Opaque LSAs is 1. Opaque ID The Opaque ID is a local reference to the contents of the Opaque LSA which consists of the Forwarding Address, Origin Flags, Domain ID Length and Domain ID. Flooding Scope The Flooding Scope field of the AS External Reference Opaque LSA is set to 2 which denotes that the LSA is flooded throughout the routing domain but not distributed beyond the routing domain. Network Mask Length This field may be used when the first 128 bits of the Opaque Information is an address prefix (the interpretation of this field is dependent on the Opaque Type). For AS External Reference Opaque LSAs this field is set to 128 denoting that the Forwarding Address which follows is a host route. Forwarding Address Data traffic for the destination advertised in the referencing AS External LSA is forwarded to this address. If the Forwarding Address is set to 0::0, data traffic will be forwarded instead to the advertisement's originator (i.e., the responsible AS boundary router). Note that setting the Opaque LSA Reference field to 0 will also result in data traffic being forwarded to the advertisement's originator. Optional External Route Tag A 32-bit aligned variable length optional field that is not used by the OSPF protocol itself but may be used to communicate infor- mation between AS boundary routers. This information may be locally defined information, prefix origin information or a list of domain identifiers. The precise nature of such information is outside the scope of this specification. The length of the External Route Tag (which may be 0 if the field is omitted) may be determined by the LSA's length field. Coltun Expires June 1996 [Page 60] Internet Draft OSPFv6 December 1995 Appendix B: Architectural Constants Several OSPF protocol parameters have fixed architectural values. These parameters have been referred to in the text by names such as LSRefreshTime. The same naming convention is used for the configur- able protocol parameters. They are defined in Appendix C of this docu- ment and [OSPF]. The name of the OSPFv6 specific architectural constant follows, together with its value and a short description of its function. IPv6DefaultDestination The Destination ID that indicates the default route. This route is used when no other matching routing table entry can be found. The default destination can only be advertised in AS External LSA and in stub areas' type 3 summary LSAs. Its value is the IP address 0::0. Its associated Network Mask Length is always 0. Allv6SPFRouters For IPv6 this multicast address has been assigned the value FF02:0:0:0:0:0:0:5. All routers running OSPFv6 should be prepared to receive packets sent to this address. Hello packets are always sent to this destination. Also, certain OSPFv6 protocol packets are sent to this address during the flooding procedure. This address has a link-local scope. See [IPV6ADDR] for a further description of IP version 6 Addresses Architecture. Allv6DRouters This IPv6 multicast address has been assigned the value FF02:0:0:0:0:0:0:6. Both the Designated Router and Backup Desig- nated Router must be prepared to receive packets destined to this address. Certain OSPFv6 protocol packets are sent to this address during the flooding procedure. This address has a link- local scope. See [IPV6ADDR] for a further description of IP ver- sion 6 Addresses Architecture. Coltun Expires June 1996 [Page 61] Internet Draft OSPFv6 December 1995 Appendix C: Configurable Constants The OSPF protocol has quite a few configurable parameters. These parameters are listed below. They are grouped into general functional categories (area parameters, interface parameters, etc.). Some parameter settings need to be consistent among groups of routers. For example, all routers in an area must agree on that area's parame- ters, and all routers attached to a network must agree on that network's IP network number and mask. Some parameters may be determined by router algorithms outside of this specification (e.g., the address of a host connected to the router via a SLIP line). From OSPF's point of view, these items are still confi- gurable. This specification gives the Global Parameters for OSPFv6. Appendix C of [OSPF] should be referred to for the remaining parameters. C.1 Global Parameters In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per- area basis. The few global configuration parameters are listed below. Router ID This is a 128-bit number that uniquely identifies the router in the Autonomous System. One algorithm for Router ID assignment is to choose the largest or smallest IP address assigned to the router. If a router's OSPF Router ID is changed, the router's OSPF software should be restarted before the new Router ID takes effect. Before restarting in order to change its Router ID, the router should flush its self-originated link state advertisements from the routing domain (see Section 14.1 of [OSPF]), or they will persist for up to MaxAge minutes. Instance ID This is a 8-bit number that uniquely identifies the OSPFv6 Instance (or process) within the router. The Instance ID was added to OSPFv6 to facilitate identifying a particular OSPFv6 Instance by network management (to identify the particular instance to be managed) and by the OSPFv6 send and receive func- tions (to identify packet's target OSPFv6 instance). See Section 3.4.2 and Section 5 of this document for further details. Coltun Expires June 1996 [Page 62] ------------------------------------------------------------------------------ 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