From owner-ipng@sunroof.eng.sun.com Fri Jan 2 06:37:19 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA14356 for ipng-dist; Fri, 2 Jan 1998 06:29:08 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA14349 for ; Fri, 2 Jan 1998 06:28:56 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA15120 for ; Fri, 2 Jan 1998 06:28:53 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA13333 for ; Fri, 2 Jan 1998 06:29:22 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA01115; Fri, 2 Jan 1998 09:28:49 -0500 (EST) Message-Id: <199801021428.JAA01115@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5095) I-D ACTION:draft-ietf-ipngwg-aaaa-01.txt Date: Fri, 02 Jan 1998 09:28:49 -0500 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 : DNS Extensions to support IP version 6 Author(s) : C. Huitema, S. Thomson Filename : draft-ietf-ipngwg-aaaa-01.txt Pages : 9 Date : 31-Dec-97 This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. 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-aaaa-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-aaaa-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-aaaa-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. 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: <19971231145031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-aaaa-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-aaaa-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971231145031.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 2 06:37:19 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA14347 for ipng-dist; Fri, 2 Jan 1998 06:28:54 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA14340 for ; Fri, 2 Jan 1998 06:28:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA15114 for ; Fri, 2 Jan 1998 06:28:37 -0800 Received: from ns.ietf.org ([132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA13276 for ; Fri, 2 Jan 1998 06:29:06 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA01078; Fri, 2 Jan 1998 09:28:32 -0500 (EST) Message-Id: <199801021428.JAA01078@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5094) I-D ACTION:draft-degermark-ipv6-hc-05.txt Date: Fri, 02 Jan 1998 09:28:32 -0500 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 : IP Header Compression Author(s) : S. Pink, M. Degermark, B. Nordgren Filename : draft-degermark-ipv6-hc-05.txt Pages : 45 Date : 31-Dec-97 This document describes how to compress multiple IP headers and TCP and UDP headers per-hop over point-to-point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers. Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 octet UDP or TCP checksum. This largely removes the negative impact of large IP headers and allows efficient use of bandwidth on low- and medium-speed links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-degermark-ipv6-hc-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-degermark-ipv6-hc-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-degermark-ipv6-hc-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19971231144240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-degermark-ipv6-hc-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-degermark-ipv6-hc-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971231144240.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 2 07:01:12 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA14390 for ipng-dist; Fri, 2 Jan 1998 06:53:51 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA14383 for ; Fri, 2 Jan 1998 06:53:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA20852 for ; Fri, 2 Jan 1998 06:53:38 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA18595 for ; Fri, 2 Jan 1998 06:54:08 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id JAA11909; Fri, 2 Jan 1998 09:53:38 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.5/8.6.12) id JAA18589; Fri, 2 Jan 1998 09:53:38 -0500 (EST) Date: Fri, 2 Jan 1998 09:53:38 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-Id: <980102095336.ZM18587@seawind.bellcore.com> In-Reply-To: Robert Elz "(IPng 5092) Re: December minutes / Site addresses" (Jan 1, 5:57pm) References: <3.0.3.32.19971224124709.0083d830@mailhost.ipsilon.com> <971229164947.ZM15837@seawind.bellcore.com> <28195.883469879@munnari.OZ.AU> <971231094153.ZM17308@seawind.bellcore.com> <8653.883637851@munnari.OZ.AU> X-Mailer: Z-Mail (5.0.0 30July97) To: Robert Elz , huitema@bellcore.com (Christian Huitema) Subject: (IPng 5096) Re: December minutes / Site addresses Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk KRE, You may have a clear idea of what is going on in your campus. But my own experience is somewhat different. Consider: - a visiting professor who has retained links (satellite, wireless, tunnel) with his or her university, - a research team whose contracts require them to maintain links (encrypted, probably) with their industrial partner. These are two real life examples. There are many more, and similar situations exist in commercial sites. In these cases, you find individuals, some of which carry a lot convincing power, who want their computers in two sites at the same time. Just try to tell them that they have to choose one because the software you picked would not let them do what they want -- they will not be very impressed. Worse, chances are they will instruct some grad student to hack teh system and fix "the bug." You may not like the result. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 2 11:55:57 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA14821 for ipng-dist; Fri, 2 Jan 1998 11:52:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id LAA14814 for ; Fri, 2 Jan 1998 11:52:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA23047 for ; Fri, 2 Jan 1998 11:52:11 -0800 Received: from gate.ntrs.com (gate.ntrs.com [192.77.161.2]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id LAA11411 for ; Fri, 2 Jan 1998 11:52:40 -0800 (PST) Received: by gate.ntrs.com id AA24382 (InterLock SMTP Gateway 3.0 for ipng@sunroof.Eng.Sun.COM); Fri, 2 Jan 1998 13:52:11 -0600 Received: by gate.ntrs.com (Internal Mail Agent-1); Fri, 2 Jan 1998 13:52:11 -0600 X-Lotus-Fromdomain: NORTHERN TRUST From: "Adam Fleming" To: ipng@sunroof.eng.sun.com Message-Id: <86256580.006B7F1E.00@chi-g02.ntrs.com> Date: Fri, 2 Jan 1998 13:50:14 -0600 Subject: (IPng 5097) Performance of IPv6 encapsulation Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Has anyone ever compared the performance of running IPv6 encapsulated in IPv4 with just running straight IPv4? Is there a performance degradation? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 3 11:25:07 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA15852 for ipng-dist; Sat, 3 Jan 1998 11:21:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id LAA15845 for ; Sat, 3 Jan 1998 11:21:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA25558 for ; Sat, 3 Jan 1998 11:21:36 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id LAA07680 for ; Sat, 3 Jan 1998 11:22:02 -0800 (PST) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id TAA12388; Sat, 3 Jan 1998 19:18:31 GMT From: "Peter Curran" To: "Adam Fleming" , Subject: (IPng 5100) Re: Performance of IPv6 encapsulation Date: Sat, 3 Jan 1998 19:30:54 -0000 Message-ID: <01bd187e$1c61cf80$0f0120c1@desktop.ticl.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0011_01BD187E.1C47DEE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0011_01BD187E.1C47DEE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adam > >Has anyone ever compared the performance of running IPv6 encapsulated in >IPv4 with just running straight IPv4? > Quite a few people :-) >Is there a performance degradation? > Depends on what you mean by 'performance'. Using the INRIA implementation under FreeBSD, the difference in time taken to ping a device on the same subnet using it v4 address and v4-compatible v6 address is around 2 millisecs. This difference is primarily the delay imposed by the encapsulation (implemented as a network device), although there will be a slight increase in serialisation delay due to the larger packet (couple of microsecs). So the simple answer to your question is that (using the INRIA implementation) you can expect an additional delay of 1 millisec one-way. Of course, the packets you send are 20 bytes bigger. This consumes more bandwidth per packet and therefor reduces the efficiency of the network. This is pretty difficult to measure. To give you some idea of the end-to-end efficiency of a v6-over-v4 tunnel, take a look at some of the many stats pages maintained by some of the 6bone sites (go to http://www.6bone.net for pointers in the right direction). Hope this helps, Peter Curran ------=_NextPart_000_0011_01BD187E.1C47DEE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII0TCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAnkwggHioAMCAQICEFIfNR3ycH4AK77KWYcE1TkwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDYyNzAwMDAwMFoXDTk5MDYyNzIz NTk1OVowYjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTQwMgYD VQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJzY3JpYmVyMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQC2FKbPTdAFDdjKI9BvqrQpkmOOLPhvltcunXZLEbE2jVfJw/0c xrr+Hgi6M8qV6r7jW80GqLd5HUQq7XPysVKDaBBwZJHXPmv5912dFEObbpdFmIFH0S3L3bty10w/ cariQPJUObwW7s987LrbP2wqsxaxhhKdrpM01bjV0Pc+qQIDAQABozMwMTAPBgNVHRMECDAGAQH/ AgEBMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAwfr3 AudXyhF1xpwM+it3T4dFFzvj0sHaD1g5jq6VmQOhqKE4/nmakxcLl4Y5x8poNGa7x4hF9sgMBe6+ lyXv4NRu5H+ddlzOfboUoq4Ln/tnW0ilZyWvGWSI9nLYKSeqNxJqsSivJ4MYZWyN7UCeTcR4qIbs 6SxQv6b5DduwpkowggQQMIIDeaADAgECAhApF9yEa2f1I6vNhJOMYHGgMA0GCSqGSIb3DQEBBAUA MGIxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMr VmVyaVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzExMjEwMDAw MDBaFw05ODAxMjAyMzU5NTlaMIIBDTERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJz Y3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4g YnkgUmVmLixMSUFCLkxURChjKTk2MScwJQYDVQQLEx5EaWdpdGFsIElEIENsYXNzIDEgLSBNaWNy b3NvZnQxFTATBgNVBAMTDFBldGVyIEN1cnJhbjEhMB8GCSqGSIb3DQEJARYScGN1cnJhbkB0aWNs LmNvLnVrMFswDQYJKoZIhvcNAQEBBQADSgAwRwJAbGS4S0SN7NX2OODlfiOves53hbLKytcxawKy ipnvwVqlHCtugU+GznF/cq3jvMQeehvX+9+lxts1Q7BXxw9QuQIDAQABo4IBXTCCAVkwCQYDVR0T BAIwADCBrwYDVR0gBIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEa PVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVy aVNpZ24AAAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2 M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2Rh NWMxZTMxNDFiZWFkYjJiZDI5YWZhMTJiZDY4OTFhMTExNDk5OGExYmE0M2Y0ZTY5MTY1NDEwDQYJ KoZIhvcNAQEEBQADgYEAUXbKrrDI9DdxdSL9W4pMtNBTZpFV9yMkBkiKdSOwdjmSh3/qPl11P/HM KDT9CtIXpeT0JcUlkZsXaGkLGZnVWHvsqjUyvqT6XOCy1Vm1VokROmbfFItKacbTwoQsArhISOYB DdUOwpZiD/HEdCTnTb4r6bC3MZ+6afsCn0zi//sxggE6MIIBNgIBATB2MGIxETAPBgNVBAcTCElu dGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3Mg MSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcgIQKRfchGtn9SOrzYSTjGBxoDAJBgUrDgMCGgUA oF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTgwMTAzMTkzMDU0 WjAjBgkqhkiG9w0BCQQxFgQUMEQm0RlRIvcKesr5LN97d+HtQ5YwDQYJKoZIhvcNAQEBBQAEQCoC ujXGsUrMgHaX9jKwTjIPLAt/Ch5TlzjjYuj02lBlV/sUsge3m9189hn5h7jp5y3HrOLQm2Ji4veu 4XoKfG0AAAAAAAA= ------=_NextPart_000_0011_01BD187E.1C47DEE0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 3 22:03:49 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id WAA16138 for ipng-dist; Sat, 3 Jan 1998 22:00:27 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id WAA16131 for ; Sat, 3 Jan 1998 22:00:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA23213 for ; Sat, 3 Jan 1998 22:00:15 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id WAA01400 for ; Sat, 3 Jan 1998 22:00:42 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id GA22451; Sun, 4 Jan 1998 17:00:01 +1100 (from kre@munnari.OZ.AU) To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5101) Re: December minutes / Site addresses In-Reply-To: A message of "Fri, 02 Jan 1998 09:53:38 -0500." References: <3.0.3.32.19971224124709.0083d830@mailhost.ipsilon.com> <971229164947.ZM15837@seawind.bellcore.com> <28195.883469879@munnari.OZ.AU> <971231094153.ZM17308@seawind.bellcore.com> <8653.883637851@munnari.OZ.AU> <980102095336.ZM18587@seawind.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Jan 1998 17:00:00 +1100 Message-Id: <22048.883893600@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 2 Jan 1998 09:53:38 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-ID: <980102095336.ZM18587@seawind.bellcore.com> Before I respond to your two examples, your postamble text reveals a vast difference in model from what I have been assuming... | In these cases, you find | individuals, some of which carry a lot convincing power, who want | their computers in two sites at the same time. Just try to tell | them that they have to choose one because the software you picked I don't expect the end user to have the vaguest idea what site(s) their box happens to be in - I think that if the casual user ever finds out, we have failed. All this needs to be automatic, the user should not care in the slightest, and unless they're the curious type at the low level (as you or I might be) they ought never find out what site they're a member of (if any). I see the point (the sole point) of site local addresses (other than the augmented dentist's office, which we might call the medical centre model, a group of connected nets, not connected to anyplace else) as being that they allow local connectivity to survive renumbering (so all your file server connections don't die if your site is renumbered principally). Aside from that, if global addresses are available, they may as well be used, site local addresses have no other advantages. In particular, I don't see them as at all useful for security, firewalling, etc, and I think it would be a disservice to design the things with the assumption that people would be using them for any such purpose. So I'm not in the least worried about users caring that they have to select only one sight to be in, they should never have to select any, and they're not likely to notice what has been chosen for them. | You may have a clear idea of what is going on in your campus. But my | own experience is somewhat different. Consider: I'll take your two examples in the opposite order than you gave them (easier to deal with). | - a research team whose contracts require them to maintain links | (encrypted, probably) with their industrial partner. I can't imagine site local addresses being used there, those are clearly two different sites, and should be using global addressing. If they need private links, which they want to remain stable over potential renumberings by one or both, a better solution than having some of the nodes pretending to be in the other site would be to extend the model to allow communications between different sites using site local addressing. That's one direction I think the model could eventually be extended, though I'd prefer not to think too much about that until we have the simpler cases handled. | - a visiting professor who has retained links (satellite, wireless, | tunnel) with his or her university, This might be one of two cases - either it is being considered as a mobile node, in which case I think in general the node will remain in the site it left, and use the private link (tunnel usually, though I gather implemented using source routing, which would make site local addresses difficult to use, which I think is a mistake, and I expect tunnels wil be quite common). Alternatively, it is just a new node in the new site, a member of that site, which happens to communicate a lot with the old site, using global addressing to do that. | Worse, chances are they will instruct some grad student | to hack teh system and fix "the bug." You may not like the result. Then again, I might. That might often be done, and fail miserably (which might mean serve the immediate purpose, but be not generally useful), but that kind of experimentation is how I see the model being gradually extended once we have the basics in place. Again, I'd prefer to design the simple case now, rather than attempt to figure out everything now, but by all means avoid designing in restrictions which will make growth difficult, so I certainly believe that using the empty bits in site local addresses to carry a site identifier is the right thing to do, as almost any future extension is likely to depend upon that. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 5 11:31:46 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA17563 for ipng-dist; Mon, 5 Jan 1998 11:27:08 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id LAA17556 for ; Mon, 5 Jan 1998 11:26:59 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id LAA00066 for ; Mon, 5 Jan 1998 11:26:57 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA20534; Mon, 5 Jan 1998 11:26:06 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA15831 for ; Sat, 3 Jan 1998 10:42:29 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA23967 for ; Sat, 3 Jan 1998 10:42:26 -0800 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id KAA29933 for ; Sat, 3 Jan 1998 10:42:55 -0800 (PST) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <52339(2)>; Sat, 3 Jan 1998 10:42:13 PST Received: from parc.xerox.com ([13.0.211.227]) by casablanca.parc.xerox.com with SMTP id <71813>; Sat, 3 Jan 1998 10:41:57 PST Message-ID: <34AE8670.7F71BB5A@parc.xerox.com> Date: Sat, 3 Jan 1998 10:41:52 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: brian@hursley.ibm.com CC: deering@cisco.com, fielding@ics.uci.edu, ipng@sunroof.eng.sun.com Subject: (IPng 5103) Re: IPv6 literals in URLs References: <349566FE.37BC@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi -- I'd like to appeal directly to the IPNG WG's to include the "---abcd-ef12.1.2.3.4.ipv6" notation in the documentation of text representations of IPv6 addresses. I don't like having one proposed standard saying "you should do Ipv6 literals this way" and then another URL standard say "except inside URLs, you should do them that way". I suppose we could just make yet another document that talks about this compromise and reference it both from the URL spec and the IPv6 spec. Larry -- http://www.parc.xerox.com/masinter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 5 12:14:55 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id MAA17651 for ipng-dist; Mon, 5 Jan 1998 12:06:47 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id MAA17644 for ; Mon, 5 Jan 1998 12:06:36 -0800 (PST) Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id MAA05789; Mon, 5 Jan 1998 12:06:31 -0800 (PST) Date: Mon, 5 Jan 1998 12:06:30 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5105) Re: December minutes / Site addresses To: Robert Elz Cc: Christian Huitema , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <8653.883637851@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I actually had (somewhere in my tiny brain) an idea that the sitedness > of a node would be automatically determined by the software, a node which > say "site N" advertised on one link, and "site M" advertised on another > would simply refuse to configure any site local addressing (the software > would not allow it to happen) and would automatically be a member of > neither site. I agree that this could be done but it has some in my opinion undesirable properties. As routers and interfaces come and go a node with multiple interfaces will sometimes (when it hears only one site adveertisement) use a site local address but other times (when the router or interface to another site is up) not use a site local address. The point is that the node can't once and for all determine whether or not it is connected to links in more than one site. > Similarly, on a link where a node saw adverts for two > different sites, it would ignore all of those, and treat the link as if > no site addresses were available on it (including for the purpose of the > previous test). So in a sense, yes, it could be enforced. One could make strong arguments for links only belonging to one site: a multicast to a site scope multicast address would not be well behaved if it is sent on a link which belongs to more than one site. Is there really a case when it would be useful to have a link belong to more than one site? Since tunnels are point to point links it would still be possible for multiple sites to use the same physical link (e.g. Ethernet) by configuring tunnels. > I don't come to that conclusion. My building belongs to only one > campus, and other than sub-units of the campus (essentially sub-nets in > the IP addressing world) I see nothing that is simultaneously a member of > multiple different campuses. So, your real life entity example to me > re-inforces my definition, rather than contradicts it. If you exclude multi-sited nodes from a site you might end up with odd cases when connectivity changes. For example, with a two-subnet single router site: H2 | ---------- Subnet 2, Site X | R | ---------- Subnet 1, Site X | H1 When R gets connected to site Y using another interface then, according to your definition, R is in neither site X nor Y. This means that the internal connectivity in site X now uses a router which does not belong to site X. I think that means that the router would no longer advertise or propagate site local routes which means that the internal communication in site X would break. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 5 13:42:21 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id NAA17738 for ipng-dist; Mon, 5 Jan 1998 13:36:16 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id NAA17731 for ; Mon, 5 Jan 1998 13:36:05 -0800 (PST) Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id NAA01772; Mon, 5 Jan 1998 13:35:55 -0800 (PST) Date: Mon, 5 Jan 1998 13:35:56 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5106) Re: December minutes / Site addresses To: Matt Crawford Cc: ipng@sunroof.eng.sun.com, Christian Huitema In-Reply-To: "Your message with ID" <199712292350.RAA14187@gungnir.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > * The site identifiers should be unique. Recovery in the case of > duplication will be essentially impossible. ("Recovery" might > consist of an injunction for nodes from one site to never visit the > site with the duplicate id, plus some jiggery-pokery to hide the > site-local DNS entries with the duplicated prefix.) I don't quite understand the requirement for globally unique site ids. If we decide to store site local addresses in the DNS it is easy for nodes to ignore site locals for different sites even if the site ids happen to be identical. This can be done by observing the whole AAAA RRset and only accept the site local address in that set if the set also contains one or more global addresses which match the global prefixes assigned to the site. Is your point about "visits" in relations to mobile IP or for something else? Mobile IP would definitely need to be aware of site locals and do some things differently, but for non-mobile IP vists I assume that the node will autoconfigure in the visited site and not try to use its "home" addresses. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 5 16:38:52 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id QAA18112 for ipng-dist; Mon, 5 Jan 1998 16:34:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id QAA18105 for ; Mon, 5 Jan 1998 16:33:52 -0800 (PST) From: bmanning@ISI.EDU Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA10515; Mon, 5 Jan 1998 16:33:49 -0800 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA04845; Mon, 5 Jan 1998 16:34:19 -0800 (PST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id QAA06406; Mon, 5 Jan 1998 16:33:47 -0800 (PST) Posted-Date: Mon, 5 Jan 1998 16:32:27 -0800 (PST) Message-Id: <199801060032.AA22105@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Mon, 5 Jan 1998 16:32:27 -0800 Subject: (IPng 5107) Re: December minutes / Site addresses To: Erik.Nordmark@Eng Date: Mon, 5 Jan 1998 16:32:27 -0800 (PST) Cc: crawdad@fnal.gov, ipng@sunroof.eng.sun.com, huitema@bellcore.com In-Reply-To: from "Erik Nordmark" at Jan 5, 98 01:35:56 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > * The site identifiers should be unique. Recovery in the case of > > duplication will be essentially impossible. ("Recovery" might > > consist of an injunction for nodes from one site to never visit the > > site with the duplicate id, plus some jiggery-pokery to hide the > > site-local DNS entries with the duplicated prefix.) > > I don't quite understand the requirement for globally unique site ids. > If we decide to store site local addresses in the DNS it is easy > for nodes to ignore site locals for different sites even if the > site ids happen to be identical. This can be done by observing > the whole AAAA RRset and only accept the site local address > in that set if the set also contains one or more global addresses > which match the global prefixes assigned to the site. > There was some previous discussion on the applicability of storing site local and link local addresses within the DNS. If I remember correctly, this was deemed to be undesirable. Have we come full circle on this topic? -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 5 21:35:51 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id VAA18397 for ipng-dist; Mon, 5 Jan 1998 21:29:51 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id VAA18390 for ; Mon, 5 Jan 1998 21:29:40 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id VAA27232; Mon, 5 Jan 1998 21:29:31 -0800 (PST) Date: Mon, 5 Jan 1998 21:29:09 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5108) Re: December minutes / Site addresses To: bmanning@ISI.EDU Cc: Erik.Nordmark@Eng, crawdad@fnal.gov, ipng@sunroof.eng.sun.com, huitema@bellcore.com In-Reply-To: "Your message with ID" <199801060032.AA22105@zed.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There was some previous discussion on the applicability of storing > site local and link local addresses within the DNS. If I remember > correctly, this was deemed to be undesirable. Have we come full > circle on this topic? I don't think we have decided. We had (and presumably still have) consensus that we don't want to require a two-faced DNS. Now we have an observation that it is possible to combine the ideas in the site prefixes draft with storing site local addresses in the DNS and having the resolver determine (based on the advertised site prefixes) whether or not it should use the site local address it got from the DNS. Thus this wouldn't assume a two-faced DNS but it would require that by default all hosts ignore site local addresses returned by the DNS while we figure out how we want site local address to work. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 6 20:43:01 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id UAA19653 for ipng-dist; Tue, 6 Jan 1998 20:36:17 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id UAA19646 for ; Tue, 6 Jan 1998 20:36:07 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA04268 for ; Tue, 6 Jan 1998 20:36:04 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id UAA10319 for ; Tue, 6 Jan 1998 20:36:35 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id XAA08093; Tue, 6 Jan 1998 23:28:20 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA16767; Tue, 6 Jan 1998 23:28:15 -0500 Message-Id: <199801070428.AA16767@wasted.zk3.dec.com> To: Bob Hinden Cc: minutes@ietf.org, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 5109) RFC2133 API Update Bullets: Re: IPng W.G. Minutes In-Reply-To: Your message of "Tue, 30 Dec 1997 09:54:59 PST." <3.0.3.32.19971230095459.0097d580@mailhost.ipsilon.com> Date: Tue, 06 Jan 1998 23:28:15 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, Sorry these are late but Holidays took precedent. I suggest we not have IETF meetings in December to the Chairs and the community? They should happen in early November? I have put RESOLUTIONS based on meeting short presentation and discussion with principle communicators on the mail list (Hartrick, Nordmark, McCann, Bound, et al..). We RFC 2133 authors need to get an updated draft out for discussion but input to these minutes would be nice for a week or so? Thanks /jim ------------------------------------------------- IETF 40 Washington D.C. Update to RFC 2133 IPng Meeting 12/18/97 Jim Bound Digital Equipment Corporation o gethostbyname2() Issues: - RES_USE_INET6 requires setting global parameter - WG mail list consensus Basic API should be Thread Safe - WG mail list consensus Basic API needs Flaga and Dynamic control capability o struct hostent *gethostbyname3( const char *name, int AF, int Flags); - name : host name or address - AF : AF_INET or AF_INET6 - Flags: ** This is the point and "opportunity" for discussion? o void freehostent(struct hostent *ptr) o AF and Flags Now: - AF_INET, 0 = IPv4 returned, h_length = 4; - AF_INET6, 0 = IPv6 returned, h_length = 16, - AF_INET6, AI_V4MAPPED = IPv6 OR v4-mapped, h_length = 16; - AF_INET6, AI_ALL = IPv6 AND v4mapped, h_length = 16; - AF_INET6, AI_V6ADDRCONF = IPv6 IFF v6 addr on interface; - AF_INET6, AI_ALL | AI_V6ADDRCONF = same as above except will return v4mapped for IPv4 for interface; o freehostent() MUST always be called. AF and Flags Default Suggestion; SUGGESTION #1: IF AF_INET6, 0; return v6only | v4mapped. Choice is impelementations, but caller MUST set AI_NOV4MAPPED to restrict it to only IPv6-Only Addresses. RESOLUTION: This appears to have consensus but should be defined via new AI_DEFAULT below. * Rationale - Simple port from gethostbyname to gethostbyname3 like gethostbyname3(name, 6, 0); gethostbyname(name); SUGGESTION #2: Caller must set AI_ALLOC to cause dynamic allocation, hence, only then must freehostent() be called. RESOLUTION: Consensus was this should be rejected. freehostent() must be used. If gethostbyname() does not support MT safety then compile time constant will have to be used to not call freehostent. SUGGESTION #3: AI_V6ADDRCONF is default and also define for IPv4 interfaces too? RESOLUTION: This had rough consensus. SUGGESTION #4: Do not require gethostbyaddr() to return dynamic alloc of memory. Issue is source and binary compatibility. RESOLUTION: This had consensus. But IPv6 will have new gethostbyaddr() function. SUGGESTION #5: Define default behavior if Flags = AI_DEFAULT?? RESOLUTION: This had rough consensus: The authors seek input or will use SUGGESTION #1 as basis for this New Flag, and use their judgement for a new draft. SUGGESTION #6: Name Change Suggestion: - getdynhostname(); - freedynhostent(); - getdynhostbyaddr(); RESOLUTION: This had consensus. But Steve Deering suggested removing the word host for "node". WG was polled and that appears to have rough consensus for Steve's suggestion. SUGGESTION #7: Add any "new" AI FLAGS to getaddrinfo. Warning::: The Open Group XNET Group owns this API. RESOLUTION: NO DISCUSSION at Wash D.C. can discuss on mail list. Thanks Bob, Sue, Jim, and Rich (the authors)........ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 05:21:30 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA20223 for ipng-dist; Wed, 7 Jan 1998 05:04:48 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA20209 for ; Wed, 7 Jan 1998 05:04:30 -0800 (PST) From: rc_hjac@graovasco.ipv.pt Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18535 for ; Wed, 7 Jan 1998 05:04:26 -0800 Received: from graovasco.ipv.pt ([193.137.7.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03322 for ; Wed, 7 Jan 1998 05:04:54 -0800 (PST) Received: from graovasco.ipv.pt (193.137.7.73) by graovasco.ipv.pt (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 04 Jan 1998 17:36:42 +0000 Message-Id: <1.5.4.32.19980107120522.00685de8@elect.estv.ipv.pt> X-Sender: rc_hjac@elect.estv.ipv.pt X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jan 1998 13:05:22 +0100 To: Erik.Nordmark@Eng Subject: (IPng 5114) Re: December minutes / Site addresses Cc: crawdad@fnal.gov, ipng@sunroof.eng.sun.com, huitema@bellcore.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > * The site identifiers should be unique. Recovery in the case of > > duplication will be essentially impossible. ("Recovery" might > > consist of an injunction for nodes from one site to never visit the > > site with the duplicate id, plus some jiggery-pokery to hide the > > site-local DNS entries with the duplicated prefix.) > > I don't quite understand the requirement for globally unique site ids. > If we decide to store site local addresses in the DNS it is easy > for nodes to ignore site locals for different sites even if the > site ids happen to be identical. This can be done by observing > the whole AAAA RRset and only accept the site local address > in that set if the set also contains one or more global addresses > which match the global prefixes assigned to the site. > There was some previous discussion on the applicability of storing site local and link local addresses within the DNS. If I remember correctly, this was deemed to be undesirable. Have we come full circle on this topic? -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 05:21:28 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA20199 for ipng-dist; Wed, 7 Jan 1998 05:04:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA20185 for ; Wed, 7 Jan 1998 05:03:50 -0800 (PST) From: rc_hjac@graovasco.ipv.pt Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18490 for ; Wed, 7 Jan 1998 05:03:48 -0800 Received: from graovasco.ipv.pt ([193.137.7.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03089 for ; Wed, 7 Jan 1998 05:04:14 -0800 (PST) Received: from graovasco.ipv.pt (193.137.7.73) by graovasco.ipv.pt (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 04 Jan 1998 17:36:38 +0000 Message-Id: <1.5.4.32.19980107120517.00682174@elect.estv.ipv.pt> X-Sender: rc_hjac@elect.estv.ipv.pt X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jan 1998 13:05:17 +0100 To: bmanning@ISI.EDU Subject: (IPng 5112) Re: December minutes / Site addresses Cc: Erik.Nordmark@Eng, crawdad@fnal.gov, ipng@sunroof.eng.sun.com, huitema@bellcore.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There was some previous discussion on the applicability of storing > site local and link local addresses within the DNS. If I remember > correctly, this was deemed to be undesirable. Have we come full > circle on this topic? I don't think we have decided. We had (and presumably still have) consensus that we don't want to require a two-faced DNS. Now we have an observation that it is possible to combine the ideas in the site prefixes draft with storing site local addresses in the DNS and having the resolver determine (based on the advertised site prefixes) whether or not it should use the site local address it got from the DNS. Thus this wouldn't assume a two-faced DNS but it would require that by default all hosts ignore site local addresses returned by the DNS while we figure out how we want site local address to work. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 05:21:31 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA20198 for ipng-dist; Wed, 7 Jan 1998 05:04:06 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA20183 for ; Wed, 7 Jan 1998 05:03:42 -0800 (PST) From: rc_hjac@graovasco.ipv.pt Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18471 for ; Wed, 7 Jan 1998 05:03:40 -0800 Received: from graovasco.ipv.pt ([193.137.7.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03010 for ; Wed, 7 Jan 1998 05:04:00 -0800 (PST) Received: from graovasco.ipv.pt (193.137.7.73) by graovasco.ipv.pt (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 04 Jan 1998 17:36:35 +0000 Message-Id: <1.5.4.32.19980107120515.00682164@elect.estv.ipv.pt> X-Sender: rc_hjac@elect.estv.ipv.pt X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jan 1998 13:05:15 +0100 To: Bob Hinden Subject: (IPng 5111) RFC2133 API Update Bullets: Re: IPng W.G. Minutes Cc: minutes@ietf.org, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, Sorry these are late but Holidays took precedent. I suggest we not have IETF meetings in December to the Chairs and the community? They should happen in early November? I have put RESOLUTIONS based on meeting short presentation and discussion with principle communicators on the mail list (Hartrick, Nordmark, McCann, Bound, et al..). We RFC 2133 authors need to get an updated draft out for discussion but input to these minutes would be nice for a week or so? Thanks /jim ------------------------------------------------- IETF 40 Washington D.C. Update to RFC 2133 IPng Meeting 12/18/97 Jim Bound Digital Equipment Corporation o gethostbyname2() Issues: - RES_USE_INET6 requires setting global parameter - WG mail list consensus Basic API should be Thread Safe - WG mail list consensus Basic API needs Flaga and Dynamic control capability o struct hostent *gethostbyname3( const char *name, int AF, int Flags); - name : host name or address - AF : AF_INET or AF_INET6 - Flags: ** This is the point and "opportunity" for discussion? o void freehostent(struct hostent *ptr) o AF and Flags Now: - AF_INET, 0 = IPv4 returned, h_length = 4; - AF_INET6, 0 = IPv6 returned, h_length = 16, - AF_INET6, AI_V4MAPPED = IPv6 OR v4-mapped, h_length = 16; - AF_INET6, AI_ALL = IPv6 AND v4mapped, h_length = 16; - AF_INET6, AI_V6ADDRCONF = IPv6 IFF v6 addr on interface; - AF_INET6, AI_ALL | AI_V6ADDRCONF = same as above except will return v4mapped for IPv4 for interface; o freehostent() MUST always be called. AF and Flags Default Suggestion; SUGGESTION #1: IF AF_INET6, 0; return v6only | v4mapped. Choice is impelementations, but caller MUST set AI_NOV4MAPPED to restrict it to only IPv6-Only Addresses. RESOLUTION: This appears to have consensus but should be defined via new AI_DEFAULT below. * Rationale - Simple port from gethostbyname to gethostbyname3 like gethostbyname3(name, 6, 0); gethostbyname(name); SUGGESTION #2: Caller must set AI_ALLOC to cause dynamic allocation, hence, only then must freehostent() be called. RESOLUTION: Consensus was this should be rejected. freehostent() must be used. If gethostbyname() does not support MT safety then compile time constant will have to be used to not call freehostent. SUGGESTION #3: AI_V6ADDRCONF is default and also define for IPv4 interfaces too? RESOLUTION: This had rough consensus. SUGGESTION #4: Do not require gethostbyaddr() to return dynamic alloc of memory. Issue is source and binary compatibility. RESOLUTION: This had consensus. But IPv6 will have new gethostbyaddr() function. SUGGESTION #5: Define default behavior if Flags = AI_DEFAULT?? RESOLUTION: This had rough consensus: The authors seek input or will use SUGGESTION #1 as basis for this New Flag, and use their judgement for a new draft. SUGGESTION #6: Name Change Suggestion: - getdynhostname(); - freedynhostent(); - getdynhostbyaddr(); RESOLUTION: This had consensus. But Steve Deering suggested removing the word host for "node". WG was polled and that appears to have rough consensus for Steve's suggestion. SUGGESTION #7: Add any "new" AI FLAGS to getaddrinfo. Warning::: The Open Group XNET Group owns this API. RESOLUTION: NO DISCUSSION at Wash D.C. can discuss on mail list. Thanks Bob, Sue, Jim, and Rich (the authors)........ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 05:21:35 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA20215 for ipng-dist; Wed, 7 Jan 1998 05:04:38 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA20201 for ; Wed, 7 Jan 1998 05:04:21 -0800 (PST) From: rc_hjac@graovasco.ipv.pt Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18522 for ; Wed, 7 Jan 1998 05:04:19 -0800 Received: from graovasco.ipv.pt ([193.137.7.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03150 for ; Wed, 7 Jan 1998 05:04:22 -0800 (PST) Received: from graovasco.ipv.pt (193.137.7.73) by graovasco.ipv.pt (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 04 Jan 1998 17:36:40 +0000 Message-Id: <1.5.4.32.19980107120519.00683438@elect.estv.ipv.pt> X-Sender: rc_hjac@elect.estv.ipv.pt X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jan 1998 13:05:19 +0100 To: bmanning@ISI.EDU Subject: (IPng 5113) Re: December minutes / Site addresses Cc: Erik.Nordmark@Eng, crawdad@fnal.gov, ipng@sunroof.eng.sun.com, huitema@bellcore.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There was some previous discussion on the applicability of storing > site local and link local addresses within the DNS. If I remember > correctly, this was deemed to be undesirable. Have we come full > circle on this topic? I don't think we have decided. We had (and presumably still have) consensus that we don't want to require a two-faced DNS. Now we have an observation that it is possible to combine the ideas in the site prefixes draft with storing site local addresses in the DNS and having the resolver determine (based on the advertised site prefixes) whether or not it should use the site local address it got from the DNS. Thus this wouldn't assume a two-faced DNS but it would require that by default all hosts ignore site local addresses returned by the DNS while we figure out how we want site local address to work. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 05:28:41 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA20295 for ipng-dist; Wed, 7 Jan 1998 05:06:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA20258 for ; Wed, 7 Jan 1998 05:05:29 -0800 (PST) From: rc_hjac@graovasco.ipv.pt Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18627 for ; Wed, 7 Jan 1998 05:05:24 -0800 Received: from graovasco.ipv.pt ([193.137.7.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03648 for ; Wed, 7 Jan 1998 05:05:51 -0800 (PST) Received: from graovasco.ipv.pt (193.137.7.73) by graovasco.ipv.pt (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 04 Jan 1998 17:36:58 +0000 Message-Id: <1.5.4.32.19980107120538.0069dc5c@elect.estv.ipv.pt> X-Sender: rc_hjac@elect.estv.ipv.pt X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jan 1998 13:05:38 +0100 To: brian@hursley.ibm.com Subject: (IPng 5120) Re: IPv6 literals in URLs Cc: deering@cisco.com, fielding@ics.uci.edu, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi -- I'd like to appeal directly to the IPNG WG's to include the "---abcd-ef12.1.2.3.4.ipv6" notation in the documentation of text representations of IPv6 addresses. I don't like having one proposed standard saying "you should do Ipv6 literals this way" and then another URL standard say "except inside URLs, you should do them that way". I suppose we could just make yet another document that talks about this compromise and reference it both from the URL spec and the IPv6 spec. Larry -- http://www.parc.xerox.com/masinter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 05:38:14 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA20290 for ipng-dist; Wed, 7 Jan 1998 05:06:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA20244 for ; Wed, 7 Jan 1998 05:05:11 -0800 (PST) From: rc_hjac@graovasco.ipv.pt Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18598 for ; Wed, 7 Jan 1998 05:05:07 -0800 Received: from graovasco.ipv.pt ([193.137.7.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03543 for ; Wed, 7 Jan 1998 05:05:34 -0800 (PST) Received: from graovasco.ipv.pt (193.137.7.73) by graovasco.ipv.pt (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 04 Jan 1998 17:36:56 +0000 Message-Id: <1.5.4.32.19980107120536.00691fc4@elect.estv.ipv.pt> X-Sender: rc_hjac@elect.estv.ipv.pt X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jan 1998 13:05:36 +0100 To: brian@hursley.ibm.com Subject: (IPng 5119) Re: IPv6 literals in URLs Cc: deering@cisco.com, fielding@ics.uci.edu, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi -- I'd like to appeal directly to the IPNG WG's to include the "---abcd-ef12.1.2.3.4.ipv6" notation in the documentation of text representations of IPv6 addresses. I don't like having one proposed standard saying "you should do Ipv6 literals this way" and then another URL standard say "except inside URLs, you should do them that way". I suppose we could just make yet another document that talks about this compromise and reference it both from the URL spec and the IPv6 spec. Larry -- http://www.parc.xerox.com/masinter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 05:40:41 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA20298 for ipng-dist; Wed, 7 Jan 1998 05:07:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA20284 for ; Wed, 7 Jan 1998 05:06:18 -0800 (PST) From: rc_hjac@graovasco.ipv.pt Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18699 for ; Wed, 7 Jan 1998 05:06:12 -0800 Received: from graovasco.ipv.pt ([193.137.7.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03918 for ; Wed, 7 Jan 1998 05:06:34 -0800 (PST) Received: from graovasco.ipv.pt (193.137.7.73) by graovasco.ipv.pt (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 04 Jan 1998 17:37:06 +0000 Message-Id: <1.5.4.32.19980107120546.006ab70c@elect.estv.ipv.pt> X-Sender: rc_hjac@elect.estv.ipv.pt X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jan 1998 13:05:46 +0100 To: "Adam Fleming" , Subject: (IPng 5123) Re: Performance of IPv6 encapsulation Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Adam > >Has anyone ever compared the performance of running IPv6 encapsulated in >IPv4 with just running straight IPv4? > Quite a few people :-) >Is there a performance degradation? > Depends on what you mean by 'performance'. Using the INRIA implementation under FreeBSD, the difference in time taken to ping a device on the same subnet using it v4 address and v4-compatible v6 address is around 2 millisecs. This difference is primarily the delay imposed by the encapsulation (implemented as a network device), although there will be a slight increase in serialisation delay due to the larger packet (couple of microsecs). So the simple answer to your question is that (using the INRIA implementation) you can expect an additional delay of 1 millisec one-way. Of course, the packets you send are 20 bytes bigger. This consumes more bandwidth per packet and therefor reduces the efficiency of the network. This is pretty difficult to measure. To give you some idea of the end-to-end efficiency of a v6-over-v4 tunnel, take a look at some of the many stats pages maintained by some of the 6bone sites (go to http://www.6bone.net for pointers in the right direction). Hope this helps, Peter Curran Attachment Converted: c:\eudora\attach\smime.p7s -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 05:42:22 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA20263 for ipng-dist; Wed, 7 Jan 1998 05:05:46 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA20213 for ; Wed, 7 Jan 1998 05:04:34 -0800 (PST) From: rc_hjac@graovasco.ipv.pt Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18548 for ; Wed, 7 Jan 1998 05:04:30 -0800 Received: from graovasco.ipv.pt ([193.137.7.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03354 for ; Wed, 7 Jan 1998 05:05:00 -0800 (PST) Received: from graovasco.ipv.pt (193.137.7.73) by graovasco.ipv.pt (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 04 Jan 1998 17:36:44 +0000 Message-Id: <1.5.4.32.19980107120524.00689448@elect.estv.ipv.pt> X-Sender: rc_hjac@elect.estv.ipv.pt X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jan 1998 13:05:24 +0100 To: Erik.Nordmark@Eng Subject: (IPng 5115) Re: December minutes / Site addresses Cc: crawdad@fnal.gov, ipng@sunroof.eng.sun.com, huitema@bellcore.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > * The site identifiers should be unique. Recovery in the case of > > duplication will be essentially impossible. ("Recovery" might > > consist of an injunction for nodes from one site to never visit the > > site with the duplicate id, plus some jiggery-pokery to hide the > > site-local DNS entries with the duplicated prefix.) > > I don't quite understand the requirement for globally unique site ids. > If we decide to store site local addresses in the DNS it is easy > for nodes to ignore site locals for different sites even if the > site ids happen to be identical. This can be done by observing > the whole AAAA RRset and only accept the site local address > in that set if the set also contains one or more global addresses > which match the global prefixes assigned to the site. > There was some previous discussion on the applicability of storing site local and link local addresses within the DNS. If I remember correctly, this was deemed to be undesirable. Have we come full circle on this topic? -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 05:43:41 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA20268 for ipng-dist; Wed, 7 Jan 1998 05:05:52 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA20217 for ; Wed, 7 Jan 1998 05:04:39 -0800 (PST) From: rc_hjac@graovasco.ipv.pt Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18558 for ; Wed, 7 Jan 1998 05:04:35 -0800 Received: from graovasco.ipv.pt ([193.137.7.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03380 for ; Wed, 7 Jan 1998 05:05:04 -0800 (PST) Received: from graovasco.ipv.pt (193.137.7.73) by graovasco.ipv.pt (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 04 Jan 1998 17:36:47 +0000 Message-Id: <1.5.4.32.19980107120526.0068722c@elect.estv.ipv.pt> X-Sender: rc_hjac@elect.estv.ipv.pt X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jan 1998 13:05:26 +0100 To: Matt Crawford Subject: (IPng 5116) Re: December minutes / Site addresses Cc: ipng@sunroof.eng.sun.com, Christian Huitema Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > * The site identifiers should be unique. Recovery in the case of > duplication will be essentially impossible. ("Recovery" might > consist of an injunction for nodes from one site to never visit the > site with the duplicate id, plus some jiggery-pokery to hide the > site-local DNS entries with the duplicated prefix.) I don't quite understand the requirement for globally unique site ids. If we decide to store site local addresses in the DNS it is easy for nodes to ignore site locals for different sites even if the site ids happen to be identical. This can be done by observing the whole AAAA RRset and only accept the site local address in that set if the set also contains one or more global addresses which match the global prefixes assigned to the site. Is your point about "visits" in relations to mobile IP or for something else? Mobile IP would definitely need to be aware of site locals and do some things differently, but for non-mobile IP vists I assume that the node will autoconfigure in the visited site and not try to use its "home" addresses. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 05:45:02 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA20281 for ipng-dist; Wed, 7 Jan 1998 05:06:15 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA20238 for ; Wed, 7 Jan 1998 05:05:03 -0800 (PST) From: rc_hjac@graovasco.ipv.pt Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18582 for ; Wed, 7 Jan 1998 05:04:59 -0800 Received: from graovasco.ipv.pt ([193.137.7.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03513 for ; Wed, 7 Jan 1998 05:05:28 -0800 (PST) Received: from graovasco.ipv.pt (193.137.7.73) by graovasco.ipv.pt (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 04 Jan 1998 17:36:54 +0000 Message-Id: <1.5.4.32.19980107120534.0069a5e8@elect.estv.ipv.pt> X-Sender: rc_hjac@elect.estv.ipv.pt X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jan 1998 13:05:34 +0100 To: Robert Elz Subject: (IPng 5118) Re: December minutes / Site addresses Cc: Christian Huitema , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I actually had (somewhere in my tiny brain) an idea that the sitedness > of a node would be automatically determined by the software, a node which > say "site N" advertised on one link, and "site M" advertised on another > would simply refuse to configure any site local addressing (the software > would not allow it to happen) and would automatically be a member of > neither site. I agree that this could be done but it has some in my opinion undesirable properties. As routers and interfaces come and go a node with multiple interfaces will sometimes (when it hears only one site adveertisement) use a site local address but other times (when the router or interface to another site is up) not use a site local address. The point is that the node can't once and for all determine whether or not it is connected to links in more than one site. > Similarly, on a link where a node saw adverts for two > different sites, it would ignore all of those, and treat the link as if > no site addresses were available on it (including for the purpose of the > previous test). So in a sense, yes, it could be enforced. One could make strong arguments for links only belonging to one site: a multicast to a site scope multicast address would not be well behaved if it is sent on a link which belongs to more than one site. Is there really a case when it would be useful to have a link belong to more than one site? Since tunnels are point to point links it would still be possible for multiple sites to use the same physical link (e.g. Ethernet) by configuring tunnels. > I don't come to that conclusion. My building belongs to only one > campus, and other than sub-units of the campus (essentially sub-nets in > the IP addressing world) I see nothing that is simultaneously a member of > multiple different campuses. So, your real life entity example to me > re-inforces my definition, rather than contradicts it. If you exclude multi-sited nodes from a site you might end up with odd cases when connectivity changes. For example, with a two-subnet single router site: H2 | ---------- Subnet 2, Site X | R | ---------- Subnet 1, Site X | H1 When R gets connected to site Y using another interface then, according to your definition, R is in neither site X nor Y. This means that the internal connectivity in site X now uses a router which does not belong to site X. I think that means that the router would no longer advertise or propagate site local routes which means that the internal communication in site X would break. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 05:46:37 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA20296 for ipng-dist; Wed, 7 Jan 1998 05:07:17 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA20269 for ; Wed, 7 Jan 1998 05:05:50 -0800 (PST) From: rc_hjac@graovasco.ipv.pt Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18664 for ; Wed, 7 Jan 1998 05:05:45 -0800 Received: from graovasco.ipv.pt ([193.137.7.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03705 for ; Wed, 7 Jan 1998 05:05:57 -0800 (PST) Received: from graovasco.ipv.pt (193.137.7.73) by graovasco.ipv.pt (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 04 Jan 1998 17:37:01 +0000 Message-Id: <1.5.4.32.19980107120541.0067039c@elect.estv.ipv.pt> X-Sender: rc_hjac@elect.estv.ipv.pt X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jan 1998 13:05:41 +0100 To: huitema@bellcore.com (Christian Huitema) Subject: (IPng 5121) Re: December minutes / Site addresses Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 2 Jan 1998 09:53:38 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-ID: <980102095336.ZM18587@seawind.bellcore.com> Before I respond to your two examples, your postamble text reveals a vast difference in model from what I have been assuming... | In these cases, you find | individuals, some of which carry a lot convincing power, who want | their computers in two sites at the same time. Just try to tell | them that they have to choose one because the software you picked I don't expect the end user to have the vaguest idea what site(s) their box happens to be in - I think that if the casual user ever finds out, we have failed. All this needs to be automatic, the user should not care in the slightest, and unless they're the curious type at the low level (as you or I might be) they ought never find out what site they're a member of (if any). I see the point (the sole point) of site local addresses (other than the augmented dentist's office, which we might call the medical centre model, a group of connected nets, not connected to anyplace else) as being that they allow local connectivity to survive renumbering (so all your file server connections don't die if your site is renumbered principally). Aside from that, if global addresses are available, they may as well be used, site local addresses have no other advantages. In particular, I don't see them as at all useful for security, firewalling, etc, and I think it would be a disservice to design the things with the assumption that people would be using them for any such purpose. So I'm not in the least worried about users caring that they have to select only one sight to be in, they should never have to select any, and they're not likely to notice what has been chosen for them. | You may have a clear idea of what is going on in your campus. But my | own experience is somewhat different. Consider: I'll take your two examples in the opposite order than you gave them (easier to deal with). | - a research team whose contracts require them to maintain links | (encrypted, probably) with their industrial partner. I can't imagine site local addresses being used there, those are clearly two different sites, and should be using global addressing. If they need private links, which they want to remain stable over potential renumberings by one or both, a better solution than having some of the nodes pretending to be in the other site would be to extend the model to allow communications between different sites using site local addressing. That's one direction I think the model could eventually be extended, though I'd prefer not to think too much about that until we have the simpler cases handled. | - a visiting professor who has retained links (satellite, wireless, | tunnel) with his or her university, This might be one of two cases - either it is being considered as a mobile node, in which case I think in general the node will remain in the site it left, and use the private link (tunnel usually, though I gather implemented using source routing, which would make site local addresses difficult to use, which I think is a mistake, and I expect tunnels wil be quite common). Alternatively, it is just a new node in the new site, a member of that site, which happens to communicate a lot with the old site, using global addressing to do that. | Worse, chances are they will instruct some grad student | to hack teh system and fix "the bug." You may not like the result. Then again, I might. That might often be done, and fail miserably (which might mean serve the immediate purpose, but be not generally useful), but that kind of experimentation is how I see the model being gradually extended once we have the basics in place. Again, I'd prefer to design the simple case now, rather than attempt to figure out everything now, but by all means avoid designing in restrictions which will make growth difficult, so I certainly believe that using the empty bits in site local addresses to carry a site identifier is the right thing to do, as almost any future extension is likely to depend upon that. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 05:47:57 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA20297 for ipng-dist; Wed, 7 Jan 1998 05:07:26 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA20273 for ; Wed, 7 Jan 1998 05:05:59 -0800 (PST) From: rc_hjac@graovasco.ipv.pt Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18684 for ; Wed, 7 Jan 1998 05:05:54 -0800 Received: from graovasco.ipv.pt ([193.137.7.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03851 for ; Wed, 7 Jan 1998 05:06:19 -0800 (PST) Received: from graovasco.ipv.pt (193.137.7.73) by graovasco.ipv.pt (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 04 Jan 1998 17:37:04 +0000 Message-Id: <1.5.4.32.19980107120543.006a23b8@elect.estv.ipv.pt> X-Sender: rc_hjac@elect.estv.ipv.pt X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jan 1998 13:05:43 +0100 To: huitema@bellcore.com (Christian Huitema) Subject: (IPng 5122) Re: December minutes / Site addresses Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 2 Jan 1998 09:53:38 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-ID: <980102095336.ZM18587@seawind.bellcore.com> Before I respond to your two examples, your postamble text reveals a vast difference in model from what I have been assuming... | In these cases, you find | individuals, some of which carry a lot convincing power, who want | their computers in two sites at the same time. Just try to tell | them that they have to choose one because the software you picked I don't expect the end user to have the vaguest idea what site(s) their box happens to be in - I think that if the casual user ever finds out, we have failed. All this needs to be automatic, the user should not care in the slightest, and unless they're the curious type at the low level (as you or I might be) they ought never find out what site they're a member of (if any). I see the point (the sole point) of site local addresses (other than the augmented dentist's office, which we might call the medical centre model, a group of connected nets, not connected to anyplace else) as being that they allow local connectivity to survive renumbering (so all your file server connections don't die if your site is renumbered principally). Aside from that, if global addresses are available, they may as well be used, site local addresses have no other advantages. In particular, I don't see them as at all useful for security, firewalling, etc, and I think it would be a disservice to design the things with the assumption that people would be using them for any such purpose. So I'm not in the least worried about users caring that they have to select only one sight to be in, they should never have to select any, and they're not likely to notice what has been chosen for them. | You may have a clear idea of what is going on in your campus. But my | own experience is somewhat different. Consider: I'll take your two examples in the opposite order than you gave them (easier to deal with). | - a research team whose contracts require them to maintain links | (encrypted, probably) with their industrial partner. I can't imagine site local addresses being used there, those are clearly two different sites, and should be using global addressing. If they need private links, which they want to remain stable over potential renumberings by one or both, a better solution than having some of the nodes pretending to be in the other site would be to extend the model to allow communications between different sites using site local addressing. That's one direction I think the model could eventually be extended, though I'd prefer not to think too much about that until we have the simpler cases handled. | - a visiting professor who has retained links (satellite, wireless, | tunnel) with his or her university, This might be one of two cases - either it is being considered as a mobile node, in which case I think in general the node will remain in the site it left, and use the private link (tunnel usually, though I gather implemented using source routing, which would make site local addresses difficult to use, which I think is a mistake, and I expect tunnels wil be quite common). Alternatively, it is just a new node in the new site, a member of that site, which happens to communicate a lot with the old site, using global addressing to do that. | Worse, chances are they will instruct some grad student | to hack teh system and fix "the bug." You may not like the result. Then again, I might. That might often be done, and fail miserably (which might mean serve the immediate purpose, but be not generally useful), but that kind of experimentation is how I see the model being gradually extended once we have the basics in place. Again, I'd prefer to design the simple case now, rather than attempt to figure out everything now, but by all means avoid designing in restrictions which will make growth difficult, so I certainly believe that using the empty bits in site local addresses to carry a site identifier is the right thing to do, as almost any future extension is likely to depend upon that. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 05:43:44 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA20276 for ipng-dist; Wed, 7 Jan 1998 05:06:08 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA20229 for ; Wed, 7 Jan 1998 05:04:58 -0800 (PST) From: rc_hjac@graovasco.ipv.pt Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18579 for ; Wed, 7 Jan 1998 05:04:54 -0800 Received: from graovasco.ipv.pt ([193.137.7.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03406 for ; Wed, 7 Jan 1998 05:05:10 -0800 (PST) Received: from graovasco.ipv.pt (193.137.7.73) by graovasco.ipv.pt (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 04 Jan 1998 17:36:51 +0000 Message-Id: <1.5.4.32.19980107120531.00691018@elect.estv.ipv.pt> X-Sender: rc_hjac@elect.estv.ipv.pt X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Jan 1998 13:05:31 +0100 To: Robert Elz Subject: (IPng 5117) Re: December minutes / Site addresses Cc: Christian Huitema , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I actually had (somewhere in my tiny brain) an idea that the sitedness > of a node would be automatically determined by the software, a node which > say "site N" advertised on one link, and "site M" advertised on another > would simply refuse to configure any site local addressing (the software > would not allow it to happen) and would automatically be a member of > neither site. I agree that this could be done but it has some in my opinion undesirable properties. As routers and interfaces come and go a node with multiple interfaces will sometimes (when it hears only one site adveertisement) use a site local address but other times (when the router or interface to another site is up) not use a site local address. The point is that the node can't once and for all determine whether or not it is connected to links in more than one site. > Similarly, on a link where a node saw adverts for two > different sites, it would ignore all of those, and treat the link as if > no site addresses were available on it (including for the purpose of the > previous test). So in a sense, yes, it could be enforced. One could make strong arguments for links only belonging to one site: a multicast to a site scope multicast address would not be well behaved if it is sent on a link which belongs to more than one site. Is there really a case when it would be useful to have a link belong to more than one site? Since tunnels are point to point links it would still be possible for multiple sites to use the same physical link (e.g. Ethernet) by configuring tunnels. > I don't come to that conclusion. My building belongs to only one > campus, and other than sub-units of the campus (essentially sub-nets in > the IP addressing world) I see nothing that is simultaneously a member of > multiple different campuses. So, your real life entity example to me > re-inforces my definition, rather than contradicts it. If you exclude multi-sited nodes from a site you might end up with odd cases when connectivity changes. For example, with a two-subnet single router site: H2 | ---------- Subnet 2, Site X | R | ---------- Subnet 1, Site X | H1 When R gets connected to site Y using another interface then, according to your definition, R is in neither site X nor Y. This means that the internal connectivity in site X now uses a router which does not belong to site X. I think that means that the router would no longer advertise or propagate site local routes which means that the internal communication in site X would break. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 12:59:56 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id MAA21339 for ipng-dist; Wed, 7 Jan 1998 12:51:42 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id MAA21332 for ; Wed, 7 Jan 1998 12:51:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA04038 for ; Wed, 7 Jan 1998 12:51:29 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id MAA02121 for ; Wed, 7 Jan 1998 12:52:01 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA09444; Wed, 7 Jan 98 12:48:53 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA16458; Wed, 7 Jan 1998 12:52:17 -0800 Date: Wed, 7 Jan 1998 12:52:17 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199801072052.MAA16458@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5125) Link-local addresses in Type 0 routing headers X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, While updating our implementation to reflect the changes made in draft-ietf-ipngwg-ipv6-spec-v2-01.txt I noted that the specification still allows for link-local addresses to appear as segments in type 0 routing headers. I remember discussions on this topic which seemed to have con- cluded that allowing this behavior would be "bad". Are my recollections incorrect or did this item simply get dropped from the last round of edits? Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 13:23:33 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id NAA21518 for ipng-dist; Wed, 7 Jan 1998 13:15:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id NAA21511 for ; Wed, 7 Jan 1998 13:15:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA09551 for ; Wed, 7 Jan 1998 13:15:30 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA13769 for ; Wed, 7 Jan 1998 13:15:59 -0800 (PST) Received: from spruce.ipsilon.com (slip139-92-70-112.he.fi.ibm.net [139.92.70.112]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id NAA23695; Wed, 7 Jan 1998 13:15:19 -0800 Message-Id: <3.0.3.32.19980107131844.00a071a0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 07 Jan 1998 13:18:44 -0800 To: thartric@mentat.com (Tim Hartrick) From: Bob Hinden Subject: (IPng 5126) Re: Link-local addresses in Type 0 routing headers Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199801072052.MAA16458@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, > While updating our implementation to reflect the changes made >in draft-ietf-ipngwg-ipv6-spec-v2-01.txt I noted that the specification >still allows for link-local addresses to appear as segments in type 0 routing >headers. > > I remember discussions on this topic which seemed to have con- >cluded that allowing this behavior would be "bad". Are my recollections >incorrect or did this item simply get dropped from the last round of >edits? My recollection from the discussion was that link-local addresses in routing headers might be useful for diagnostic purposes, so we didn't want prohibit this usage. I think the worst that happens if one constructed a source route incorrectly with link-local addresses, is the packet would be dropped. One would have to know a lot about the topology and interfaces to use this capability effectively, but someone might find it useful. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 7 13:23:33 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id NAA21531 for ipng-dist; Wed, 7 Jan 1998 13:18:46 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id NAA21524 for ; Wed, 7 Jan 1998 13:18:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA10429 for ; Wed, 7 Jan 1998 13:18:35 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA15357 for ; Wed, 7 Jan 1998 13:19:05 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA09932; Wed, 7 Jan 98 13:16:06 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id NAA16487; Wed, 7 Jan 1998 13:19:29 -0800 Date: Wed, 7 Jan 1998 13:19:29 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199801072119.NAA16487@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5127) Re: Link-local addresses in Type 0 routing headers X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > > My recollection from the discussion was that link-local addresses in > routing headers might be useful for diagnostic purposes, so we didn't want > prohibit this usage. I think the worst that happens if one constructed a > source route incorrectly with link-local addresses, is the packet would be > dropped. One would have to know a lot about the topology and interfaces to > use this capability effectively, but someone might find it useful. > Since you are the document editor and the minutes taker I will take it as a given that your recollections are better than mine. Thanks for the clarification. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 8 06:44:26 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA22524 for ipng-dist; Thu, 8 Jan 1998 06:38:04 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA22517 for ; Thu, 8 Jan 1998 06:37:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA06021 for ; Thu, 8 Jan 1998 06:37:51 -0800 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA09206 for ; Thu, 8 Jan 1998 06:38:25 -0800 (PST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id JAA02636; Thu, 8 Jan 1998 09:37:43 -0500 (EST) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA28018; Thu, 8 Jan 1998 09:37:44 -0500 Received: from ludwigia.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA20478; Thu, 8 Jan 1998 09:37:43 -0500 Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id GAA00953; Thu, 8 Jan 1998 06:52:57 -0500 Message-Id: <199801081152.GAA00953@hygro.raleigh.ibm.com> To: Bob Hinden Cc: thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com Subject: (IPng 5128) Re: Link-local addresses in Type 0 routing headers In-Reply-To: Your message of "Wed, 07 Jan 1998 13:18:44 PST." <3.0.3.32.19980107131844.00a071a0@mailhost.ipsilon.com> Date: Thu, 08 Jan 1998 06:52:57 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My recollection is that you are both right. :-) There was certainly much discussion on this topic and quite a lot of feeling that allowing link-local addresses was not really such a good idea. In particular: - Forwarding a packet with a link-local address onto another link can cause scoping problems. If that address is referenced on another link, it might be delivered to the wrong interface, since link-local addresses aren't globally unique. This would at best lead to failed communication. - If a router receives a packet with a link-local address in the Routing Header, the router may not know which link that address is on. Indeed, there could be multiple links on which the address corresponds to an interface. Consequently, it may be wishful thinking to assume that routers do something predictable (i.e., useful) with such packets. At the same time, there were some who felt that it should be OK for routers to forward a packet with a link-layer address back onto the *same* link on which it was received. Thus a blanket prohibition seems a bit too strong. IMO, some specific text would probably help here. As it stands now, implementations are likely to do different, incompatible things, making it very questionable whether link-local addresses can be used in practice in Routing Headers. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 8 08:55:46 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id IAA22884 for ipng-dist; Thu, 8 Jan 1998 08:51:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id IAA22877 for ; Thu, 8 Jan 1998 08:51:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA11395 for ; Thu, 8 Jan 1998 08:51:35 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA13577 for ; Thu, 8 Jan 1998 08:52:06 -0800 (PST) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id QAA04604 for ; Thu, 8 Jan 1998 16:43:54 GMT From: "Peter Curran" To: "IPNG WG List" Subject: (IPng 5129) draft-ietf-ipngwg-icmp-v2-00.txt Date: Thu, 8 Jan 1998 17:01:21 -0000 Message-ID: <01bd1c57$0b34e3f0$0f0120c1@desktop.ticl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve/Alex Is this draft going to be updated further? Two things spring to mind: 1. With the new minMTU of 1280, do we still need to restrict the maximum size of an ICMPv6 error message to 576 octets? 2. Incorporation of IGMPv2 stuff - I know Steve mentioned this a few weeks ago, but I had the impression that it was proposed to generate a separate document for this. The ICMPv6 spec just needs updating to point to the correct place. Peter Curran TICL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 8 13:44:15 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id NAA23243 for ipng-dist; Thu, 8 Jan 1998 13:37:19 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id NAA23236 for ; Thu, 8 Jan 1998 13:37:10 -0800 (PST) Received: from strat (strat [129.146.85.177]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id NAA08063; Thu, 8 Jan 1998 13:37:06 -0800 (PST) Message-Id: <199801082137.NAA08063@jurassic.eng.sun.com> Date: Thu, 8 Jan 1998 13:35:50 -0800 (PST) From: Sebastien Roy Reply-To: Sebastien Roy Subject: (IPng 5130) IPv6 testing at Connectathon 98 To: IPv6Imp@munnari.OZ.AU Cc: ipng@sunroof.eng.sun.com, audrey@vanb.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yRPbdwQTVTIMmbIZRUwCcQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3_7 SunOS 5.7 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv6 implementors, This is a reminder that engineers wishing to participate in IPv6 testing at Connectathon 98 should register before February 1st. The event will be held March 4-12, 1998, in San Jose, California, and the UNH/Interoperability Lab's IPv6 consortium will be providing their testing services. Information regarding the event can be obtained from http://www.sun.com/connectathon or, you may contact Audrey Van Bellenghem at (408) 358-9598. You can also contact Bill Lenharth (whl@bigred.sr.unh.edu) with any questions regarding specifics of IPv6 testing. Please respond as soon as possible so that planning can go smoothly. Thanks, Sebastien Roy Sebastien.Roy@eng.Sun.COM -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 10 15:08:40 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id PAA25796 for ipng-dist; Sat, 10 Jan 1998 15:05:14 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id PAA25789 for ; Sat, 10 Jan 1998 15:05:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA27502 for ; Sat, 10 Jan 1998 15:05:02 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id PAA03201 for ; Sat, 10 Jan 1998 15:05:37 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA12983; Sat, 10 Jan 98 15:02:41 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id PAA03130; Sat, 10 Jan 1998 15:06:08 -0800 Date: Sat, 10 Jan 1998 15:06:08 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199801102306.PAA03130@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5132) Re: Link-local addresses in Type 0 routing headers X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, > > My recollection is that you are both right. :-) > > There was certainly much discussion on this topic and quite a lot of > feeling that allowing link-local addresses was not really such a good > idea. In particular: > > - Forwarding a packet with a link-local address onto another link > can cause scoping problems. If that address is referenced on another > link, it might be delivered to the wrong interface, since link-local > addresses aren't globally unique. This would at best lead to failed > communication. > > - If a router receives a packet with a link-local address in the > Routing Header, the router may not know which link that address is > on. Indeed, there could be multiple links on which the address > corresponds to an interface. Consequently, it may be wishful thinking > to assume that routers do something predictable (i.e., useful) with > such packets. > > At the same time, there were some who felt that it should be OK for > routers to forward a packet with a link-layer address back onto the > *same* link on which it was received. Thus a blanket prohibition seems > a bit too strong. > > IMO, some specific text would probably help here. As it stands now, > implementations are likely to do different, incompatible things, > making it very questionable whether link-local addresses can be used > in practice in Routing Headers. > You have succinctly stated my concerns. Too bad I couldn't.:-) Unless we write down what a node should do when presented with a limited scope address (site-local or link-local) as a next hop in type 0 routing header then we are unlikely to be able to derive any utility from the ability to do so since the behavior of each implementation when presented with the circumstance is likely to vary. The site-local case could be particularly nasty since I don't believe we have concensus on the definition of a site at this point. That said, I don't want this edge case to hold up the documents at all. Coming to consensus on exactly how to handle this edge case may do that and that would be "very bad". I regret bringing the topic up. I am with Bob. Let's drop it. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 12 06:09:58 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA26989 for ipng-dist; Mon, 12 Jan 1998 06:01:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA26982 for ; Mon, 12 Jan 1998 06:01:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA19724 for ; Mon, 12 Jan 1998 06:01:10 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA25116 for ; Mon, 12 Jan 1998 06:01:44 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA16279; Mon, 12 Jan 1998 09:00:39 -0500 (EST) Message-Id: <199801121400.JAA16279@ns.ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 5133) Protocol Action: Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Date: Mon, 12 Jan 1998 09:00:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Transmission of IPv6 Packets over Ethernet Networks' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are: Jeffrey Burgan and Thomas Narten Note: This document is a replacement for RFC1972. The IESG also requests that RFC1972 be reclassified as historic. Technical Summary This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 12 06:24:36 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA27032 for ipng-dist; Mon, 12 Jan 1998 06:15:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA27025 for ; Mon, 12 Jan 1998 06:15:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA21196 for ; Mon, 12 Jan 1998 06:15:05 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA00525 for ; Mon, 12 Jan 1998 06:15:42 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA16576; Mon, 12 Jan 1998 09:15:01 -0500 (EST) Message-Id: <199801121415.JAA16576@ns.ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 5134) Protocol Action: Transmission of IPv6 Packets over FDDI Networks to Proposed Standard Date: Mon, 12 Jan 1998 09:15:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Transmission of IPv6 Packets over FDDI Networks' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Note: This document is a replacement for RFC2019. The IESG also requests that RFC2019 be reclassified as historic. Technical Summary This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an FDDI network. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 12 09:45:56 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA27511 for ipng-dist; Mon, 12 Jan 1998 09:39:02 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA27504 for ; Mon, 12 Jan 1998 09:38:47 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA12798 for ; Mon, 12 Jan 1998 09:38:44 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id JAA18097 for ; Mon, 12 Jan 1998 09:39:17 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA16296 for ; Mon, 12 Jan 1998 09:38:41 -0800 Message-Id: <3.0.3.32.19980112093900.00844880@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 12 Jan 1998 09:39:00 -0800 To: ipng@sunroof.eng.sun.com From: The IESG (by way of Bob Hinden ) Subject: (IPng 5135) Last Call: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the Inter-Domain Routing Working Group to consider Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 26, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 12 10:09:33 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA27564 for ipng-dist; Mon, 12 Jan 1998 10:03:02 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA27557 for ; Mon, 12 Jan 1998 10:02:53 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA19982 for ; Mon, 12 Jan 1998 10:02:50 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA00779 for ; Mon, 12 Jan 1998 10:03:23 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA04539; Mon, 12 Jan 1998 12:11:51 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA17100; Mon, 12 Jan 1998 12:11:50 -0500 Message-Id: <199801121711.AA17100@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com, 6bone@isi.edu Subject: (IPng 5136) Congrats to IBM - IPv6 support shipping in AIX 3.3 Date: Mon, 12 Jan 1998 12:11:49 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Good job IBM...another leap to get IPv6 used and deployed in the market. http://www.rs6000.ibm.com/ipv6/ /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 12 10:36:55 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA27628 for ipng-dist; Mon, 12 Jan 1998 10:32:08 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA27621 for ; Mon, 12 Jan 1998 10:31:59 -0800 (PST) From: deanna@austin.ibm.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA27729 for ; Mon, 12 Jan 1998 10:31:57 -0800 Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA17495 for ; Mon, 12 Jan 1998 10:32:31 -0800 (PST) Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by ausmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id MAA11448 for ; Mon, 12 Jan 1998 12:31:55 -0600 Received: from dquigg.austin.ibm.com (dquigg.austin.ibm.com [9.53.150.14]) by netmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id MAA26180 for ; Mon, 12 Jan 1998 12:31:29 -0600 Received: (from deanna@localhost) by dquigg.austin.ibm.com (AIX4.3/UCB 8.7/8.7-client1.01) id MAA50524; Mon, 12 Jan 1998 12:31:45 -0600 (CST) Message-Id: <199801121831.MAA50524@dquigg.austin.ibm.com> X-Mailer: exmh version 1.6.7 5/3/96 To: ipng@sunroof.eng.sun.com cc: deanna@dquigg.austin.ibm.com Subject: (IPng 5137) Re: Congrats to IBM - IPv6 support shipping in AIX 3.3 In-reply-to: (Your message of Mon, 12 Jan 98 12:11:49 -0500.) <199801121711.AA17100@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jan 98 12:31:45 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Good job IBM...another leap to get IPv6 used and deployed in the market. Just a quick correction - that's actually AIX 4.3. Deanna > > http://www.rs6000.ibm.com/ipv6/ > > /jim > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 12 12:50:56 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id MAA27995 for ipng-dist; Mon, 12 Jan 1998 12:42:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id MAA27988 for ; Mon, 12 Jan 1998 12:42:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA07107 for ; Mon, 12 Jan 1998 12:42:36 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA05511 for ; Mon, 12 Jan 1998 12:43:10 -0800 (PST) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id UAA12453; Mon, 12 Jan 1998 20:33:42 GMT From: "Peter Curran" To: , , <6bone@ISI.EDU> Subject: (IPng 5138) Re: Congrats to IBM - IPv6 support shipping in AIX 3.3 Date: Mon, 12 Jan 1998 20:50:56 -0000 Message-ID: <01bd1f9b$c7fdc190$0f0120c1@desktop.ticl.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_009B_01BD1F9B.C7B60A30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_009B_01BD1F9B.C7B60A30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Congrats to INRIA - I thinks its their code! http://www-frec.bull.com/OSBU2_0/aixhighlight_eg.htm :-) >Good job IBM...another leap to get IPv6 used and deployed in the market. > >http://www.rs6000.ibm.com/ipv6/ > >/jim > /peter TICL/UK ------=_NextPart_000_009B_01BD1F9B.C7B60A30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII0TCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAnkwggHioAMCAQICEFIfNR3ycH4AK77KWYcE1TkwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDYyNzAwMDAwMFoXDTk5MDYyNzIz NTk1OVowYjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTQwMgYD VQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJzY3JpYmVyMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQC2FKbPTdAFDdjKI9BvqrQpkmOOLPhvltcunXZLEbE2jVfJw/0c xrr+Hgi6M8qV6r7jW80GqLd5HUQq7XPysVKDaBBwZJHXPmv5912dFEObbpdFmIFH0S3L3bty10w/ cariQPJUObwW7s987LrbP2wqsxaxhhKdrpM01bjV0Pc+qQIDAQABozMwMTAPBgNVHRMECDAGAQH/ AgEBMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAwfr3 AudXyhF1xpwM+it3T4dFFzvj0sHaD1g5jq6VmQOhqKE4/nmakxcLl4Y5x8poNGa7x4hF9sgMBe6+ lyXv4NRu5H+ddlzOfboUoq4Ln/tnW0ilZyWvGWSI9nLYKSeqNxJqsSivJ4MYZWyN7UCeTcR4qIbs 6SxQv6b5DduwpkowggQQMIIDeaADAgECAhApF9yEa2f1I6vNhJOMYHGgMA0GCSqGSIb3DQEBBAUA MGIxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMr VmVyaVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzExMjEwMDAw MDBaFw05ODAxMjAyMzU5NTlaMIIBDTERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJz Y3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4g YnkgUmVmLixMSUFCLkxURChjKTk2MScwJQYDVQQLEx5EaWdpdGFsIElEIENsYXNzIDEgLSBNaWNy b3NvZnQxFTATBgNVBAMTDFBldGVyIEN1cnJhbjEhMB8GCSqGSIb3DQEJARYScGN1cnJhbkB0aWNs LmNvLnVrMFswDQYJKoZIhvcNAQEBBQADSgAwRwJAbGS4S0SN7NX2OODlfiOves53hbLKytcxawKy ipnvwVqlHCtugU+GznF/cq3jvMQeehvX+9+lxts1Q7BXxw9QuQIDAQABo4IBXTCCAVkwCQYDVR0T BAIwADCBrwYDVR0gBIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEa PVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVy aVNpZ24AAAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2 M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2Rh NWMxZTMxNDFiZWFkYjJiZDI5YWZhMTJiZDY4OTFhMTExNDk5OGExYmE0M2Y0ZTY5MTY1NDEwDQYJ KoZIhvcNAQEEBQADgYEAUXbKrrDI9DdxdSL9W4pMtNBTZpFV9yMkBkiKdSOwdjmSh3/qPl11P/HM KDT9CtIXpeT0JcUlkZsXaGkLGZnVWHvsqjUyvqT6XOCy1Vm1VokROmbfFItKacbTwoQsArhISOYB DdUOwpZiD/HEdCTnTb4r6bC3MZ+6afsCn0zi//sxggE6MIIBNgIBATB2MGIxETAPBgNVBAcTCElu dGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3Mg MSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcgIQKRfchGtn9SOrzYSTjGBxoDAJBgUrDgMCGgUA oF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTgwMTEyMjA1MDU2 WjAjBgkqhkiG9w0BCQQxFgQUkaDw8XM+ipc6IYa8KT64PBuzkZ4wDQYJKoZIhvcNAQEBBQAEQA8l rVrIzRjyJSgFaVxnQyxkyQPiZUkytlRIdvKWqvVADffLdsQ7ryC5GIL1qMB9WtGOPBp1ybH7oEh5 HOCBZ0IAAAAAAAA= ------=_NextPart_000_009B_01BD1F9B.C7B60A30-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 12 18:48:14 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id SAA28717 for ipng-dist; Mon, 12 Jan 1998 18:41:42 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id SAA28710 for ; Mon, 12 Jan 1998 18:41:33 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA08239 for ; Mon, 12 Jan 1998 18:41:29 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id SAA05637 for ; Mon, 12 Jan 1998 18:42:06 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id VAA12723; Mon, 12 Jan 1998 21:36:21 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA17185; Mon, 12 Jan 1998 21:36:20 -0500 Message-Id: <199801130236.AA17185@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com, 6bone@isi.edu Subject: (IPng 5139) Re: Congrats to IBM - IPv6 support shipping in AIX 3.3 In-Reply-To: Your message of "Mon, 12 Jan 1998 12:11:49 EST." <199801121711.AA17100@wasted.zk3.dec.com> Date: Mon, 12 Jan 1998 21:36:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Good job IBM...another leap to get IPv6 used and deployed in the market. > >http://www.rs6000.ibm.com/ipv6/ Much apologies. Its AIX 4.3. sorry, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 14 06:50:54 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA01060 for ipng-dist; Wed, 14 Jan 1998 06:43:59 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA01049 for ; Wed, 14 Jan 1998 06:43:42 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA19685 for ; Wed, 14 Jan 1998 06:43:37 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA17639 for ; Wed, 14 Jan 1998 06:44:14 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA25804; Wed, 14 Jan 1998 09:43:34 -0500 (EST) Message-Id: <199801141443.JAA25804@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5141) I-D ACTION:draft-ietf-ipngwg-ipv6-icmp-mib-02.txt Date: Wed, 14 Jan 1998 09:43:33 -0500 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 : Management Information Base for IP Version 6: ICMPv6 Group Author(s) : D. Haskin, S. Onishi Filename : draft-ietf-ipngwg-ipv6-icmp-mib-02.txt Pages : 19 Date : 13-Jan-98 This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. 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-icmp-mib-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-icmp-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-icmp-mib-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19980113171325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-icmp-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-icmp-mib-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980113171325.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 14 06:50:57 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA01059 for ipng-dist; Wed, 14 Jan 1998 06:43:56 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA01044 for ; Wed, 14 Jan 1998 06:43:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA19671 for ; Wed, 14 Jan 1998 06:43:33 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA17600 for ; Wed, 14 Jan 1998 06:44:11 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA25784; Wed, 14 Jan 1998 09:43:30 -0500 (EST) Message-Id: <199801141443.JAA25784@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5140) I-D ACTION:draft-ietf-ipngwg-ipv6-mib-03.txt Date: Wed, 14 Jan 1998 09:43:29 -0500 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 : Management Information Base for IP Version 6: Textual Conventions and General Group Author(s) : D. Haskin, S. Onishi Filename : draft-ietf-ipngwg-ipv6-mib-03.txt Pages : 43 Date : 13-Jan-98 This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. 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-mib-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-mib-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-mib-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. 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: <19980113170905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-mib-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980113170905.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 14 07:00:14 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA01085 for ipng-dist; Wed, 14 Jan 1998 06:53:57 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA01078 for ; Wed, 14 Jan 1998 06:53:42 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA22626 for ; Wed, 14 Jan 1998 06:53:37 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA22379 for ; Wed, 14 Jan 1998 06:54:14 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA26332; Wed, 14 Jan 1998 09:53:33 -0500 (EST) Message-Id: <199801141453.JAA26332@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5142) I-D ACTION:draft-ietf-ipngwg-bsd-frag-00.txt Date: Wed, 14 Jan 1998 09:53:33 -0500 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 : Forcing Fragmentation to Network MTU Author(s) : M. Andrews Filename : draft-ietf-ipngwg-bsd-frag-00.txt Pages : 3 Date : 13-Jan-98 There exists a class of applications which cannot accept Path MTU discovery [RFC-1191]. This is recommended to be turned on by default for IPv6 [RFC-1883, 4.5, 5]. This document describes an extension to the BSD API [RFC-2133] to inform the kernel when it should be fragmenting at the network MTU rather than trying to discover the path MTU. Path MTU discovery works well when there is a stream of data. However for distributed servers sending small answers larger than the network MTU to many clients the lack of fragmentation in intermediate nodes is anathema. 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-frag-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-bsd-frag-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-bsd-frag-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980113121151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-frag-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-frag-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980113121151.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 15 02:44:26 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id CAA02290 for ipng-dist; Thu, 15 Jan 1998 02:37:22 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id CAA02283 for ; Thu, 15 Jan 1998 02:37:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA00663 for ; Thu, 15 Jan 1998 02:37:06 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id CAA24775 for ; Thu, 15 Jan 1998 02:37:41 -0800 (PST) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id KAA16136; Thu, 15 Jan 1998 10:30:00 GMT From: "Peter Curran" To: "IPNG WG List" , Subject: (IPng 5144) re: draft-ietf-ipngwg-bsd-frag-00.txt Date: Thu, 15 Jan 1998 10:47:05 -0000 Message-ID: <01bd21a2$eb9d3910$0f0120c1@desktop.ticl.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0070_01BD21A2.EB910410" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0070_01BD21A2.EB910410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Mark I have just received a copy of your draft. In some ways this is an answer to a maidens prayer, as I actually have this problem with an application I am playing with at the moment. However, I have a couple of problems with your ID: 1. You cite RFC1191 as a definition of PMTU discovery. This is incorrect, RFC1981 is the appropriate reference for IPv6. 2. You cite RFC1883 as the base IPv6 spec document. While strictly this is correct, it is a bit shortsighted when there is a v2 spec in front of the IESG at the moment. 3. In the revised IPv6 base spec, the minimum link MTU is increased to 1280. Whilst this does not alter the argument for having the facility you describe, it does mean that it may not be used so often. 4. I think that you should have some statement that spells out the implications on performance that fragmentation imposes (the reason why we got rid of it in the first place). 5. In the security section you imply that there are no implications. As with IPv4, there are potential problems with fragmentation: fragment overlay attacks, buffer allocation flooding. 6. I think you should also mention that there is no point sending a 10K byte message, suitably fragmented, if the reeceiver only allocates a max 8K buffer to receive it. As the opportunity to 'clean up' one of the dumb things in IPv4 fragmentation was not taken - i.e. telling the receiver the size of the original packet - then we are still stuck with implementation-specific selection of reassembly buffer sizes etc. Hope this helps Peter Curran TICL ------=_NextPart_000_0070_01BD21A2.EB910410 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII0TCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAnkwggHioAMCAQICEFIfNR3ycH4AK77KWYcE1TkwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDYyNzAwMDAwMFoXDTk5MDYyNzIz NTk1OVowYjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTQwMgYD VQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJzY3JpYmVyMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQC2FKbPTdAFDdjKI9BvqrQpkmOOLPhvltcunXZLEbE2jVfJw/0c xrr+Hgi6M8qV6r7jW80GqLd5HUQq7XPysVKDaBBwZJHXPmv5912dFEObbpdFmIFH0S3L3bty10w/ cariQPJUObwW7s987LrbP2wqsxaxhhKdrpM01bjV0Pc+qQIDAQABozMwMTAPBgNVHRMECDAGAQH/ AgEBMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAwfr3 AudXyhF1xpwM+it3T4dFFzvj0sHaD1g5jq6VmQOhqKE4/nmakxcLl4Y5x8poNGa7x4hF9sgMBe6+ lyXv4NRu5H+ddlzOfboUoq4Ln/tnW0ilZyWvGWSI9nLYKSeqNxJqsSivJ4MYZWyN7UCeTcR4qIbs 6SxQv6b5DduwpkowggQQMIIDeaADAgECAhApF9yEa2f1I6vNhJOMYHGgMA0GCSqGSIb3DQEBBAUA MGIxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMr VmVyaVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzExMjEwMDAw MDBaFw05ODAxMjAyMzU5NTlaMIIBDTERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJz Y3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4g YnkgUmVmLixMSUFCLkxURChjKTk2MScwJQYDVQQLEx5EaWdpdGFsIElEIENsYXNzIDEgLSBNaWNy b3NvZnQxFTATBgNVBAMTDFBldGVyIEN1cnJhbjEhMB8GCSqGSIb3DQEJARYScGN1cnJhbkB0aWNs LmNvLnVrMFswDQYJKoZIhvcNAQEBBQADSgAwRwJAbGS4S0SN7NX2OODlfiOves53hbLKytcxawKy ipnvwVqlHCtugU+GznF/cq3jvMQeehvX+9+lxts1Q7BXxw9QuQIDAQABo4IBXTCCAVkwCQYDVR0T BAIwADCBrwYDVR0gBIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEa PVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVy aVNpZ24AAAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2 M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2Rh NWMxZTMxNDFiZWFkYjJiZDI5YWZhMTJiZDY4OTFhMTExNDk5OGExYmE0M2Y0ZTY5MTY1NDEwDQYJ KoZIhvcNAQEEBQADgYEAUXbKrrDI9DdxdSL9W4pMtNBTZpFV9yMkBkiKdSOwdjmSh3/qPl11P/HM KDT9CtIXpeT0JcUlkZsXaGkLGZnVWHvsqjUyvqT6XOCy1Vm1VokROmbfFItKacbTwoQsArhISOYB DdUOwpZiD/HEdCTnTb4r6bC3MZ+6afsCn0zi//sxggE6MIIBNgIBATB2MGIxETAPBgNVBAcTCElu dGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3Mg MSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcgIQKRfchGtn9SOrzYSTjGBxoDAJBgUrDgMCGgUA oF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTgwMTE1MTA0NzA1 WjAjBgkqhkiG9w0BCQQxFgQUrrthrNSxMvwiyYLSSUH6acAPqpEwDQYJKoZIhvcNAQEBBQAEQE6I zXp6u1NbSsff5UgVXX1+bpUvS4xSpFDLD+oj/bedH6DlFLW8bThJr3KsrHVzjgNMWzVcclQfPbbJ TCh5S2AAAAAAAAA= ------=_NextPart_000_0070_01BD21A2.EB910410-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 18 06:52:59 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA05762 for ipng-dist; Sun, 18 Jan 1998 06:49:33 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA05755 for ; Sun, 18 Jan 1998 06:49:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA02481 for ; Sun, 18 Jan 1998 06:49:17 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id GAA29970 for ; Sun, 18 Jan 1998 06:49:58 -0800 (PST) From: Margaret Wasserman To: ipng@sunroof.eng.sun.com Subject: (IPng 5146) ND Division Date: Sun, 18 Jan 98 09:49:17 -0500 Message-ID: <9801180949.aa04997@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As assigned at the December IPng meeting in D.C., I have written up a proposal for separating Neighbor Discovery into discrete pieces. It was published last week as the following Internet Draft. Margaret Title : Division of IPv6 Neighbor Discovery Into Separable Mechanisms Author(s) : M. Wasserman Filename : draft-wasserman-ipv6-nd-division-00.txt Pages : 11 Date : 14-Jan-98 This memo proposes a formal division of the existing IPv6 Neighbor Discovery protocol into eight separable, related mechanisms: Address Resolution, Duplicate Address Detection (DAD), Router Discovery, Prefix/Parameter Discovery, Address Autoconfiguration, Router Unreachability Detection (RUD), Neighbor Unreachability Detection (NUD) and ICMPv6 Redirects. These mechanisms all depend upon a common set of ICMPv6 Neighbor Discovery messages, but can be enabled and disabled independently, subject to the restrictions and recommendations outlined in this draft. It is not the intention of this memo to propose substantive changes to the existing IPv6 Neighbor Discovery protocol, but to allow the separate portions of IPv6 Neighbor Discovery to be unambiguously identified, making it possible to specify or configure different portions of IPv6 Neighbor Discovery for use on specific link-types, links or interfaces. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 19 10:01:44 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA06428 for ipng-dist; Mon, 19 Jan 1998 09:54:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA06421 for ; Mon, 19 Jan 1998 09:54:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA21568 for ; Mon, 19 Jan 1998 09:54:34 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA10054 for ; Mon, 19 Jan 1998 09:55:13 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA19629; Mon, 19 Jan 1998 12:54:28 -0500 (EST) Message-Id: <199801191754.MAA19629@ns.ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 5147) Last Call: IP Header Compression to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Mon, 19 Jan 1998 12:54:28 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider IP Header Compression as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 2, 1998. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 19 10:45:56 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA06568 for ipng-dist; Mon, 19 Jan 1998 10:38:08 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA06561 for ; Mon, 19 Jan 1998 10:37:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA28893 for ; Mon, 19 Jan 1998 10:37:52 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA00486 for ; Mon, 19 Jan 1998 10:38:33 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA20466; Mon, 19 Jan 1998 13:37:49 -0500 (EST) Message-Id: <199801191837.NAA20466@ns.ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 5148) Last Call: Management Information Base for IP Version 6: Textual Conventions and General Group to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Mon, 19 Jan 1998 13:37:49 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider publication of the following Internet-Drafts: o Management Information Base for IP Version 6: Textual Conventions and General Group as a Proposed Standard. o Management Information Base for IP Version 6: ICMPv6 Group as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 2, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-mib-03.txt ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-icmp-mib-02.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 21 17:09:34 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id RAA08815 for ipng-dist; Wed, 21 Jan 1998 17:02:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id RAA08808 for ; Wed, 21 Jan 1998 17:02:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA08189 for ; Wed, 21 Jan 1998 17:02:11 -0800 Received: from sleepless.com ([199.248.228.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id RAA26765 for ; Wed, 21 Jan 1998 17:02:52 -0800 (PST) Received: from moon.sleepless.com (moon.sleepless.com [199.248.228.8]) by sleepless.com (8.8.5/8.8.5) with ESMTP id RAA23222 for ; Wed, 21 Jan 1998 17:51:36 -0700 Received: from moon.sleepless.com (localhost [127.0.0.1]) by moon.sleepless.com (8.7.6/8.7.3) with ESMTP id RAA15102 for ; Wed, 21 Jan 1998 17:59:35 -0700 Message-Id: <199801220059.RAA15102@moon.sleepless.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5150) URL-based socket addressing? Date: Wed, 21 Jan 1998 17:59:35 -0700 From: Bryan Ford Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd like to throw out and get feedback on an idea I've been toying with for a while - I'm posting to this list because the idea is related to the Berkeley sockets API and similar APIs, and in particular to the practical protocol-independence issues this group has been dealing with for the IPv4-to-IPv6 transition. However, I don't expect the idea to have direct impact on the work being done here, so please don't interpret this as a "proposal" for this particular group. Forgive me if something like this has already been suggested umpteen times and has been beaten to death - I've searched through the mailing list archives, but certainly not exhaustively. If this is old news, let me know and I'll shut up. :-) Anyway, it seems fairly clear that a lot of typical Internet-based applications are not very protocol-specific by nature, but are made protocol-specific mainly because of the API through which they access the protocol stack. A typical client app just wants to open a stream to a remote server given a host name and perhaps a port number, supplied by the user or a configuration database of some kind, and start talking - but the sockets API forces the application to do a gethostbyname() (or whatever its IPv6-friendly, MT-safe replacement turns out to be), and feed the resulting address to connect(), making it dependent on the sockaddr_in[6] structure. If the sockets API had provided a connect()-like function that just takes a hostname in the first place, then probably half of the client apps that currently need to be updated to support IPv6 would instead "just work." Things get a little more hairy when the protocol itself involves passing references to TCP or UDP ports in streams or messages - FTP being the canonical example; but even then, the problem is not that the protocol itself really cares about how hosts and ports are addressed, but that some method was needed, no standard existed, and the obvious solution was just to pass along the addresses that the sockets API provided - which happen to be protocol-specific. CORBA tries to get around this problem using "Interoperable Object References" (IORs), but no one but CORBA uses them. Anyway, I assume this is all old news. It seems what is needed is simply some kind of "higher-level" form of addressing that applications can use to achieve true protocol-independence. Surprise surprise, we already have such a beast, known as the URL, and it's already so ubiquitous it even appears on TV commercials. :-) The problem is that it is only used at the application/user interface and not at the OS/application interface. But it seems it could work just as well for the latter, with very little additional complexity in the OS, and probably reduced complexity for many applications since they wouldn't have to deal directly with the resolver and IP addresses and such. To use the Berkeley sockets API as a concrete example, suppose an additional "address family" was added to the API, e.g., AF_URL. All addresses in this family supplied to connect() and the like would be variable-length URLs; some common forms might be: "TCP:hostname:port" - TCP stream to a DNS-named host and port "TCP:123.45.67.89:port" - TCP stream to an IPv4 address and port "TCP:ipv6-addr:port" - not sure what to do with the colons... "TCP::port" - for bind(), acts like INADDR_ANY "TCP:" - for bind(), acts like INADDR_ANY, port 0 "UDP:hostname:port - UDP socket to a DNS-named host and port "hostname:port" - shorthand; defaults to TCP for SOCK_STREAM, or UDP for SOCK_DGRAM ...you get the idea. The OS then takes care of figuring out the exact protocol stack to use and how to parse the address. Applications that don't rely on any of the more exotic features of TCP or UDP could then perhaps even be made to run obliviously on other stream- or datagram-based transports that the OS supports (IPX, OSI, etc.). In fact, this hypothetical "TCP:" URL scheme would appear to be almost equivalent to the existing "TELNET:" scheme, except that there would be no default port number, and it would imply a raw 8-bit stream without any of the TELNET escape codes and such. In both cases, the URL is specifying an interactive stream-oriented connection endpoint - this may not be the most common type of object for URLs to refer to, but it has precedent. In typical Unix implementations this URL-based "address family" would probably be implemented purely in the C library and would never even touch the kernel. In fact this would probably be necessary given typical userland DNS resolver implementations, since AF_URL would use DNS as part of the URL translation process and therefore must be above the DNS level. (I can already hear grumbling about needing user-space wrappers around sockets API syscalls; at the moment I'm just trying to get the idea in some semi-concrete form, and not worry about the particular API...) SSL/TLS and similar transport-level "stream tunneling" protocols could be invoked transparently to the applications using them, simply by chaining URLs together according to the set of protocols desired. For example, configure a "naive" AF_URL-based server to bind() and listen() on the following URL: "SSL::TCP:localhost:" and then clients connect to it through a similar URL: "SSL::TCP::" In both cases, the could be used, by some appropriate syntax, to specify which ciphers are allowable and such. Of course, this will not address situations in which the application itself by nature needs to be security-aware, e.g., so the server can apply different permissions to different files depending on the session's crypto parameters. Nevertheless, it would be very useful to be able to use SSL and similar protocols in a truly "lego-block" fashion like this - to be able to "wrap" strong security or similar services around an arbitrary application merely by changing its configuration parameters. Supposing the kind of Unix implementation suggested above, where AF_URL is implemented in the C library or some other user-space library, dynamic libraries could be used to handle nontrivial URL schemes (e.g., when the Cl ibrary sees "SSL:", it loads "liburlsock_ssl.so"), making the system easily extensible without cluttering the C library. If applications were to use this high-level addressing scheme wherever possible, it should also help alleviate other problems that have been discussed on this list, such as the problem of IP address changes disrupting long-running applications that only look up a server's address once and then naively try to re-connect to the same IP address if the connection fails. If the application never sees the IP address in the first place, the OS can consistently do the right thing. NB: I'm not suggesting that kernels or C libraries or other protocol stack implementations should know anything about HTTP, FTP, or any of the other existing application-level URL schemes. I'm only suggesting the idea of using URL _syntax_ to provide flexible, protocol-independent socket naming to applications, in the same way that URLs already provide flexible, protocol-independent document/object naming to users. And I don't really care exactly where and how it shows up in the OS's API. Also, even if this idea seems worth exploring further, I realize that it is not likely to (and probably should not) affect the work this WG is already engaged in - I'm bringing it up here because of its close relationship to the Berkeley sockets API extension work and the whole protocol independence issue. Support for something like an AF_URL would not in any way eliminate the need for AF_INET or AF_INET6 - it would only provide a way in which many "typical" applications could be made truly protocol-independent; plenty of applications would remain that need specific knowledge of IPv4/IPv6 addresses and such and would need to use the lower-level primitives directly. Anyway, let me know what you think - or if there is a more appropriate place for discussing this. Thanks! Bryan Ford Sleepless Software -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 23 07:01:56 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA10192 for ipng-dist; Fri, 23 Jan 1998 06:52:28 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA10185 for ; Fri, 23 Jan 1998 06:52:15 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA09162 for ; Fri, 23 Jan 1998 06:52:09 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA24079 for ; Fri, 23 Jan 1998 06:52:53 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA00726; Fri, 23 Jan 1998 09:52:07 -0500 (EST) Message-Id: <199801231452.JAA00726@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5151) I-D ACTION:draft-ietf-ipngwg-aaaa-02.txt Date: Fri, 23 Jan 1998 09:52:07 -0500 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 : DNS Extensions to support IP version 6 Author(s) : C. Huitema, S. Thomson Filename : draft-ietf-ipngwg-aaaa-02.txt Pages : 9 Date : 19-Jan-98 This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. 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-aaaa-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-aaaa-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-aaaa-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19980123093237.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-aaaa-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-aaaa-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980123093237.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 26 06:25:42 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA12287 for ipng-dist; Mon, 26 Jan 1998 06:15:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA12280 for ; Mon, 26 Jan 1998 06:14:37 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA21572 for ; Mon, 26 Jan 1998 06:14:32 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA12533 for ; Mon, 26 Jan 1998 06:15:09 -0800 (PST) Received: from wasted.zk3.dec.com (abelia.zk3.dec.com [16.140.64.63]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id JAA03674 for ; Mon, 26 Jan 1998 09:06:36 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA23043; Mon, 26 Jan 1998 09:06:33 -0500 Message-Id: <199801261406.AA23043@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5153) IGMP Spec Needed Folks and IPv6 Multicast Routing Date: Mon, 26 Jan 1998 09:06:33 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve/Bob, Can we get a draft of the new IGMP spec please. We need this for implementation. ALso can you point us to what group is concerned about IPv6 Multicast Routing and give us in the WG an update as to what the strategy is to get a spec for this component? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 26 11:34:05 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA12735 for ipng-dist; Mon, 26 Jan 1998 11:25:16 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id LAA12725 for ; Mon, 26 Jan 1998 11:25:06 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA08363 for ; Mon, 26 Jan 1998 11:24:25 -0800 Received: from srvwww.sirti.it ([194.243.146.3]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA01126 for ; Mon, 26 Jan 1998 11:23:38 -0800 Received: by srvwww.sirti.it(Lotus SMTP MTA v1.06 (346.4 3-18-1997)) id C1256598.005D7652 ; Mon, 26 Jan 1998 18:00:51 +0200 X-Lotus-FromDomain: SIRTI From: "Laura Castagna" To: ipng@sunroof.eng.sun.com Message-ID: <41256598.005AD3B2.00@srvwww.sirti.it> Date: Mon, 26 Jan 1998 18:01:43 +0200 Subject: (IPng 5155) IP over SONET/SDH Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I need some information about the possibility to support IP directly over SDH, without passing through ATM. Have you some titles of articles and other references for helping me? Thanks in advance Laura Castagna E-mail L.Castagna@sirti.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 28 07:21:41 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id HAA15442 for ipng-dist; Wed, 28 Jan 1998 07:16:22 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id HAA15435 for ; Wed, 28 Jan 1998 07:16:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA25194 for ; Wed, 28 Jan 1998 07:16:06 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA27356 for ; Wed, 28 Jan 1998 07:16:53 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA29880; Wed, 28 Jan 1998 10:16:00 -0500 (EST) Message-Id: <199801281516.KAA29880@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5158) I-D ACTION:draft-ietf-ipngwg-unicast-aggr-03.txt Date: Wed, 28 Jan 1998 10:16:00 -0500 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 : An IPv6 Aggregatable Global Unicast Address Format Author(s) : B. Hinden, M. O'Dell, S. Deering Filename : draft-ietf-ipngwg-unicast-aggr-03.txt Pages : 11 Date : 27-Jan-98 This document defines an IPv6 aggregatable global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [IPV6] and the ''IPv6 Addressing Architecture'' [ARCH]. It is designed to facilitate scalable Internet routing. This documented replaces RFC 2073, ''An IPv6 Provider-Based Unicast Address Format''. RFC 2073 will become historic. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-unicast-aggr-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicast-aggr-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-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. 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: <19980127160947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-unicast-aggr-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980127160948.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 28 07:21:39 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id HAA15397 for ipng-dist; Wed, 28 Jan 1998 07:11:47 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id HAA15390 for ; Wed, 28 Jan 1998 07:11:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA23759 for ; Wed, 28 Jan 1998 07:11:29 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA25350 for ; Wed, 28 Jan 1998 07:12:15 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA29665; Wed, 28 Jan 1998 10:11:23 -0500 (EST) Message-Id: <199801281511.KAA29665@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5157) I-D ACTION:draft-ietf-ipngwg-bsd-frag-01.txt Date: Wed, 28 Jan 1998 10:11:23 -0500 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 : Forcing Fragmentation to Network MTU Author(s) : M. Andrews Filename : draft-ietf-ipngwg-bsd-frag-01.txt Pages : 3 Date : 27-Jan-98 There exists a class of applications which cannot accept Path MTU discovery [RFC-1981]. This is recommended to be turned on by default for IPv6 [IPV6-SPEC-V2, 4.5, 5]. This document describes an extension to the BSD API [RFC-2133] to inform the kernel when it should be fragmenting at the network MTU rather than trying to discover the path MTU. Path MTU discovery works well when there is a stream of data. However for distributed servers sending small answers larger than the network MTU to many clients the lack of fragmentation in intermediate nodes is anathema. RFC-1981 Section 5.6 recommends that a system utility be provided to: - Specify that Path MTU Discovery not be done on a given path. - Change the PMTU value associated with a given path. This documents specifies how to do the same at the application level to a individual socket. Internet-Drafts are available by anonymous FTP. Login wih 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-frag-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-bsd-frag-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-bsd-frag-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. 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: <19980127140310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-frag-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-frag-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980127140310.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 30 06:45:23 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA18611 for ipng-dist; Fri, 30 Jan 1998 06:40:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA18604 for ; Fri, 30 Jan 1998 06:39:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA28888 for ; Fri, 30 Jan 1998 06:39:56 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA01581 for ; Fri, 30 Jan 1998 06:39:56 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA11731; Fri, 30 Jan 1998 09:39:52 -0500 (EST) Message-Id: <199801301439.JAA11731@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5160) I-D ACTION:draft-ietf-ipngwg-addr-arch-v2-06.txt Date: Fri, 30 Jan 1998 09:39:51 -0500 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 : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v2-06.txt Pages : 25 Date : 28-Jan-98 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. 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-addr-arch-v2-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-addr-arch-v2-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v2-06.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980128134308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v2-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v2-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980128134308.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 30 07:54:41 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id HAA18667 for ipng-dist; Fri, 30 Jan 1998 07:50:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id HAA18660 for ; Fri, 30 Jan 1998 07:50:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA20446 for ; Fri, 30 Jan 1998 07:50:23 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA03628 for ; Fri, 30 Jan 1998 07:50:22 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA14315; Fri, 30 Jan 1998 10:50:18 -0500 (EST) Message-Id: <199801301550.KAA14315@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5161) I-D ACTION:draft-ietf-ipngwg-ipv6-over-ppp-05.txt Date: Fri, 30 Jan 1998 10:50:18 -0500 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 : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-ipv6-over-ppp-05.txt Pages : 13 Date : 29-Jan-98 The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-over-ppp-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19980130095246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-over-ppp-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980130095246.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------